preseed/late_command="in-target apt-get install -y sysvinit-core"or by using a preseeding file (which is a really nice feature I used for installing my Hadoop nodes) to do the same:
d-i preseed/late_command string in-target apt-get install -y sysvinit-coreIf you are a sysadmin, using preseeding can save you a lot of typing. Put all your desired configuration into preseeding files, put them on a webserver (best with a short name resolvable by local DNS). Let's assume you have set up the DNS name d-i.example.com, and your DHCP is configured such that example.com is on the DNS search list. You can also add a vendor extension to DHCP to serve a full URL. Manually enabling preseeding then means adding
auto url=d-ito the installer boot command line (d-i is the hostname I suggested to set up in your DNS before, and the full URL would then be http://d-i.example.com/d-i/jessie/./preseed.cfg. Preseeding is well documented in Appendix B of the installer manual, but nevertheless will require a number of iterations to get everything work as desired for a fully automatic install like I used for my Hadoop nodes.
# /etc/pyroman/02_icmpv6.py:82 -A rfc4890f -p icmpv6 --icmpv6-type 255 -j DROPindicates that this particular line was produced due to line 82 in file /etc/pyroman/02_icmpv6.py. This makes debugging easier. In particular it allows pyroman to produce a meaningful error message if the rules are rejected by the kernel: it will tell you which line caused the rule that was rejected.
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.