[02:29] <pwnguin> what controls the creation of /dev nodes in Ubuntu?
[02:30] <ion_> udev
[02:45] <pwnguin> hrm
[02:45] <pwnguin> how on earth does one read udev logs?
[06:15] <tjaalton> lamont: ping, re: fbset/hppa in xserver-xorg
[06:20] <pitti> Good morning
[06:21] <ion_> Good evening
[06:30] <StevenK> Morning pitti
[06:30] <StevenK> pitti: How do you feel about doing some NBS work? :-)
[06:31] <pitti> hey StevenK
[06:31] <pitti> sure
[06:32] <pitti> oh, except that my laptop's ssh key can't get to the DC yet
[06:32]  * pitti pings IS
[06:32] <StevenK> pitti: If you NBS out libicu36-dev, libicu-dev ought to then stand in for it and I can test build the seven rebuilds for that.
[06:33] <StevenK> pitti: net-snmp is in NEW, and once you let it out, I have 26 rebuilds to upload.
[07:05] <dholbach> good morning
[07:09] <ion_> Good evening.
[07:09] <dholbach> hey ion_
[07:23] <ion_> Hi
[07:27] <StevenK> pitti: No DC access for you?
[07:27] <pitti> StevenK: NBSed/NEWed
[07:28] <pitti> StevenK: I'm back on my desktop now :)
[07:28] <StevenK> Ah
[07:28] <StevenK> Yay
[07:29] <StevenK> pitti: If you also process bug 175059, that will mean asterisk can stop depending on libsnmp10 and actually build
[07:29] <ubotu> Launchpad bug 175059 in openh323 "Please sync openh323 (universe) from Debian unstable (main)" [Undecided,Confirmed] https://launchpad.net/bugs/175059
[07:31]  * StevenK wonders if he can fool build.py
[07:31] <pitti> StevenK: done
[07:31] <pitti> StevenK: fool in what way?
[07:32] <StevenK> pitti: build/bin/build.py from Helix, not your magical script
[07:32] <StevenK> pitti: Thanks
[07:34] <kagou> Good morning
[07:37] <dholbach> hey lloydinho_ :)
[07:46] <lloydinho_> morning dholbach :-)
[07:57] <pochu> pwnguin: re gtkfilechooser - gtk+2.0?
[08:06] <MacSlow> Greetings everybody!
[08:42] <StevenK> pitti: net-snmp is marked as DONE, do you think it's safe to throw 26 uploads to Soyuz?
[08:46] <Fujitsu> StevenK: They'll be marked done fairly early in the publisher run, but it should be safe by now.
[08:48] <lool> Is an archive admin around?  I'm failing to see why the lpia binaries for x264 as built in <https://edge.launchpad.net/ubuntu/+source/x264/1:0.svn20070930-0.0ubuntu2/+build/459260> don't appear in http://ports.ubuntu.com/pool/multiverse/x/x264/
[08:48] <lool> This is causing another build (gst-plugins-multiverse) to be stuck waiting for libx264-dev and the MBU team needs it
[08:49] <pitti> lool: lpia is a supported architecture and thus will appear on archive, not ports
[08:50] <lool> pitti: Uh?
[08:50] <lool> pitti: http://ports.ubuntu.com/dists/hardy/multiverse/ => binary-lpia http://archive.ubuntu.com/ubuntu/dists/hardy/multiverse/ => no binary-lpia
[08:50] <pitti> oh, seems I'm wrong
[08:51] <pitti> since when did we move it?
[08:51] <pitti> lool: sorry, seems I'm out of date
[08:51] <lool> pitti: Probably a while ago, I always remember it like that
[08:51] <pitti> libx264-dev | 1:0.svn20070930-0.0ubuntu2 | hardy/universe | amd64, i386, ia64, lpia, powerpc
[08:52] <pitti> at least it's there on drescher
[08:52] <pitti> http://ports.ubuntu.com/pool/universe/x/x264/libx264-dev_0.svn20070930-0.0ubuntu2_lpia.deb
[08:53] <lool> I'm a bit lost that in my rmadison output the source is in multiverse but builds binaries in universe
[08:53] <lool> I thought it was allowed the other way aound
[08:53] <lool> *around
[08:53] <pochu> It's in universe here
[08:54] <lool>       x264 | 1:0.svn20070930-0.0ubuntu2 | hardy/multiverse | source
[08:54] <pochu> Nope. You're right.
[08:55] <lool> Also, whereever the binaries are, gst-plugins-multiverse builds should see it: they have universe and multiverse?!
[08:55] <pitti> lool: thanks for the hint; seems someone incorrectly overrode it
[08:55]  * pitti fixes
[08:55] <geser> lool: I guess someone moved the debs to the wrong component when the debs got accepted
[08:55] <lool> pitti: Ah cool
[08:55] <pitti> lool: yes, indeed multiverse should build against universe
[08:56] <lool> pitti: I am not sure your fix will be enough to get this building: https://edge.launchpad.net/ubuntu/+source/gst-plugins-bad-multiverse0.10/0.10.5-1/+build/364774
[08:56] <lool> pitti: I don't really understand why it's not building if the binaries are in universe
[08:56] <pitti> no, it won't help
[08:56]  * pitti looks
[08:58] <pitti> lool: simple: -1 is not current
[08:58] <pitti> lool: -3 is current, and it has built on lpia
[08:58] <pitti> soyuz won't bother building superseded versions
[08:58] <lool> pitti: Ok, someone handed me that direct URL, I should have checked it's the latest source
[08:58] <lool> pitti: Thanks!
[08:58] <StevenK> I found a corner case where it did.
[08:58] <pitti> yw
[08:59] <pitti> StevenK: s/won't/shouldn't/ then :)
[08:59]  * StevenK grins
[09:00] <geser> pitti: while you are at it: please also move the i386, amd64, powerpc debs of x264 from universe to multiverse (see http://archive.ubuntu.com/ubuntu/pool/universe/x/x264/)
[09:00] <pitti> geser: done already
[09:01] <StevenK> You'd think the scripts would enforce that.
[09:02] <Fujitsu> Bug #132234
[09:02] <ubotu> Launchpad bug 132234 in soyuz "packages in 'multiverse' can have binaries in 'main' " [High,Fix released] https://launchpad.net/bugs/132234
[09:02] <Fujitsu> Well, apparently not.
[09:03] <Fujitsu> Ah, that's PPA.
[09:03] <StevenK> Right, I was about to say.
[09:14] <geser> pitti: please give-back: xscavenger. Thanks
[09:15] <pitti> done
[09:28] <geser> pitti: please give-back: tseries rcmdr rxvt-unicode snack
[09:34] <pitti> geser: done
[09:45] <tkamppeter> pitti, hi
[09:49]  * ogra waves from seville
[09:50] <ogra> cjwatson_:  in case ou want me to talk about any particular task here, i'm sitting in the HW session here (only http open on teh firewall, so connection might be wonky)
[09:51] <pitti> hi tkamppeter
[09:52]  * ogra wishes for a company sponsored spanish training :/ i wish i'd understand anything
[09:53] <tkamppeter> pitti, it is about avahi.
[09:54] <tkamppeter> The "update-rc.d -f avahi-daemon remove" I have from the doc file /usr/share/doc/sysv-rc/README.Debian.gz
[09:55] <pitti> tkamppeter: that's bad advice, I think
[09:56] <tkamppeter> It does not remove the actual init script, but only the links in the /etc/rc.... directories. This causes new links to be added by the part of the .postinst script which gets inserted at #DEBHELPER#
[09:56] <pitti> tkamppeter: well, I'm open for other opinions, but IMHO the way /var/lib/dpkg/info/dbus.postinst does it is better
[09:56] <pitti> tkamppeter: I know
[09:58] <tkamppeter> I will look, but what I will change is checking for the package version instead of checking for presence of a file to decide whether to do something. On a system where the user has manually changed the boot configuration, the fix would not get applied otherwise.
[09:59] <geser> tkamppeter: you need to keep at least one symlink if you don't want that new symlinks get created by update-rc.d
[10:00] <soren> Sheesh, packages.debian.org is slow today.
[10:01] <tkamppeter> geser, I want to have new symlinks, as I want to change the boot order so that avahi starts before CUPS.
[10:07] <ogra_> cjwatson: hey, i'm sitting in a (spanish) session about HW compatibility atm if you want me to ask/tell anything particulary ....
[10:08] <ogra_> gah this web-cgi IRC client sucks ... :(
[10:15]  * ogra__ grumbles about firewall admins that only offer http ...
[10:21] <tkamppeter> pitti, I am applying the method from /var/lib/dpkg/info/dbus.postinst in avahi now.
[10:21] <tkamppeter> pitti, thank you for this hint.
[10:30] <geser> doko: Hi, have you time to look over the debdiff in bug #174749?
[10:30] <ubotu> Launchpad bug 174749 in graphviz "[hardy] Drop libttf-dev from Build-Depends" [Undecided,New] https://launchpad.net/bugs/174749
[10:31] <geser> pitti: please give-back: gabber giblib libtk-img nspr. Thanks.
[10:33] <doko> geser: looks fine
[10:33] <tkamppeter> pitti, I have updated avahi now, 4ubuntu2 at the usual place ready for upload
[10:40] <tjaalton> tkamppeter: some of the hplip-gui desktop-files lack a OnlyShowIn=KDE -tag, can I add them?
[10:40] <Riddell> tjaalton: those apps are useful outside of KDE
[10:40] <tjaalton> are they?
[10:40] <tjaalton> ok
[10:41] <Riddell> I'm sure non-KDE users own HP printers too
[10:42] <tjaalton> sure, I'll just blacklist from the local menu then ;)
[10:42] <Riddell> if you don't want the apps then uninstall the package
[10:43] <tjaalton> we install both *-desktop's
[10:43] <geser> pitti: please give-back: aalib
[10:44] <seb128> is there a known issue with fonts in firefox and gecko applications in hardy?
[10:45] <Fujitsu> seb128: I noticed my Gecko fonts got all strange with this morning's upgrade.
[10:45] <ion_> My fonts have looked like crap for a while now (after a fontconfig update, i think). I haven’t investigated the problem yet, though.
[10:46] <seb128> ion_: everywhere or just firefox and gecko?
[10:48]  * soren misses packages.debian.org
[10:49] <pitti> soren: PTS still works, though
[10:49] <soren> ..that does't make requestsync happy :(
[10:50] <crimsun> pitti: Hi, do you have insight into https://edge.launchpad.net/ubuntu/+source/pulseaudio/0.9.8-1ubuntu2/+build/465314, or is cprov the go-to?
[10:50] <ion_> seb128: Hm. Seems like just firefox. Bitstream Vera seems to look fine in all apps, but Microsoft® corefonts seem to be missing hinting alltogether in Firefox, whereas Nautilus’ font preview shows them correctly.
[10:51] <Fujitsu> That looks like a cprov bug.
[10:53] <pitti> crimsun: yes, indeed cprov
[10:53] <crimsun> pitti: ok, thanks!
[11:13] <stgraber> Is there any way to disable that SSH agent part of the gnome-keyring ? I haven't seen anything in the config dialog nor in gconf-editor ...
[11:15] <Fujitsu> crimsun: Note the recent arrival.
[11:15] <asac> hmm ... any mono (semi-)expert here?
[11:16] <seb128> stgraber: I don't think so, any issue using it?
[11:17] <dholbach> asac: ajmitch and slomo are our experts
[11:17] <pochu> stgraber: I think you can, http://live.gnome.org/GnomeKeyring/Ssh
[11:17] <seb128> asac: slomo knows about mono but he just closed his IRC
[11:17] <pochu> stgraber: --components arg
[11:17] <asac> thanks
[11:17] <asac> ajmitch: ?
[11:17] <seb128> pochu: that means patching gnome-session code no?
[11:18] <StevenK> pitti: Would you mind punting openh323 out of binary NEW?
[11:19] <pitti> StevenK: doing
[11:19] <StevenK> pitti: Danke
[11:19] <pochu> seb128: hmm, does it? I don't know.
[11:20] <seb128> pochu: gnome-keyring is started by gnome-session, not sure how to add an argument there without changing the code
[11:20] <cjwatson> pitti: a fixed finish-install for bug 174689 is in hardy now; could you review my -proposed upload?
[11:20] <ubotu> Launchpad bug 174689 in finish-install "hvc/hvsi consoles not handled" [Undecided,In progress] https://launchpad.net/bugs/174689
[11:21]  * StevenK watches Firefox chew up large amounts of CPU time as he asks it to open 26 new tabs
[11:21] <Fujitsu> StevenK: Why do rebuilds take tabs?
[11:22] <StevenK> Fujitsu: Because I open a new tab for each upload to pounce on build failures
[11:22] <pochu> seb128: I thought I could change it in gnome-session-properties...
[11:22] <StevenK> Which is a throwback from before LP mailed you
[11:22] <Fujitsu> StevenK: Ah.
[11:23] <StevenK> I don't think Firefox likes having 70 tabs open
[11:23] <seb128> pochu: you can for applications listed in the session and using an autostart, the keyring start is coded though
[11:23] <persia> StevenK: It can handle a couple hundred, but your chances of session corruption rise significantly.
[11:24] <cjwatson> does it not save the session atomically?
[11:28] <StevenK> Oh, grumble hplip got rejected.
[11:28] <Fujitsu> StevenK: Pffft, I often have >150 open. It gets unmanageable eventually, though.
[11:33] <crimsun> Fujitsu: thanks (I'm normally gone for work by now).
[11:34] <crimsun> cprov: Hi, do you have insight into https://launchpad.net/ubuntu/+source/pulseaudio/0.9.8-1ubuntu2/+build/465314?
[11:35] <StevenK> tkamppeter: Ping
[11:35] <cprov> crimsun: let me check, one sec.
[11:38] <tkamppeter> hi StebenK
[11:38] <tkamppeter> hi StevenK
[11:39] <StevenK> My name has no B. :-P
[11:40] <StevenK> tkamppeter: The hplip merge doesn't do the Maintainer spec change; I have to upload a rebuild due to the net-snmp merge, do you want me to do it?
[11:41] <tkamppeter> StevenK. what is a Maintainer spec change?
[11:43] <persia> tkamppeter: https://wiki.ubuntu.com/DebianMaintainerField has context
[11:43] <tkamppeter> pitti, have you seen my CUPS change on the SVN
[11:44] <cprov> crimsun: builds 465307 & 465314 rescued, they will build in 15 minutes or so.
[11:44] <crimsun> cprov: many thanks!
[11:45] <pitti> tkamppeter: yes, I'll get to them
[11:46] <tkamppeter> StevenK, Mark Purcell and me are managing the HPLIP package on the Debian SVN, in principle we keep the Debian and Ubuntu versions of the package equal.
[11:46] <stgraber> seb128: well, I have some scripts where I would prefer to have the text prompt instead of the gtk one + I would need to check but I'm pretty sure that some times the ssh keyring was kept open even without the "Automatically unlock" thing checked
[11:47] <seb128> stgraber: that would be a bug
[11:47] <tkamppeter> StevenK. is you rebuild simply to get new binary packages so that they link with a new ABI of the netsnmp library? Or are there any changes except debian/changelog?
[11:47] <tkamppeter> pitti, OK.
[11:47] <StevenK> tkamppeter: No changes aside from debian/changelog
[11:48] <StevenK> tkamppeter: It's to link against libsnmp15 rather than libsnmp10
[11:49] <stgraber> seb128: I just reproduced it, I opened my irssi terminal (which connects to my server using SSH), I had the prompt for my key, entered it without checking the unlock thing
[11:49] <stgraber> seb128: then closed the window and open it again
[11:49] <tkamppeter> pitti, I have one doubt with Ghostscript. I want to package it as upstream made a patch to solve the problem of encrypted PDFs not printing out of Adobe Reader 8.
[11:49] <stgraber> seb128: it didn't ask for the key
[11:50] <tkamppeter> This is no problem, but on Saturday there was a discussion on removing the transitional package gs-common from ghostscript.
[11:51] <tkamppeter> StevenK, I think you can go ahead, such a rebuild does not need to be registered in the Debian SVN. I assume that you simply add an entry in debian/changelog and then upload the source package to the build server which has libsnmp15 installed and so binaries using libsnmp15 will get generated?
[11:52] <StevenK> tkamppeter: Right
[11:52] <pochu> stgraber: I can confirm that it remembers it until I end the session
[11:52] <tkamppeter> StevenK, then it's OK, go ahead.
[11:52] <tkamppeter> pitti,
[11:54] <seb128> stgraber: can you open a bug with the details to trigger the bug (without using irssi if possible ;-)
[11:54] <tkamppeter> pitti, they tell gs-common is not needed, as ghostscript updates/replaces gs-esp and gs-gpl, but I think if on a system with the old gs-... Ghostscript gs-common is installed, and the new ghostscript has no gs-common transitional package, the old gs-common will stay and conflict with ghostscript. as ghostscript contains the files of the former gs-common.
[11:56] <stgraber> seb128: sure
[11:56] <StevenK> tkamppeter: Uploaded, thanks!
[11:56] <pitti> tkamppeter: not unless the newer ghostscript Conflicts:/Replaces: gs-common
[11:57] <pitti> tkamppeter: (which it should); then upgrades will work without a transitional pacakge
[11:57] <pochu> stgraber: let me know the number and I'll confirm it ;)
[11:59] <tkamppeter> pitti, ghostscript Replaces, Conflicts, and Provides gs-common (<< 8.60).
[11:59] <tkamppeter> pitti, for which case are the transitionals needed then?
[11:59] <pitti>  gs-common | 8.61.dfsg.1~svn8187-0ubuntu3 | gutsy/universe | all
[12:00] <pitti> tkamppeter: it should replace/conflict to << 8.61.dfsg.1
[12:00] <pitti> then it will work
[12:00] <pitti> tkamppeter: you only need a transitional package if you actually want to keep the original name; that's not necessary for libraries, or -common packages which users usually don't want to install directly
[12:01] <tkamppeter> Yes, I understand. The transitional allows the user to do "apt-get install gs-esp" and he gets ghostscript.
[12:02] <tkamppeter> pitti, thanks, I will update ghostscript appropriately.
[12:02] <persia> tkamppeter: It also allows packages to continue to depend on the old name for a bit, to soften the upgrade transition (doesn't work for libraries, where the ABI changed anyway)
[12:03] <pitti> tkamppeter: so Debian dropped the transitional package in an earlier version?
[12:03] <pitti> tkamppeter: we need to keep that change until after hardy then, then we can drop it
[12:04] <tkamppeter> pitti, I do not know what Debian did.
[12:05] <tkamppeter> On Saturday they only told me that the gs-common is not really needed.
[12:05] <pitti> tkamppeter: I mean when they dropped gs-common
[12:06] <stgraber> seb128, pochu: bug 175288
[12:06] <ubotu> Launchpad bug 175288 in gnome-keyring "[Hardy] SSH key kept unlock after usage" [Undecided,New] https://launchpad.net/bugs/175288
[12:06] <seb128> stgraber: thanks
[12:06] <tkamppeter> pitti, I merged with Debian on the last upload (8.61.dfsg.1-0ubuntu2) and Debian did not remove gs-common
[12:07] <pitti> tkamppeter: hm, then maybe the newer gs-commons don't have any files any more, so that they don't conflict?
[12:08] <pitti> cjwatson: done
[12:12] <tkamppeter> gs-common got a transitional (without files) when I introduced the merger of ESP and GPL GS with the name ghostscript into Ubuntu. In Debian Masayuki Hatta introduced this ghostscript on Oct 14.
[12:13] <pitti> tkamppeter: ah, ok; that should be fine then
[12:13] <pitti> tkamppeter: so why again do you want to modify anything?
[12:13] <tkamppeter> pitti, so I will remove gs-common
[12:14] <pitti> tkamppeter: but that will break several reverse dependencies
[12:14] <tkamppeter> pitti, the motivation to make a ghostscript package is fixing bug 172264
[12:14] <ubotu> Launchpad bug 172264 in ghostscript "Ghostscript in Gutsy and Hardy is not able to print encrypted PDFs out of Adobe Reader 8.1.1" [High,In progress] https://launchpad.net/bugs/172264
[12:14] <pitti> tkamppeter: TBH I wouldn't bother ATM and just leave the transitional package as it is until Debian removes it
[12:14] <tkamppeter> pitti, so better leaving gs-common in?
[12:15] <pitti> tkamppeter: right; just apply the patch and you should be good AFAICS
[12:15] <tkamppeter> pitti, OK, so only the patch for bug 172264 ...
[12:15] <pitti> tkamppeter: I agree that it would be cleaner to remove it, but then we have to do the transition and introduce a delta
[12:15] <pitti> tkamppeter: right
[12:20] <StevenK> Hobbsee, pitti: Can you give-back asterisk on all arches, please?
[12:20] <pitti> StevenK: done
[12:20] <StevenK> pitti: Danke!
[12:35] <Hobbsee> pitti: can you shove meta-kde4 sources and binary to universe please?
[12:35] <Hobbsee> pitti: they're currently in main
[12:36] <Hobbsee> er, source and binaries
[12:36] <pitti> Hobbsee: done; hm, there are no binaries, is that correct?
[12:37] <Hobbsee> pitti: i've only just accepted the binaries
[12:37] <pitti> ah
[12:37] <Hobbsee> i'm not sure how long they take to publish
[12:37] <pitti> about an hour
[12:37] <pitti> but I can move them in ACCEPTED
[12:38] <Hobbsee> which does what?  where are they now?
[12:38] <Hobbsee> in limbo, or in accepted?
[12:38] <pitti> ok, done
[12:38] <Hobbsee> thanks
[12:38] <pitti> Hobbsee: they are not published yet, but in the ACCEPTED queue ("to be published")
[12:38] <Hobbsee> ah right
[12:38] <Hobbsee> so accepted is the limbo.  got it.
[12:38] <Hobbsee> launchpad is so confusing, at times.
[12:38] <StevenK> At time, you say?
[12:39] <StevenK> times, even
[12:39] <Hobbsee> yeah well.
[12:39] <Hobbsee> the stuff that has documetation probably isnt' too bad
[12:41] <cjwatson> the modern display of the ACCEPTED queue is a whole lot less confusing than it used to be, and IIRC less confusing than the same state in dak
[12:41] <cjwatson> FWIW
[12:41] <Hobbsee> cjwatson: i'm comforted :)
[12:42] <Hobbsee> cjwatson: progress is good!  :)
[12:43]  * Fujitsu notes that it's even more confusing now that sources don't ever go through ACCEPTED.
[12:45] <cjwatson> in the modern Launchpad display, it just shows up as DONE (and you might be a little confused for a short while, but at least you know it exists somewhere)
[12:45] <cjwatson> in old-Launchpad and dak, the corresponding state meant that the package was invisible and you had no idea what was going on
[12:45] <cjwatson> so I think it is definitely an improvement
[12:45] <Fujitsu> Sources used to go through ACCEPTED, though.
[12:46] <cjwatson> the DONE-but-not-yet-published state existed regardless, merely at a different time
[12:46] <Fujitsu> Right.
[12:46] <cjwatson> it used to be ACCEPTED -> DONE (but not published, so limbo) -> published
[12:46] <cjwatson> now it's DONE (not published, but you can see its state) -> published
[12:47] <cjwatson> except when the distro is frozen in which case ACCEPTED is still involved
[12:50] <lamont> tjaalton: sup? (fbset/hppa)_
[12:58] <lamont> *** You don't have any defomized font packages.
[12:58] <lamont> *** So we are trying to force to generate pangox.aliases...
[12:58] <lamont> there's just something about that inglish there... :)
[13:01] <tkamppeter_> pitti, patched Ghostscript is ready for upload.
[13:05] <tjaalton> lamont: right, so our xserver-xorg.postinst has carried a diff that uses fbset for hppa, with a note that the functionality should be moved to xresprobe. Well, xresprobe is now going away, and the idea is to rely on the server&drivers to do the right thing insted
[13:05] <tjaalton> *instead
[13:05] <lamont> ah, right.
[13:06]  * lamont looks at xserver-xorg.postinst
[13:06] <tjaalton> lamont: so the question is, will something break?
[13:07] <Hobbsee> tjaalton: we'll find something to blame you for breaking, yes.
[13:07] <Hobbsee> whether it was your fault or not is entirely different.
[13:07] <tjaalton> hehe
[13:08] <lamont> tjaalton: how about if we comment it out for now?  then I'll have an idea of what I have to fix if it does break?
[13:08] <lamont> tjaalton: and of course something will break... Hobbsee will see to that.
[13:08] <tjaalton> lamont: well, I think the whole xresprobeint() will be deleted :)
[13:08] <lamont> tjaalton: ah, well then, OK.
[13:09] <Hobbsee> tjaalton: and while you're at it, fix whatever needs to be fixed so my system stops crashing please :_
[13:09] <lamont> Hobbsee: PEBCAK
[13:09] <Hobbsee> lamont: hmph :P
[13:09] <lamont> tjaalton: the one gutsy/hppa box I have easy access to doesn't have a graphics card... I'll look at one in the office otday
[13:09] <tjaalton> 05:24 < gravity> This shouldn't even work really, unless xresprobe isn't present
[13:09] <tjaalton> 05:24 < gravity> If it is, the fbset call on hppa will get overridden by xresprobe, and you're  back where you started
[13:10] <tjaalton> 05:28 < gravity> Plus the fbdev driver should get the resolution from the fbdev interface
[13:10] <tjaalton> lamont: ^
[13:11] <tjaalton> lamont: ok, so you could try commenting that out and see what happens?
[13:11] <tjaalton> Hobbsee: I think we came to the conclusion that it was compiz :)
[13:12] <cjwatson> lamont: you have a fair few main merges on your list; do you need help with them?
[13:12] <Hobbsee> tjaalton: and amaranth says it's the driver giving bogus things, and compiz dying over it.
[13:12] <lamont> cjwatson: ah yes.
[13:12]  * lamont should do those.
[13:12] <tjaalton> Hobbsee: it's intel, so there you go :)
[13:13] <lamont> cjwatson: anything where I'm not the debian maintainer can be considered fair game, and I'll get on them later today.
[13:13] <lamont> today I need to spend the morning explaining something to a customer.
[13:13] <Hobbsee> tjaalton: so, fix it for me please :)
[13:14] <lamont> (and the ones where I am the debian maintainer, I'll do first.)
[13:14] <Hobbsee> you're hte X whiz ;)
[13:14] <lamont> Hobbsee: apt-get remove --purge compiz
[13:14] <tjaalton> Hobbsee: heh, well I guess bryce is more uptodate with intel than me :)
[13:14]  * lamont thought keithp was the X whiz...
[13:14] <tjaalton> and no, I'm not :)
[13:14] <Hobbsee> you lot all are, compared to me :)
[13:14] <Hobbsee> lamont: yeah well.  i'd prefer *not* to do that.
[13:14] <Hobbsee> if i were to do that, then i may as well go back to kde as well
[13:15] <lamont> Hobbsee: perish the thought.
[13:15] <Hobbsee> why?
[13:16] <tjaalton> Hobbsee: I'll get a stinkpad X61s soon, so if I'm hit with the same bug then I'll take a closer look at it :)
[13:16] <Hobbsee> heh :)
[13:16] <StevenK> Stinkpad? I lost that opinion of them when I got an X40
[13:17] <Hobbsee> tjaalton: if you were actually here, you could borrow my laptop for a bit or something.  but you're a bit far away
[13:17] <tjaalton> StevenK: yeah, I currently have a T23, and had a X60 at UDS and it was niec
[13:17] <tjaalton> niec
[13:17] <tjaalton> uh, niCE
[13:17] <azeem> so why do you call it stinkpad?
[13:17] <tjaalton> Hobbsee: put it in a bottle, it'll get here sooner or later ;)
[13:18] <seb128> StevenK: any news about the gimp update to hardy?
[13:18] <tjaalton> azeem: ok ok, Thinkpad!
[13:18] <seb128> StevenK: to gutsy rather
[13:18] <StevenK> seb128: Geh?
[13:18] <StevenK> seb128: Oh, right.
[13:18] <Hobbsee> tjaalton: hah.
[13:18] <Hobbsee> tjaalton: then i'll have no internet!
[13:18] <StevenK> Oh yeah, those users we want to silence
[13:18] <seb128> yes
[13:18] <sladen> tjaalton: I gave back the T60 with the job at the weekend, so don't have an ATI anymore
[13:19] <StevenK> seb128: I think it'll be a fun merge. :-/
[13:19] <seb128> StevenK: there is no merge when doing a SRU, it's basically taking the gutsy version and running uupdate
[13:19] <lamont> doko: gcc-3.4 is your's, contrary to what http://merges.ubuntu.com/main.html may say... I just triggered a rebuild...
[13:19] <lamont> (please)
[13:20] <seb128> dholbach: will you do your main merges or should we look at taking over those?
[13:20] <StevenK> seb128: My problem is ABI bumps
[13:21] <lamont> doko: and zope3... what's a "fake sync"?
[13:21] <Hobbsee> lamont: differing .orig.tar.gz sums
[13:21] <doko> lamont: gcc-3.4 doesn't need a sync
[13:21] <dholbach> seb128: if you find somebody to do them, I'm happy
[13:21] <doko> lamont: listen to that women ;)
[13:21] <seb128> StevenK: ABI? there is a libgimp and it changed because RC3 and 2.4?
[13:21] <seb128> dholbach: well, somebody will be me ;-)
[13:21]  * dholbach hugs seb128
[13:22]  * seb128 hugs dholbach back
[13:22] <StevenK> seb128: I think the shlibs file changed at least
[13:22]  * lamont wonders why we have a different orig.tar.gz
[13:22] <Hobbsee> mmm...merges
[13:23] <seb128> StevenK: ABI bump usually is no issue, ABI breakages are
[13:23] <cjwatson> anyone brave enough to take the e2fsprogs merge?
[13:23] <Hobbsee> lamont: does upstream distribute as a .tar.bz2?
[13:23] <Hobbsee> cjwatson: s/brave/insane/
[13:23] <cjwatson> looks like Ted solved a similar issue differently from how Ian addressed it
[13:23] <StevenK> soren is
[13:23]  * StevenK hides
[13:23]  * lamont picks Ted's solution.
[13:23] <soren> I'm waht?
[13:23] <lamont> :-)
[13:23] <cjwatson> so the merge will not be trivial
[13:24] <soren> Erk..
[13:24] <cjwatson> it looked to me as if Ian's fix was a bigger hammer and perhaps less likely to result in the bug coming back
[13:24] <lamont> doko: gcc-3.4 needs an upload to shut up MoM then
[13:24] <cjwatson> but also potentially less correct; hard to say
[13:24] <seb128> soren: I'll do your tsclient merge if you didn't start on it, that's sort of a desktop team package
[13:24] <doko> lamont: not really
[13:24] <soren> seb128: That would be great. I only did it to score experience points for my core-dev application :)
[13:25] <seb128> soren: ok, will do it then
[13:25]  * soren hugs seb128 
[13:25] <doko> lamont: it's a changed tarball (to exclude the gfdl docs) which we do not want
[13:25] <lamont> http://merges.ubuntu.com/main.html  3.4.6-6ubuntu2 	3.4.6ds1-6 	3.4.6-4
[13:26] <lamont> doko: but MoM won't leave us alone until the hardy version is higher than debian
[13:26] <cjwatson> I think such cases are OK to ignore in MoM
[13:26] <doko> lamont: just ignore MoM on these two cases
[13:26] <lamont> cjwatson: cool
[13:26] <cjwatson> doko: you could add a blacklist feature to MoM, if there isn't one already, maybe?
[13:26]  * lamont doesn't like to bitchslap MoM. :0)
[13:27] <StevenK> MoM already blacklists certain packages, I thought
[13:27] <tjaalton> sladen: hmm, so you had some ATI bug you reported or..?
[13:27] <lamont> doko: also, I finally gave in and turned on unaligned on the buildds... so what do we need to do about java?
[13:27] <doko> cjwatson: yes, maybe it's worth that
[13:28] <cjwatson> StevenK: it's entirely possible it just needs stuff added to a list, yes
[13:38] <sladen> tjaalton: yeah, this whole, y'know ...avivo thing.
[13:39] <sladen> tjaalton: puts a damper on fixing any fixing any more issues on that laptop
[13:39] <tjaalton> sladen: "There are currently no open bugs" :)
[13:39] <Hobbsee> uh oh.  everyone behave.  sabdfl is here.
[13:40] <lamont> Hobbsee: that was your out-loud voice.
[13:40] <Hobbsee> oh, whoops
[13:40]  * Hobbsee resends it, telepathically then.
[13:40] <lamont> morning sabdfl
[13:41] <tjaalton> sladen: anyway, no worries
[13:41] <lamont> cjwatson: like udev? :0)
[13:42] <sabdfl> howdy folks
[13:42] <lamont> (it took me a while to come up with an example...)
[13:42] <pitti> hi sabdfl
[13:42]  * lamont takes kids to school.  offline for about an hour
[13:57] <soren> cjwatson_: FWIW, I think Ted's approach looks sufficiently sane. Ian's patch might do the trick, too, but (not surprisingly) Ted's is more correct. I vote for Ted's approach, too.
[14:02] <slomo> asac: whats with mono
[14:13] <asac> slomo: its about csharp gtkmozembed binding for xulrunner 1.9 ...
[14:14] <asac> slomo: do you know how to interface with native libs in mono?
[14:21] <cjwatson> pitti: you set the bug to fix-committed, but finish-install still seems to be in the gutsy-proposed unapproved queue
[14:22] <pitti> huh? /me must be asleep then
[14:22] <pitti> cjwatson: sorry, accepted now
[14:23] <cjwatson> thanks
[14:31] <slomo> asac: yes... http://www.mono-project.com/Interop_with_Native_Libraries
[14:31] <slomo> asac: so you want to create one or there is one?
[14:31] <slomo> asac: (gecko-sharp(2) already exists)
[14:31] <asac> slomo: yes, but it needs to be adapted for xul 1.9
[14:31] <slomo> asac: bbl, write me a mail please slomo@ubuntu.com
[14:31] <slomo> sorry
[14:31] <asac> slomo: ok thanks
[14:34] <seb128> asac: read my question on #ubuntu-desktop? ;-)
[14:35] <asac> seb128: which?
[15:10] <pitti> slomo: did you see my /msg?
[15:16] <geser> pitti: in case you missed my previous request, please give-back: gabber giblib libtk-img nspr. Thanks.
[15:17] <pitti> geser: done
[15:49] <pitti> Lure: got a minute to talk about digikam?
[15:50] <Lure> pitti: yes
[15:50] <pitti> Lure: I just spent some time reading http://bugs.kde.org/125696
[15:50] <pitti> Lure: in short, digikam does not find libgphoto plugins because kdelibs has its own nonstandard libtdl
[15:51] <pitti> Lure: Debian has a normal libgphoto, and digikam depends on libgphoto2-dev
[15:51] <Lure> pitti: I think that should be fixed in hardy - last merge of kdelibs got proper fix from debian
[15:51] <pitti> so that it gets the .la files
[15:51] <pitti> Lure: oh, great; it uses the system libtdl now?
[15:52] <pitti> Lure: I would like to drop the libgphoto Ubuntu delta for the .la files, and also the digikam delta
[15:52] <Lure> pitti: did not check the actual kdelibs, but the comment is very clear that it fixes need for .la files
[15:52] <pitti> Lure: awesome
[15:52] <pitti> Lure: so we can get rid of both deltas
[15:52] <Lure> pitti: I paln to merge digikam and recent digikam in debian already droped -dev depends
[15:52] <pitti> Lure: I'll merge libgphoto2 now; please cry out if it causes any problems
[15:52] <pitti> rock
[15:53] <Lure> pitti: good, will check probably tonight/tommorow when I will look in digikam merge
[15:54] <Lure> pitti: http://packages.debian.org/changelogs/pool/main/k/kdelibs/kdelibs_3.5.8.dfsg.1-4/changelog
[15:55] <Lure> pitti: btw, am I ok to merge from debian/expirimental instead of the version suggested by MoM?
[15:55] <pitti> Lure: absolutely, if you tested it
[15:56] <pitti> well, since we always test our uploads anyway, that doesn't add any constraint, right? :)
[15:56] <Lure> pitti: will do, digikam 0.9.3 will be released before our FF, so will pick beta from experimental
[15:56] <Lure> pitti: ;-)
[15:56] <pitti> that sounds fine; early testing FTW
[15:57] <Lure> pitti: I have to test at least my main packages not to get ugly looks from Riddell (who is sponsoring uploads) ;-)
[16:26] <evand> does anyone want to pick up the syslinux merge?  I gave it a shot, but my assembly-foo just isn't strong enough to rework the gfxboot patch.
[17:10] <soren> evand: I think doko was trying a few days ago, too?
[17:20] <evand> oh, perhaps we just overlapped.
[17:20] <evand> Fantastic, if he is.
[17:21] <stgraber> I'm doing the iTalc integration for Edubuntu/LTSP and trying to move to clean way to logout/shutdown/reboot for the different desktops, KDE was easy with DCOP, now I'm trying to find an equivalent for gnome
[17:22] <stgraber> what I need to do is to have a scriptable way to close the session and trigger the shutdown/reboot action of gdm
[17:22] <stgraber> I tried with gdm-signal without much success and "gnome-session-save --kill" just shows the logout box instead of directly triggering a direct logout
[17:23] <stgraber> oh, I just noticed the --silent for gnome-session-save, so this one is good
[17:25] <stgraber> but I still need to find a way to shutdown/reboot :)
[17:27] <seb128> stgraber: gnome-keyring upstream argue that storing the passphrase is the purpose of an ssh-agent so that's not a bug, they have a point there ;-)
[17:28] <stgraber> seb128: yes, but maybe I don't want to use the agent and still enter my key instead of the password :)
[17:28] <stgraber> seb128: currently I have no way to just enter my key and not see it stored :)
[17:28] <seb128> stgraber: right, which is a different issue of the one you described
[17:28] <seb128> well, don't use an agent if you don't want it stored
[17:29] <seb128> which is wishlist for "make the agent being optional"
[17:29] <stgraber> that's a regression (vs standard SSH without any external agent) :)
[17:30] <seb128> stgraber: right, and that will be fixed before hardy
[17:31] <stgraber> my current problem is that I want the keyring part of the daemon but not the SSH one and I have no way to fix that as I can't simply kill it + reload with the -c thing (the env variables would point to a no longer existing process ID)
[17:32] <seb128> stgraber: agreed, there should be a gconf key or something to set for people who don't want the ssh agent
[17:32] <seb128> stgraber: about the reboot option, gdm-signal should do that, if it doesn't work it should be fixed
[17:33] <seb128> stgraber: or maybe you can speak to gnome-power-manager over dbus like for suspend and hibernate
[17:34] <pochu> seb128: but if the ssh agent will store it anyway, what's the point of the 'Remember me' check box?
[17:34] <stgraber> pochu: I think it'll remember not only until the session close, but even after you logout
[17:35] <pochu> stgraber: oh, that makes sense.
[17:36] <seb128> pochu: it stores it in the keyring
[17:36] <seb128> pochu: so it's available for next sessions
[17:36] <stgraber> seb128: ok, just gave gdm-signal a try on Hardy and it doesn't work either, so it's not working on Feisty/Gutsy/Hardy :) I will file a bug
[17:38] <stgraber> seb128: but I suspect a bug in gdm itself for this one as stracing the gdm-signal shows that it correctly sent the actions (SET_LOGOUT_ACTION REBOOT) and received an OK from the gdm server ...
[17:38] <seb128> stgraber: well, that's the logout action, you need to log out then
[17:39] <stgraber> oh, right :)
[17:40] <stgraber> It was easier to do with KDE :) (just send a DCOP signal and that's it)
[17:41] <seb128> stgraber: with the new gdm (might not land in hardy) that will likely be a signal to send over dbus
[17:41] <stgraber> cool
[17:43] <seb128> stgraber: looks like gnome-power-manager has methods for that already, so talking to it over dbus should work there
[17:44] <bryce> heya stgraber
[17:45] <stgraber> hi bryce
[17:51] <cjwatson> mdke: will you have a chance to do your gnome-user-docs merge by Thursday?
[17:51] <soren> evand: I'm not sure if he actually finished it. I'm looking at it right now, too, actually. I'll give it a shot. Give me... 15 minutes.
[17:52] <cjwatson> calc: there's an hsqldb merge outstanding that looks (at first glance, though please check) as if it may be a sync; could you look at this?
[17:53] <calc> cjwatson: ok
[17:53] <calc> cjwatson: i am fairly certain it is just a sync
[17:53] <calc> cjwatson: will verify it now
[17:53] <evand> thanks soren
[17:54] <cjwatson> doko: stealing your libept merge, which I believe is a sync (only remaining diff is the apt build-dep which we don't have to keep as a delta)
[17:57] <calc> cjwatson: yep its a sync
[17:58] <calc> cjwatson: should i file a sync bug or is there someone who can do the sync right now?
[17:58] <cjwatson> calc: I'll do it now, thanks
[18:06] <cjwatson> ajmitch: is python-mysqldb a sync? I didn't check all the details, but Debian builds the -dbg package now
[18:16] <cjwatson> lamont: stealing your db4.3 merge; it's a sync because Clint dropped Java support altogether
[18:21] <cjwatson> doko: stealing freeglut, which is a sync
[18:22] <ScottK> cjwatson: While you're doing sync's, would you please have a look at Bug #175036
[18:22] <ubotu> Launchpad bug 175036 in lintian "Please sync lintian (main) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/175036
[18:22] <geser> cjwatson: a sync request for freeglut was filed as bug #174729 already
[18:22] <ubotu> Launchpad bug 174729 in freeglut "Please sync freeglut 2.4.0-6  (main) from Debian unstable (main)" [Undecided,Confirmed] https://launchpad.net/bugs/174729
[18:23] <cjwatson> ScottK: whoa. You've checked that in detail?
[18:23] <cjwatson> geser: oh, whoops, missed that. I'll close, thanks
[18:23] <cjwatson> sigh, and fltk1.1 too
[18:23] <ScottK> cjwatson: Yes.  I reveiewed the entire diff between what we have and the new revision.  I've also been using it since I did.
[18:24] <soren> I think I might have managed syslinux. I'll need to take it for spin first, though.
[18:24] <ScottK> cjwatson: Laserjock has merged lintian before and so I think his ack is worthwhile too.
[18:24] <ScottK> cjwatson: The reason I ask is so the I can get the backport request for gutsy in.
[18:24] <cjwatson> nod, it just surprised me :)
[18:24]  * ScottK too.
[18:25] <pitti> cjwatson: I checked fltk1.1, ack'ing
[18:26] <cjwatson> ScottK: done
[18:27] <ScottK> cjwatson: Thanks.  I've already tested it in Gutsy.  Any chance you could just run the magic backport script or do you want a bug for that?
[18:27] <cjwatson> I'm supposed to be going shopping, but sure, just for you ;-)
[18:27] <ScottK> cjwatson: Thanks.  persia will be happy too.
[18:28] <ScottK> He's the one that guilted me into reviewing it in the first place.
[18:28] <doko> evand, soren: I asked upstream; the gfxboot part isn't yet updated
[18:28] <cjwatson> ScottK: feisty has a lintian backport too; should it be updated?
[18:28] <soren> doko: I think I've managed to do it.
[18:28] <soren> doko: I'll know in a bit.
[18:28] <cjwatson> ScottK: oh, err, can't run backport-source until it's actually in the archive
[18:28] <cjwatson> ScottK: remind me later
[18:28] <ScottK> cjwatson: I would assume so, althougth I haven't personally tested it.  Let me file a bug for that so someone can check.
[18:29] <ScottK> cjwatson: Will do.
[18:29] <ScottK> I'll probably just file the bug so I don't forget.
[18:29] <ScottK> Thanks again.
[18:30] <geser> could someone please sponsor bug #157668 and bug #174749?
[18:30] <ubotu> Launchpad bug 157668 in scons "[Merge] scons 0.97.0d20071203-1ubuntu1" [Wishlist,Confirmed] https://launchpad.net/bugs/157668
[18:30] <ubotu> Launchpad bug 174749 in graphviz "[hardy] Drop libttf-dev from Build-Depends" [Undecided,New] https://launchpad.net/bugs/174749
[18:40] <coNP[uni]> geser: this means testing and eventual uploading?
[18:41]  * coNP[uni] was sure graphviz is in universe.
[18:42] <geser> coNP[uni]: graphviz is in main and currently in depwait as libttf-dev is in universe
[18:43] <coNP[uni]> (sure, I checked that inbetween)
[18:59] <lamont> cjwatson: cool
[19:06] <soren> Well, syslinux compiles now. That's a good start.
[19:06] <elmo> ship it
[19:06] <soren> :)
[19:07] <LaserJock> any archive admins about?
[19:10] <LaserJock> I'm not sure why goffice0.4 hasn't made it into Hardy, we don't have to explicitly ask for new packages from Debian do we?
[19:10] <ScottK> LaserJock: Not for another 3 days.
[19:10] <ScottK> I don't think.
[19:11] <LaserJock> hmm, it's been over a month since it made it into Debian
[19:13] <pochu> LaserJock: maybe it's blacklisted
[19:13] <LaserJock> pochu: do you know where the blacklist is?
[19:14] <elmo> http://people.ubuntu.com/~ubuntu-archive/sync-blacklist.txt
[19:14] <pochu> LaserJock: goffice0.4 # pitti, transitional oldlibs in Debian
[19:14] <LaserJock> pochu: bah
[19:14] <LaserJock> that's not right at all
[19:15] <LaserJock> elmo: do you have power to fix that or do I need to wait for pitti?
[19:15] <elmo> LaserJock: I'm just pasting links, I don't have any power in this area :)
[19:15] <elmo> I think you want  any archive admin tho
[19:16]  * LaserJock liked the days when the answer to anything was "ask elmo" but I suspect elmo doesn't feel the same ;-)
[19:18] <LaserJock> hmm, I don't know why Debian ftpmasters did an override to send it to oldlibs
[19:18] <LaserJock> the source package has libs I think
[19:26] <LaserJock> so ... any archive admins still around today?
[19:27] <ScottK> LaserJock: Riddell's been active in #kubuntu-devel recently.
[19:28] <LaserJock> Riddell: can you do an ubuntu-archive favor for me and un-blacklist goffice0.4 ?
[19:28] <Riddell> not something I've done before
[19:28] <Riddell> LaserJock: what's the reson?
[19:28] <LaserJock> Riddell: because it shouldn't have been blacklisted to start with :-)
[19:29] <LaserJock> it is a new version of goffice (goffice is currently 0.5) to make sure apps other than gnumeric can build
[19:29] <LaserJock> I've been waiting on it for a couple of merges
[19:30] <soren> \o/ isolinux boots.
[19:31] <Riddell> "goffice0.4 # pitti, transitional oldlibs in Debian" LaserJock have you confirmed it with pitti?
[19:31] <LaserJock> no, but that's wrong
[19:31] <LaserJock> for some reason Debian put it into oldlibs when it shouldn't have
[19:32] <LaserJock> and I'm guessing that's why he did that
[19:32] <LaserJock> but it's not transitional
[19:32] <LaserJock> it's barely 1 month old
[19:32] <LaserJock> and the stable version of the library
[19:33] <LaserJock> I can take it up with pitti if you're not comfortable with doing it
[19:33] <Riddell> LaserJock: I expect you're right but I'd like to check with pitti first, please file a bug and subscribe ubuntu-archive and ask pitti to comment
[19:33] <Riddell> it's my archive day tomorrow anyway
[19:33] <LaserJock> alright, will do
[19:42] <soren> evand: I believe syslinux is done. I'll upload in a bit.
[19:43] <evand> Fantastic.  Thanks a bunch, soren
[19:43] <soren> \o/
[19:43] <soren> it at least builds and isos boot fine. I haven't tested anything else yet.
[20:31] <mdke> cjwatson: I will have a go at merging from Gnome, but I doubt I'll be able to look at any changes to the packaging in Debian by thurs. Unlikely there is anything significant
[20:44] <warp10> Hi all!
[21:22] <emes> where can I get the kernel config file for the stock kernel?
[21:24] <sn0> emes this isn't really the channel to ask, see topic. but check in /boot/
[21:28] <emes> thanks
[22:31] <soren> Hm... firefox is throwing SIGBUS all over the place.. Highly annoying.
[22:59] <soren> who can fiddle with PAS?
[23:00] <soren> Archive admins? buildd admins?
[23:12] <slangasek> soren: "lamont, elmo, and infinity", I think?
[23:13] <slangasek> AFAIK Ubuntu pulls directly from the same source that Debian uses, and they're the maintainers of that file
[23:13] <soren> Ok.
[23:15] <soren> I just noticed that lpia was added to the list of architectures in the syslinux package, but there are no build records for it. I'm assuming this is due to pas.
[23:16] <slangasek> http://buildd.debian.org/quinn-diff/Packages-arch-specific says yes
[23:16] <soren> Interesting.
[23:17] <soren> lamont: Could you add lpia to the list of architectures for which we build syslinux?
[23:36] <soren> slangasek: Have you by any chance seen the e2fsprogs merge?
[23:36] <slangasek> soren: no
[23:37] <soren> slangasek: Ok.
[23:37] <slangasek> soren: I can take it, though
[23:37] <soren> slangasek: I looked at it already.
[23:37] <slangasek> ok
[23:37] <soren> slangasek: I'm just looking for a second opinion.
[23:38] <soren> slangasek: The thing is that Ian made a workaround for bug 131201, and now upstream has provided a different workaround.
[23:38] <ubotu> Launchpad bug 131201 in e2fsprogs "always fscks first boot after install" [Low,Fix released] https://launchpad.net/bugs/131201
[23:39]  * slangasek gets really, really tired of seeing that bug :)
[23:39] <soren> slangasek: I can imaginge.
[23:40] <soren> slangasek: Ian's patch basically ignores the error, while the upstream fix allows the sb->s_lastcheck to be up to 24 hours in the future.
[23:40] <slangasek> hmm
[23:41] <slangasek> I suppose that should cover it, yes
[23:41] <soren> slangasek: I vote for upstream's approach, but this is not entirely my area of expertise.
[23:42] <slangasek> I do too :)
[23:43] <soren> Cool. I'll file the sync request tomorrow.
[23:45]  * soren head to bed
[23:45] <slangasek> 'night
[23:45] <soren> 'night :)