Search Results: "will"

6 May 2010

Petter Reinholdtsen: Parallellizing the boot in Debian Squeeze - ready for wider testing

These days, the init.d script dependencies in Squeeze are quite complete, so complete that it is actually possible to run all the init.d scripts in parallell based on these dependencies. If you want to test your Squeeze system, make sure dependency based boot sequencing is enabled, and add this line to /etc/default/rcS:
CONCURRENCY=makefile
That is it. It will cause sysv-rc to use the startpar tool to run scripts in parallel using the dependency information stored in /etc/init.d/.depend.boot, /etc/init.d/.depend.start and /etc/init.d/.depend.stop to order the scripts. Startpar is configured to try to start the kdm and gdm scripts as early as possible, and will start the facilities required by kdm or gdm as early as possible to make this happen. Give it a try, and see if you like the result. If some services fail to start properly, it is most likely because they have incomplete init.d script dependencies in their startup script (or some of their dependent scripts have incomplete dependencies). Report bugs and get the package maintainers to fix it. :) Running scripts in parallel could be the default in Debian when we manage to get the init.d script dependencies complete and correct. I expect we will get there in Squeeze+1, if we get manage to test and fix the remaining issues. If you report any problems with dependencies in init.d scripts to the BTS, please usertag the report to get it to show up at the list of usertagged bugs related to this.

Andrew Pollock: [life] Crazy few days

Here's why: Zoe's birth Zoe Dianne Pollock was born at 12:30pm PDT, at Lucile Packard Children's Hospital, via Caesarean-section. Her birth weight was 2920 grams (6 lbs, 7 oz) and she's 49.5 centimetres (19.5 inches) long. As for why she was born 11 days early than her previously scheduled early arrival... Monday morning started off like any other normal Monday morning. I got up at 6am to go to the gym with Dan. I got home at around 8am. I asked Sarah if she'd felt any baby movement, and she said she hadn't. Even after some jiggling and a cold glass of orange juice, there was nothing. Not wanting a repeat performance of what happened last time, we wasted no time in heading to Labour and Delivery to get things checked out. When we were nearly at the hospital, Sarah felt some small movement, so that was a relief. When we got to the hospital, they performed a non-stress test as they have previously. They spent a good couple of hours with Sarah hooked up to the monitor, and then the on-call obstetrician asked us how we'd feel about just having the baby today. I asked if there was anything particularly concerning about the NST, and the OB said that she (the baby) was doing marvelously now, but was "less than marvelous" when we first came in. I haven't had a chance since to ask her if there was anything untoward observed during the delivery. Anyway, she (the on call OB) said that rather than have Sarah get stressed out for the following 11 days, she'd talked with our regular OB, and they felt that since she was at 37 weeks (and considered "full term") that it was okay to deliver at that point. At the end of the conversation, it was upgraded to a recommendation, rather than an option. So so much for an attempt at VBAC. We got to the hospital at around 9am, and I think they/we made the decision to deliver at about 10:30am. I had enough time to race home and grab the camera and race back again, and the next thing I knew we were all in the operating room, and Zoe was being delivered. It was amazing getting to see the "extraction". They dropped down the sheet that was blocking our view of the action right at the end, and I got to see (and photograph) Zoe's head and whole body being pulled out. She gave out a little cry, and Sarah and I totally lost it with relief. Things were a bit of a blur after that. I got to come over and meet Zoe while they were weighing her and measuring her, and then they bundled her up and let me take her back to Sarah's head-end on the operating table, so Sarah could get a look at her. Sarah handled this C-section better than last time. She didn't get any nausea, but she still got the itching and involuntary shivering, courtesy of the morphine. While they were still putting Sarah's insides back in, Zoe and I went to the nursery, where they put her under a heater for a little while to warm her up a bit. Then it was back to the recovery room to have a proper meeting with Sarah. Once Sarah was ready to move to the maternity ward, Zoe and I again returned to the nursery, where she got her first bath, had her umbilical cord trimmed some more, and her anti-theft device fitted to her umbilical cord clamp. Then it was off to the maternity ward. I think we were all in the maternity ward by 3pm. After a little while, we managed to get bumped to a private room, which was a lot better than the shared room (the other bed was vacant, but just having more space made a big difference), and that's where we've been ever since. I've stayed each night on the roll away bed, helping out with diaper (sorry Aussies, I've been here too long, and dealt with too many babies, I never think of them as "nappies" any more) changes, and burping and other miscellaneous tasks. Monday night was okay. Tuesday was a bit rough. Sarah didn't get any sleep on Monday night, and the anaesthesia totally wore off and she was in a fair bit of pain. She slept better on Tuesday night, and today, the breastfeeding has been going well, and the post-operative pain is well and truly under control. She's lost a bit of weight since delivery (as is to be expected). She was down to 5 lbs 14 oz (2664 grams) at last night's weigh-in, and at tonight's weigh-in she came in at 5 lbs 13 oz (2636 grams). So the weight loss is starting to plateau. We're already supplementing the breastfeeding with syringes of colostrum/milk that Sarah's pumped previously, so I hope the weight loss will have turned around by tomorrow night's weigh-in. The breastfeeding in general is going pretty well as of today. Mum and bub have both mastered the latch. I think it's just a matter of Sarah's milk coming in now. I've brought forward my 7 weeks paternity leave (an excellent benefit Google offers) to start as of Zoe's delivery. Sarah's Mum arrives on the 19th for 4 weeks, which will be great. We expect to be discharged from hospital on Friday. Luckily we were pretty much all ready for this happening a little bit earlier. We had our last baby classes on the weekend. The nursery is ready enough to bring a baby home to, so aside from Sarah's Mum being disappointed that Zoe's going to be a bit older when she first gets to see her, we're all good. The WiFi in the hospital is great. We've already Skyped with both grandmothers and they've had a chance to see Zoe. We've had a steady trickle of visitors, and the whole baby routine is making the time go pretty quickly.

5 May 2010

MJ Ray: General Election 2010

You may have noticed that the UK votes in a General Election tomorrow. It looks like the closest for at least 18 years and maybe more. Happily, all the major parties are saying nice things about cooperatives, but I wonder how much of that will translate into policies that are practical for co-ops like mine. Our national body Cooperatives UK has gathered the commitments from 18 manifestos and summarised them in a PDF. The first 7 pages deal with the five biggest English parties. One striking thing is how many gaps there are in the Labour, LibDem and UKIP policies, while it s not really clear to me that the Conservatives or LibDems really understand cooperatives. The Conservatives seem to suggest council-controlled co-ops (which wouldn t normally be co-ops if they lack autonomy), while the LibDems mention employee trusts more often than worker co-ops. I m sulking at Labour after several recent schemes that subsidised private competitors and excluded worker co-ops and I don t believe Labour can win in Weston-super-Mare. That would leave the Greens, who probably can t win but do seem to get it, except that there s no Green candidate where I live because he stood aside and recommended the LibDems (as I understand it). Drat. So, only a few hours to go before the start of the ballot and I m still an undecided voter.

Ana Beatriz Guerrero Lopez: KDE 4.4.3 in unstable

Following Qt 4.6.2, uploaded a couple of weeks ago, KDE 4.4.3, has finally found its way to unstable in the last 48 hours.
Given KDE 4.5.0 is not expected until August, it is likely the next point release, 4.4.4, will be the KDE version included in next Debian stable, Squeeze. What this means: go and update to 4.4.3, test, and when you find a bug, please, follow this instructions. If you are lazy to read it: report upstream bugs at the KDE Bugzilla and report the packaging/integration bugs in the Debian BTS. When in doubt, you have the Debian KDE mailing list, that is being successful so far in maintaining a good signal-noise ratio. I would like highlight the drop in the open bugs in the BTS experimented in the last 2-3 months, I published this graph in February: Number of bugs reported against KDE in Debian in the last 3 years - February 2010 And look at the situation now: Number of bugs reported against KDE in Debian in the last 3 years -May 2010 This is mainly due to the great work of Eckhart W rner. Also there is other people who contributed to it more modestly, a big thank you to all of you! As you can see in the second graph, there are less than 1000 bugs open now in the BTS, they are still too much and time has taught us it is very easy going over 1000 again, so we still welcome more volunteers looking at bugs. If you are not the bugsquasher type, you can write HTML and you do some IRC, we also need somebody to help us reorganize a bit the pkg-kde website. I will help you personally on this task, but it is good if you can lurk by IRC and you are not scared to share your doubts with the rest of the team there. Finally, I promise I will publish something about the status of KOffice pre-2.2 in Debian, but I still can not say whether it will be in Squeeze.

Christian Perrier: New progress in samba packaging

SambaXP day 2 for me. More progress on samba packaging. Today, I completed the backport of samba 3.4.7 to backports.org. We already had that version but it was desynced with the version in testing (2:3.4.7~dfsg-2 in testing while we had -1 in backports.org). As the difference is noticeable (dropping the old smbfs package in favoir of cifs-utils, which I blogged about yesterday), I wanted to resync all this. So a new 2:3.4.7~dfsg-2~bpo50+1 package (what a funky numbering scheme, isn't it?) was just uploaded today in backports.org. The transition between smbfs and cifs-utils should be smooth (as soon as autobuilders complete the entire build which may be quite long, for samba). I also completed a full resync of packages we have in experimental. Here, we do provide the bleeding edge samba version, namely 3.5.2. It's very likely that we don't provide samba 3.5 in squeeze, the option being conservative and keeping up with the 3.4 branch. So, for our users wanting the last samba version, having it in experimental is interesting. Next step is building 3.5.2 backported packages. These will be provided "as is", for i386 and probably very soon amd64, on the pkg-samba team's unofficial repository. I'll be working on this tomorrow^Wtoday.

4 May 2010

Erich Schubert: Facebook tracking users via "like" function.

Facebook recently launched the "Like" function, which basically can be embedded into arbitrary web sites. Naively, it does two things:
  1. Provide a "Like" button for sharing the web site
  2. Show you how many other users like the web site
Sounds good, doesn't it?But now reconsider: even when you don't use the "Like" function, facebook is in fact notified of which web sites you visit!.Encouraging you to "share" content with friends is the hanger for this function. This is what makes web masters install it on their sites: they expect to get some extra traffic from your friends, so they just add it.But whether you like it or not, it basically allows Facebook to track your complete web viewing habits. And it's the target web site that opts in, not the user! Combined with all the personal information Facebook already has on you, this is a major privacy concern. Combining this information might even be illegal in some countries (but probably not in the US where Facebook lives, privacy unfortunately has a low role here).The best workaround currently is to blacklist Facebooks "Like" function using some kind of AdBlock, for example using this element filter:
IFRAME[src^="http://www.facebook.com/plugins/like.php"]
But in general, we should try to make this kind of data aggregation illegal without explicit consent and force Facebook to make this an opt-in feature. Political work needed here ...P.S.: Make sure to check if your AdBlock actually blocks and not just hides. As far as I can tell, WebKit Adblock, including Chromes, only hide ads. Firefoxs AdblockPlus seems to be more powerful.P.P.S.: yes I've read the claim that Facebook doesn't track. No wait, all they basically said was that they are not going to announce at F8 they will be selling web surfing behaviour based ads to their customers. They actually did NOT state (or guarantee) they will NOT use data mining on this data. Just that you probably will not be able to buy eyeballs based on rules such as "has visited/liked disney.com" ...P.P.P.S.: I've been told that facebook.com/widgets/like.php also needs to be blocked, since some sites use this URI scheme. And of course, Privoxy and similar privacy-increasing proxies are a useful addition, too.

Chris Lamb: Rotating email into your inbox using imapfilter

I'm not a fan of "life hacks", but I have the adopted the following automated processing of my email inbox: if I don't want to deal with a message today, I move it to (eg.) Mail.DELAYED.4 and it will reappear in my inbox automatically in 4 days. It is inspired by the Inbox Zero, tickler files and the Debian DELAYED queue. My implementation uses imapfilter. You'll need to tweak the move_messages syntax for lenny's version; the following works fine in squeeze and sid:
mbox = IMAP  
    server = 'mail.server.net',
    username = 'username',
    password = 'password',
    ssl = 'ssl3'
 
num = 14
dst = 'INBOX'
prefix = 'Mail.DELAYED.'
for x = num, 1, -1 do
    mbox[prefix .. x]:select_all():move_messages(
        mbox[x == 1 and dst or prefix .. (x - 1)]
    )
end
The messages are moved when I'm (hopefully) asleep:
# m h dom mon dow command
  0 6 *   *   *   imapfilter -c /path/to/delayed.lua >/dev/null

Wouter Verhelst: On clue and opinions

How does one define one's "national identity"? One way is to look at where a person is born. By that definion, I could be called Flemish, Belgian, or European, whatever you think about it. Another way to look at it is how one feels about one's own identity. This, of course, is a much more accurate way to describe a person; and by that definition, I am either Belgian or European. I do not feel any affinity with much of the so-called "flemish" identity, nor do I wish to be associated with it any more than is strictly necessary. Obviously, some people feel different about that for themselves. This I can understand. In fact, the statement to feel more Belgian than Flemish is probably not one that is very common in this general area. I am not stupid; I know that Belgium is not a Nation (it is a state, but that is a different matter). I just do not feel a lot of warm fuzzy feelings about Flanders. Naturally, other people have other feelings about that. This, too, I can understand. The logical result of the above is that my personal opinions about the somewhat convoluted politics in this country are not shared by many; that when I state my opinion, I may expect opposition, or at the very least someone stating why they disagree with me. This, of course, I can also understand. But what I cannot understand is that every time I state my opinion, someone must come out and insult my intelligence by telling me I "do not have a clue". Please do not mistake my disagreement for misunderstanding. Martijn asks me to "check the facts". Let's do that, shall we?
  1. There's been a judgement by the constitutional court that the current situation regarding which party may run for election in the BHV region is unconstitutional.
  2. One group of politicians wishes to resolve this issue by splitting the BHV region in two. That would certainly solve the issue.
  3. Another group of politicians dislikes this solution. They may be willing to go along, but they want other concessions before they will do so. This is what I referred to when I said that there were "a huge heap of all kinds of side issues" in my previous post.
  4. The first group does not wish to make such concessions. Some of their numbers have even stated in the press that there is no need to make them, because, given the first point, there's only one solution and that is to split.
That last point is, of course, complete and utter bullshit. It would hold merit if there was only one way to solve a constitutional crisis; but by definition, there are always at least two ways: one is to change the law to comply with the constitution, the other is to change the constitution to make the law no longer be unconstitutional. So a group that feels strongly about one of these two possible solutions should be prepared to negotiate with the other group so as to hammer out an agreement that benefits both parties. In some cases, this will mean doing things that they do not completely like; but if they're not willing to do that, at all, they have no business being politicians. For the longest time during the early negotiations, however, both parties have stubbornly refused to even acknowledge the other position, let alone talk about it. Now, for clarity, I'm not advocating that the latter of the two options in that previous paragraph is what should happen. Frankly, I don't even care what happens, so long as they manage to resolve the issue at hand in some way. What I do care about, however, is that this country has been in a near-constant state of stalemate over these past few years for an issue that only matters to politicians; I don't care who or what a group of people in a (to me) obscure part of the country can vote for. This country needs a stable government which can act on things that actually matter. Like, say, the international economic crisis of the past two years; I think it matters much more whether the man in the street has a job than whether John Q. Politician will past these next elections.

3 May 2010

Matthew Garrett: PCI power management problems

I've previously written about some of the implementation details of runtime PCI power management. One of the key aspects for PCI devices is that the PME line on the device be able to generate a wakeup event. Unfortunately, it turns out that since Windows makes no use of this functionality at present, some vendors have started failing to wire this up. This is problematic because the device itself still announces PME support and will even raise a PME signal when it gets woken up - but it's pretty much screaming as hard as it can and nobody's listening because somebody's replaced the air with cheese.

Bother, etc.

The obvious question is what to do next. We could poll all the PCI devices every second or so to see if there's a PME status register that's been set. This would be reasonably cheap (we're going to wake up at least once a second on x86 anyway, so it makes no real difference to power consumption) but would introduce obvious latency in the wakeup path. This would be fine for certain types of situation (you're probably not going to be too sad if your SD reader takes a second longer to notice a card insertion) but not others (if an sdio wireless card generates a wakeup interrupt then we really ought to do something about it in a more sensible timeframe). A second is to force users to pass a boottime argument to enable this at all. That kind of sucks.

The third possibility is limited to a subset of hardware, but does allow the introduction of some kind of elegance into what would otherwise be one of those nightmarish scenarios that makes me consider taking up farming instead. If we can trigger a PME ourselves then we can test whether the line is connected. This doesn't appear to be possible on SDHCI but the spec for firewire makes it look like we can do it there - one of the interrupt sources is the port enable/disable register, and we can hit toggle that ourselves. I haven't actually tested this yet, but if it works that would let us make this determination.

It's depressing that doing anything interesting with power management is still heavily determined by what Microsoft have bothered to implement - to the extent that on some machines (hello, Thinkpads) there are no GPE methods at all for PME signals and you don't get runtime power management at all. The only thing that saves us is that (a) it's pretty hard to be able to screw up stuff that's already all glued into one chip package, so integrated stuff like USB should be fine anyway, and (b) PCIe does this as part of the normal traffic stream so there's no way to get that wrong. Unless you're still missing the GPE methods for the signals (hello, Thinkpads) in which case you get nothing unless the native PCIe signalling works. I suspect that we can always force that, so there's some hope yet.

In summary, then: dispassionate.

Russell Coker: Flash, Apple, and Linux

Steve Jobs has published an interesting article about Flash [1]. He criticises Flash for being proprietary, this seems a little hypocritical coming from Apple (who s the only competitor for Microsoft in terms of being the most proprietary computer company) but is in fact correct. Steve advocates HTML5 which is a better technical solution to a lot of the things that Flash does. He claims that Apple users aren t missing out on much, but I think that sites such as Physics Games [2] demonstrate the benefits of Flash. I think that Apple s attack on Flash is generally a good thing. HTML5 web sites will work everywhere which will be a good incentive for web designers to fix their sites. I also think that we want to deprecate it, but as it s unfortunately popular it s useful to have tools such as GNASH to use Flash based web sites with free software. Microsoft has belatedly tried to compete with flash, but it s Silverlight system and the free but patent encumbered Linux equivalent Moonlight have very little content to play and will probably disappear soon. As an aside the relentless determination of GNOME people to force the MONO project (including Moonlight) on it s users convinced me to remove GNOME from all systems that I run. OS News has a good analysis of the MPEG-LA patents [3] which are designed to prevent anyone making any commercial use of H.264 which includes putting such videos on sites that contain Google advertising! These patent terms are so horrible that they want to control video streams that were ever encoded with them, so you can t even transcode a H.264 stream to an open format without potentially having the scum at MPEG-LA going after you. This is worth noting when examining Apple s actions, they support MPEG patents and therefore seem happy to do anything that reduces the freedom of their customers. Apple s 1984 commercial has been proven to be a lie, it s Apple that wants to control our freedom. Charles Stross makes some good points about the issues related to Apple and Flash [4]. He believes that it s all part of an Apple push to cloud computing and that Apple wants to own all our data at the back-end while providing a relatively reliable front-end (IE without all the anti-virus nonsense that is needed on the MS-Windows platform. Cloud computing is a good thing and I can t wait for the Linux support for it to improve, I support a number of relatives who run Linux and it would be a lot easier for me if they could have the primary storage for everything be on the cloud so that I can do central backups of user data and they can use their own data while visiting each other. I think that a network filesystem that is similar in concept to offline-IMAP would be a really good thing, I know that there are some filesystems such as AFS and CODA that are designed for wide area network use with client-side caching but as far as I am aware they aren t designed for the type of operation that offline/caching IMAP supports. Matt Brubeck has given a good status report of the work porting Firefox to Android [5]. He notes that the next version of Fennec (mobile Firefox) will have Electrolysis the Firefox one process per tab feature that was first implemented in Google Chrome [6]. I think that the development of Fennec and the one process per tab feature are both great developments. Matt also says One of my personal goals is to make Firefox compatible with more mobile sites, and to give web developers the tools and information they need to make their sites work great in mobile Firefox. I ll write much more about this in future articles , that sounds great, I look forward to the results of his coding and to reading his blog posts about it!

Guido G?nther: krb5-auth-dialog: DBUS signals and plugins

Krb5-auth-dialog now sends DBus signals when you acquire or renew your Kerberos ticket granting ticket and when the ticket expires. When using OpenAFS This can e.g. be used to trigger a call to aklog on ticket renewal. It's simple to catch the DBus signals from a Python script:
import dbus
bus = dbus.SessionBus()
bus.add_signal_receiver(tgt_renewed_handler, dbus_interface = "org.gnome.KrbAuthDialog", signal_name = "krb_tgt_renewed")
bus.add_signal_receiver(tgt_acquired_handler, dbus_interface = "org.gnome.KrbAuthDialog", signal_name = "krb_tgt_acquired")
bus.add_signal_receiver(tgt_expired_handler, dbus_interface = "org.gnome.KrbAuthDialog", signal_name = "krb_tgt_expired")
The tgt_*_handler will then be called when the signal is received. The shipped Python example allows to execute a script already:
tgt-signals.py -q --acquired-action=aklog --renewed-action=aklog
Krb5-auth-dialog also got a plugin system so you could use a loadable module for these kind of things instead. It already ships a PAM plugin that can be used to run some typical actions like calling pam-afs-session or getting kx509 set up. You need to tell krb5-auth-dialog which plugins to load via gconf. To load the dummy and PAM plugins use:
gconftool-2 --set --list-type=string --type=list /apps/krb5-auth-dialog/plugins/enabled [pam,dummy]
Since I'm not using AFS or kx509 myself I'd be interested to know if this works out as expected. If you want to write your one plugins you can use the dummy plugin as a basis. A package with the above enabled has been uploaded to Debian experimental.

David Welton: Mochiweb proto-deb and hacking

I had some time over the weekend to play a bit with Mochiweb. It's a very nice little bit of work, but kind of strange for an open source project. I think both things come from the fact that it was built to do some very specific things in a business, and once those goals were accomplished, that suited the owner just fine. There is no nice/fancy project home page, no links to documentation, and in general, all of the stuff you're supposed to do for a successful open source project. The code, however, is good, fast, and pretty easy to deal with. Anyway, I wanted to use it for a thing or two I'm working on, so I created some .deb packaging for it. It's been ages since I've done that (indeed, I officially retired from Debian), so it's probably missing something, but I thought I'd throw it out there for people to have a look. The git repository is here: http://github.com/davidw/mochiweb - my changes live in the 'deb' branch. The big thing I've tried to do is make it so that if you have several mochiweb projects on the same machine, they'll all be started/stopped by the init scripts, if you so choose. What you do is add a file with the path to the application to the /etc/mochiweb/apps directory, and when you do /etc/init.d/mochiweb start, it will start all of those. At stop time, it will run the stop.sh script, which shuts things down. It runs things as the user that owns the start.sh script, unless it's root, in which case it simply doesn't run. The thing that's missing right now is a way to get the thing to write logs somewhere, and I'm not quite sure how to do that, so here's hoping someone will write in with a suggestion. The .deb file I generated ought to be attached to this post, although there are no guarantees that I'll keep it up to date.

Ingo Juergensmann: Drupal and PostgreSQL - SELECT DISTINCT, ORDER BY

Some time ago, version 6.16 of Drupal was released and hit the Debian archives shortly after. It fixed some security issues, but apparently introduced a regression for PostgreSQL users. The problem seems to be a MySQLism in Drupal or in other words: Drupal is not following the SQL92 standard.
The error is:

2010-05-02 06:36:23.155 CEST drupal6_mycr drupal6 ERROR: for SELECT DISTINCT, ORDER BY expressions must appear in select list
2010-05-02 06:36:23.155 CEST drupal6_mycr drupal6 STATEMENT: SELECT DISTINCT nc.nid FROM node_comment_statistics nc INNER JOIN node_access na ON na.nid = nc.nid WHERE (na.grant_view >= 1 AND ((na.gid = 0 AND na.realm = 'all') OR (na.gid = 0 AND na.realm = 'content_access_author') OR (na.gid = 1 AND na.realm = 'content_access_rid'))) AND ( nc.comment_count > 0 )ORDER BY nc.last_comment_timestamp DESC LIMIT 10 OFFSET 0


There are several issues open in the Drupal issue tracker like #742896 and #742006 and #735120. Apparently there are several ways to address this issue, but none seem to be the preferred solution. In #735120 there's a patch, but it seems not to be accepted so far.

So, is there a good and viable patch for that issue that will go into the next update of Drupal?

2 May 2010

Dominique Dumont: Improve config file upgrades Ep 01

Hello The GSoC project Krzysztof and I are working aims to facilitate configuration upgrade during package upgrades. Most of the cases, this upgrade should not require any input from the user, even if the user had previously customized his configuration file. Currently configuration upgrade may ask questions to the user which may be hard to answer for most non-technical users. For more details see PackageConfigUpgrade on Debian wiki. (If you are not familiar with upgrade issues, you might want to read this page.) At the 2 extremes of upgrade tools, we have: Each tool has its own advantages and drawbacks. On the plus side of diff3 tools : On the other hand, here are the issues with diff3 based tools: For more details on diff3 issues, see Benjamin Pierce s paper (thanks to David Lutterkort from Augeas for the info) On the other end of the spectrum, Config::Model pros are: But, Config::Model main problem is: diff3 tools is lackluster for users. While Config::Model puts too much strain on packagers because it requires configuration models where all parameters are defined and declared in the model. For fast evolving projects, this can be a huge recurrent task (been there, done that for Xorg) . (Well, this recurrent task is a problem until doc, implementation and config model can be extracted from a single meta-description But I digress, this may be a project for GSoC 2011 :-p ) So, this GSoC project (for 2010) aims to find a compromise between these 2 extreme cases. On Config::Model, I ve always had a drawer statement whenever I was asked why Config::Model does not handle unknown parameter:
a configuration file cannot be validated if an unknown parameter can t be distinguished from a user typo.
This stance is fine for casual user interaction on a stable system: an unknown parameter is most likely an error. And the user must be warned of his error as soon as possible. For a stable distro release, packagers should have the time to provide complete models, so basing upgrade on complete models should be possible (famous last words ?). On the other hand, a lot of configuration upgrades will be done on unstable systems where software evolve quite fast, where models will likely fall behind software evolutions. Another shorcoming of my drawer statement is that it assumes user interaction where erroneous input is more likely. In case of configuration upgrades, there should be no user interaction. And we can assume that the config file to be upgraded was used (and thus validated) by the old version of the software. So unknown parameters should be tolerated and managed as best as possible. Now, the big question is: how ? In all attempts I ve seen in managing upgrades that goes beyond diff3 tools, the configuration is stored as structured data. Sometimes this structure can be infered from the configuration file syntax (shell vars, INI files, YAML, XML), sometimes not (sshd config file). In the latter case, some structural knowledge must be built in the upgrade tool. Currently, Config::Model is designed to bring a complete description of the structure and semantics of a configuration file. This is perceived as bringing too much structural and semantic knowledge ( too semantic ). So the maintenance cost is perceived as too important. That may be right or wrong, but that does not matter. Perception is more important here. So, let s figure out a way to reduce the amount of work required to perform upgrades (you may want to read a little bit more on configuration model creation before going on ) One possibility would be to support configuration models that allow unknown leaves in nodes. Such a model would provide a kind of fallback leaf description. Something like: this parameter is unknown, let s assume it s a simple string value . Let s consider sshd_config example to see how such a behavior would pan out for some upgrade scenarios. sshd model is made of 2 main classes:
- Sshd
- SshdMatchElement The second one contains all parameters allowed in a Match class (in fact, Match parameter is the only one in sshd that defines a new hierarchical level. All other parameters are simple leaves). Now let s consider typical upgrade scenarios from old version (with old models) to a more modern version. Let s assume that the model is lagging behind and the model does not follow sshd evolutions. So Config::Model will face 3 upgrade cases (extracted from sshd config history):
  1. Unexpected parameter that are actually simple leaf parameters. E.g. introduction of ClientAliveInterval.
  2. Obsolete parameters that should be migrated. E.g KeepAlive is renamed into TCPKeepAlive
  3. New structural parameters (introduction of Match element)
So what would happen with a model allowing unknown parameters but lacking specific instructions for these upgrades:
  1. ClientAliveInterval value would be kept. :-)
  2. KeepAlive would be kept as is.TCPKeepAlive would also be kept. No migration is performed, but the configuration would be good. As long as sshd supports the old parameter, we re good. :-/
  3. Without knowledge of the structure brought by Match parameters, Config::Model would consider that parameter in Match block would duplicate parameters in the main block and remove the duplicate. User data may be lost. :-(
So, there s not silver bullet. Let s resume what we ve learnt: Next step is to figure out what would happen if the same strategy is applied to other types of configuration files. But that will be for another blog. All the best

Dominique Dumont: Config-Model related project for GSoC 2010

Hello It s official: I m going to mentor a project related to config-model (without forgetting Augeas which might also be involved) this year:

Content-aware Config Files Upgrading
by Krzysztof Tyszecki, mentored by Dominique Dumont When a package deliver configuration files, the problem of merging user data with new configuration instructions will arise during package upgrades on users systems. Sometimes merging can be done with 3 way merge, but this process does not insure that the resulting file is correct or even legal. This project intends to create standards,
tools and heuristics to make the scary config file conflict resolution debconf prompt a thing of the past.
This project is hosted by Debian organization. Since this project might interest a lot of people, I will (try to) blog regularly on progress, issues, ideas.

From you people, I d like feedback and more importantly, I d like to get real life use cases.

What are the configuration upgrade scenario that bothered you ? What was your configuration file ? What was the setup done by package maintainer ? What result did you get ? What result did you expected to get ?

All the best


Julien Blache: forked-daapd: now with AirTunes v2 streaming

I ve been working on this for a few months now; it s taken quite some time because I wanted to do it right and deliver something better than what already existed in the OpenSource world as far as that particular technology was (not) concerned. So here it is:

AirTunes v2 UDP streaming forked-daapd can now do streaming to multiple AirTunes devices (as well as the local soundcard) and can be controlled from Remote (and, ideally, from anything that speaks DACP). I m releasing this early while the paint is still wet and not everything works on the DACP-side of things. Case in point, while playing a song or an album is supported, playing a playlist isn t. There s some work needed on this particular feature, and it ll get there eventually. There have been a couple of other changes in the codebase in recent weeks too; details after the jump. Implementing AirTunes v2 has been quite fun and, in addition to releasing the forked-daapd code today, I ve also taken the time to write down my findings about the protocol so others can experiment with it. This documentation is by no means exhaustive nor complete as far as the protocol goes; if you find out anything I haven t, let me know so I can update this document. Let s review the recent changes in the forked-daapd codebase over the past few weeks. AirTunes v2 You can now use Remote from your iSomething together with your AirTunes devices and forked-daapd to listen to your library. As mentioned above, playing a playlist is not supported; I have a few things to sort out before this can work and I suspect this will bring changes not only to the DACP interface but also to other parts of the code. So, stay tuned. forked-daapd supports synchronized playback to multiple AirTunes devices together with the local soundcard if so desired. You can expect the AirTunes devices to be in sync with each other, but the soundcard will usually run in circles around them. It looks like AirTunes plays sound a bit slower than 44.1 kHz; not a big deal, though, as AirTunes will catch up periodically and the desync, while it can be noticeable, isn t big (ie we re not talking seconds, not even one full second). Make sure your network can handle the load, as streaming to a single AirTunes device requires in excess of 1.6 Mbps (1.8 Mbps is actually closer to the real thing). Local audio output is supported via ALSA and OSS4, although note that the OSS4 code hasn t been very well tested. I intend to test and debug it fully at a later date, but feel free to beat me to it and send patches. Also note that, while there is code for FreeBSD in the player/streaming part of forked-daapd, it doesn t work well at all. The streaming code needs a timer with a higher resolution than kqueue/kevent has to offer, and I haven t found anything as capable as timerfd. So it s there, but it s broken. Read on about FreeBSD support. Metadata scanning Several fixes and enhancements have been made to the filescanner so it picks more and better metadata. Format-specific tagnames have been added to work around ffmpeg s limitations. Using a recent enough ffmpeg version (anything after mid-december 2009) will work best, especially for MP3 files. SQLite concurrency fixes The database code has been reworked to handle concurrency on the database. Issues with locked tables (or the whole database) were noticed pretty easily with big libraries when accessing forked-daapd during the library update after startup. On uniprocessor machines, this was even easier to hit. This, however, comes with new requirements for SQLite3: you ll now need SQLite3 v3.5.0 at least and it must be built with the unlock notify API enabled. Not all distributions ship SQLite3 with the unlock notify API enabled, so you may need to do a rebuild. Debian, for instance, doesn t; this is #579266. A word about FreeBSD support I m giving up on FreeBSD support. The streaming code doesn t work on FreeBSD due to timer issues, and I don t intend to fix it. I also don t intend to invest much time in porting future features to FreeBSD; if I can make it work, then fine, otherwise, too bad. Someone needs to step up if there s interest in having forked-daapd work on FreeBSD.

Petter Reinholdtsen: Forcing new users to change their password on first login

One interesting feature in Active Directory, is the ability to create a new user with an expired password, and thus force the user to change the password on the first login attempt. I'm not quite sure how to do that with the LDAP setup in Debian Edu, but did some initial testing with a local account. The account and password aging information is available in /etc/shadow, but unfortunately, it is not possible to specify an expiration time for passwords, only a maximum age for passwords. A freshly created account (using adduser test) will have these settings in /etc/shadow:
root@tjener:~# chage -l test
Last password change                                    : May 02, 2010
Password expires                                        : never
Password inactive                                       : never
Account expires                                         : never
Minimum number of days between password change          : 0
Maximum number of days between password change          : 99999
Number of days of warning before password expires       : 7
root@tjener:~#
The only way I could come up with to create a user with an expired account, is to change the date of the last password change to the lowest value possible (January 1th 1970), and the maximum password age to the difference in days between that date and today. To make it simple, I went for 30 years (30 * 365 = 10950) and January 2th (to avoid testing if 0 is a valid value). After using these commands to set it up, it seem to work as intended:
root@tjener:~# chage -d 1 test; chage -M 10950 test
root@tjener:~# chage -l test
Last password change                                    : Jan 02, 1970
Password expires                                        : never
Password inactive                                       : never
Account expires                                         : never
Minimum number of days between password change          : 0
Maximum number of days between password change          : 10950
Number of days of warning before password expires       : 7
root@tjener:~#  
So far I have tested this with ssh and console, and kdm (in Squeeze) login, and all ask for a new password before login in the user (with ssh, I was thrown out and had to log in again). Perhaps we should set up something similar for Debian Edu, to make sure only the user itself have the account password? If you want to comment on or help out with implementing this for Debian Edu, please contact us on debian-edu@lists.debian.org. Update 2010-05-02 17:20: Paul T tterman tells me on IRC that the shadow(8) page in Debian/testing now state that setting the date of last password change to zero (0) will force the password to be changed on the first login. This was not mentioned in the manual in Lenny, so I did not notice this in my initial testing. I have tested it on Squeeze, and 'chage -d 0 username' do work there. I have not tested it on Lenny yet. Update 2010-05-02-19:05: Jim Paris tells me via email that an equivalent command to expire a password is 'passwd -e username', which insert zero into the date of the last password change.

Russell Coker: Lexmark Supposedly Supports Linux

I wanted to get a Lexmark Prestige Pro805 printer to work under Linux, due to bad drivers from Lexmark and no driver support in Debian/Unstable I ve given up and advised the people who purchased it to return it for a refund. I recommend that Lexmark not be considered when purchasing a printer for use with Linux. The box advertises the URL http://www.lexmark.com.au/prestige for downloading Linux drivers. The driver file is named lexmark-inkjet-09-driver-1.5-1.i386_ts.deb.sh.tar.gz which makes anyone expect a tar.gz archive of a shell archive of a Debian package. But that s not what it is at all, in Lexmark-land deb is not the file name extension for a Debian package, but just a random bit of text to identify a file that is somewhat related to Debian, the fact that the Linux driver for Ubuntu/Debian Package Manager based distros doesn t use the string ubu in it s name is something that would lead a typical Linux user to believe that deb means a Debian package. Similarly the file named lexmark-inkjet-09-driver-1.5-1.i386_ts.rpm.sh.tar.gz and described as Linux driver for RedHat Package Manager based distros is not actually an RPM package or inherently for RPM based distros, it s just a shar archive that is built and tested for some unspecified version of some Red Hat distribution (RHEL? Fedora? SUSE?). Now when I execute lexmark-inkjet-09-driver-1.5-1.i386_ts.deb.sh on an AMD64 version of Linux it opens an X11 window, prompts for the root password, and then fails because an i386 Debian package that it somehow built couldn t be installed. When I ran the shar archive with the options --noexec --keep and examined the files it contained it has a few AMD64 executables so obviously the software they used to create the installer has some support for AMD64 but they just decided not to use it. It seems that the only way to buy an i386 system nowadays is to buy an embedded system or a NetBook, all Desktops, laptops, and servers run the AMD64 architecture, as most people do a Linux install that matches the full capabilities of their system (IE running AMD64 software on an AMD64 CPU) that means most systems sold in the last few years can t be used with a new Lexmark printer without an unreasonable amount of work. Sure it is possible to setup a chroot environment or KVM virtual machine for running printer drivers, but I don t really want to do that and a significant portion of the potential customers don t have the skill needed to do so. While technically their claims about having Linux driver support are correct (they support some distributions of Linux on i386), the majority of new systems won t work with it unless someone who has good skills spends some time and effort on it. Probably the majority of Linux Desktop and server systems that are in use today use AMD64 and are run by people who don t know how to setup a chroot so therefore for most real installations it s not supported. Even for i386 systems installation is unlikely to be trouble-free, when they support RPM based distributions (without identifying which of the many wildly different RPM systems they tested on) and Debian (without mentioning a version number) it seems that the incidence of people running a distribution that is supported is going to be quite low. Lexmark uses the Linux logo to claim compatibility Based on this experience I am not inclined to trust Lexmark in future, I will not trust any future claims of Linux support that they may make. The above picture of the Lexmark box shows Tux (the Linux logo), it doesn t mean support out of the box as you would hope, but instead means support for old systems with some effort.

Romain Beauxis: SPIP is cool

I have been playing around with SPIP for some time today. I am really happy with the software and its current packaging ! I have packaged this application because I believed it was missing among the possible powerful CMS for Debian. I hope this will be a good package for squeeze !

1 May 2010

Filippo Giunchedi: how to ship spidermonkey in your autotools project

While working on freej we'd need to update spidermonkey/mozjs to the latest version and while doing that integrate it better with the rest of autoconf/automake. AFAICT spidermonkey/mozjs is distributed as part of XULRunner nowadays. The requirements are to make it easy to put a new version of spidermonkey into the tree and redistribute it with make dist and also to have a successful make distcheck. The first step is a trick explained in automake manual about third-party Makefiles so we're using a GNUMakefile.in (git) to "proxy" the targets down to the real Makefile or to ignore some targets called by autotools, e.g:
# otherwise linking static libmozjs.a with dynamic libfreej.so won't work
CFLAGS += -fPIC
# the makefile to proxy targets to
js_makefile = $(builddir)/Makefile
# proxy these targets to the real makefile
all export js-config clean libs tools:
  $(MAKE) -f $(js_makefile) $(AM_MAKEFLAGS) $@
# targets required by autotools but which we don't need at all
.PHONY: dvi pdf ps info html installcheck check install uninstall
dvi pdf ps info html installcheck check install uninstall:
This more or less fixes the make part, now for the autoconf part there's a similar tecnique in the autoconf manual involving running arbitrary configuration commands. I first tried to treat spidermonkey as a separate project via AC_CONFIG_SUBDIRS as expained in Configuring Other Packages in Subdirectories but it didn't work and I forgot exactly why. The configure.ac (git) snippet is something like this: (sorry no highlighting, highlight doesn't support m4 yet)
if test x$have_mozjs = xno   test x$static_mozjs = xyes; then
  dnl run lib/javascript/configure after freej's configure, building it static
  AC_CONFIG_COMMANDS([lib/javascript/.xulrunner-subdir],
    (cd lib/javascript &&
      CXXFLAGS="$GLOBAL_CFLAGS $CXXFLAGS -fPIC" \
      CFLAGS="$GLOBAL_CFLAGS $CFLAGS -fPIC" \
      $ac_srcdir/configure --enable-static \
        --enable-js-static-build --disable-jit)   exit $?
  ])
fi
This will run spidermonkey configure after the main configure, at this point config.status will also expand GNUmakefile.in into GNUmakefile with the correct variables. The final step after all this work is of course to add the spidermonkey directory to SUBDIRS (e.g. SUBDIRS += lib/javascript), after that make will hopefully recurse into lib/javascript and use our GNUmakefile. While this is nice it doesn't cater for the make dist family of autotools targets which build the real distribution tarball. To accomplish this I've used an explicit list of spidermonkey files that will end up in the tarball and made make distdir to copy only those files plus GNUmakefile.in and the list itself (.js-distfiles). Which is the second part of the GNUmakefile.in above, i.e. distdir/distfiles targets plus distclean to clean them up, see comments in the file as well. I hope this is somewhat useful to people who are trying to properly (autotools-wise) ship spidermonkey in their project, comments welcome as usual :)

Next.

Previous.