Package: systemd-sysv Pin: release o=Debian Pin-Priority: -1from the documentation, a priority less than 0 disallows the package from being installed. systemd-sysv is the package that would enable systemd as your default init (/sbin/init).
sudo dpkg --force-depends -i google-earth-stable_current_i386.deb
It has been all over the place. The Debian CTTE has chosen systemd over upstart as default init system by chairman call. This decision was overdue, as it was pretty clear that the tie will not change, and thus it will be up to chairman. There were no new positions presented, and nobody was being convinced of a different preference. The whole discussion had been escalating, and had started to harm Debian.
Some people may not want to hear this, but another 10 ballots and options would not have changed this outcome. Repating essentially the same decision (systemd, upstart, or "other things nobody prefers") will do no good, but turn out the same result, a tie. Every vote counting I saw happen would turn out this tie. Half of the CTTE members prefer systemd, the other half upstart.
The main problems, however, are these:
So please, everybody get back to work now. If there ever is enough reason to overturn this decision, there are formal ways to do this, and there are people in the CTTE (half of the CTTE, actually) that will take care of this.
Until then, live with the result of a 0.1 votes lead for systemd. Instead of pursuing a destructive hate campaign, why not improve your favorite init system instead.
Oh, and don't forget about the need to spell out a policy for init system support requirements of packages.
How to reduce your usage of debian-multimedia packages:
As you might be aware, the "deb-multimedia" packages have seen their share of chaos.
Originally, they were named "debian-multimedia", but it was then decided that they should better be called "deb-multimedia" as they are not an official part of Debian. The old domain was then grabbed by cybersquatters when it expired.
While a number of packages remain indistributable for Debian due to legal issues - such as decrypting DVDs - and thus "DMO" remains useful to many desktop users, please note that for many of the packages, a reasonable version exists within Debian "main".
So here is a way to prevent automatically upgrading to DMO versions of packages that also exist in Debian main:
We will use a configuration option known as apt pinning. We will modify the priority of DMO package to below 100, which means they will not be automatically upgraded to; but they can be installed when e.g. no version of this package exists within Debian main. I.e. the packages can be easily installed, but it will prefer using the official versions.
For this we need to create a file I named /etc/apt/preferences.d/unprefer-dmo with the contents:
Package: * Pin: release o=Unofficial Multimedia Packages Pin-Priority: 123
As long as the DMO archive doesn't rename itself, this pin will work; it will continue to work if you use a mirror of the archive, as it is not tied to the URL.
It will not downgrade packages for you. If you want to downgrade, this will be a trickier process. You can use aptitude for this, and start with a filter (l key, as in "limit") of ?narrow(~i,~Vdmo). This will only show packages installed where the version number contains dmo. You can now patrol this list, enter the detail view of each package, and check the version list at the end for a non-dmo version.
I cannot claim this will be an easy process. You'll probably have a lot of conflicts to clear up, due to different libavcodec* API versions. If I recall correctly, I opted to uninstall some dmo packages such as ffmpeg that I do not really need. In other cases, the naming is slightly different: Debian main has handbrake, while dmo has handbrake-gtk.
A simple approach is to consider uninstalling all of these packages. Then reinstall as needed; since installing Debian packages is trivial, it does not hurt to deinstall something, does it? When reinstalling, Debian packages will be preferred over DMO packages.
I prefer to use DFSG-free software wherever possible. And as long as I can watch my favorite series (Tatort, started in 1970 and airing episode 900 this month) and the occasional DVD movie, I have all I need.
An even more powerful aptitude filter to review installed non-Debian software is ?narrow(~i,!~ODebian), or equivalently ?narrow(?installed,?not(?origin(Debian))). This will list all package versions, which cannot be installed from Debian sources. In particular, this includes versions that are no longer available (they may have been removed because of security issues!), software that has been installed manually from .deb files, or any other non-Debian source such as Google or DMO. (You should check the output of aptitude policy that no source claims to be o=Debian that isn't Debian though).
This filter is a good health check for your system. Debian packages receive a good amount of attention with respect to packaging quality, maintainability, security and all of these aspects. Third party packages usually failed the Debian quality check in at least one respect. For example, Sage isn't in Debian yet; mostly because it has so many dependencies, that making a reliable and upgradeable installation is a pain. Similarly, there is no Hadoop in Debian yet. If you look at Hadoop packaging efforts such as Apache Bigtop, they do not live up to Debian quality yet. In particular, the packages have high redundancy, and re-include various .jar copies instead of sharing access to an independently packaged dependency. If a security issue arises with any of these jars, all the Hadoop packages will need to be rebuilt.
As you can see, it is usually not because of Debian being too strict or too conservative about free software when software is not packaged. More often than not, it's because the software in question itself currently does not live up to Debian packaging quality requirements. And of course sometimes because there is too little community backing the software in question, that would improve the packaging. If you want your software to be included in Debian, try to make it packaging friendly. Don't force-include copies of other software, for example. Allow the use of system-installed libraries where possible, and provide upgrade paths and backwards compatibility. Make dependencies optional, so that your software can be pacakged even if a dependency is not yet available - and does not have to be removed if the dependency becomes a security risk. Maybe learn how to package yourself, too. This will make it easier for you to push new features and bug fixes to your userbase: instead of requiring your users to manually upgrade, make your software packaging friendly. Then your users will be auto-upgraded by their operating system to the latest version.
Update: If you are using APT::Default-Release or other pins, these may override above pin. You may need to use apt-cache policy to find out if the pins are in effect, and rewrite your default-release pin into e.g.
Package: * Pin: release a=testing,o=Debian Pin-Priority: 912for debugging, use a different priority for each pin, so you can see which one is in effect. Notice the o=Debian in this pin, which makes it apply only to Debian repositories.
!?reverse-depends(~i) ~M !?essentialIt will display only packages with no direct dependency from another installed package and that are marked as automatically installed (so they must be kept installed because of a weaker dependency.
~i !~M ?reverse-depends(~i) !?essentialThis will catch "installed but not automatically installed packages, that another installed package depends on". Note that you should not blindly put all of these to "automatic" mode. For example "logrotate" depends on "cron | anacron | fcron". If you have both cron and anacron installed, aptitude will consider anacron to be unnecessary (it is - on a system with 24h uptime). So review this list, and see what happens when you set packages to "A", and reconsider your intentions. If it is a software you want for sure, leave it on manual.
from gi.repository import Gio s = Gio.Settings.new("org.gnome.libgnomekbd.keyboard") s.set_strv("layouts", ["de"])
The sysvinit version that hit unstable today has a grave bug if you have been running "startpar" or maybe "shell" style parallel booting. Read this bug report, if you have been using these (they were not enabled by default, so unless you've been giving parallel boot a try before, you should be ok.)
How to check if you are affected:
grep CONCURRENCY /etc/default/rcS
If this command says "startpar", then you ARE affected. If it says "shell" you MIGHT be affected. If you have not set CONCURRENCY or if it's "none" or "makefile", then you should be ok (according to the bug).
The workaround is as simple: just put either "none" or "makefile" in there, these are the only two values that are still distinct.
How to recover a broken system:
You should have a working system again.
I can only confirm that changing "startpar" to "none" helped me. I havn't tried "makefile" yet, and "none" seemed more likely to fix things.
Unless someone drops in as new maintainer, I'll file for removal of ModLogAn from Debian soon.
The software has been abandoned upstream for, well, a couple of years. It still works okayish (just the patterns need refreshing), and in fact I'm still running it. But there is plenty of software to replace it, and it seems as if many people go the Google Analytics way today.
Please speak up quickly if you care about ModLogAn, otherwise it's gone from Debian soon.
is a great game, with a unique mixture of puzzles with mouse skills and action. If you know the discontinued game Oxyd originally on the Atari ST in the 90s (also on Amiga and one version on DOS), then you know the principle of Enigma. Except that it has tons of more levels and is Open Source.
Some weeks ago, I uploaded a 1.10 pre-release (approximately milestone 5) to Debian experimental. This is the soon-to-be-released new version, using a new level file format (with a much extended API to make level development even easier, ~50% less code per level now), new levels (of course), updated graphics (including support for new graphics modes), ...
Unstable still contains version 1.01; the reason is simple that I knew there would be another 1.01 maintainance release coming. However I believe it doesn't offer much against the current unstable version; it largely marks an upstream release containing patches already in the Debian package (since communication with upstream is really good).
So I have now two choices: refreshing the Debian unstable package to the "probably last" 1.01 release upstream, or going straight for the 1.10 milestones to give enigma some extra testing.
Just a short reminder that the application phase for the Google Summer of Code 2009 is running.
So far, we have quite few applications. Deadline is April 3rd, 19:00 UTC. Usually applications arrive rather late, but still I have the impression that we have much less than the previous years. But less copy & paste, too.
If you are interested in doing a GSoC project at Debian:
I hope to see more applications - and good luck that we get enough slots for all of you!
P.S. as far as I can tell, current Debian Developers can be eligible as well, although it has also always been a goal of the project to get new contributors involved.
Congratulations to all developers (DDs or not, we have sponsored uploads, Debian contributors and such, too!) who contributed to the release of Debian GNU/Linux "lenny" 5.0. I must admit that I've been largely inactive recently, I just managed to keep the bugs on my remaining packages low. Funnily, just the day lenny was released I learned about a bug in Enigma on AMD64 that is probably worth fixing through proposed updates ...
From Roderich Schupp I received the following instructions:
cp /usr/share/doc/hal/examples/10-x11-input.fdi /etc/hal/fdi/policy/
And in order to set a default keymap:
<deviceinfo version="0.2"> <device> <match key="input.xkb.rules" contains="base"> <merge key="input.xkb.layout" type="string">de</merge> <merge key="input.xkb.variant" type="string">nodeadkeys</merge> </match> </device> </deviceinfo>
Into yet another custom file in this directory.
Thank you, I'm going to try that on my next reboot (which may take a week).
Xorg 1.4 in experimental is supposed to have input device hotplugging.
Does anyone have a Howto for Debian? I tried it, but I couldn't get it to hot-plug my USB mouse, so I'm back to using the regular mouse driver for it again, using the /dev/input/mice in-kernel-hack for hotplugging.
P.S. on a recent kernel, you might want to add
to a custom file in /etc/modutils/, in order to avoid your PC speaker showing up as regular audio device. You don't want your regular apps to consider your legacy PC speaker as audio device usually.
P.S. No, my blog doesn't have comments. Just send me an email (you know, 'legacy' email) via erich AT debian org.
Today, I uploaded a new version of my firewall configuration tool, pyroman, to Debian unstable.
About 4 hours later I googled for "Pyroman Debian" and was surprised to find the upload notification in the top results. The first hour of this was probably spent with me doing some package function tests (I don't want to upload broken packages, after all), then the announcement was distributed to the -changes mailing list at Debian, which in turn was picked up by Google Groups.
However that might be due to groups.google.com getting special treatment, though. For this resource, Google can actually trigger an update instead of having to have a spider frequently re-crawl all the contents.
Still I find it pretty impressive to have such new data already in their main index. I was used to this e.g. for blog and news search, but not for regular web search.
The Summer of Code wiki page in the Debian Wiki has been updated with an overview of the projects that made the race for the 13 slots we have.
A separate press release (containing a short paragraph on what each project is about) is in preparation and will be out soonish.
We've received another of the last minute slots (thanks to those organizations which returned some of their assigned slots) to a total of 13 this year.
We have received some very good application, and we'll be able to fill these 13 slots easily with very good applications working on a variety of topics.
The results will be published on Monday, since there may still be minor changes in which students are accepted or who didn't make it to the top slots.
[Yes, this post was written on April 1st and is not to be taken serious.]
The usability experts of Ubuntu have finally started to handle the single most mentioned usability issue with Linux: the top level directory names.
Quoting Finn C. Tional from the Ubuntu Usability Group:
It's one of the mysteries of Unix that the directory named "usr" is not for user data, and the directory named "etc" while looking like random stuff thrown together stores all the important config files. [...] This is probably the single most confusing hurdle for new Unix users. [...] We need to finally tackle this, before people are too used to these odd directory names.
Therefore, they propose the following renaming scheme:
/bin /system/executables /boot /system/boot /dev /system/devices /etc /system/config /lib /system/libraries /home /users /media /storage /mnt /storage /proc /system/processes /root /users/Administrator /sbin /system/executables/admin /tmp /system/temporary /usr /system/applications
They'll include a patch for the GNU C library as well as for AppArmor to redirect the old path names to the new ones. Given the existing filename matching already done by AppArmor the overhead is expected to be neglible at least for AppArmor enabled systems. SELinux enabled systems will remain unchanged, since the user won't be allowed to see anything potentially irritating in the root directory anyway, but will be confined to his user directory.
Since there are a dozen applications that will need changes to accomodate the new naming scheme, expect these changes only to be included with Ubuntu 10.4 (also lovingly named Ubuntu X) scheduled for April 2010.
Other distributions are expected to follow up with these changes in 2011.
P.S. Yeah, the Ubuntu folks really need to think this throuh some more. Russel pointed out that "My System" is even easier to understand; after all this is not about someone elses system or some systematic error or whatever. I figure he's right. How about "My Computer" than this lowercase (pessimistic?) "system" directory they're proposing there!
So far, we have rather few applications - much less than last year. This doesn't seem specific to Debian, other organizations have also been reporting fewer applications, and Google is considering a deadline extension. Maybe the low number is related to Easter holidays. Also at least at my university the summer term will start only on April 1st, just past the deadline. So many students probably are still away in holiday.
Anyway: if you are interested in participating in the Google Summer of Code, chances are still pretty good. We don't have too many applications yet; not even all of the projects on the Wiki Ideas page have received a submission yet, only a few have received more than one; and even with those a well-written submission standas a good chance. Also some new ideas have been added in the meantime.
In particular missing from our submissions list are:
(see the Wiki page for details on these projects).
Especially the lack of a submission for the MergeMaster port is surprising. Many people would love to see a good configuration file merging tool in Debian. I can only guess that people are thinking "awh, everybody is going to submit an application for this one, I don't have a chance here". You currenlty DO have a chance, because there is no single proposal in for this one yet!
If you have any questions, IRC channel #debian-soc in OFTC is pretty useful.
Debian is part of the Google Summer Of Code again this year (2008).
Last year was quite successful, so we hopefully will get at least as many slots as last year.
Applications will be possible March 24th to March 31st. This means, you should already starting writing your project proposals and get feedback by possible mentors. Ideas can be found in the Debian Wiki, but notice these are just ideas. You are by no means limited to what we're proposing there.
As for writing an application, here are some general notes:
In turn, we (= the mentors and admins) will try to (again - we did that last year) have at least three mentors read through your application, provide feedback on it and judge it. We don't draw lots for the slots, but we'll rank the applications based on the scoring by the mentors. We'll also try to assign you a fallback mentor in case your mentor has to step back for whatever reason and to give you additional people to talk to.
... was a lot easier than expected. Just not very well documented.
First of all, you need the appropriate utilities. Debian users can aptitude install libsmbios-bin
Next identify your system. It will look something like this
$ sudo modprobe dcdbas $ sudo getSystemId Libsmbios: 0.13.10 System ID: 0x01D8 Service Tag: ...REMOVED... Express Service Code: ...although my warrany is over... Product Name: MXC061 BIOS Version: A10 Vendor: Dell Inc. Is Dell: 1
The information you need is the "System ID".
Now you need to get the so-called HDR file for your bios. This can either be extracted from their EXE file using wine (with -dump-hdr or so), or you can find it on the linux.dell.com server. This page contains a huge list, and there are tons of dirs like system_bios_ven_0x1028_dev_0x01d8_version_a10. 0x1028 apparently is "Dell". The second hex number is your System ID. The last number (A10 here) is the BIOS revision. Pick the appropriate directory. There should be a bios.hdr file in there.
You can verify if the file is appropriate for your system:
$ sudo dellBiosUpdate -f bios.hdr -t
And do the update by calling
$ sudo modprobe dell_rbu $ sudo dellBiosUpdate -f bios.hdr -u
When rebooting the next time, your screen might be garbled for a few seconds. At least it was for me. I was scared I might have trashed my system, but then it rebooted and had the new BIOS. So just give it some time (Fortunately I've done enough BIOS updates to know to just wait. I've even done a 'blind' video BIOS update on a Nvidia TNT. The first update had trashed the card, but I was able to redo the flash process without seeing anything on the screen, and guess what, the card worked again!)
In case you're wondering how this works: as I understand it, the dell_rbu driver will reserve memory for the BIOS update. Being a kernel module, it can just lock the memory in place until the next reboot. It will store that address in CMOS for the Bios and set the update flag. On reboot, the current Bios will check if that the stored image is still intact (I bet they do some checksumming here!) and then load that into the BIOS flash. That way, you don't need to boot into a low-level system such as Dos or Dos-Mode anymore to do an update.
Well, I havn't seen this recently. Maybe because aptitude has rename 'upgrade' do 'safe-upgrade', to make it obvious, that 'dist-upgrade' might do unwanted things.
Back when I was the maintainer of the galeon webbrowser package, I got bug reports and reports on IRC each time the mozilla packages was updated.
The galeon package used to have a conflict with mozilla of any newer major version than the one it was built with. This was a good thing - mozilla APIs were chaning, and when Mozilla was upgraded from let's say version 1.5 to 1.6, it would break galeon. Galeon would at least need to be recompiled or might even need source changes. So there was plenty of reason to add this conflic.
People were using 'dist-upgrade' all the time, and what dist-upgrade did then was to upgrade the mozilla package by removing galeon. And they couldn't even install galeon back again, because the new mozilla had replaced the old mozilla in unstable. And each time, I basically had to tell people "well, you shouldn't have used 'dist-upgrade', it's for upgrading between major version of Debian, not for daily use.
In fact, running dist-upgrade right now would uninstall 'iceweasel-dom-inspector' for me. I guess this is exactly due to the same reasons.
I'm wondering whether we should maybe do a 'uninstall-ok' list (or 'dist-upgrade-hints') and ship it with the distribution. I'd then modify the 'dist-upgrade' command to
Note that I'm not suggesting to automatically remove any package. It also is not supposed to be a list with all packages that ever were removed. But just packages where it's known that they might need to be removed. Nor is this list meant to do away with aptitudes automatic uninstalling of packages that were only installed to satisfy dependencies. (If you are still using 'apt-get', you should really consider to use 'aptitude' instead. It will automatically uninstall all those 'libfoo13' packages for you if you use it consequently. Whenever you install a package with 'apt-get', aptitude won't know if it was manually selected or automatically, and assume manual.)
So let's say there was experimental-browser in some revision, built with mozilla version 1.7, and conflicting to mozilla 1.8. The browser is discontinued, and ends up in the 'uninstall-hints' file. If the user does a dist-upgrade, it will be removed as usual.
However, if 'galeon' has such a conflict and is still alive, it won't be listed in unstables 'uninstall-hints' file, and thus not considered for automatic uninstallation. So people who unnecessarily run dist-upgrade will still suffer less (unless they chose to remove it anyway!)
However, if the user has built his own 'custom-webbrowser' package, it will cause a bigger warning when running dist-upgrade, because aptitude doesn't have that package in the hints file. So the users of local packages actually have a benefit here, too.
P.S. Sorry; I don't have time to follow planet debian these days. Still if you have feedback it's recommended to use planet or the mailing lists!
I wasn't aware of the "network-test" command in Debian, but it's actually quite neat:
INFO: This system has exactly one default route INFO: Host localhost answers to ICMP pings INFO: Loopback interface is working properly [...] INFO: The wifi0 interface has tx and rx packets. INFO: The router 192.168.2.1 is reachable INFO: This system is configured to use nameserver 192.168.2.1 INFO: Host 192.168.2.1 answers to ICMP pings INFO: Dns server 192.168.2.1 resolved correctly www.debian.org INFO: The nameserver configured for this system works properly INFO: System can reach Internet host www.debian.org INFO: System can access web server at Internet host www.debian.org
It does a quick network debugging output. I'd s/Dns/DNS/ though.
DRI (3D acceleration) stopped working for me. The reason is simple (as revealed by looking at the Xserver log file): it was missing the DRI library for my graphics card.
So if 3D acceleration isn't working for you anymore, try this:
aptitude install libgl1-mesa-dri
This package includes the library required for DRI on my Intel 915 graphics board. Not sure how it got lost, though. Maybe I purged it when trying to remove "unneded" packages from my system (in order to free up some space)... I tend to try to uninstall everything I don't think I need.
P.S. Looks like you can now but ATI/AMD graphics again, given that they're releasing specifications for their chips - reliable opensource drivers on the horizon!
I've fought both the Nvidia and old ATI driver hell - not having to do that was one of the main reasons why I wanted Intel graphics. Now ATI/AMD is back on my radar.