Hacker News new | comments | show | ask | jobs | submit login
Ask HN: What do you want to see in Debian 10 (“buster”)?
352 points by lamby 126 days ago | hide | past | web | 317 comments | favorite
Hey,

Chris Lamb here, Debian Project Leader. As a bit of background, I've been around the "startup" scene on and off, even participating in YCombinator during S12. I have a few side projects here and there and I also do a lot of full-stack web development using Python/Django.

I'm very much interested in soliciting your feedback and feature requests for the Debian 10 ("buster") development cycle which opens up tomorrow after the release of "stretch" today. This is obviously a shameless appropriation of Ubuntu's post a few months ago and some requests would definitely overlap but I feel we could get some interesting replies nonetheless.

Please include in your replies the following bullets:

- HEADLINE: 1-line description of the request

- DESCRIPTION: A lengthier description of the feature. Bonus points for constructive criticism...

- DISTRIBUTION: (Optional) [stable, testing, unstable, or even a Debian deriviative]

- ROLE/AFFILIATION: (Optional, your job role and affiliation)

We would be exteremely interested in your feedback! Everything is fair game -- kernel, security, community, default settings, architectures, init systems (!), desktop, Docker, documentation, default packages, cloud images, etc. etc.. Feel free to comment even if you are using a Debian derivative such as Ubuntu, Mint, etc. too.

Thanks, HN!

—lamby

https://twitter.com/lolamby




HEADLINE: Easier way to create local packages

DESCRIPTION: My first distro was Debian. Then, for a while, I used Arch. But it kept irritating me with its total disregard for backwards-compatibility (symlinking /usr/bin/python to python3), coarse-grained packages (want to install QEMU PPC without pulling in every other architecture as well? too bad!), lack of debug packages (good luck rebuilding WebKit just to get stack traces after a SIGSEGV), and package versioning ignoring ABI incompatibilities (I once managed to disable the package manager by upgrading it without also upgrading its dependencies... and later cut off WiFi in a similar manner). So, when I finally trashed my root partition a few weeks ago, I decided to use the opportunity to return to Debian.

One thing I miss from Arch, though, is having an easy way to create a package. It's simply a matter of reading one manpage, writing a shellscript with package metadata in variables and two-to-four functions (to patch up the unpacked source, check the version, build it, and finally create a tarball), and then running `makepkg`. And it will just download the source code, check signatures, patch it, and build it in one step; it even supports downloading and building packages straight from the development repository. I took advantage of it to create locally-patched versions of some software I use, while keeping it up to date and still under the package manager's control.

Contrast that with creating a .deb, where doing the equivalent seems to require invoking several different utilities (uscan, dch, debuild; though ) and keeping track of separate files like debian/control, debian/changelog, debian/rules and whatever else. All the tooling around building packages seems oriented towards distro maintainers rather than users. I'd love something that would relieve me of at least some of the burden of creating a local package from scratch.

DISTRIBUTION: unstable, I guess


I will +1 this. I generally end up copying a bunch of the required control files from another project and using a higher level script which creates the deb for me via black magic. I would love to understand the process more, but the depth of knowledge required to grok the process from end-to-end is well beyond the time I can commit to it.

On a related note, the way that repos can only be secured as a whole (and require each package to effectively be present when creating the signature) makes adding a single authenticated package to an existing repo much harder than it needs to be.


Creating your own packages with Debian tools is easier now than ever. Unfortunately, the documentation may be lagging a bit and will also focus of making state-of-the-art packages.

Last year, I have written some examples on how to do simple packages while still leveraging Debian tools: https://vincent.bernat.im/en/blog/2016-pragmatic-debian-pack...

Also, automatic package generation for many languages already providing package management (Python, Ruby, Java, Go, ...) is already a reality but you have a different tool for each. The topic comes back regularly but until now, we don't have a generic tool for that. The last attempt was debdry but it isn't maintained anymore.


Yes, I think documentation is part of the problem. When I was a heavy Debian user several years ago I tried to create my own packages but failed. The problem was that the documentation was too numerous to find anything, especially the current way to build packages. Every single resource I tried had 2-3 different ways to build packages and it was difficult|impossible to tell which one was the "recommended" way. I ended up not creating any packages and moving on to another distro. :(


If there is no documentation, the feature doesn't exist. If the documentation is misleading or outdated, it's even worse — like a productivity sabotage, stealing many work hours from your fellow developers (looking at you, Docker).

I understand that expecting something from free and open source software beyond bare necessities can sound like being entitled. And yet, I believe that documentation is not optional. Software with better documentation wins. All the time.


Jeebus, my old chap from the old times of fr.comp.os.linux.* actually lurks HN, my that brings memories back :)

Sorry for this completely irrelevant interruption :)



All the learning and process needed to create Debian packages has been a big motivator for us to make snap packaging simple and quick. Have a look at the Heroku CLI snap, for example: https://github.com/heroku/cli/blob/master/snap/snapcraft.yam...

You can quickly piece together a snapcraft.yaml, push it to GitHub, and turn on auto builds and publication (https://build.snapcraft.io). Then anyone can install your package with a single command - no PPA/repo needed.


Maybe snaps can fill this role, I understand they are easier to create.


They're certainly easier to create than debs. For many applications a single yaml file is all that's needed. Snapcraft can use whatever build system the app needs, and produce a snap which can be locally installed, shared privately or more widely via the snap store. I made a short video about it. https://www.youtube.com/watch?v=DLxqdf89hRo


Look into the equivs package: https://packages.debian.org/stretch/equivs. It's intended mostly for making metapackages, but you can include files as well.


This (and checkinstall) are stopgaps, ideally the .deb creation process would get an entirely new packaging toolchain, with the minimal arguments: dependencies, build-dependencies, sourcefile/url/repo, buildcommands.

Then a linter could tell you that a changelog.Debian.gz, man-pages and debtags are still missing, but for internal redistribution that is enough for now.

And can failed build commands continue from where they were interrupted? Always cleaning everything is terrible for iterative exploration of the package creation process. The final package should be marked as tainted of course, but always starting a minute long compile process should be skippable.


If you just want to pack up a bunch of config files, I can shamelessly plug my own https://github.com/holocm/holo-build


How about checkinstall for making a quick and dirty package? :P


I've had very bad experience with checkinstall.

The idea seems perfectly sound, but the implementation needs a lot of work. The UI needs to be better (e.g. saving your answers to the questions about title, author, etc.) And there are also some straight up bugs. It has crashed for me many times. And not even for a sketchy program- I'm talking like llvm.


Hmm, I usually use checkinstall for that and it worked rather decently for building quick-and-dirty .DEB packages used locally. Did you try it yet?


Re Easier way to create local packages, you can use dh-make[1] to populate the packaging with some templates that might make your job a bit easier :)

[1] https://packages.debian.org/en/sid/dh-make


Really +1. There are some programs I work on that I wanted to package for debian, but after a full day of no progress I gave up and threw my hands in the air.


- HEADLINE: Simplify contributing to Debian.

- DESCRIPTION: TL;DR: Debian's web pages are hard to navigate and use and it's very hard to see what's happening.

I contribute to FOSS projects whenever I have time and have been wanting to contribute to Debian, but the difficulty is offputting. I'm used to searching for the program name and arriving at a portal page from which I can easily browse the source, see the current problems and instantly start interacting with the community. Unfortunately, contributing to Debian seems to require in-depth knowledge about many systems and arcane email commands. As a would-be contributor this completely alienates me.

One reason is that Debian has many independent services: lintian, mailing lists, manpages (which btw are fantastic and give me hope), Wiki, CI, alioth, the package listing, BTS, etc. To contribute, you need to learn most of them and For example, searching a package name gives me a page at packages.debian.org, but it's very hard to navigate or even discover the other services from there. I can't easily see if there are any lintian issues, critical bugs or current discussions. Additionally, I find most of the systems very hard to use (I still can't figure out the mailing list archives). Ideally, these services would be more tightly integrated.

Another big reason Debian is very hard to contribute to is the main discussion takes place via mailing lists. I understand that many people enjoy working with them, but for light usage they are a big pain. Submitting and history are in completely different programs, there seems to be no real threading, volume is often high and reading large amounts of emails is a chore to me. A solution here would be an improved mailing list archive with options for replying directly integrated to the site.

- DISTRIBUTION: unstable

- ROLE/AFFILIATION: Student


Generally I agree with most of the submissions, but this one is the most important.

I really love debian because of its principles (and I would love to contribute), but I feel that new contributors (like me) have problems because of the many (and some old) tools and outdated and non-friendly documentation.

Also, I don't know how many contributors come and stay, but even in unstable I see some outdated packages in weeks, and also some useful software that is not packaged.


As a parallel, one of the reasons Slack has won in the paid-chat stakes is because of it's buttery-smooth onboarding process. The chat client isn't anything special, really, but it's just so easy to get set up and running.

The difficulty gradient of onboarding is a significant contributor to attracting folks.


Ditto. In the last 2 years I actually switched to Fedora because of the clearer and easier road to contribution. (Area: design)


Not banning people behind a VPN would make the Debian wiki useful to me (it's just a static site!).


Send a mail to the contact link in wiki, I'm sure they'll help.


HEADLINE: Consolidation of Documentation; Removal of Outdated Documentation

DESCRIPTION: Any time you do a web search for anything regarding Debian, the search results include a huge amount of official but outdated information. Normally for Linux-related questions I refer to the amazing Arch wiki, but there are topics that are Debian-specific, and then sifting through all the detritus is a huge waste of time. There's a wiki, a kernel handbook, a manual, random xyz.debian.org pages, mailing lists, user forums, the Debian Administrator's Handbook...

Granted, it's a huge effort to clean all of that up, but perhaps there's a way to incorporate user feedback, so that pages can be marked as "outdated" by users, or updated by users (wait, there's a log-in page- does this mean I can edit wiki pages? Did not know that...:( ), or otherwise made more systematic.

In particular, it would be great to have more complete information on the installation process: which images to use (RC, ..., or weekly image?), how to put them on a USB stick (why does my 32GB stick now say it has 128GB?; you mean I can just copy the files to a FAT32-formatted drive?), what the options are (for hostname, is any name, a FQDN necessary?), etc. For every single clarification, there will be a hundred, thousand, ten thousand people who are helped; that seems like a worthwhile investment. Everyone is a beginner at the beginning, regardless of knowledge outside this specific domain, so why not make it easier.

All that said, have been using Stretch/testing for a few years, love it, love the Free/Libre Software ethos, love what you guys do, keep it up, thank you!


Seconded.

One often has to rely on stackoverflow (and the likes) to get info because the doc/wiki is outdated.

That being said, the info provided on theses websites aren't necessarily correct.

There is for instance no clear, up-to-date, doc on how to install some packages from testing and keep them updated (pinning ? no pinning ? what values ? what sources ?)


Hear, hear. The site is generally an excellent resource but I've also come across reams of outdated guides which steered me wrong, and worse, have sometimes left my system in an indefinite state because I only realized halfway through that this guide is no longer relevant. Cleaning this stuff up should be a priority.


This! As I see it a major problem not only with Debian but Linux over all is the amount of outdated documentation. At least some people will when they don't find what they're looking for on the Debian wiki google for it and might end up with at best solutions that are old and outdated, or at worst solutions that are all wrong these days and might leave their system wide open.


HEADLINE: Repurpose testing as a rolling release positioned for not-just-testing usage

DESCRIPTION:

There are users who'd like to use a non-corporate community distro but who don't need or want software to be as old as software in Debian stable. The standard answer is "use testing" (e.g. http://ral-arturo.org/2017/05/11/debian-myths.html), but 1) security support for testing is documented to be slower than for stable and unstable (https://www.debian.org/doc/manuals/securing-debian-howto/ch1...) and 2) the name is suggestive of it being for testing only.

Please 1) provide timely security support for testing and 2) rename testing to something with a positive connotation that doesn't suggest it's for testing only. I suggest "fresh" to use the LibreOffice channel naming.

DISTRIBUTION: testing

ROLE: Upstream browser developer. (Not speaking on behalf of affiliation.)


    > rename testing to something with a positive
    > connotation that doesn't suggest it's for
    > testing only.
Isn't unstable what you want to use?

The reason it's called "testing" is because it's a branch of Debian that's "in testing for stable". IIRC packages have to be 2 weeks in unstable without bugs before migrating to testing.

So it's explicitly not a bleeding edge release, but a preparation release for the next stable, which is why testing since late-2016 or so hasn't been getting any new major releases, it's been undergoing release prep.

Maybe there should be a sixth branch of Debian between unstable and testing that doesn't slow down the migration of packages bug-free for 2 weeks from unstable around release, but that seems like a lot of maintenance burden to impose on Debian.


I always run "testing" because every time I try to run "stable" on the desktop I always end up with an outdated package that limits me one way or an other. A missing driver, missing functionality etc...

On the other hand "unstable" is way too unstable when you need a reliable environment in my experience. Packages breaking randomly etc... Completely expected of course, but I can't take that bet on a work computer for instance.

So as far as I'm concerned on the desktop "debian testing" is the one true debian. I don't even try to install stable first anymore since I'm certain I'll end up moving to testing eventually, I directly ask the setup to use the testing repos.


On the other hand "unstable" is way too unstable when you need a reliable environment in my experience. Packages breaking randomly etc... Completely expected of course, but I can't take that bet on a work computer for instance.

That's not my experience at all. Which packages have you had breaking randomly?


I've had upgrades break occasionally in unstable too. That's the nature of a rolling release though...

Of course what everyone wants is something with all the advantages of a rolling release but without the disadvantages. Ie, always have the latest version of everything, but without anything breaking in ways that affect me.


At the very least "unstable" has a name with a negative connotation. It has the air of it being the user's fault if you use it and stuff breaks.

I don't know what the practical breakage situation is, so I don't know if renaming and repositioning unstable would make more sense than doing it with testing.

My point is that it would be good for non-expert end users who like Debian's community image and who want security​ support to have a Debian release channel that provides fresher software with security support than stable.


Have you actually tried unstable? Granted, I haven't used it for a few years now (the only Debian boxes I have today are servers running stable), but "unstable" was actually quite reliable. Yes, it did break occasionally (mostly just minor issues with package dependencies) but those were usually easy fixes and "unstable" was actually quite usable as an everyday, desktop Linux.

If you haven't tried it, give it a shot. You may be surprised.


I used a daily-updated unstable for a while, and every so often, like once per 18 months to 2 years or so, I'd hit an early boot (grub/initramfs) bug that rendered my system unbootable. Early boot is dark magic to me, and without internet access (because my system wouldn't boot) it would take me a few hours to fix. By the time I did, someone else had filed an RC bug report which would have prevented that package from upgrading, and it was generally fixed a few hours after that. But that didn't help me fix my broken system.

That was the risk I accepted. That's what unstable is for. And you need somewhere like that to find those bugs.

But that's what you need to be able to handle if you run unstable. So I never recommend it to anyone; if anything I warn people off. If you can't make do with stable+backports, try testing. But don't try unstable unless you know enough about it to understand why you shouldn't, and still want to anyway.

Definitely don't run unstable because someone on the internet told you it was a great way to get up-to-date packages.


I've been running unstable for years, and have had what you mention happen exactly once. If you're on unstable, use apt-listbugs and don't update every day, and _generally_ you'll be fine. Don't use giant DE's like KDE that go through a lot of transitions and you'll be even better off.


No, I haven't used unstable myself.

But "have you spent the time evaluating it?" is beside the point. My point is that it would be positive to have a Debian release channel with fresh software with 1) explicit security support and 2) naming with positive connotations so that fewer people who don't need to use out-of-date "stable" used "stable" because it is the Debian release channel with the most positive-connotation name.

Asking each user individually to go against the framing of negative-connotation naming ("testing", "unstable") to get empirical data of what the actual level of breakage is wasteful. If "unstable" works so well, it shouldn't be called "unstable". Calling it "unstable" but telling people it's the solution to whatever is wrong with "stable" is a set-up for a blame-the-user excuse if something goes wrong.


But what is wrong with stable in the first place ?

What you are asking is basically to switch to a rolling cycle with guaranteed support. This is a huge change and also don't account for the fact that many people choose Debian stable specifically because of it's non-rolling cycle...


> But what is wrong with stable in the first place ?

* It's generally unpleasant for a user to know their problem has been fixed but they don't get access to the fix in a long time.

* Users using old software when they don't need to has network effects that give rise to negative externalities. See my other top-level reply: https://news.ycombinator.com/item?id=14580042

> don't account for the fact that many people choose Debian stable specifically because of it's non-rolling cycle

My suggestion is based on the premise that there are users who choose or would like to choose Debian because of its community distro brand equity and not because Debian stable has old software. Also note that I suggested a change in the framing of testing and didn't suggest stable be dropped.


> At the very least "unstable" has a name with a negative connotation.

Have you tried running `sid`? It sounds like exactly what you're looking for. ;)


Is the concept of a release still important? OpenBSD did away with the CDs for instance, so what is the value of calling a tag for a particular set of packages (versions) a release?

The only time I cared was when I installed from scratch on a new computer (too much hazle to mirror and existing drive and figure out how to switch from bios to efi etc), and last time, stable did not support my hardware, testing and nightly did not work due to being in transit to release. In other words the lack of any suitable installer meant I was forced to use another distribution (Ubuntu).

I have tried both testing and unstable and both broke for me at inconvenient times, usually I was not the first to notice, and with some effort usually able to find a fix or work-around. Stable plus backports work well, although as a rule, you are stuck on old packages unless (at least the way I use it) explicitly upgrade a particular package. It is configuration that I have to manually sync between machines.

Other than varnish (3rd party repo which is going away I believe) I have no issues with automated (i.e apt-cron) updates for many years.

What I would love to see is a rolling release that is non-breaking. If something breaks, roll that particular package back. I don't know what the particular mechanism that would be, but the ticket system (which is a wealth of data) could be an input along with local configuration.

Push upgrades. With stable, security fixes, is a feed, but it would nice if I don't need to jury-rig something myself to minimize my exposure window. With rolling releases, it would be nice to get that faster (or if you prefer delayed by a configurable amount).


A problem would be the security updates. You can't really spend even 'more' people on security updates for a rolling release. The frequency of updates would be too high for this to work.

This is also the reason for only stable (and olstable?) getting security updates. The thing is that if you want to support something, you'll need to scope it. You can't support just any random thing, you'd need an army of maintainers just to do that. So you make a 'release' where that specific version has people watching over it and making sure things are safe and working. Even that process is hard enough as-is.

While it would certainly be nice to have a rolling release, or 'really fast' release, it can only be done if more hours/people/donations are available to fuel it.


Having security support for renamed testing would be more work than now but not the kind of work security support for stable is. Security support for stable involves backporting fixes. For a rolling release it would mean expedited pushes of upstream versions with security fixes in them.


The testing and unstable branches beeing kind of second class citizens is why I eventually jumped ship to OpenSUSE Tumbleweed and Fedora (technically not rolling but things are more up to date) after a long time using the testing branch.


I remember hearing a Debian Developer give a talk where he said that 'testing' can almost be considered a normal rolling distro in its own right, but there are times when it's broken - the example he gave was that at one point the installer itself was broken for a short time.


Have you seen Backports?

https://backports.debian.org/


I have.

From the FAQ (https://backports.debian.org/FAQ/):

"Q: Is there security support for packages from backports.debian.org?"

"A: Unfortunately not. [...]"


HEADER

Python 3 as default

DESCRIPTION

Just to quote from the packaging manual:

> Debian currently supports two Python stacks, one for Python 3 and one for Python 2. The long term goal for Debian is to reduce this to one stack, dropping the Python 2 stack at some time.

The first step for that would be of course Python 3 as default Python version and I'd like to see that for buster, as Python 3 nowadays offers way more features than Python 2 and should be the choice for new Python projects.


Upstream Python specifically recommends against installing Python 3 as /usr/bin/python; see PEP 394 at https://www.python.org/dev/peps/pep-0394/ . Beyond that, many of Debian's python-using packages are already migrating over, and I'd expect the rest to likely migrate in buster.


To quote from the abstract of PEP394:

> * for the time being, all distributions should ensure that python refers to the same target as python2 .

> * however, end users should be aware that python refers to python3 on at least Arch Linux (that change is what prompted the creation of this PEP), so python should be used in the shebang line only for scripts that are source compatible with both Python 2 and 3.

> * in preparation for an eventual change in the default version of Python, Python 2 only scripts should either be updated to be source compatible with Python 3 or else to use python2 in the shebang line.


That's just a recognition of the existence of that particular quirk of Arch, and that people may need to cope with that. It's remarkably painful, in practice, to deal with the one special distribution that makes "#!/usr/bin/python" do the wrong thing. And unfortunately, some other distributions don't have a "python2" or "python3" binary, making it painful to write portable scripts; you can't write "#!/usr/bin/python2" or "#!/usr/bin/python3" and expect it to work on every distribution out there.

As mentioned, Debian is working on migrating scripts to support Python 3, and doing so using /usr/bin/python3 , which already appears in the shebang of a large number of Debian's Python programs.


Arch has had python2 and python3 binaries for a long time. /usr/bin/python2 has been there since at least 2010 https://git.archlinux.org/svntogit/packages.git/commit/trunk...


Yes but not the other distributions. Which makes it difficult to write portable scripts.


But ultimately isn't the first choice for most Python projects to date. So many scripts have python paths expecting python 2 hardcoded and pretty much everything that wants python3 calls python3. I'm firmly against this for compatibility reasons, it breaks too much.


Calling python3 for a python 3 binary is ok

I don't see how older python 2 programs can be supported without updating the hashbang line in a Py3 default system (which is most of the time trivial) - you could also have a dedicated virtualenv for them as well which would work - and which would (looks like to) be an equivalent amount of work as changing the hashbang lines

Switching to default Py3 is a breaking change and that's fine


> Switching to default Py3 is a breaking change

Not only breaking, but also completely unnecessary


Python 2.7 being EOL at a future date means switching to Python 3 is needed


Perhaps then a better solution is just to remove the `/usr/bin/python` symlink, and make scripts be explicit in their dependency list.

It would be a small change (that could be automated) in packages, and removes any confusion about what /usr/bin/python means.


Sounds like a dangerous precedent to start removing symlinks or otherwise not linking to the latest version? Is that just a foil to stand in for proper updates to other scripts and such.

Shouldn't instead scripts be updated either to be compatible with latest python or to specify the version they demand?


even if Guido denounces 2 completely, I'm ready to bet some $$ that 2 will be alive and well long after that date


The "lintian" packaging static-analysis tool has been issuing an info-level message about new packages that introduce Python 2.x packages. I've just upgraded this to a "warning" level, so we should at least curb the influx of additional Python 2 packages unless strictly necessary — I suspect most of them are simply included now out of habit.


HEADLINE: Switch to persistent journald by default

DESCRIPTION: Right now, Debian's default install includes rsyslog, and every message gets logged twice. Once in rsyslog on disk, and once in journald in memory. Let's turn on the persistent journal by default, and demote rsyslog to optional. (People who want syslog-based logging can still trivially install it, such as people in an environment that wants network-based syslogging. But that's not the common case.) This will make it easier to get urgent messages displayed in desktop environments as well.


This, a thousand times this.

Failing that, though, at least change the default rsyslog configuration such that:

* Timestamps are not ambiguous (the default includes no timezone offset)

* Timestamps are higher resolution (milliseconds at least, but preferably microseconds)

* The syslog severity/priority is not discarded (tools which display these files must use disgusting heuristics like searching for "err" to highlight errors)

* Rate limiting is disabled, as rsyslog sees all messages as coming from journald. This means that a misbehaving (chatty) application can cause critical messages from other apps to be dropped. journald does its own (per-source) rate limiting anyway.

* /var/log/syslog is rotated by size as well as time, so a misbehaving program can't easily fill up the partition which contains that file by accident. The current default is 1/day rotation, with no size limit.


HEADLINE: easier, simpler package creation and building

DESCRIPTION: on distros like arch, to a lesser extent void and even gentoo, writing package definition files (PKGBUILDs, ebuilds, templates) is relatively straightforward; in contrast, i don't even know where to start with finding, editing and building debian packages. i think they're built from source packages but beyond that i have no clue. i think visibility of documentation could help here, if not more radical changes to be more similar to the arch/gentoo workflow.


Indeed. Typical scenario, I have software X that can follow such a process:

    tar xfvz foo
    cd foo
    ./configure --prefix aze
    make
    make install DEST_DIR=qsd
I want to package this to save build and deploy time as well as increase reliability. It should be downright trivial to:

    1. find the info explaining me how to do this
    2. understand it
    3. effectively do this
Debian fails even starting with step 1. Even if you manage to go through step 2 with some hair left, step 3 is insane compared to the mentioned alternatives.

This does not even involve step 4 (contributing the package back if it's not for internal use)


I'm totally with this. Simplified build process will help people adopting newer/custom packages into stable releases. Better if a package can be generated from single definition file. Even Redhat has a simpler build system that relies on package "spec" files. The current workflow resembles the one in Redhat, but is more verbose and, well, dirty.


And if you dig down deep you'll find that Debian packages most of the time don't even support the features the manpages claim (e.g. building with debug info or custom CFLAG's)


HEADLINE: Full audit of what's in "standard" and "important"

DESCRIPTION: There have been numerous detailed analyses posted to debian-devel that go through every package in standard and important and list out which ones shouldn't be. However, actual changes have only ever been made here on a point-by-point basis. (I've managed to get a dozen or so packages downgraded to "optional" and out of the default install by filing bugs and convincing the maintainer.) I'd really like to see a systematic review that results in a large number of packages moved to "optional".

This would include downgrading all the libraries that are only there because things depending on them are (no longer something enforced by policy). And among other things, this may also require developing support in the default desktop environment for displaying notifications for urgent log messages, the way the console does for kernel messages. (And the console should do so for urgent non-kernel messages, too.)

DISTRIBUTION: Start with unstable early in the development cycle, so that people can test it out with a d-i install or debootstrap install of unstable.



I'm interested in this - does this mean the size of a default install becomes smaller?

Is there anywhere to read more about this?


HEADLINE: First class ZFS install support on Live CD.

DESCRIPTION: The license conflict between the open source ZFS and open source Linux kernel mean ZFS needs to be in contrib. Unlike a lot of other packages in contrib, ZFS doesn't rely on any non-free software. It just can't be in Debian main because of the conflict of licenses.

However, it would be nice if there was a way to have a more official path to ZFS on root for Debian. The current instructions require a fairly high number of steps in the ZFS On Linux wiki.

The ZFS On Linux wiki also lists a new initramfs file that has to be included so ZFS is supported. It seems odd that Debian couldn't include that as part of initramfs. I realize Debian doesn't want to necessarily promote non-free software, but this is free software that just conflicts with the GPL. It doesn't seem like it should be a second class citizen where you have to manually include files that should already be part of the package.

By the nature of the license conflict, it will be a second class citizen in that it can't be part of the normal installation package and you'll have to compile on the fly. However, it would be nice if there was a mode in the Live CD that could handle ZFS installation rather than doing it all manually.

DISTRIBUTION: currently mixture of testing/unstable but I'd like to use day(s) old sid (see other post).


I would really like to see ZFS make it into the regular install image. Debian already releases an install image with non-free firmware and ZFS is free software. It just has an incompatible license.

The specific issue you mention about creating the initramfs file is actually not necessary in Stretch since this file already exists. There have been other, more significant changes in Stretch as well. (Note: I've contributed to the Debian Jessie ZFS on Root Howto and have followed this guide for numerous systems on both Jessie and Stretch).

1) ZFS has made it into Debian Stretch, so it is no longer necessary to add the backports repository. You just need contrib.

2) The grub-pc package in Stretch provides ZFS support. In contrast, Jessie required installing the package from Testing, and this could cause issues with prior versions of the Howto, as it would often pull Grub's dependencies from Testing as well, blocking installation of among other things, Gnome. The Howto now ensures that dependencies are satisfied from Stable.

3) Since ZFS and grub-pc can be installed from Stable, there's no need to add the /etc/apt/preferences file for pinning priority.


I promised a few people that I would do a fresh ZFS port to FUSE that could be merged into ZoL HEAD. While life has delayed that, I hope to make it a reality this year. It was intended to be a development aid, but I know that there are some internal politics in a few distributions about shipping out of tree kernel modules on install media. I am told that a FUSE port will alleviate the internal politics. I imagine Debian et al integration would improve once that is a reality. Conceptually, it should allow for users to make an easy switch to the kernel modules once the system is installed. Keep your eyes open for that later this year.


Thirded! I've been building out all my Debian boxes with ZFS root (and everywhere) for a year or more. Not only does this require installing via debootstrap, but there are some subtle things that have to be done just so or the system won't boot. Stretch improves this over Jessie, but it's still clearly not a first order citizen.

Like with non-free firmware, and other such things, I get the licensing and taint issues, but it would be good to see this evolve and be supported in the installer, someday, if only on a "forked" installer like with non-free firmware.


Absolutely seconded.

Decent support for ZFS in general, especially during installation already.

Ideally, ZFS root filesystem support (snapshot before upgrade, yay!).

I've been using ZFS for six(?) years now, on both Debian and Ubuntu, and while ZFS root is so important to me that I'm willing to jump through the necessary hoops to install it, it's kinda grating and perhaps riskier. And not for the faint of heart.


- HEADLINE: Not start services by default

- DESCRIPTION: If I installed e.g. postgresql I would prefer it not starting automatically by default. I would rather like a message: If you want x to start on boot, type 'update-rc.d enable x'

- DISTRIBUTION: (Optional) [stable]

- ROLE/AFFILIATION: (software dev, mostly web)


I can't thumbs up this enough. Packages that start services when they are installed can cause so many issues between not giving the user the chance to fully configure them, to weird interactions with distributed applications talking to each other before all the configuration is ready.

This is definitely one of the defaults that I think RPM gets right over debian packages.


This isn't something that is inherent to Debian packaging. So it´s not an RPM/DEB thing at all.

There was a proposal a couple of years back by one Debian member to do pretty much this, and buried somewhere on the Debian WWW sites there is an explanation by that person. Unfortunately, I mislaid the URL and have forgotten who it was.

The essence, however, is to do as Gerrit Pape happens to have done all along with xyr Debian packages. M. Pape split them into daemontools and daemontools-run, runit and runit-run, and so forth. One package installs the softwares and the service definitions. The other package enables+starts/disables+stops the services.

* http://smarden.org/pape/Debian/

* https://lists.debian.org/debian-devel/2012/06/msg00100.html

I do the same with my Debian packages.

* http://jdebp.eu./Softwares/nosh/debian-binary-packages.html#...

* http://jdebp.eu./Softwares/nosh/debian-binary-packages.html#...

The most oft-repeated complaints about the current system are that policy-rc.d requires that administrators have prior knowledge of the internals of a package, to know what services to whitelist/blacklist before installing the package and seeing what services it contains; and that both policy-rc.d and the general body of maintainer scripts in Debian and Ubuntu do not play at all well with systemd's own preset mechanism.


You can configure this behaviour today. Search for "policy-rc.d". IMHO, it's a bug in configuration management tools that they do not arrange this by default.


deb/dpkg/apt is the only one I've seen which does this. All other distributions go for install only.

Starting on install is more intuitive for people new to linux, but it's bad as an overall practice.


I think Debian's rationale is that if a sysadmin interactively installs a package, then that sysadmin does so to get its primary service (if any) running, so packages should arrange this by default.

> but it's bad as an overall practice.

I agree with you, but only in the case of non-interactive use. Different use cases demand different defaults. Tooling should be able to make the appropriate distinction automatically. Currently, the tooling does not, but that (IMHO) is a design flaw in the tooling, which Debian does not produce.

In the interactive case, I'm torn, but I do see the logic.

In the general case, then, I maintain that tooling should use policy-rc.d to adjust the default as necessary, and that failure to do so is in the tooling, not in Debian.


> I think Debian's rationale is that if a sysadmin interactively installs a package, then that sysadmin does so to get its primary service (if any) running, so packages should arrange this by default.

Except that if a sysadmin installs a package that provides a daemon, this daemon usually needs to be configured first, so starting it with semi-broken config (and debconf-generated one is still semi-broken) is counterproductive.


HEADLINE: Better support for non-free firmware during installation

DESCRIPTION: Long-time Debian user here and free software supporter. One aspect where I don't have any practical choice for free software is my non-free iwlwifi firmware.

It's a huge PITA to install Debian like that when you don't have the fallback of a wired network. You provide "non-free" firmware packages, but these don't have the actual firmware! Rather they're dummy *.deb packages that expect to be able to download the firmware from the installer, which is of course a chicken & egg problem for WiFi firmware.

I end up having to "apt install" the relevant package on another Debian system, copy the firmware from /lib manually, copy it to a USB drive, then manually copy it over in the installer.

I understand that the Debian project doesn't want to distribute non-free firmware by default, but it would be great to be able to run a supported official shellscript to create an ISO image that's like the Stretch installer but with selected non-free firmware available on the image.

DISTRIBUTION: Stable on my server, testing on my laptop.


Debian already provides images with non-free firmware: https://cdimage.debian.org/cdimage/unofficial/non-free/cd-in...

I use these when installing on laptops.


These don't work for WiFi drivers as I pointed out because they're not actually the firmware, they're packages to download the firmware. That obviously doesn't work if you don't have a network connection.



I see that I mixed up two of my laptops in my example. You're right, but my general feature request still stands.

Yes the iwlwifi firmware in particular is shipped on the nonfree firmware CD image. But the firmware my other laptop isn't. With the stretch rc5 non-free image mounted:

    $ dpkg -c firmware/firmware-iwlwifi_20161130-3_all.deb|grep -c ucode
    46
But instead of providing the b43 firmware there's only a network installer to fetch it:

    $ ls firmware/*b43*
    firmware/firmware-b43-installer_019-3_all.deb
    firmware/firmware-b43legacy-installer_019-3_all.deb
Looking over the packages more closely now it seems only the b43 package[1] uses this approach (although there might be more firmware that's not included at all).

1. https://wiki.debian.org/bcm43xx#b43_and_b43legacy


Blame Broadcom for that; the b43 firmware may not legally be redistributed, so the only legal option is the fwcutter.


Hence my suggestion that the Debian project distribute a script that I can run to get the firmware myself & trivially build my own install CD, and that this be prominently advertised on debian.org.

The Debian project already ships that sort of script in the current non-free firmware CD, so clearly it's not a legal issue. What it doesn't ship is the ability to run that on another machine as part of preparing an ISO to install on a fresh machine that needs the proprietary firmware.


I upvoted this even though I am of two minds regarding this issue.

Missing wifi support is my number 1 reason why I don't use Debian on the Desktop. On the other hand, I don't like non-free software and like the concept of Debian to not include it.

An alternative could be to put more effort into supporting all wifi hardware by writng free drivers for it. I will post that as my Feature Request.


The drivers are free and already in the kernel. I'm talking about firmware support.

You can still use Debian on the desktop, it has all the WiFi support e.g. Ubuntu has. It's just the installer that doesn't have parity since it's 100% free, working around it is a bit of a hassle as I described, but a one-time pain.


What does "firmware support" mean? Is it not about installing software?


Drivers are software that runs in the kernel to interface with hardware.

Firmware is software that runs on the actual hardware itself, in this case it runs on the microprocessor on the WiFi card


firmware support involves supplying the binary blobs that the driver needs to upload to certain peripherals like intel wireless cards.

personally i would like to see non-free software kept out of the main disc images but the images including firmware being more visibly advertised and it made clear on the download pages what hardware requires it and who needs it.


So the firmware for a certain WiFi card is the same, no matter if you use Linux or Windows of MacOS? And it is provided by the manufacturer of the Hardware?

And some WiFi cards works out of the box with Debian? Is that because the manufacturers of those cards provided the source of their firmware or because open source alternatives have been written by somebody else?


There are a few models that don't need a firmware blob or where the manufacturer provided source code for it (mostly pre ac Atheros chips).


firmware is specific to chipset and are binary blobs supplied by the manufacturer. ath9k-supported and generally realtek cards don't need firmware; theo de raadt noticed the culture difference between american vendors like intel and broadcom who leave the functionality to the firmware so they can be first to market, and chinese vendors like realtek who take their time to best fit customer needs


- HEADLINE: transactional upgrades and package installs

- DESCRIPTION: This is a feature of the guix package manager. From their website:

"Each invocation is actually a transaction: either the specified operation succeeds, or nothing happens. Thus, if the guix package process is terminated during the transaction, or if a power outage occurs during the transaction, then the user’s profile remains in its previous state, and remains usable."

They also do transactional rollbacks, but I'm not sure how realistic that is for the apt package system.


This is impossible. Debian packages are stateful: They have maintainer scripts that can do stuff, they are inherently non-transactional by design.

Even if you can rollback updates, a lot of the time that's no help - your user data format was upgraded, rendering your data useless (especially for web browsers, which you can't really downgrade).

That said, it's trivial to use file system snapshots. Ubuntu has apt-btrfs-snapshot to do this automatically, but it was never provided in Debian AFAICT.

But even with snapshots, you also need to snapshot user state, not just the installation, otherwise you end up with upgraded incompatible data again.


Fedora/RHEL also has transactional package operations via their package-manager, `dnf`.

One of the reasons I'd prefer not to go back to apt-based distros.


What is the point of being "transactional" if it can't even handle the most trivial failure scenario resiliently?

https://lists.fedoraproject.org/archives/list/devel@lists.fe...


Thanks, I didn't know that.

Does Fedora also have transactional rollbacks?


Yep, all installations and upgrades are transactional, and can be undone or rolled-back transactionally


This works for guix because it doesn't follow FHS (if it's like Nix) which I doubt would ever happen in Debian. The alternative is to namespace via the FS.


HEADLINE: enable AppArmor by default

DESCRIPTION: AppArmor improves security by limiting the capabilities of programs. Ubuntu has done this years ago [1]. I'd like to see profiles for web browsers enabled by default.

I think AppArmor is the right choice of default Mandatory Access Control for Debian because Ubuntu and security focused Debian derivatives like Tails [2] and SubgraphOS [3] have already committed to it.

[1]: https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/AppArmorP...

[2]: https://tails.boum.org/contribute/design/application_isolati...

[3]: https://subgraph.com/


AppArmor is like SELinux though: it's annoying so people just turn it off. Most recent example I encountered was on Ubuntu 1604; I wanted to run VMs under QEMU/KVM with libvirt but AppArmor was preventing the VM from using a USB device from the host. Just by chance I took a look at dmesg and saw some audit message about qemu bridge helper.


Yes. This is good one. RHEL by default has active SELinux profile for samba and that's why was not affected by SambaCry. I vote for AppArmour.


https://github.com/subgraph/subgraph_metaproxy

'Metaproxy is not going to work very well with IPv6'


has nothing to do with apparmor.


Why not SELinux?


Because Debian has already done much work on integrating AppArmor [1].

And Debian based distro's like Ubuntu, Tails, and Subgraph also work on AppArmor so choosing AppArmor over SELinux means overall less work for the Debian community.

[1]: https://wiki.debian.org/AppArmor/Progress


SELinux is more secure, flexible and comprehensive, so Debian should adopt it by default... Anyway if AppArmor gets selected by default, I hope I can switch somewhat easily to SELinux if I want to.


- HEADLINE: Easier DEB repository creation.

- DESCRIPTION: Creating a custom remote/local/CD/DVD repo or a partial mirror is simply a nightmare, mainly because package management internals are poorly documented. There are many tools developed to just solve this problem, but most of them aren't actively maintained. Aptly seems like the best right now, but is way much complicated and inflexible.


I agree this is currently a problem, the solutions are currently either too heavy weight, or too limited ( https://wiki.debian.org/DebianRepository/Setup).

What I've been wanting to do is to add a better alternative to the dpkg suite, something that can generate a fully functional repo, matching current standards, something like a dpkg-genrepository or similar (which would supersede dpkg-scanpackages and dpkg-scansources, and perhaps even major parts of mini-dak, which would avoid the need to rewrite it from scratch).


HEADER

100% reproducible packages

DESCRIPTION

While having over 90% of packages reproducible already is awesome, 100% would be even better. The stretch release announcement describes best why:

> Thanks to the Reproducible Builds project, over 90% of the source packages included in Debian 9 will build bit-for-bit identical binary packages. This is an important verification feature which protects users from malicious attempts to tamper with compilers and build networks.


We're working on it, we're working on it! I definitely plan for buster to be 100% reproducible.


They're working on it! I'm sure they'd appreciate your help in getting to 100%.


HEADLINE

Remove openssl1.0

DESCRIPTION

stretch made OpenSSL 1.1 the default openssl package. Unfortunately, OpenSSL 1.0 was kept around, since so many things depended on it.

There should now be enough time that a firm stance can be taken toward not allowing OpenSSL 1.0 in Debian Buster.

Once TLS 1.3 is finalized, OpenSSL 1.2 will be released with TLS 1.3 support. Not supporting TLS 1.3 in buster would (in my opinion) make Debian appear less in other people's eyes. That means supporting OpenSSL 1.2, and having three OpenSSL packages (1.0, 1.1, and 1.2) is too much for one distribution.

DISTRIBUTION

buster


OpenSSL doesn't follow semantic versioning. This is not a simple version upgrade. They knowingly broke the API between 1.0 and 1.1 and it can require substantial changes. They also refused to provide a compatibility shim to make it easier for developers to migrate.

This is not a Debian problem. This is an OpenSSL problem where they forced each upstream program author to make changes in order to upgrade. You'll have to wait for each upstream program author to update.


How would you feel about a switch to one of the forks, such as BoringSSL or LibreSSL?


Sorry, I'm not in support of switching from OpenSSL to BoringSSL or LibreSSL as the default.

On a fairly regular basis, I use alot of the weirder things that I don't think BoringSSL or LibreSSL support.

For example, I was working on iOS profile stuff that called on OpenSSL's S/MIME enveloping functionality to make signed/encrypted profiles.


Android Studio relies on OpenSSL 1.


HEADLINE: a merger of flatpkg and snap

DESCRIPTION: a consensus on the next generation of package management. Please. We have had decades of fragmentation (not to mention duplicated innovation) around the RPM vs DEB ecosystem. Which is why it is still hard for beginners to want to use Linux - try explaining to anyone who comes from a Mac about rpm vs deb vs whatever else. Which is why they would pay for the mac rather than use Linux ("its too hard to install software").

Its not just my opinion - PackageKit (https://www.freedesktop.org/software/PackageKit/pk-intro.htm...) was invented for this reason. So you could have Gnome Software Manager that can work the same on every flavor of Linux. Its time to build this the right way.

You have an opportunity now - but again the camps are getting fragmented. We now have snap (ubuntu/deb) vs flatpkg (redhat) all over again. And pretty strongly divided camps are beginning to form around them. It seems that the new rhetoric is snap for servers and flatpkg for desktops... which absolutely doesnt make sense.

Debian is the place to make this stand - systemd was adopted from fedora despite Ubuntu making a strong push for something else. Debian made Ubuntu adopt systemd. I dont think anyone has anything but respect for that process. Debian 10 must take a stand on this.


I don't think Debian needs to choose. Debian will keep using deb/dpkg as flatpak and snap are not intended to replace a distro's main packaging. They are supplements so users can get newer packages directly from upstream developers. Note that Debian 9 already supports both flatpak [1] and snap [2]. Because of the way snaps/flatpaks are isolated from the rest of the system, they can coexist without issues.

I thought the creators of snaps/flatpaks would be upstream developers, so they themselves will vote on the package management system by using either. There is no duplication of effort here.

Myself I prefer AppImage [3], because of its simplicity and the fact that they are already supported on all Linux distributions, without installing any explicit support.

[1]: https://packages.debian.org/stretch/flatpak

[2]: https://packages.debian.org/stretch/snapd

[3]: http://appimage.org


This is exactly right. Debs, snaps, and flatpaks will happily coexist. The upstream gets to choose which works best for them while still supporting users of all distros.


Just came to add another comment on how bad it was - I just wanted to download pypy for some experiments.

http://pypy.org/download.html

>download PyPy from your release vendor (usually an outdated version): Ubuntu (PPA), Debian, Homebrew, MacPorts, Fedora, Gentoo and Arch are known to package PyPy, with various degrees of being up-to-date.

This is the world of Linux software installation.


> This is the world of Linux software installation.

You don't get to first choose Arch for its different packaging system and then act highly surprised that it's different and adds to the variety of package types. Sorry, no banana here.


> This is the world of Linux software installation.

Homebrew and Macports are OS X, not Linux.


Snapd is actually part of Debian 9 (Stretch), which means that Snap packages are also supported on Debian, as well as Ubuntu, Fedora, SUSE, CentOS, Gentoo, Yocto, Arch, etc.

Flatpak exists for one and only one reason -- because Red Hat, Inc. refuses to work with technology of any kind led by Canonical, period.


> try explaining to anyone who comes from a Mac about rpm vs deb vs whatever else. Which is why they would pay for the mac rather than use Linux ("its too hard to install software").

How does that make any sense whatsoever? You have three different systems to choose from ... and you choose one of them because the other two are different from one another?!


HEADLINE: Keep selected packages up-to-date on stable

DESCRIPTION: If you are using Debian, especially stable, you have to put up with outdated packages. This is especially a problem with browsers, although you do include security updates and track Firefox ESR, if I understand correctly. But things like Webkitgtk do not recieve updates, and lack feature and security wise after a while.

I think keeping up-to-date versions and having a stable distribution is not per se a conflict. Stable means to me no breaking changes, no need for reconfiguration when I update. It shouldn't mean frozen in time.

It would be great if certain packages would recieve frequent updates even in stable:

- packages that are not dependencies, have a good track record of backwards compatibility, and are unlikely to break

- packages that have to be updated because of security issues (which I think is already addressed now)

- or because of a fast moving ecosystem - even if it was safe, it is frustrating to use a very outdated browser component. I think many networked packages could fit in this category, e.g. Bittorrent or Tor clients, if there are protocol changes.

I think the situation has improved a lot (https://blogs.gnome.org/mcatanzaro/2017/06/15/debian-stretch...), and it would be great to have a stable basis in future and still have up-to-date applications on top as far as possible.

DISTRIBUTION: stable (but also others)


I disagree. Stable should mean fixed, except for security bugs. You say "no breaking changes", but the Debian devs can only test the base system, they can't ensure that it won't break whatever software is running on the user's machine. In fact, my system may have a workaround for a bug that shipped with stable, and which might break if the bug is fixed later! Stable is stable, (non-security) bugs and all.

Plus, the point of the pre-release freeze is to make sure the whole system is stable. If you're constantly releasing new versions of packages, you can never guarantee that kind of stability.

Personally, I think people should just try Unstable; it works fine for a desktop/laptop system. I haven't had a major issue in years.


I haven't used Debian in a while, so yes, maybe "stable" is not the right branch for me.

I would have been looking for something that you install once, and then it just works without intervention for a long time. But at the same time I also want to have access to some latest software, without relying on third party repositories (because the chance of breakage is very high) or compiling myself (because then I have to track versions manually).

When I think of a "stable" system, I expect that the underpinning is stable, no structural changes. Don't laugh, but Windows XP was a bit like that for many people. Install it, confirm the occasional update, and it just keeps running for a decade. (Of course, not with the level of security I would expect from a Linux system...) If I really want a frozen version of an app, I can just pin the version or compile it myself.

I think this is a very general problem in the Linux world today, you can choose between "frozen" (stable, LTS) and "unstable" (frequent releases, rolling). There is no "stable underpinning, fresh apps" distribution, although the Linux/glibc undersystem is incredibly backwards compatible. If you compile all the neccessary libraries, you can install almost everything on a distro a few generations old. But it is very odious, and would be great if you didn't have to do it.

Probably you're right and I should give unstable a try next time. Or maybe an alternative would be to make backports more self-contained, so that they would pull in dependent packages (thereby breaking other apps)? Maybe containers like snap etc. are a solution?

[Edit: cut down verbosity]


I think snaps + Debian stable could be that solution. You get the stability of Debian at the system level with the reliability of app updates from snaps.

Bad updates automatically roll back, and you can subscribe to a risk level at a per-application level (https://www.youtube.com/watch?v=-3b9qkl9Z_k).

As well, because snaps bundle their dependencies you don't have that problem you mention of adding a repo and getting busted library versions.


This is supposed to be what backports is for, but it’s very much a volunteer effort. It would definitely be good to see the Debian project commit to supporting a set of leaf packages on a rolling basis in stable. Fragmenting the project in this way might just be too much work for the maintainers though. How many different Debian installs can you realistically support?


I partially agree. In the sense that I would port regression fixes constantly (THIS is important security-wise), I would NOT like to have updates to major releases, as this means breaking-changes and it's against the whole Stable philosophy. GCC 6.4 is going to be released soon and I hope Debian Stable will get all those regression fixes that update will inevitably bring to the table. After my experience with Jessie (which still offers GCC 4.9.2 although version 4.9.4 fixed an impressive list of bugs and it's not even available in the backports), I'm not going to be so optimistic. This is so important it should not be left to the volunteers' will.


HEADLINE: Easy way to use multiple screens with different DPI

DESCRIPTION: Many laptops (e.g. Macbook Pro) come with retina screens, but most of us use 'regular' monitors. Even after setting org.gnome.desktop.interface scaling-factor and playing with xrandr, it can be difficult or impossible to get a single external non-retina display set up in the right position and without one screen containing tiny text (or huge text).

Being able to make it work at all, and persist after a reboot, would be great. Having per-monitor scaling in the Display settings panel (or in 'Arrange Combined Displays') would be amazing.

DISTRIBUTION: I've experienced this with jessie. I haven't tried with stretch.


I to have this issue on my laptop. Gnome​ is the worst offender but definitely not the only. I've found that changing the font size in mate to around 6 to 8 does help.


GNOME supports different dpi per screen just fine under Wayland and 3.24 or newer. The dpi support isn't done yet, they're further improving it so hopefully 3.26 and 3.28 will work better (fractional scaling).


Pssst: since you mentioned mbp, you might know ;)

Is mbp retina supported? All my attempts to get things to look right (using XUbuntu) failed :( Any cheat sheets?


When I'm just using the internal retina screen, all works fine on jessie and stretch, and I don't recall doing anything special to make it work. Perhaps I used gsettings to set gnome scaling to 2 or something.

On jessie, using one external screen results in the problems I described. Using two external screens additionally results in one of the monitors not working at all (even though the same configuration works fine on OSX).


HEADLINE: Provide rolling compiler packages in stable

DESCRIPTION:

There are users who simultaneously want to get their infrastructural packages like compilers from their distro and want to build fresh upstream application releases from source.

This leads to pressure for Linux apps and libraries to be buildable using whatever compiler version(s) that shipped in Debian stable, which amounts to Debian stable inflicting a negative externality on the ecosystem by holding apps and libraries back in terms of what language features they feel they can use.

To avoid this negative externality, please provide the latest release (latest at any point in time, not just at time of Debian stable relase) of gcc, clang, rustc+cargo, etc. as rolling packages in Debian stable alongside the frozen version used for building Debian-shipped packages so that Linux apps and libraries aren't pressured to refrain from adopting new language features as upstream compilers add support.

(Arguably, the users in question should either get their apps from Debian stable or get their compilers from outside Debian stable, too, but the above still seems a relevant concern in practice.)

DISTRIBUTION: stable

ROLE: Upstream browser developer. (Not speaking on behalf of affiliation.)


HEADLINE

First-class init that is not systemd

DESCRIPTION

I believe it's notorious that systemd is highly controversial, even spinning off a fork called Devuan. It might be more favorable to reunite the community by including one alternative init system that is, fundamentally, a first-class citizen in the Debian ecosystem.

"First-class" implies that the user is given a choice on new installations in a specified prompt. The default should be the option "systemd (recommended)".

DISTRIBUTION

buster+1 given the expected effort

ROLE/AFFILIATION

Individual and hobbyist system administrator


Debian is already one of the few distributions that goes out of its way to provide support for non-systemd init systems. Beyond that, it would help if a non-systemd init system as capable as systemd existed; if one did, I'm sure that Debian would include it and support it. This is a case where the problem isn't "please package and support", it's "please develop".


> Debian is already one of the few distributions that goes out of its way to provide support for non-systemd init systems.

How does this manifest itself in practice? I don't want to use systemd in Debian 9, what has been done so I can easily change to another init like runit?

In practice it's not possible because of so many (unecessary) dependencies on systemd.


It means that you can install sysvinit or any sysvinit-compatible init, and all daemon packages still provide init scripts, as painful as that is. And Debian still supports installing systemd-shim instead of systemd, so you can have a desktop system with a non-systemd init and it'll still function.

> In practice it's not possible because of so many (unecessary) dependencies on systemd.

Such as? As far as I can tell, almost nothing depends on systemd. A handful of things depend on libpam-systemd (for session management), which functions with systemd-shim.


The amount of work that goes into Devuan for pulling out systemd of Debian Jessie is clear evidence that what you are saying is not easily possible.


As I understand it, much of that work goes into removing any trace of even innocuous things like libsystemd, which is used by applications that want to support systemd if available. All the necessary work to support a non-systemd init is already in Debian, making Devuan fairly pointless in practice.


That's correct. Debian ships sysvinit as well as systemd and daemons have initscripts/confs for both.

A lot of people still use sysvinit and it just works.


If this is really true, I might have to eat my own words.


Yes, it's true.

To replace PID 1 with sysvinit, run:

  apt-get install sysvinit-core systemd-sysv-
  reboot
To prevent it from coming back, create the file /etc/apt/preferences.d/no-systemd.pref containing:

  Package: systemd-sysv
  Pin: origin *
  Pin-Priority: -1
This works great on servers and lightweight desktops. As others have noted, if you want GNOME you also need to install systemd-shim. I have no experience with this, but I have no reason to doubt that it works.


If you do run into cases where something doesn't work as expected with sysvinit instead of systemd, please do file a bug.

For that matter, if this is a use case you care about, systemd-shim could use a maintainer or maintenance team: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=832508


I'm running openRC on all my systems and the problem is usually dependencies. As an example, both Brasero and K3b depends on something that depends on systemd. I can understand if a program uses the systemd library but these need systemd as pid 1 because reasons.


I would love some type of toggle, or "last chance to turn back" during install as far as being able to signal what type of init system I'd like to use.


The problem is that no-one has incorporated a modification to the Debian installer to have this. There are so-called "preseed" hooks that one can use to manually alter what packages the Debian installer installs. Putting in place pre-seed hooks that permitted something other than systemd to be installed ab initio was one of the first things that the Devuan people did, about two and a half years ago.

But no-one to my knowledge has yet done the work to give the Debian installer this capability without the need for pre-seed hooks, as a menu item/checkbox/question for the administrator to pick/tick/answer. Such work is more than merely writing code, note. It involves testing it too. Thoroughly.

* https://wiki.debian.org/DebianInstaller/Preseed

* https://wiki.debian.org/systemd#Installing_without_systemd

Ironically, this was once a problem the other way around. Attempted changes to enable administrators to select systemd at install time (and indeed upstart, as you can see) failed to make it past a Debian gatekeeper.

* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=668001


Oh man, preseed is a pain in the ass too. I wish they'd support using kickstart files or that there were a kickstart to preseed conversion/migration tool.


What do you dislike about systemd? Do you disagree with the ideas behind it, or is your discontentment more about the specific implementation of those ideas? Can you give examples?


Not the OP, but:

- It's effectively a black box that nobody but the systemd team really understands; and the response by said team to problems with systemd too often defaults to "you're doing it wrong"

- Systemd is not just an init system, it's a message bus, authentication system, logging system, container management system, xinitd system, and any other number of highly coupled systems.

- Service startup order can still be non-deterministic and fairly slow; hard init problems have been made harder, while easy init problems "only" remain easy.

- Unit files can be stored in a minimum of four separate locations on disk, and this can be increased dynamically.

- Failures are opaque, and the failure of systemd triggers the failure of the entire system.

The original idea that drove systemd's creation is still fairly sound: create a simple, deterministic, and parallel init system which is better than initv. The implementation doesn't live up to those goals, and instead of iterating against that goal, the team's focus has shifted to take over all aspects of the Linux runtime which isn't managed by the kernel.


> - It's effectively a black box that nobody but the systemd team really understands; and the response by said team to problems with systemd too often defaults to "you're doing it wrong"

I'm seeing this attitude a lot. Just last week, at our Linux User Group meeting, someone brought in a notebook with Debian 9, which didn't boot up correctly because drives were not detected.

The issue turned out to be really simple (udevd is started after `udevadm trigger`, so device files do not get created), and I advised them to file a bugreport with Debian about this. But it still took over an hour to diagnose because everyone around me was bickering how impossible it was to diagnose anything with systemd, whereas I just looked at `systemd-analyze plot`, `journalctl` and poked around a bit.

So, not something that I would call opaque. It's just that they're not used to it. I never really learned inits before systemd (I knew how to enable and disable services on $distro, but that was about it).


So, the "impossible it was to diagnose anything with systemd" comes about because "systemd-analyze plot" and "journalctl" have no meaning prior to systemd. It's a whole new toolset which needs to be learned.

It doesn't follow any existing patterns, which makes it harder to learn if you're already familiar with troubleshooting init prior to systemd (troubleshooting which would have started with a quick trip to /var/log/dmesg and stopped with /var/log/syslog).

So yes, it can absolutely be learned. But existing administrators have to abandon most of their existing toolkit to do so.

That all said, that's not what I mean by opaque. By opaque, I'm referring to how many (few?) people truly grok what's going on inside of systemd. As an arbitrary point of measure - systemd (and only systemd) consists of over 500,000 lines of C code. It takes a lot of dedication and time to understand what is going on in that much C code. There are, by GitHub stats, less than 10 people who have contributed (combined additions and deletions in commits) to even 1% of the codebase, and only 4 who have touched more than 50%.

In comparison, sysvinit consists of about 9,300 lines, and upstart 115,000.


Doesn't that applies to the kernel, libc, openssl, the X server, desktop environments, and web browsers?


Also, where before one could mark1 eyeball what the bootup was trying to do, and reason fixes from that, now one have to rely on an analyzer to tell what the sequence will be. And if said analyzer can't be used, what then?

And similarly the journal format is something that can only be read with the journalctl tool. plain ascii you can throw just about anything at.


I have to second this. I am a long-time Linux user, having run Debian since the late 90s and Slackware since 1993 but systemd put me over the edge. Things that worked and were easy to figure out in the previous init system just stopped working under systemd. It is a brutally complicated init that didn't add anything to my experience and pushed me out of Debian and into FreeBSD where things still have sane defaults. I like to get my work done instead of messing around with an init system that refuses to let me do even the most basic things.

Not all new things are great and I think Debian made a mistake not supporting a traditional init system alongside systemd or at least until the kinks could be worked out.


Thank you for your response falcolas. Addressing your points:

> "- It's effectively a black box that nobody but the systemd team really understands; and the response by said team to problems with systemd too often defaults to "you're doing it wrong""

Is this because the data being passed around is represented in binary form rather than text form (e.g. binary logs rather than text-based logs)?

> "- Systemd is not just an init system, it's a message bus, authentication system, logging system, container management system, xinitd system, and any other number of highly coupled systems."

Sure, but this doesn't strike me as neccessarily bad. I appreciate the Unix philosophy is based around having a series of tools that serve a single purpose that can be chained together in different ways, but it's still a necessity to have common interfaces over which this chaining takes place. Is this again related to the binary vs. text issue?

> "- Service startup order can still be non-deterministic and fairly slow; hard init problems have been made harder, while easy init problems "only" remain easy."

The non-determinism and speed of start up both strike me as major issues, thank you for mentioning them. Does anyone know if there are there plans to tackle these issues?

> "- Unit files can be stored in a minimum of four separate locations on disk, and this can be increased dynamically."

Again, this also seems like a reasonable complaint. Is this issue due to the intrinsic design of systemd or is this solely a flaw in the implementation?

> "- Failures are opaque, and the failure of systemd triggers the failure of the entire system."

Are there no fallbacks in place should a systemd component fail? I see no reason why this couldn't be implemented.

> "and instead of iterating against that goal, the team's focus has shifted to take over all aspects of the Linux runtime which isn't managed by the kernel."

I don't disagree with that assessment, but there must be reasons why systemd is proving popular amongst distro maintainers. Why would you suggest that is? What advantages do you gain from having a unified layer that provides the services that systemd provides?


> Is this because the data being passed around is represented in binary form rather than text form

None of my complaints relate to binary vs. text. Both have their strengths and weaknesses, and while binary data requires new set of tooling, I intentionally did not mention it because of how contentious it is to even bring up.

> Sure, but this doesn't strike me as neccessarily bad.

It's just not necessary. This all worked before. Not always perfectly, and sometimes even poorly... but it worked. And importantly, it worked without requiring the authentication system, message bus (tied into the kernel), custom logging, and init all to be tied together.

> What advantages do you gain from having a unified layer that provides the services that systemd provides?

Personally? None - no advantages. Consider where I'm coming from - I've run Linux on the desktop and server for years (perhaps even before systemd was a glimmer in Pottering's eye). I've written software which ran on startup (including the sysvinit scripts), done init troubleshooting... and it all just worked.

Without reasonable gains in speed, and without resolving the determinism problem, and given a world in which supervisord, daemontools, and LXC exist... systemd just doesn't bring anything to the table that I've been asking for. Instead, it's brought a whole new toolset I have to now learn, and a ton more complexity and opacity.


beefhash's explicitly stated rationale was reuniting the community. By attempting to derail this into yet another massive thread about the merits/demerits of systemd, rather than a discussion of the desired future and already present capabilities of the Debian installer, and putting words into beefhash´s mouth that xe did not say as you have done here, you are instigating exactly the opposite.

* http://uselessd.darknedgy.net/ProSystemdAntiSystemd/


>"you are instigating exactly the opposite"

Not really.

In order to 'reunite the community' you need to understand what that will take. Every init system that is supported adds an additional support burden onto the developers and maintainers that work on Debian. In order to minimise that work, it's important to understand the issues with the status quo.

At one end of the spectrum, perhaps a few tweaks to systemd would be enough to satisfy most who had issues with it in the past. On the opposite end of the spectrum you have the distro needing to support 5+ init systems if there's little consensus about what a strong alternative to systemd would look like.

The questions I asked previously are useful in understanding how much work would be required to 'reunite the community'. Feel free to answer them if you think this is a worthwhile line of inquiry.



HEADLINE: Lower barrier for contributors DESCRIPTION: Have a git repo for each package with a simple issue tracker, like GitHub/gitlab, a flow for accepting pull-requests and automated CI. Also move away from message boards and IRC to more user friendly tools.

Currently, it's too hard to report bugs, inspect debian source packages, propose fixes, etc. The overhead to making a simple contribution is too high. Note: this isn't a debian specific issue, many open source projects has old infrastructure.


As for PR workflow, it will be hopefully. There's a discussion[1] to replace the Alioth[2] with Pagure[3], which has a similar workflow with Github. Maybe the Pagure is not the final decision, but it will be a modern platform that's easy for contributors.

[1] https://lwn.net/SubscriberLink/724986/90728a14d7a85770/

[2] https://alioth.debian.org/

[3] https://pagure.io/


The problem with a git repo for each package is that not every maintainer uses git..

I realise that integration could be better, but most of these things do already exist:

CI: https://ci.debian.net/

Tool for reporting bugs: reportbug (CLI) / reportbug-ng (GUI). This is also the way to submit patches.

Inspect debian source packages: apt-get source


> ...not every maintainer uses git.

I can't think of a valid reason for people to avoid learning git. Is there one?


"Avoid learning" and "not using (for this particular job)" are different things.


Is there a valid reason to move to git from any other VCS a person happy with, regarding time and resources one have to spend on it instead of productive work?


It could be beneficial for a Linux distribution sticking to only one tool to be able to build a common Workflow around it. For example Debian only uses one bug tracking system which might not be what everyone likes most but imagine what a nightmare it would be if everyone would set up their own solution for their package.


I can't contrast git with all the different VCS tools that are available, but different tools have different capabilities with respect to working offline and reconciling branches.

At any rate, it was an honest question. I'm not familiar with any salient reasons to not use git. If the only reason is that some developers still haven't learned git yet, I guess that's an answer. Not a very satisfying one to me, but it's worth knowing that's the reason.


There are those of us who have learned git and still prefer Mercurial. It's really annoying that git is supposed to be what we use across all programs, distributions, operating systems and hardware. Just about ASCII or TCP/IP are the only things that are about as universal, and git shouldn't be nowhere nearly as foundational as them. There should be room for more than one way to do source control.

Sadly, mercurial-buildpackage in Debian is a dead-end. :-(


> Have a git repo for each package

Bad idea, because you don't want to lock all of Debian into one technology. Suppose Debian had similarly had one cvs repo for each package 20 years ago. Progress happens when people have the opportunity to independently build and test out different solutions without first having to convince the world that theirs is the best.

> with a simple issue tracker

Dunno what you mean by "simple", but there is an issue tracker for all the packages that's as simple to use as it gets, you don't even need to create an account!?

> Also move away from message boards and IRC to more user friendly tools.

I haven't seen message boards used by Debian!? As for IRC, what would you consider a more user friendly tool?

> Currently, it's too hard to report bugs

So, running reportbug on your machine is too hard?!

> inspect debian source packages

So, running apt-get source on your machine is too hard?!

> propose fixes

See bugtracker above?

> many open source projects has old infrastructure

What is wrong with old infrastructure?


It doesn't have to be a git repo :)

But a github-like setup, project package, issues, branches, PRs.

> So, running apt-get source on your machine is too hard?!

Where is the web ui? I honestly feel like these commands are magic because I don't know what they clone from. (and I have to be on debian)

> As for IRC, what would you consider a more user friendly tool?

slack or similar...

> So, running reportbug on your machine is too hard?!

This assumes on a debian machine. Sometimes I find a bug searching on google, it'll be something like this:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=304373

How do you subscribe, comment, propose a PR, where do you find the source.

I have used some of the debian tools like apt-get source, but it takes a long time to learn these things, and I forget them. A github-like system is much more intuitive.

----

Note: I'm not criticizing the debian project, many open source projects have old infrastructure, that's hard to use. And I fully understand how that infrastructure came to be, and why migrating away is super hard.

My point is: github-like development flow have dramatically better usability and, hence, lowered the bar for participation. I wish more of the big open source projects would embrace the importance of these advancements in usability.


> But a github-like setup, project package, issues, branches, PRs.

Well, how is that supposed to work and not run into essentially the same problem? You can use any version control system, but only after you have integrated it into the Debian meta version control system?!

> Where is the web ui?

Why would you want a web UI, especially if it's supposed to be user friendly? I have a very nice and powerful development environment ... why would I ever want to have a "Debian Web UI" for inspecting a package's source code instead of just using the tools that I know well how to use?

> I honestly feel like these commands are magic because I don't know what they clone from.

Well, there is documentation that explains what they do?! Like ... man apt-get? And it's not really all that complicated either.

> (and I have to be on debian)

Well, you can just download the source packages from the website if you want, but in the common case that you just want to inspect or modify the code of the package that you have installed, what's easier than have apt download and unpack it for you?

Also, of course, that's all only relevant to the Debian packaging, not the upstream source.

> slack or similar...

What do you mean by similar? Proprietary software with a monopolistic supplier that you cannot participate in unless you enter into a contract with that third-party supplier under their terms, and that forces you to use their user interface instead of integrating it with your existing communication infrastructure? How is that more user friendly than "start any free-software IRC client of your choosing if you haven't one running yet, and join the channel (or use some web IRC client if you want)"?!

> This assumes on a debian machine.

Well, it is meant for reporting bugs in a Debian install, so ... yeah?

Also, again, you don't need to use that, but it's the easy way in the common case that you are indeed on a Debian system when you want to report a Debian bug.

> How do you subscribe

You click the "subscribe" link in the line "Reply or subscribe to this bug." at the top.

> comment

You click the "Reply" link in the line "Reply or subscribe to this bug." at the top.

> propose a PR

Same as above, just put the URL of the repo to pull from in the email.

Though in practice just putting the patch into the email is the usual approach, given the nature of packaging bugs (the fix usually is relatively simple).

> where do you find the source.

You click on the "docker" (or whatever the package name is) link in the "Package: docker [...]" line at the top, that gets you to the bug tracker overview page of that package (essentially the list of all bugs related to that package), there you click on the "docker package page" link in the "You might like to refer to the docker package page, [...]" line at the top, which gets you to the list of available related packages and their versions, where you click on the relevant package and version, which gets you to the info page about exactly that package in exactly that version, which, among many other things, contains links to the source package in the right column.

That might seem like a lot of clicks to get from A to B, but if you realize that bugs are not specific to single package versions, but Debian as a distro of course is built on specific versions that are published as packages, it actually makes sense.

> I have used some of the debian tools like apt-get source, but it takes a long time to learn these things, and I forget them.

Well, yeah, it certainly is something you have to learn if you want to use it, just as github is something you have to learn if you want to use it!?

I just don't see how anything like github would be a replacement for Debian package management tools. I mean, the purpose of apt and dpkg and the like is not to be general-purpose software development tools, they exist just for the purpose of packaging and building software for Debian. If you want to package and build software for a distro, you'll naturally have to learn how to use the packaging tools of that distro, and if you are just interested in the upstream source of some software that just also happens to be packaged for Debian, then why bother with any of the Debian stuff?!

> A github-like system is much more intuitive.

Are you sure you don't just mean "I am more familiar with github"?

I find github just annoying in that it's constantly trying to get me to use their user interface instead of just giving me easy access to the raw data and letting me use my own tools (and I am not interested in using github for anything, I just am confronted with it when other people choose to host their software on it).

> many open source projects have old infrastructure,

I still don't see what's wrong with old infrastructure?!

> that's hard to use.

Well, hard to use infrastructure is bad, whether old or new, isn't it? Github, for example, is relatively new, and just terrible. I can't even report a bug in projects hosted there, I'd first have to create an account with them just to post a simple bug report, it's just such a terribly complicated workflow (not to forget I'd probably have to accept their TOS?).

I still don't really see any similar problems with how Debian operates from what you have written!?

> And I fully understand how that infrastructure came to be, and why migrating away is super hard.

Well, I still don't see why one possibly would want to migrate away in the first place!? I mean, not that there is nothing that could be improved, but I don't really see anything that "switching to" would somehow make things better.

> My point is: github-like development flow have dramatically better usability and, hence, lowered the bar for participation.

Did it? I guess it depends on what you mean by "github-like"? My experience with github specifically is completely the opposite.

I have contributed to quite a few projects, with usually very low barriers to get involved. Usually, you just send an email with the patch (or a pull request for more complex changes) to the mailing list or maintainer, and that's it (or maybe a few more mails back and forth to discuss some improvements or whatever, but no up-front cost before you can get started, no need to create accounts, no need to learn additional user interfaces, ...).

On the other hand, I had a few bug fixes for projects that were hosted solely on github where I couldn't find any way to submit them without first making an account with github and learning their proprietary user interface, so I just ended up dropping them on the floor.

How is the latter an improvement?! Or is it?

> I wish more of the big open source projects would embrace the importance of these advancements in usability.

But ... what are those advancements in usability? Really, I still don't see any. I mean, not that usability couldn't be improved here and there, but what you write so far mostly reads to me like "if you know github and don't know non-github, then github is easier to you than non-github" ... which might be true, but would generally be equally true for anything else, and in particular doesn't really have anything to do with usability!?


You need some linebreaks in your post.

This issue could be helped with some tactical updates to the Debian Wiki. I'm in two minds about IRC - I'd hate to see it disappear and go to something like Slack, but I understand it's a bit daunting.

#debian-mentors on OFTC can help with contributions to Debian.


Yes. See that KDE makes this easy with bug reporting built in to applications and desktop tools.


Debian has reportbug and reportbug-ng.


I know that when I google an error code and somehow find a bug from debian it's always often obscure mailing list archive.

If I google a docker error code, I often end up on a github issue.


It is not Debian's fault that Google prioritizes ad ridden mailing list mirror links over the neat & clean bugs.debian.org pages.


There's already a git repo for every package.

    % apt-get install dgit
    % dgit clone foo-package


HEADLINE: Better package discovery

DESCRIPTION: There are a ton of packages in Debian. I sometimes browse through all of the packages looking for some gem that I didn't know about before. It's a time intensive process and I don't have any input into my decision other than reading the description. Sometimes I'll install it immediately. Other times I'll check out the website to see if it's still maintained (or if there's a better alternative). It's all a very manual process.

popcon doesn't fill this void. Popcon tells me what packages are popular across all users. I'm more interested in what a subset of users with similar interests or preferences would install. Or maybe I want to see what it's like to live in someone else's shoes. For instance, maybe I'm learning a new programming language and I want to setup my environment similar to an experienced user so I have all of the popular libraries already installed.

It would be nice if there was a better way to discover packages that are relevant to you. Perhaps you could add this feature as a way of getting people to install popcon? For example, you could say if you install popcon, then it will upload your set of installed packages and make recommendations for you.

If people are able to add metadata about themselves (e.g. I'm an expert Emacs user and I'm a golang developer), then you could use that plus their package list to make recommendations. I could say "show me what packages golang developers tend to install". Or you could say "for someone with a package list similar to mine, find out what packages are popular that I'm missing".


Popcon also has the disadvantage that it has an unconscious bias: if you care about security, you don't send your package lists out to be part of the survey.

Corporations setting policy for their systems are also unlikely to install popcon.

The overall effect is to bias popcon in favor of home users who don't think much about security.


HEADLINE

Secure Boot in Stable

DESCRIPTION

UEFI Secure Boot Support in Debian.

Debian does not run on systems with Secure Boot enabled.

DISTRIBUTION

stable/buster

ROLE

I work at an insurance company and all of our development computers and most of our servers run debian jessie.

We will probably upgrade to Debian 9 very soon! Thanks for all the hard work on debian Iamby!

EDIT: grammar and formatting


> Thanks for all the hard work on debian Iamby!

Oh wow, it's really not just me...


:)


HEADLINE: Reconcile and refresh the Debian Wiki

DESCRIPTION: The wiki is frequently stale or incomplete. A lot of people get information much more readily out of a wiki than mailing lists. Like me, for example :) Mailing lists have a very high latency (often infinite) and can be difficult to search.

For example, say you want to host your own apt repo to hold a custom package; this page is not very clear https://wiki.debian.org/DebianRepository/Setup - how do you choose which of all the software types to use? It's a reasonable software overview, but not great to help people get a repo set up.

Arch has a fantastic wiki that's clear and concise. It's also more readable (mediawiki) than Debian format, though I understand Debian aims to work as bare html for greater device compatibility.

DISTRIBUTION: Primarily Stable, with later sections for non-stable if needed.

ROLE: sysadmin


- HEADLINE: An install-time option to set up a barebones WM

- DESCRIPTION: The installer should offer an option to install a simple WM, like i3 or awesomewm, in the way that there is an option in the minimal installer to install a DE like Xfce or GNOME. Bonus points if you make it aesthetically pleasing to some extent.

- HEADLINE: Kernels in repo which do more than the mainline/default kernel

- DESCRIPTION: I'm thinking of specifically of the patches by Con Kolivas, but any other useful pre-compiled kernels being available in the repo would be great, it would save me having to figure it out by myself and I'm sure there are many who would welcome the availability of pre-patched kernels, better i/o schedulers etc

- HEADLINE: Look into more optimisation (like Solus)

- DESCRIPTION: Solus (www.solus-project.com) does some optimisation on their distro that would be a good-to-have in any other distro

- ROLE/AFFILIATION: Infrastructure programmer for multinational corp


- HEADLINE: Continue to provide a mechanism for offline installation of a large selection of the repository.

- DESCRIPTION: Debian is the only distribution that I know of that provides .iso images from which you can install the operating system and subsequently install a wide range of (libre) software. In addition, Debian provides update .isos. These affordances make installing and maintaining a desktop computer without an Internet connection, or with a slow and expensive connection, viable. I hope that Debian will continue to provide this affordance as we transition from optical disks over the next few releases.

- DISTRIBUTION: All Debian distributions.

- ROLE/AFFILIATION: End user (desktop)


> without an Internet connection, or with a slow and expensive connection

Could you elaborate more on your particular use-case? Would be interested if there were also compromise solutions such as smarter binary diffs, etc.


my use case could be just walking down the hill with my laptop to the arts centre with the fast wifi.

However, having installed a fairly full Debian desktop from DVD1/2 offline it struck me that Debian is the only distribution that could support someone with (say) a desktop PC in a location with dial-up or no Internet or only mobile internet. I imagine a single large .iso image (the BD perhaps?) included on 'El Paquete'[1] and dd'ed to a USB key for installation or DVDs/USB key mailed in the post.

A Debian equivalent to drpm packages would be a really nice idea. I'm glad you said 'also'!

[1] https://www.fastcompany.com/3048163/in-cuba-an-underground-n...


The internet is often prohibitively expensive for a small minority of users. But those users often have infrequent access to a high-bandwidth connection.

And of course, odds are that they won't be reading this thread!

I've often been in this situation myself.


A not so small minority globally.

Only 1.2% of India has fixed broadband, but 20% have mobile data.

Even in the USA, less than 30% of the population has fixed broadband, but almost 75% have mobile data.

https://en.wikipedia.org/wiki/List_of_countries_by_number_of...


What do you think of content rich distros like Endless OS (Linux aimed at end users with a lot of offline content)?

I'm thinking of ditching the phone line and scavenging in local cafes/public buildings, so yes, weekly access to reasonable speed connection. Tethered mobile connection for emergency email/rdp access.


HEADLINE: More user-friendly install process

DESCRIPTION: Recently had to reinstall my Debian system for the first time in a while, and was struck by how user-unfriendly the installer still is compared to many of the alternatives. I don't think it's necessarily a problem that it's ncurses, but it could use some more explicit hand-holding. I remember one point where I needed to select some options from a list and there was no indication of what operation was required for selection, for example (I think I needed to hit '+'?). I'm pretty familiar with command lines and curses-type UI's and this was unintuitive for me, I can only imagine how frustrating it might be for a more desktop-oriented user.

I also recall a very confusing UI paradigm where the installer steps are a modal view and there's a hidden 'overview/master menu' you can back out into at any time, and it's not clear to me how those two modes are related and what state it leaves your installation in if you back out and then jump into the installation at a different step.

Generally the explanatory text is quite good at telling you what decision needs to be made, and providing necessary info to research that decision if necessary, but how you make those decisions I think could still be improved.

DISTRIBUTION: Stable


I agree with this, one of the few things I miss about Windows is the easy disk setup in the installer.


HEADER

Wayland as default display server

DESCRIPTION

X11 is aging, so it's time to switch to Wayland. It'd be cool if buster would ship with Wayland as default display server.


GNOME will more than probably be running in wayland as default in Buster

You can already try it in Stretch by selecting the proper option in GDM. I'm personally using wayland on both my desktop and (work) laptop for months


> X11 is aging, so it's time to switch to Wayland

I can't say I follow the logic. Wayland is aging too, but I assume you wouldn't be on board with the idea "Wayland is aging, so it's time to switch back to X11"?


I guess OP is implying it is aging architecturally, technical debt and other perceived problems with X11 which prompted the development of wayland/mir


HEADLINE: Out of the box support for being run in VirtualBox.

DESCRIPTION: I tested the stretch release candidates in VirtualBox, and while I did eventually get them working, I had to follow the instructions in several bug reports from across both the Debian and VirtualBox probably project websites.

I don't mind following instructions, so if there is a reason why this can't be achieved seamlessly with zero configuration, then I would at least like to see some official instructions prominent on the Debian website.

COMMENT: Debian is awesome, thanks for everyone's hard work!


I seem to recall Jessie working fine as a VBox host. What did you run into?


I'm running Debian boxes 100% of the time on VirtualBox since 4 years. I run macOS, but only as a host, I spend about 95% of my time within Debian boxes.

Never had a problem that Debian didn't run 'out of the box' within VirtualBox. Wouldn't even know what that entails.


One thing that it entails is that the kernels available in Debian 8 backports are not compatible with the VirtualBox guest tools for Debian 8 that are published by Oracle. So one has to make the choice on Debian 8 between a kernel that supports version 2 control groups and having VirtualBox device drivers for things like the display.


Isn't that a problem for the VirtualBox team to solve - effectively, supporting newer kernels?


I do also have had some problems running Debian Stretch in Virtual Box.

For example I had to install the "xserver-xorg-legacy" package to get the X server working as X is not running as root anymore.


That package is installed by default in Debian 9 (but it was added fairly late in Stretch's development cycle).


Any issues you have should definitely be submitted as bug reports. I run Stretch and Jessie in VirtualBox just fine, but a few of the d-i RCs were a bit shaky.


Could you link to any of those bug reports?


- HEADLINE: port pledge(2) from OpenBSD

- DESCRIPTION: Debian has been a great source of innovation and leadership within the OSS world. Make the next big move by adopting pledge(2) from OpenBSD to be the first major mandatory security feature on Linux. There is little hassle in making programs use it, and the LOC in the kernel is tiny compared to say SELinux. See [1] for more details.

[1] http://www.openbsd.org/papers/hackfest2015-pledge/mgp00001.h...

- DISTRIBUTION: Any and all!

- ROLE/AFFILIATION: CS program analysis researcher with MIT/CSAIL.


This isn't as easy as it sounds. Pledge works in OpenBSD because OpenBSD is simple and all of the necessary code lives in one tree. Pledge is supported in the vast majority of OpenBSD base programs but very few ports. If programs aren't written in a careful manner or with an eye to privsep, you end up with pledges that don't protect much since they are so broad. There are a lot of programs you can't pledge even with all options turned on because pledge has a whitelist on the kernel side for what it allows.

It's not impossible for Linux, but there would have to be a lot more conditional cases in the Linux kernel to handle all of the various ways that programs would use it. The Linux ecosystem is massive and the number of alternatives for even basic daemons is large. Instead of pledge, you may end up with a syscall filter or something like FreeBSD's capsicum. Both of those are more complex because it puts all of the effort on the application developer and also gets in their way.

Straight syscall filters and complex systems like capsicum are designed to allow for arbitrary programs to be protected. In doing so, it moves all of the complexity to the application developer. The advantage of pledge is that it does not attempt to be completely generic. Pledge is designed for how OpenBSD programs are written and what's in the OpenBSD tree. It may evolve over time to include some functionality for ports, but the overall design is to make a subset of well written programs easy to protect. If you try to pledge arbitrary programs, you'll find it doesn't work out unless you rewrite the program logic to be more well written.

Pledge is conceptually simple, but the kernel side shows how it was tightly integrated into OpenBSD's way of doing things and has evolved to make it simpler (by relaxing some behavior or whitelisting parts) and breaking up other permissions to make it more fine grained when needed.


These are good points. However unlike SELinux / AppArmor, a Debian package maintainer does not need to do make sure things are set up right for pledge- programs that aren't pledge'd will run just fine (i.e. all syscalls are allowed by default, not the other way around). So even though adding pledge to the kernel does nothing by itself, can't usermode programs (the ones for which pledge makes since) slowly make themselves more secure?

> It's not impossible for Linux, but there would have to be a lot more conditional cases in the Linux kernel to handle all of the various ways that programs would use it.

Why would there be a lot more conditional cases in the kernel? I'm just imagining having a bitvector whitelist[] for each task_struct and then in the syscall_trace_enter functions one indexes into current->whitelist if it's __NR_pledge.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...


That's really something that needs to be driven from upstream - you can't really add syscalls in distro patches.


HEADLINE: Support for more wifi hardware.

DESCRIPTION: The #1 reason why I don't use Debian on the desktop is missing wifi support during installation. I wish Debian could write and include free wifi drivers for all recent laptops.

DISTRIBUTION: Debian 8 on the server. Mint Mate on the Desktop.

ROLE/AFFILIATION: Founder and CEO of a tech startup.


Drivers exist in the kernel already. The issue is the proprietary firmware that these devices require. Debian can't do much more about that, complain to the manufacturers.

See this other thread: https://news.ycombinator.com/item?id=14579821


- HEADLINE: Continue being an awesome distribution

- DESCRIPTION: Continue with the values that make debian great. E.g. https://www.debian.org/code_of_conduct https://www.debian.org/social_contract https://www.debian.org/intro/free

- DISTRIBUTION: (Optional) [stable, testing, unstable, or even a Debian deriviative]

- ROLE/AFFILIATION: (software dev, mostly web)


HEADLINE: Smarter handling of icons files during updates

DESCRIPTION: This is a nitpick/wishlist item really. I started using Stretch while in testing, and noticed that most updates would download rather large sets of icons (few MBs). They look like archive files of icons, and I guess that if any change happens the whole set is downloaded again. This wasn't the case in Jessie.

When on a slow Internet link, it can definitely slow down upgrades. It would only be noticeable for Testing/Unstable, as otherwise these sets of icons would not change much. But when regularly updating testing, often these icons sets were a significant part of the downloaded data.

It could be nice to make updating those icons optional, for people behind slow links. Alternatively, handling them as a versioned list (text, easy to diff efficiently) + independent files could make their update more efficient than compressed archive files.

Again, just a nitpick/wishlist item. It's just that I haven't chased down what this comes from (I guess for GUI package management like synaptic? TBC) and don't know where this could be reported. You just gave me the opportunity ;)

DISTRIBUTION: Testing/Unstable (any version with frequent changes)



HEADLINE: Decent rust support

DESCRIPTION: On rolling release distros there's currently a vim version that ships rust syntax highlighting, rustc and cargo. This is pretty much all you need to get started with rust development. Debian stable currently ships rustc, but lacks cargo, which is rather essential if you actually want to compile your project on a debian server. The vim-syntax thing would be nice to have. :)

DISTRIBUTION: stable/stable-backports


HEADLINE: nginx-rtmp support in Debian

DESCRIPTION: At https://fosdem.org , we are using the nginx rtmp module intensively. It seems it is becoming a de facto standard when an in-house streaming server is preferred, as opposed to an external streaming platform. It combines excellently with ffmpeg, the recently pacakged voctomix and several components of the gstreamer framework, to create an excellent FOSS video streaming stack. Some debconf video people too seem to be interested. Some positive interest from Debian nginx pacakagers. Unfortunately, no clear way forward yet.

Hopefully, Buster opening up might create some opportunities to get things going again!

SEE ALSO: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=843777#23

DISTRIBUTION: Debian 10 stable & Debian 9 backports.

ROLE/AFFILIATION: http://fosdem.org staff (= all year round volunteer), responsible for video streaming & recording since FOSDEM 2017


Update: spoke to the nginx maintainers again on irc, and Christos Trochalakis promised me to work on the packaging himself this week! Really really happy about that!


HEADLINE: Stabilize dpkg C library (libdpkg)

DESCRIPTION: Any plans to go ahead and stabilize the dpkg library for buster? Having access to a stable package management library is essential in our software. Ie. being able to verify package signatures and querying the database for files. Both of which are not supported.

DISTRIBUTION: buster


This has been part of the dpkg roadmap for some time now (https://wiki.debian.org/Teams/Dpkg/RoadMap). And something I'm slowly but progressively moving towards. But TBH it has been low priority. Knowing of projects that require it, and specifically which parts, or that are already using the static libdpkg library are very valuable, so that those parts can be improved.

If there's enough interest, my plan could be to expose just a subset of the current libdpkg as a shared library for buster.


> Knowing of projects that require it, and specifically which parts, or that are already using the static libdpkg library are very valuable, so that those parts can be improved.

What would be the best way of contributing this sort of information?


Either here or I guess a mail to the debian-dpkg@lists.debian.org mailing list would do, whatever is most convenient. :)


Eliminate all the scripts that go into a package, moving them to runtime. This is the only way to eliminate instability caused by buggy scripts that then prevent upgrades.

Also get rid of all interactivity during install and upgrade. It's deadly for managing big fleets.


I assume you mean maintainer scripts here. If so we are already going in that direction: https://wiki.debian.org/Teams/Dpkg/Spec/DeclarativePackaging

For interactivity that should in principle be a solved problem with debconf, if it's not, we would like to hear what's lacking. If there is a problem with a particular package then a bug report would be appreciated.


HEADLINE: Regression fixes from upstream

DESCRIPTION: GCC 6.4 will be released soon (July). I wish Debian will get all the regression fixes that this update will bring (according to the new numbering convention, version 6.4 does not mean new features, so no breaking-changes, only fixes). Same for CUDA 8.0.61 (already available for ~5 months) which is a maintenance update after version 8.0.44, the one available in Stretch. I'm saying this because Jessie never got the latest bug fix release (4.9.4) for the 4.9 series of GCC, not even in the backports (it still offers the 4.9.2 instead). I wish there was a policy that allowed regression fixes from upstream to be ported and with the same priority as security fixes. GCC and CUDA are only examples, the same scheme would be applicable to any other package as well. In my view, this would foster Debian adoption on desktops at a higher level. If this can't be done for the current Debian Stable, I hope my (and other people's similar) concerns will be taken into account in the future. As a developer, I care about this level of support. We all love Debian, we'd just like to make it better. Thanks.

DISTRIBUTION: Debian Stable


Headline: Stronger security enabled by default

Description: More KSP security features enabled by default, perhaps even Firejails pre-installed, Wayland as default along with flatpaks, etc


- HEADLINE: Make it easier to use newer software.

- DESCRIPTION: I think there is lots of ways. Things like flatpak look promising but also docker. It would be nice if there where less papercuts when using those things. I also dream about a command named "playground [name]" which instantly gives me a shell where I can try stuff without interfering with anything else. When finished I can just "playground remove [name]". I know that it's possible today but it's a but of a hassle.

- DISTRIBUTION: (Optional) [stable]

- ROLE/AFFILIATION: (software developer, mostly fullstack webdev)


Shameless self-promotion: I've been working on building that playground command in my free time at https://github.com/zachlatta/try.

Maybe we could add support for Debian packages?


HEADLINE: better keychain integration/mechanism for handling PGP/SSH

DESCRIPTION: It would be great to have a central keychain where keys (SSH, PGP) could be unlocked on a sessions basis (think of a merge between gpg-agent [who wouldn't scream about being hijacked every other day] and ssh-agent [who wouldn't be shell-specific and able to handle multiple keys without having to manually :

> eval $(ssh-agent -s) > ssh-add /path/to/key1 > ssh-add /path/to/key2 > ...

])

As a desktop user, what I would like is, on a session basis, when I first provide the passphrase for a given key (when I ssh into a server from the CLI or decrypt a PGP encrypted email from Thunderbird [with enigmail] for instance) have a keychain securely unlock these keys for the duration of the session (that is, until I lock the screen, close the lid or log out).


- HEADLINE: Proper support for installations on GPT partitions

- DESCRIPTION: I have tried installing debian many times on various machines and have had huge trouble getting the install usb stick to boot properly (or in the end for the bootloader to install) with Debian. Ubuntu installs flawlessly on these machines.

- DISTRIBUTION: (Optional) [stable, testing, unstable, or even a Debian deriviative]

- ROLE/AFFILIATION: (Optional, your job role and affiliation)


HEADLINE

WiFi-direct GUI

DESCRIPTION

Using WiFi direct on most debian-based distros is a hassle, requiring a lot of manual terminal work. A GUI in the network section for WiFi Direct would make connections easier and faster.


Is there an existing such feature in other distributions out of interest?



Sorry for the late reply.

If you consider Android to be a GNU/Linux distro, then Android 4.x+ could be a reference for this.


HEADLINE: faster release cycle

DESCRIPTION: In the past I've often ran into stuff in Debian just being too old for my needs. I don't need the bleeding edge, but two years is a really long time. I've switched to Ubuntu a few years ago, but not being a fan of Canonical it would be nice if I could come back to Debian.

DISTRIBUTION: stable

ROLE: full stack web developer


Use Debian Unstable on the desktop, and Debian Stable on the server. Despite the name, Unstable is pretty stable - it's just making it clear that you're dealing with relatively fresh packages and these often break as they're not battle-tested.

Unstable isn't built from bleeding-edge nightlies, but it's generally up-to-date.


HEADLINE: A way to bootstrap something slimmer than "minbase" for building images.

DESCRIPTION: When building images (especially container images), there should be a way to only install the bare minimum to make apt work. No init system, no bash, no filesystem utilities, nothing. Even `debootstrap --variant=minbase` is overkill in that regard.

One way would be to create an option for deboostrap that would accept a list of desired packages (similar to pacstrap from Arch) instead of using "--variant".


- HEADLINE: Bring back the standard (console) Live CD

- DESCRIPTION: Jessie had a standard Live CD. While the HTML still refers to this flavor, it is not found on any mirror that I checked for Stretch.

I have to use the live CD to install ZFS on Root. I would prefer to not bother downloading or booting a desktop environment when I don't need one.

I don't know why it was removed, but the name was always strange to me. Name it textonly or expert or something so people don't choose it. Standard sounds like it is the recommended image.

- DISTRIBUTION: Live CD


- HEADLINE: improve transitions and out of the box usability of rolling Debian variants.

- DESCRIPTION: Since Debian testing / unstable are often advertised as targeted for desktop usage, they can benefit from some more focus on preventing breakage. I know it's somewhat counter intuitive to expect stability from "unstable" or "testing" variant, but at the same time Debian can benefit from avoiding the stigma of server only distro. Having out of the box robust desktop experience (which is not falling behind) is the goal here.

In the period between Jessie and Stretch, testing had a number of breakages in my KDE desktop. Packages fell out of sync (like KDE frameworks and Plasma packages weren't properly aligned, because some packages were stuck in unstable because of not building on some archs) causing all kind of instability issues. It lately became a bit better, but I think desktop stability can get some more love, especially for the most popular DEs like KDE.

And if neither testing nor unstable fit that role, may be another branch should be created for it?

- DISTRIBUTION: Debian testing / unstable.

- ROLE/AFFILIATION: Programmer, Debian user.


- HEADLINE: thunderbolt, amt firmware loader

- DESCRIPTION: The last laptop that I bought from Lenovo had a thunderbolt port, and I had to use that port to get 3 x 4k monitors to work. The hardware shipping with non-functional firmware. The only way to upgrade the firmware was by booting Windows. I was not sure if there were other devices with old firmware, so I spent hours waiting for a full OS upgrade. Dell was working on a thunderbolt firmware loader at the time, not sure if they released it by now.

Similar situation with the AMI firmware security issues (CVE-2017-5689). The only way to upgrade (afaik) is by running a particular windows installer.

It seems really dumb having to buy a throw-away drive just to be able to boot windows to upgrade firmware. Obviously, I understand this at the feet of the hardware vendor. I was going to suggest pre-installed Debian, but Lenovo will ruin that with pre-installed crapware.

- DISTRIBUTION: stable

- ROLE/AFFILIATION: entrepreneur


HEADLINE: kindly support "SecureBoot" as soon as possible(for all of us who are dual booting debian and MSWindows)

More

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: