Search Results: "rul"

24 December 2009

Cyril Brulebois: Blender 2.50 alpha 0

After a while playing around with the build system, with python 3.1 (which is required), etc., I finally got around to upload a Blender package for 2.50 alpha 0, just uploaded to experimental (hopefully) given python 3.1 is only available there. Potential users really want to read the NEWS file. One can also check the upstream release logs. For those wondering about the version number, it had to be >= 2.49, and upstream doesn t seem to be sure about the versioning, since it can be 2.5 on the website, 2.50 as SVN tag, etc. I m not going to introduce an epoch right now. ;) It certainly has some rough edges, but testing and reporting are more than welcome.

Jonathan McDowell: Neat find of the day: inputlirc

I've recently been fixing up my VDR setup to work with FreeSat and make it brother/parent friendly. I've applied the EPG patches to get the 7 day guide, setup an autologging in user under gdm with vdr-sxfe running and that left getting the remote working. For some reason my old serial dongle wasn't happy with lirc - it got detected ok, and would show some signal when buttons were pressed but didn't work with the old config. The entire hardware of the box has changed, so it seems likely something isn't quite right (in particular the lirc drivers spew out warnings about SMP bits so I should probably try the dongle under a single core setup to rule that out, but there's also a move to 64 bit involved).

The easy solution to have something sorted for Christmas was to pickup a cheap remote from eBay. This ended up being a Cyberlink remote + USB dongle combo. Worked just fine when plugged in, turning up as a normal input device and the obvious keys doing the obvious things. I wanted all the keys to work though, as I'd got used to having a lot of the VDR functions instantly accessible rather than having to work my way through the menus. Various searches suggested I'd need to use LIRC to access the odder keys. That seemed a lot of hassle for something that was doing the decoding itself. Some playing with xev turned up keycodes for a number of the keys, but there were still a few missing (and important ones at that, such as Red/Green/Yellow/Blue). Further digging found me a suggestion of an Xorg keyboard map that would map the KEY_RED etc from the evdev device into something workable under X. And then I found inputlirc via the Debian package. This is really bloody neat - point it at an evdev device and it will present all of the KEY_* codes out as lirc keys. If you pass the -g parameter it makes sure the key presses only go to lirc as well. Exactly what I want and a doddle to setup - no messing with a big configuration file, just edit /etc/defaults/inputlirc to point to the correct /dev/input/by-id/ file, add the -g to the options in that file and restart.

Now the main remaining task is to get it working with BBC/ITV HD.

20 December 2009

Stefano Zacchiroli: RC bugs of the week - week 15

RCBW - week #15 Here are last weektoday squashes, by yours truly: Some highlights:

Christian Perrier: Font packages moved to source v3

Today, Hideki Yamane completed his work on the last four packages maintained by the Font packaging Team to make them switch to source v3. Along with these changes, we also moved all our packages to debhelper v7 and minimal rules files. We also dropped the dependency on the obsoleted defoma. The team maintains 77 source packages for fonts and has now built a quite solid experience in this. In the upcoming weeks, I'll try to get in touch with other people who maintain fonts, inviting them to join the team and maintain their packages in our SVN (we don't do very fancy things so SVN is very well suited for such work). The maingoals will be to continue dropping support for defoma (dropping defoma hints files: you can see good examples on how to do this properly in packages maintained by the team, such as ttf-dejavu). We also intend to drop useless Recommends or Suggests that appear in some font packages (often on "x-ttcidfontconf fontconfig" which is now completely useless) as well as harmonizing package naming schemes (with a "(ttf otf)-<foundry>-<fontname>" scheme). Feel free to join and share your advice and thoughts about The Right Way To Maintain Font Packages on our mailing list.

Francois Marier: Debugging logcheck rule files

logcheck is a neat little log file monitoring tool I use on all of my machines.

I recently noticed however that I hadn't received any logcheck messages in a while from one of my servers. Either that was a sign that things were going really well or, more likely, that logcheck wasn't producing any output anymore.

Manually logging an error to syslogHere's what I did to force a message to be printed to the logs:
logger -p kern.error This is a test
Which I would expect to produce this logcheck notice:
Dec 20 15:34:08 hostname username: This is a test
Unfortunately, that didn't happen on the next scheduled run.

Forcing a logcheck runTo rule out the following:
I ran logcheck manually:
sudo -u logcheck /usr/sbin/logcheck -o -d >& logcheck.out
Looking at the output file however, my test message still wasn't there. Either logcheck was broken or one of my rule files was swallowing everything.

Finding the broken rule fileTo find the broken rule, I started by ignoring rules defined in /etc/logcheck/ignore.d.server/ and /etc/logcheck/ignore.d.workstation/ by running logcheck in paranoid mode:
logger -p kern.error This is a test
sudo -u logcheck /usr/sbin/logcheck -o -d -p >& logcheck.out
This worked, so I then ran logcheck in server mode:
logger -p kern.error This is a test
sudo -u logcheck /usr/sbin/logcheck -o -d -s >& logcheck.out
Given that this also worked, it meant that the offending rule file was in /etc/logcheck/ignore.d.workstation/. So I moved all of my custom local-* rule files out of the way and ran logcheck in workstation mode:
logger -p kern.error This is a test
sudo -u logcheck /usr/sbin/logcheck -o -d -w >& logcheck.out
Once I verified that this worked, I started to put my local files back one by one until it broke again. Then slowly removed lines from the offending file until it worked.

Solution to my problemIt turns out that one of my rule files had a line like this:
path != NULL   column != NULL
Escaping the pipe symbols with backslashes solved the problem:
path != NULL \ \  column != NULL

Maybe I should periodically print a message to syslog to make sure that logcheck is still working...

19 December 2009

Frans Pop: debmirror IV

The Debian FTP-masters recently changed the way gzipped meta files are compressed in order to make them more efficient to update using the rsync option. This was done by adding the --rsyncable option when calling gzip. Consequence was however that when debmirror compressed Packages, Sources and Contents files after updating them by applying diffs, the md5sum of the gzipped file created by debmirror no longer matched the md5sum listed in the Release file (because debmirror did not use --rsyncable). Result was that debmirror would also download the full gzipped Packages, Sources and Contents files from the parent mirror, something the diffs are meant to avoid. Not nice. Anyway, this has been fixed in debmirror 2.4 which now by default also uses --rsyncable when gzipping the updated meta files. I've also uploaded a fixed version for Lenny (20070123lenny1), which should soon be available from proposed-updates and will be included in the next stable point release. For archives that also provide diffs (most archives don't have them) but do not have rsyncable gzipped files, the default options used when calling gzip can be overruled using the new option --gzip-options (only in version 2.4). Tip: if you are using the rsync method to download files, using --diff=none may well be more efficient now that the archive has rsyncable gzipped meta files. Version 2.4 also has a few other improvements and fixes. If you're currently using version 2.3.x an update to the new version is probably a good idea.

18 December 2009

Robert Collins: Why upstreams should do distribution packaging


Software comes in many shapes and styles. One of the problems the author of software faces is distributing it to their users. As distributors we should not discourage upstreams that wish to generate binary packages themselves, rather we should cooperate with them, and ideally they will end up maintaining their stable release packages in our distributions. Currently the Debian and Ubuntu communities have a tendancy to actively discourage this by objecting when an upstream software author includes a debian/ directory in their shipped code. I don t know if Redhat or Suse have similar concerns, but for the dpkg toolchain, the presence of an upstream debian directory can cause toolchain issues. In this blog post, I hope to make a case that we should consider the toolchain issues bugs rather than just-the-way-it-is, or even features. To start at the beginning, consider the difficulty of installing software: the harder it is to install a piece of software, the more important having it has to be for a user to jump through hoops to install it. Thus projects which care about users will make it easy to install and there is a spectrum of ease. At one end,
checkout from version control, install various build dependencies like autoconf, gcc and so on
through to
download and run this installer
Now, where some software authors get lucky, is when someone else makes it easy to install their software, they make binary packages, so that users can simply do
apt-get install product
Now some platforms like MacOSX and Microsoft Windows really do need an installer, but in the Unix world we generally have packaging systems that can track interdependencies between libraries, download needed dependencies automatically, perform uninstalls and so on. Binary packaging in a Linux distribution has numerous benefits including better management of security updates (because a binary package can sensibly use shared libraries that are not part of the LSB). So given the above, its no surprise to me to see the following sort of discussion on #ubuntu-motu:
  1. upstream> Hi, I want to package product.
  2. developer> Hi, you should start by reading the packaging guide
  3. (upstream is understandably daunted the packaging guide is a substantial amount of information, but only a small fraction is needed to package any one product.)
or (less usefully)
  1. upstream> Hi, I want to package product.
  2. developer> If you want to contribute, you should start with existing bugs
  3. upstream> But I want to package product.
Another conversation, which I think is very closely related is
  1. developer> Argh, product has a debian dir, why do they do this to me?!
The reasons for this should be pretty obvious at this point:
  • Folk want to make their product easy to install and are not themselves DD s, DM s or MOTU s.
  • So they package it privately such as in a PPA, or their own archive.
  • When they package it, they naturally put the packaging rules in their source tree.
Now, why should we encourage this, rather than ask the upstream to delete their debian directory? Because it lets us, distributors, share the packaging effort with the upstream. Upstreams that are making packages will likely be doing this for betas, or even daily builds. As such they will find issues related to new binaries, libraries and so on well in advance of their actual release. And if we are building on their efforts, rather than discarding them, we can spend less time repeating what they did and more packaging other things. We can also encourage the upstream to become a maintainer in the distro and do their own uploads: many upstreams will come to this on their own, but by working with them as they take their early steps we can make this more likely and an easier path.

Jurij Smakov: Slow boot

For a very long time my laptop (running sid for a few years now) has been booting kind of slowly. It looked like there was a 2-3 second delay every time a kernel module was loaded, which resulted in something like 3 minutes total boot time. Never bothered me enough, but yesterday I've finally got some time to investigate. After increasing the verbosity of udev logging in /etc/udev/udev.conf I've found lots and lots of messages like this in the log: 
Dec 18 00:41:46 droopy udevd-work[425]: wait for '/sys/some/path/bInterfaceProtocol' for 20 mseconds
The only udev rule file containing a reference to bInterfaceProtocol was /etc/udev/rules.d/z60_libccid.rules with the following lines in it: 
# last file created by the kernel, if this is present everything should be
WAIT_FOR_SYSFS="bInterfaceProtocol"
The libccid package itself is long gone (I don't remember installing it at all), and the versions of the package starting with 1.3.4-1 (uploaded in February 2008) do not contain this rule. However, the file survived on my system, so this rule was continuing to trigger for every device, even the ones not providing the bInterfaceProtocol at all. Removing the now-redundant file resulted in a dramatic boot speedup (it now takes about 30 seconds), so if you are experiencing similar problems, you might want to check it out.

14 December 2009

Russell Coker: Nagios and SSL in Debian

I was doing some work on NRPE (the Nagios Remote Plugin Executor) and I noticed bug report #547092 [1] which concerns the fact that the default configuration uses the same SSL certificate for all Debian servers and provides a patch to fix the problem. After building the patched package I followed the advice of the DebianAdministration.org article on creating self-signed SSL certificates [2]. cert_file=/etc/ssl/certs/FOO-cert.pem
privatekey_file=/etc/ssl/private/FOO-key.pem
cacert_file=/etc/ssl/certs/cacert.pem Then I added the above lines to /etc/nagios/nrpe.cfg to instruct the nrpe to use the certificates. For the Nagios server I had the problem that most of the systems I monitor run old versions of NRPE while only a few are recent Debian systems that allow me to easily install a new SSL checking nrpe. So I installed the following script as /usr/lib/nagios/plugins/check_nrpe to run either the old or the new check_nrpe: #!/bin/sh -e
if echo $2 egrep -q server0\ server2\ mail ; then
/usr/local/sbin/check_nrpe -C /etc/cert/cert.pem -k /etc/cert/key.pem -r /etc/cert/cacert.pem $*
else
/usr/lib/nagios/plugins/check_nrpe.orig $*
fi The reason I started working on Nagios was to try and solve bug #560002 [3] which I filed. The bug concerns the fact that applications such as mailq which are run as part of Nagios checks were inheriting a TCP socket file handle from the nrpe. SE Linux prevents such file handles from being inherited, but it does mean that I get audit messages (and this is not a good case for a dontaudit rule). Update:
One thing I forgot to mention is that the SSL key checking requires that the server common name used in the SSL certificate of the nrpe system matches the name that is used by the check_nrpe program. So if you check by IP address then you need to use the IP address in the certificate name which is rather ugly. So I have moved to putting the hostname of each server in /etc/hosts on the NAGIOS system and using the hostname in the SSL certificate. This required using $HOSTNAME$ instead of $HOSTADDRESS$ in the NAGIOS configuration (thanks to John Slee for a tip in that regard). Update2:
I removed some printf debugging from the script. It seems that I included a pre-production version of the script in the first version of this blog post.

Stefano Zacchiroli: RC bugs of the week - week 14

RCBW - week #14 Here are thislast week squashes, by yours truly: Some highlights:

13 December 2009

Julian Andres Klode: MySQL


If Oracle owned MySQL, it would not make a big difference with regards to competition on the database market. Oracle would then own 2 relational databases. But there is also the BSD-licensed PostgreSQL, the world s most advanced open source database with several enhanced products from companies. If Oracle closed MySQL, the community would step in. I truly believe that the free software community is strong enough to support MySQL. There already is MariaDB and I believe that this project could serve as the base in case Oracle closes MySQL or stops MySQL completely. The community was strong enough to build complete operating systems and maintain them, so it should not be that hard to support one database. All in all, I don t see how Oracle buying Sun (and thus MySQL) could negatively influence competition in the database market, and I would therefore recommend the EC to approve the Oracle-Sun deal as it, without imposing any conditions on Oracle. Posted in General

11 December 2009

Yves-Alexis Perez: PDF Presenter Console

For some reasons, I had to create some slides, and it's been some time I wanted to do some latex/beamer, so I jumped in and created them using vim (hating latex/beamer a few times in the process, but that's expected. At least, I didn't have to hate OpenOffice this time). Now, when presentation time comes, I started missing the nice Presenter Console extension for OpenOffice. It's a nice extension which (a bit like Keynote) (and maybe other) enables you to seperate the beamer and laptop screens. So you put on the beamer the presentation itself, and on the laptop one you can put you notes, the next slide preview, a nice countdown etc. Really useful, but it's only for OpenOffice (or PowerPoint) slides, not for pdf ones. So I started looking at PDF readers which could do that, and found multiple solutions: So in the end, I was almost ready to submit a bug report to epdfview (which I already maintain in Debian) asking for that new feature, when I found PDF Presenter Console which does exactly what I want. I'm not sure the project is really active at the moment, and I had some problems with the tool not detecting one of the screen (so it only appears on the beamer, or only on the laptop). It might be related to xfwm4 or something, I already contacted the developer about that. In the end, it's not 100% reliable (so I'm not yet packaging it for Debian) (especially since it uses CMAKE) but once it started, it does the job pretty fine. That's just something I wanted to share in case people would be interested.

8 December 2009

Christian Perrier: Bug #560000

Mika Tiainen reported the Debian bug #560000 on Tuesday December 8th, against the ferm package. Bug #550000 was reported as of October 7th 2009. So, again, no matter what, we're still keeping up with the very regular "10,000 bugs in 2 months" pace This time, I would like to highlight a specific bug that missed to be #560000 by very few hours: namely "#559980: aptitude: Totally broken on GNU/kFreeBSD". Please read that bug report and take time to send Cyril "KiBi" Brulebois a nice "Chapeau" ("hat off") for the time he invested in analyzing this bug and providing a good workaround. Update: KiBi told me that his workaround is broken. Still, the "hat off" still stands as what impressed me is more the nice investigation work than the workaround itself. Of course, admittedly, Cyril is not alone doing such work but it never hurts telling good people they are doing good work. To all Planet readers: <Teletubbies mode ON>from time to time, please remember putting more light on those people doing great and sometimes obscure work in our project</Teletubbies>. After all, blogs are not only about ranting, right? :)

7 December 2009

Martin F. Krafft: Securing e-mail communication across clients/OSs

Dear lazyweb: I am in a dreadful situation! I need to secure e-mail communication between five types of users: To make matters worse: there is no common provider or server infrastructure, so the solution must work across providers and mailboxes.

Requirements
  • Human error should be anticipated and prevented.
  • Mail between all parties must be encrypted (and signed) automatically. If encryption is not possible, the mail must not be sent. This includes the situation where not all mail recipients keys are known;
  • Ideally, one can define rules (using wildcards or regular expressions) to enforce certain policies.
  • Mail to other parties may be signed, and it would be good to be able to turn this on and off by default;
  • The MIME standard should be employed so that the mail body is not altered, and attachments can be seamlessly encrypted too. Existing MIME parts should be encapsulated as children of a new multipart tree;
  • Incoming mail should be automatically and seamlessly decrypted/verified, and the user must be alerted if the verification fails.
Ideally, the solution will be open-source. However, if proprietary software performs better, then we will gladly use that where required.

Previous attempts So far, we ve tried (and were let down by)
  • GpgOL, which has very irky and brittle integration with Outlook and can only do inline signing/encryption.
  • S/MIME, which seems supported by all involved clients, but Outlook does not really allow you to specify policies. Encryption seems to be opportunistic at best, which is not enough.
  • GPGrelay, which is promising because transparent, but apparently messes with MIME, and I am unsure whether it can fit between Outlook and Exchange. I have yet to run real tests though. If you are a GPGrelay user, or you d like to try it (it s Windows-only), please get in touch.
  • WinGEAM, but that apparently no longer exists, and neither is the underlying GEAM.

Help! Does anyone have proper suggestions over what to use? In fact, if you are interested in devising a solution, or even deploying it, there s money to pay you for those services. Write in if you are interested.

Cyril Brulebois: RBCN

I really liked doing stuff like Zack s RCBW in the past, but nowadays I m busy with some buildds, reporting RC bugs because some maintainers don t test their uploads, as well as posting patches to fix FTBFS on GNU/kFreeBSD. But from time to time, it s also fun to close RC bugs. Here s a new concept (that I probably won t reproduce as regularly as Zack and his minions, though): RCBN for Release-Critical Bugs of the Night. Those are now closed: Many thanks to Peter Green, to Ruben Molina, and to Ilya Barygin for their patches. Special thanks to Richard Darst for orpie s patches: he even managed to get rid of embedded code copies while addressing the FTBFS. Nice! Unfortunately, in the same time, I had to open some FTBFS/RC bugs: So, what s next? Get back to work!

6 December 2009

Cyril Brulebois: Early december announcements

Some uploads this week:

Stefano Zacchiroli: RC bugs of the week - week 13

RCBW - week #13 Here are this week squashes, by yours truly: And here are the usual highlights:

5 December 2009

Russ Allbery: backport 1.22

This is a new version of my script to automate some of the work of backporting Debian packages. This version sets the urgency of the changelog of the backport to the highest urgency of the changelogs included in the *.changes file and allows adding an additional entry to the changelog of the backport. It also handles a distribution of etch-backports properly. I unfortunately had to revert the change in the previous version to use -nc, since unaccountably using -nc to suppress running make clean before building the source package forces a binary package build that doesn't include the source package in the *.changes file. I filed a bug against dpkg about this. In the meantime, you'll continue to need to satisfy the requirements for debian/rules clean outside of any build chroot. This version also adds some automated backporting logic that I needed for the Shibboleth packages. You can get the latest version from my miscellaneous scripts page.

2 December 2009

Margarita Manterola: tzdata screwed up most computer clocks in Argentina.

Last year, after many years of peacefully living the whole year in GMT-3, our government decided that Argentina should use DST again. This was done in a rush, but patches were written and applied everywhere to have a correct timezone. Fixing the problem was not enough, tzdata's upstream decided to predict the future: 
# From Paul Eggert (2007-12-22):
# For dates after mid-2008, the following rules are my guesses and
# are quite possibly wrong, but are more likely than no DST at all.
Rule    Arg 2007    only    -   Dec 30  0:00    1:00    S
Rule    Arg 2008    max -   Mar Sun>=15 0:00    0   -
Rule    Arg 2008    max -   Oct Sun>=1  0:00    1:00    S
Well, back in December 2007, October 2008 might have seemed like a long time in the future, and they assumed that sometime in the middle the correct date would be announced... But, predictably (knowing Argentina's current government), no DST has yet been announced. However, Paul Eggert's guesses had propagated to almost all UNIX distributions, so that at 0:00 Sunday Oct 5th, all our computers were suddenly one hour ahead of time. Affected systems: Debian, Ubuntu, Gentoo, Red Hat, OpenBSD, FreeBSD, Mac OS. Devices: ipod, maemo, Nokia N95. Websites: Clarin (a major newspaper - still broken 36 hours later), Gmail. And probably many others that I don't know of. I even read that Windows was affected, although I don't know how that might be possible, since as far as I know they don't use tzdata. Anyway, not satisfied with how they mistakenly predicted the future before, a few weeks ago (not enough time in advance to fix almost any systems, only sid had this release), they added this change: 
# From Alexander Krivenyshev (2008-09-05):
# As per message from Carlos Alberto Fonseca Arauz (Nicaragua),
# Argentina will start DST on Sunday October 19, 2008.
#
# http://www.worldtimezone.com/dst_news/dst_news_argentina03.html
# http://www.impulsobaires.com.ar/nota.php?id=57832 (in spanish)
Rule    Arg 2007    only    -   Dec 30  0:00    1:00    S
Rule    Arg 2008    max -   Mar Sun>=15 0:00    0   -
Rule    Arg 2008    max -   Oct Sun>=15 0:00    1:00    S
So, they decided to take the word of a guy from Nicaragua (no bad feelings against Nicaragua, but I think that this kind of stuff should be informed by people from the affected country), and from a couple of articles that say that "According to some sources, we might have to change our clocks on the third Sunday of October". Would you change tzdata sources with such information? I definitely wouldn't. Anyway, Aurelien Jarno has already uploaded fixed packages, with no assumption regarding when the DST will happen, which is the sensible thing to do in a case like this. Thanks Aurel!

Benjamin Mako Hill: Introducing Between the Bars

I've been working with Charlie DeTar and the Center for Future Civic Media on a project called Between the Bars which is a blogging platform for prisoners. The current platform is essentially a snail-mail to web gateway: prisoners send letters which semi-automatically scanned and posted to the site; comments are printed and mailed back. As we plan the launch of the project, we are trying to talk to as many stakeholders as possible -- this includes ex-prisoners, families and friends of people who are or have been in prison, non-profits working with prisoners, victims of people in prison, people who work in prisons or in corrections, probation officers, or almost anyone else with a perspective or set of experience that might help us understand the difficult space our project is trying to negotiate and who might be able to help influence the design. At the moment, we're not talking to current prisoners due to rules regulating research involving prisoners, but almost anyone else would be someone we'd love to connect with. We're interested in hearing from people about their experience with prisons or prisoners, about staying connected to families and friends while behind bars, and, ultimately, about how we might design, deploy, and support technology to help folks out. If you or someone you know are stakeholders and would be willing to talk about your experience and opinions with prisons, communication, and technology, please drop us a line at betweenthebars@mit.edu.

Next.

Previous.