This page is meant to collect frequently asked questions from the debian-user mailing list. The contents are licenced under the terms of GPLv2 or, in the event a DFSG compatible licence is applied to wiki.debian.org at large, then under that licence. Posting material to this page is an acceptance of this.
- Why bother
- Should I be running Testing/Unstable(Sid) instead of Stable/Testing?
- How dangerous is it to run a mixed system?
- How different is Ubuntu from Debian?
- My harddisks/usb sticks/external drives don't always have the same device name. How can I prevent this from happening?
- My ethernet card is named ethX instead of eth0, what's going on?
- Which is the best package manager?
- Where is the foo package?
- Program foo is looking for (or lacking) file bar. Where is it?
- What package contains file foo?
- How can I prevent a specific package from being installed on upgrades?
- Should I be using upgrade/safe-upgrade or dist-upgrade/full-upgrade to keep my system updated?
- Does Debian have Firefox/What is Iceweasel?
- Firefox/Iceweasel has strange problems (segfaults, crashes, ...)
- Ubuntu/some other distro already has a newer kernel/Gnome/KDE/Firefox/other. When will Debian have it?
- I found this .deb package for a software I need, can I just install it on Debian?
- I am running a mixed system. How can I find out what packages are from which distribution?
- I tried to remove a package and now many other packages are scheduled for (auto)remove
- How can I enable Multiarch
- Do I still need ia32-libs/ia32-libs-gtk ?
- If I'm trying to upgrade ia32-libs/ia32-libs-gtk I get a lot of i386 libraries installed
- My non-Debian software has an amd64 package that depends on ia32-libs/ia32-libs-gtk, how can I get rid of ia32-libs/ia32-libs-gtk ?
- But APT wants to install a lot of i386 libraries now
- Will this break my system?
- Are cross-grades possible?
Posting on debian-user
- How should I post/reply to debian-user?
- I asked my question according to the directions written at the "How should I post" question, but I still don't get an answer
- Should I be subscribed to post to debian-user?
- Help! My e-mail address is available in your list archives for the spam-bots to harvest/Why aren't e-mail addresses scrambled?
- This list is littered with spam, do something about it!
- How can I get my postings/e-mail removed from the archives?
- I subscribed to the list, but my mailbox is flooded with mail
- What is top-posting (and why shouldn't I do it)?
- Why doesn't this list facilitate easy replies to the list (a.k.a. reply-to-munging)?
- Can I ask a question about foo?
- What is considered offtopic for debian-user?
- Is it ok if I attach/include bigfile in my message or should I use a pastebin instead?
- My posts are considered spam and rejected (or never show up)
- I'm posting via gmail's servers, but I never receive my own posts (other list mail is fine)
Why should I post to this list? I want to ask the developer/post to debian-devel/file a bug.
Of course, you are free to do this. Almost all debian lists (including debian-devel) are open for anyone to post and Debian encourages users to file bugs in the Debian Bug Tracking System (BTS). BUT, please consider the following points first:
Make 100% sure your problem needs direct attention of developers.
Remember, Debian is created by volunteers in their spare time. Distracting them with other problems will leave less time to do actual work, like solving known bugs, packaging new versions of software we are all waiting for, packaging software not yet present in Debian and improving or creating Debian specific software. Even if you know you have a really difficult problem, debian-user is read by some very knowledgeable people (including some Debian developers), and they might have a solution for your problem.
- Some problems are caused just by misconfiguration.
Sometimes even the most experienced people can do things they did not mean to do: everyone, no matter how capable, can make mistakes. Having other people look over your problem may help.
- Make sure your problem is not already known.
That means you should search the archives of debian-user (or other relevant lists) and especially the BTS. Chances are somebody else has experienced the same (or similar) problem and workarounds may be known. Even if you searched thoroughly, you should post to debian-user first (stating what you have already tried/researched).
If you have considered all the above points and still want to address debian-devel, then please make sure:
- your problem is not specific to a package (you could file a bug instead)
- it hasn't been discussed yet (you did search the archives, right?)
- you are addressing the right list (ex. legal stuff should go to debian-legal, website specific to debian-www, ...)
In case you have doubts just post to debian-user, sometimes answers come within minutes.
Should I be running Testing/Unstable(Sid) instead of Stable/Testing?
This is something that you as a user and administrator of your system have to decide for yourself. If you just need a few newer packages try http://backports.debian.org before considering an upgrade. If you have Debian on a desktop machine, testing might be an option, but it's not really recommended for production machines. If you want all the newest software Debian can provide and don't mind/can handle breakage then you could try unstable. The differences between them are in rate of change of packages as much as anything else and the amount of attention and testing that each receives. If you are in doubt always use stable. Each Debian distribution has its pros and cons. Here are some:
See DebianReleases for more information ...
stable is the currently supported Debian GNU/Linux distribution.
- released approx. every 2 years.
- has security support and occasional bug-fixes (via the security archive, stable-updates archive and point releases).
- very stable, thoroughly tested, recommended for environments where frequent changes are not desired and high uptimes are required.
the upgrade process from the previous stable release is documented in the Release Notes
- can have older software and may lack support for very new hardware.
See DebianStable for more information ...
testing is slowly evolving to become the next stable release, but until then it is still a testing ground. As the release approaches ("testing freeze") it becomes more and more like a newer stable release (with all pros and cons):
packages have already received some testing in unstable.
- has only limited security support (typically by urgent updates via unstable).
- bug fixes have to go through unstable first (10 days delay, but can take longer). Because of this any breakage might take at least 10 days to be fixed.
- requires some skill to maintain.
See DebianTesting for more information ...
Unstable (a.k.a. Sid, a.k.a Still In Development, a.k.a. the character in Toy Story who broke toys)
unstable contains packages uploaded by the developers for the next release, but it will never be released by itself. Instead, packages will migrate to testing if they fullfil specific criteria (e.g. have been tested in unstable, they don't introduce any new release-critical bugs in testing, no dependency problems, etc.).
- most of the time has quite recent software or even bleeding edge.
- no security support similar to stable, but updated packages should also incorporate security fixes.
- changes can/do happen daily, which incidentally, is why it is called unstable.
- serious breakage can (and will!) occur; requires good skills to maintain, but good for learning if you don't mind the downtime.
Experimental (a.k.a. rc-buggy)
This is not a regular distribution (you cannot run on experimental), but it is mentioned here for completeness.
- a place for maintainers to upload packages which are not suitable for unstable, but still need a wider audience for testing.
- no security support and some packages can stay here for long times without any updates.
usage is not recommended unless you really know what you are doing.
See DebianExperimental for more information ...
When a new version of Debian GNU/Linux is released the current stable becomes oldstable.
has security support for approximately one year after the release of stable
users are recommended to plan an upgrade to stable before security support ends
See DebianOldStable for more information ...
How dangerous is it to run a mixed system?
That depends on how many and what packages you are using, but it can be more dangerous than running pure unstable. Installing packages from different releases can cause complex problems which are less likely to occur with packages from a single release. One example is that existing packages may become uninstalled due to internal restructuring of central components within the testing or unstable branches.
Try backports first. If you can't find what you need there you can also backport a package yourself.
See Backports for more information ...
How different is Ubuntu from Debian?
There are lots of differences: some big, some small but all may be significant.
Packages in Ubuntu main are very highly polished, very well maintained and Canonical/Ubuntu go the extra mile to make the experience easy for the user. That comes at one or more of several costs:
Lack of choice - you get one mail client rather than a choice of several "out of the box", for example. Choices are made for you - it is an issue of supportability. Debian offers you more flexibility at the price of complexity or being willing to support your choices.
Lack of architectures: if you're not on Intel/AMD64 or, possibly, ARM/Sparc/PPC (depending on release) - you can't run Ubuntu. Debian running on 11 or so architectures does mean that a) the process is sometimes slow b) the code gets debugged c) is made portable/fixes are contributed upstream.
Canonical has relatively few paid developers, a highly motivated volunteeer developer community, a much larger community advocacy and marketing budget and a vast number of new users. This does mean that their developers are massively outnumbered by their users and priorities have to be set. Packages in universe/multiverse may therefore receive less attention than those in main in Ubuntu.
At least in theory, every package in Debian is equal and has a known named maintainer who takes an interest It does mean that Debian does much of the heavy lifting of packaging and initial support for out of the way packages - it also means that, if I want support for R and CRAN, for example, I'd go straight to Debian because the maintainer has a personal and professional interest for seeing it work well as an integrated system.
"We demand rigidly defined areas of doubt and uncertainty" - Canonical has those because it releases once every six months. This consistency comes at a price: users expect new whizzy features with each release and the development cycle is very short indeed. Long term support releases happen every other year and are supported for three years on the desktop/five years on the server. That's hard. It's very hard to support new hardware with long term releases. "Normal" releases may mix packages from Debian stable with testing, unstable or even experimental (whizzy features) but get only a short testing time.
Debian "releases when ready" but then supports that release until about a year after the next release. 22 months to release Etch, 22 months to release Lenny + 12 months = 56 months. Slow moving progress through testing to release, regular point updates with security fixes.
Freeness vs. pragmatism
Ubuntu may sometimes take a pragmatic attitude for "software that works" for users. They also have the ability, which Debian does not, to enter into commercial agreements for third party apps e.g. Oracle/VMWare. [DFSG - not "licence just for Debian"]. Canonical benefits from Debian idealism but it can't flow the other way
Upgrades between releases
You'll hear lots of views on this. Ubuntu is generally considered harder to upgrade cleanly between releases and it may actually be quicker to reinstall. You certainly can't skip a release (it's not even supported) so you'd need to do 8.04, 8.10, 9.04, 9.10 (for example). This is partly a consequence of short release cycles above. Debian doesn't support skipping a release either, but you have about 1 year to prepare for the upgrade and it's mostly smooth, especially if you take the time to read the Release Notes.
All of this is very well explained by The Official Ubuntu Book. It's also worth reading newsgroups/fora and planet.debian.org / planet.ubuntu.com to get a better appreciation of the similarities and differences in approach. Debian and Ubuntu each have strengths: it's a (sometimes uneasy) symbiosis - both distributions share many of the same developers, for example, but not necessarily end goals - but Debian would gain as much as Ubuntu if they'd just fix their bloody bug #1
My harddisks/usb sticks/external drives don't always have the same device name. How can I prevent this from happening?
You can't prevent it; this happens due to the way the kernel does device detection, but there are several methods to not let it be a problem. It seems the easiest method is to use labels instead of device names. Basically in fstab you just replace the /dev/sda1 (or hda2 or whatever) with a LABEL=mylabel. If you also have problems booting (because your / partition is assigned a different device name) you will also have to edit /boot/grub/menu.lst. Don't edit the real stanza because your changes will be overwritten on the next kernel upgrade. Instead find the line:
and replace it with
After you are done you must run update-grub as root.
Another alternative to using labels is to use UUIDs. You can find the UUID of a device with blkid(8).
As of squeeze all new installations will have /etc/fstab written with UUIDs and grub2 also deals with this correctly.
My ethernet card is named ethX instead of eth0, what's going on?
Udev is assigning the same device name to a card (based on its MAC), even if you removed every other card in the system. If you don't want this, you can:
remove /etc/udev/rules.d/70-persistent-net.rules. It will be recreated on the next reboot with numbering in the order the kernel sees the devices
edit /etc/udev/rules.d/70-persistent-net.rules. This is recommended if you have more than one card, since letting udev regenerate the file does not guarantee a specific order.
Debian is known for its robust, extensive and easy to use package system. The operations that can be performed with regard to package management are sophisticated, easily scripted, and make running Debian a relatively simple and mistake-proof experience. The following questions all deal with some aspect of the package management.
See PackageManagement for more information ...
Which is the best package manager?
While "the best" package manager is a matter of personal opinion, the Debian project and many Debian developers and users recommend aptitude. See here for more details.
Where is the foo package?
A variety of tools exists to answer this very frequent question: apt-cache search foo bar will return all the packages with both foo and bar in the name or description; aptitude search foo will return all packages with foo in the package name. These are just two of the many methods. Read man apt-cache or man aptitude as appropriate. Finally, http://packages.debian.org also features a handy search engine and don't forget your friend http://www.google.com.
Program foo is looking for (or lacking) file bar. Where is it?
This is simple: apt-file update && apt-file search bar. grep as appropriate. man apt-file.
What package contains file foo?
See previous question. If the file is already on your system dpkg should know about it (usually faster as well).
$ dpkg -S /path/to/foo
Please note that files under /home/, /usr/local/ and a few other places are not under the control of the package management. See the Filesystem Hierarchy Standard (also available as man page hier(7) ) for an explanation of how the files are organized on your system.
How can I prevent a specific package from being installed on upgrades?
Put something like
Package: unwanted-package Pin: version * Pin-Priority: -1 Explanation: prevent unwanted-package from being installed
in a file under /etc/apt/preferences.d/
Note that Package (and version obviously) accept patterns. See apt_preferences(5) for more information.
Should I be using upgrade/safe-upgrade or dist-upgrade/full-upgrade to keep my system updated?
It may help to understand what each command does:
apt upgrade: upgrade all packages, without installing or removing packages, even if this means some packages are not upgraded
apt upgrade or aptitude safe-upgrade: upgrade all packages, installing new packages if needed, but not removing packages, even if this means some packages are not upgraded
apt full-upgrade or aptitude full-upgrade or apt-get dist-upgrade: upgrade all packages and install new packages or remove installed packages if required
Of course, all these actions will actually ask for confirmation, so you might want to review the proposed actions before proceeding ;).
In practice the above means that running apt upgrade or aptitude safe-upgrade might be enough to keep your system updated, depending on whether you run stable, testing or unstable (or a mixed system). Because of this it is generally recommended to not use apt full-upgrade, apt-get dist-ugprade or aptitude full-upgrade unless it's really needed (packages have not been upgraded because removing packages is needed).
Note that aptitude in visual mode does not have an equivalent for aptitude safe-upgrade and pressing Shift-u will always prepare the equivalent of aptitude full-upgrade. This is because in the preview screen you still have the chance to review and adjust individual actions as needed.
Does Debian have Firefox/What is Iceweasel?
You really should see Where is the foo package? above, but previously Debian shipped with Iceweasel, a re-branded Firefox. That's since changed back and (currently) stable has Firefox-ESR. Take the following with a bit of salt.
See Firefox for more information ...
Firefox/Iceweasel has strange problems (segfaults, crashes, ...)
First try running with all extensions disabled by running
$ iceweasel -safe-mode
and see if that fixes your problem. Something else you can try is to (re)move your .mozilla directory or create a new user account.
Ubuntu/some other distro already has a newer kernel/Gnome/KDE/Firefox/other. When will Debian have it?
Short answer: most probably with the next release. See above for a quick explanation of how Debian releases work.
Long answer: Debian Developers are doing their best to package the software released upstream as soon as they consider it stable enough to be included in Debian so your package might already be available in testing, unstable or experimental. Unless testing is in the frozen stage (similar to a „Release Candidate”) new software is migrating from unstable to testing as soon as possible (which will then become stable on the next release), but it will never be included in the current stable release, because by definition the release must not change (apart from security fixes and some serious bugs).
If you still want to stick with stable (instead of testing or unstable) your best bet is to look at http://backports.debian.org for the packages you need.
You might think Debian is doing it wrong and should adopt the release policy of some other distro, but this system has proven its value over many years and it gives users a lot of choice. Various alternatives have been proposed over the years, but all of them have some disadvantages over the current scheme. Please do search the archives (also for the debian-devel and debian-project lists) before starting a new discussion over this issue.
I found this .deb package for a software I need, can I just install it on Debian?
That depends. If the package was created specifically for Debian (which version?) it might work, but you can't expect any support from Debian if it doesn't. If the package was created for Ubuntu or some other derivated distro chances are a lot smaller. You could try recompiling it (if the sources are also available) on Debian.
I am running a mixed system. How can I find out what packages are from which distribution?
You definitely like to play with fire if you got this far, but can't answer this simple question. OK, enough patronizing , try apt-show-versions.
I tried to remove a package and now many other packages are scheduled for (auto)remove
This usually happens because you are trying to remove a package that is a dependency of a metapackage. In such a situation all package managers will try to remove the metapackage as well, but as a consequence all dependencies of the metapackage are now considered unused and scheduled for (auto)removal. There are various solutions to this problem:
- Mark the other dependencies as manually installed and let the package manager remove the metapackage.
This will keep the other packages installed, but it has the downside that new dependencies of the metapackage will not be installed. This is not an issue for stable, only for testing, unstable or upgrades to a new release.
- Force the package manager to ignore the missing dependency and keep the metapackage installed.
This is dangerous unless you know exactly what you are doing and the package manager will keep complaining about broken packages. See next point for a better solution.
Use equivs to create a dummy package.
The package equivs can be used to ?create a dummy package to fullfil the missing dependency. This way you can keep the metapackage installed and the package manager will be happy. This however may not be worth the trouble compared to just keeping the package installed that you tried to remove in the first place.
Ask the package Maintainer to use Recommends: instead of Depends:.
If you think the package you are trying to remove should be optional you could ask the Maintainer to change the Depends: to a Recommends: via a wishlist bug. As usual when filling bugs, make sure it has not been asked before and also consider that the package Maintainer may have valid reasons to do it like this.
As of Debian 7.0 (wheezy) it is possible to install packages from different architetures on the same system. The most common use is installing i386 packages on amd64 (or vice-versa).
See Multiarch for more information ...
How can I enable Multiarch
If you are using a custom Linux kernel for 64-bit PC and want to run 32-bit programs, then you have to set the CONFIG_IA32_EMULATION Linux build configuration option, otherwise you won't be able to run 32-bit binaries.
As soon as you have APT and dpkg from wheezy installed you can do the following to activate Multiarch (assuming an amd64 system that needs i386 packages):
# dpkg --add-architecture i386 # apt-get update
Do I still need ia32-libs/ia32-libs-gtk ?
Probably no, see below.
If I'm trying to upgrade ia32-libs/ia32-libs-gtk I get a lot of i386 libraries installed
This is expected. ia32-libs/ia32-libs-gtk used to contain all those libraries. In order to ensure the same functionality now it depends on the corresponding i386 packages instead. You might be able to get rid of some of them, see below.
My non-Debian software has an amd64 package that depends on ia32-libs/ia32-libs-gtk, how can I get rid of ia32-libs/ia32-libs-gtk ?
If an amd64 package depends on ia32-libs/ia32-libs-gtk it is actually 32bit software and the vendor will probably also have an i386 package. Activate Multiarch, install the i386 package instead of the amd64 package and let APT handle the dependencies.
But APT wants to install a lot of i386 libraries now
Yes, this is expected, but unless your package has a lot of dependencies these should still be fewer than the libraries contained in the former (all-in-one) ia32-libs/ia32-libs-gtk packages, or the libraries depended on by ia32-libs/ia32-libs-gtk.
Will this break my system?
Probably not, but if you want to be on the safe side don't upgrade to wheezy before it is released.
Are cross-grades possible?
As of Jessie systemd is the default init system in Debian.
How can I prevent systemd from being installed on upgrades?
See the question above on how to prevent installation of a specific package on upgrades.
How can I temporarily boot with another init on Jessie?
Install the package sysvinit if not already present and boot with the parameter.
How can I prevent systemd to run as PID 1 (init) on Jessie?
Remove the package systemd-sysv and install one of the alternative Pre-Depends: of the package init (either sysvinit-core or upstart as of 2014-10-22)
Please note that some applications need components of systemd (mainly systemd-logind) and will therefore depend on the package libpam-systemd (which needs the package systemd to function properly and therefore depends on it). If you don't want to use systemd as PID 1, but want to be able to use applications that need systemd-logind you will also need to install the package systemd-shim. All of this can be done with just one command:
apt-get install sysvinit-core systemd-shim systemd-sysv-
(the '-' behind systemd-sysv means remove)
How can I remove the systemd package from my Jessie system?
If you want to remove the package systemd from your system you will also have to remove any package depending (directly or indirectly) on libpam-systemd. Your prefered APT tool should do this automatically if you try to remove the package systemd. See above for a different approach that requires keeping the systemd package, though only a few of its components will be used.
How can I remove any traces of systemd from my Jessie system?
Removing any traces of systemd from your system is going to be a bit more difficult, since many packages, including Essential ones, link against libsystemd (the systemd shared library, package libsystemd0 in Jessie). Removing this package will require recompilation of every package depending on it.
Please note the library is only used by other packages when they need to interact with systemd (or one of its components) and is otherwise inert.
Posting on debian-user
How should I post/reply to debian-user?
I asked my question according to the directions written at the "How should I post" question, but I still don't get an answer
Should I be subscribed to post to debian-user?
Debian has a policy of open mailing lists. This means most lists are open for anyone to write to (the occasional spam resulting from this is unavoidable, but only a minor inconvenience - the list has excellent filters). However, list subscribers can not guess if you are subscribed or not, so you should request replies to be CC'd to you (or set Reply-To accordingly).
Help! My e-mail address is available in your list archives for the spam-bots to harvest/Why aren't e-mail addresses scrambled?
Such a measure does not really help to fight the spam, just a symptom.
This list is littered with spam, do something about it!
Actually it is not. For every spam that makes it through the filters there are many thousands blocked. Besides, the filters are tuned to avoid any false positives. If you want to help (or at least not make it more difficult) please:
do NOT reply to spam, ever! (this makes it hard or even impossible to remove it from the archives, since it is now a part of a legitimate thread)
- do NOT quote spam, not even partially (this confuses the filters)
How can I get my postings/e-mail removed from the archives?
Short answer: you can't. Even if the archive administrators would do it for the official Debian archives, this list is available in several other places (gmane, googlegroups, ...) over which the Debian Project has no control. See also the official policy for more info.
I subscribed to the list, but my mailbox is flooded with mail
The debian-user mailing list has a very high volume of traffic, you should expect to get around 150 mails per day, but there are ways to cope with it:
- setup a filter to move all list mail to a dedicated folder (if you want it all) or even delete all list mail except specific threads (ex. the ones initiated by you)
- use alternatives:
- gmane is a mail-to-news gateway with an alternative nice web interface (subscription required?)
- googlegroups also carries debian-user if you prefer their interface (subscription required)
- debian-user is also available as a newsgroup (directly or via gmane)
- read the archives (but beware, it can take a while longer until a mail shows up there)
just unsubscribe. If you only want to receive answers to your posts you can ask for a CC (or set Reply-To accordingly)
use a decent mail client. It should support at least some way of threading (and sorting if not done by other means) and reply-to-list (if you plan to participate in discussions).
What is top-posting (and why shouldn't I do it)?
Both questions can be answered with this example (seen in some sig):
A: Because it messes up the way you read
Q: Why is top-posting bad?
A: Writing your answer before the question
Q: What is top-posting?
Why doesn't this list facilitate easy replies to the list (a.k.a. reply-to-munging)?
Short answer: it's against the standards. See this document for a thorough explanation. In case your email client doesn't support List-reply then please use Reply-to-all and delete all but the list address.
Can I ask a question about foo?
Don't ask to ask, just go ahead and post your question, but see also the question about offtopic.
What is considered offtopic for debian-user?
Generally anything that has no relation to Debian is offtopic on debian-user. If you really, really want to post about it:
consider posting to the offtopic list instead
do mention [OT] in the subject so that subscribers not interested can ignore your message
keep in mind that some subscribers are reading the list via very slow or unreliable connections and even a few kilobytes count
Asking questions about any software packaged for Debian is generally ok, especially if you can't tell if your problem is Debian specific or not (but do mention this).
Asking general usage questions about any software is generally discouraged since most projects have their own dedicated user lists.
It is of course acceptable to discuss Debian specific configurations/customizations (did you read /usr/share/doc/<package>/README.Debian first?) or ask for help with a version that is available in a current Debian release, but upstream does not support anymore.
Is it ok if I attach/include bigfile in my message or should I use a pastebin instead?
Many subscribers are receiving list messages via slow or expensive or unreliable connections. On the other hand email is not guaranteed to arrive in a specific order (just think about greylisting).
If possible, always make your post self-contained (consider users reading off-line and connecting only to send and receive messages).
Computer generated output of tens of lines should always be included or attached (beware to not break the lines). Log files (or dmesg output) will also be ok in most cases, but try to include only the relevant parts. Documents or images (screenshots) should never be posted and will probably be discarded by the list server anyway.
My posts are considered spam and rejected (or never show up)
I'm posting via gmail's servers, but I never receive my own posts (other list mail is fine)
Gmail has a somewhat different view of how a mail server should behave. Because there is already a copy of your mail in the Sent folder the incoming copy from the mailing list is silently discarded. But if another party responds to the message then this new message will be seen in the Inbox. And because it does it will pull in the original because it is a reply to it. Result? You don't see your own postings back from a mailing list until someone else responds to the thread.
If you still want to use Gmail for posting, here are a few possible workarounds:
- Simply be aware that your outgoing messages will be in your Sent folder until someone replies.
- Configure your mail client to save outgoing messages to the same folder. Most (all?) mail clients should be able to do this per folder.
Use a different account for receiving list mail. Most Debian lists (including debian-user) are open for anyone to post; so you don't need to be subscribed to be able to post. (You might however subscribe to the whitelist in order to help the anti-spam filters across all of the lists know your message is not spam.)
It seems Gmail considers this to be a feature and is not willing to change it, although requested by many users. You could try writing them about this as well, maybe they will eventually listen.