[01:04] <mneptok> looks like cupsys_1.3.2-1ubuntu4_i386.deb is corrupted, at least on US mirrors
[01:09] <Kmos> bug 149188
[01:09] <ubotu> Launchpad bug 149188 in cupsys "[GUTSY BETA]  error when updating cupsys" [Undecided,New]  https://launchpad.net/bugs/149188
[01:11] <mneptok> that's the one
[01:29] <slangasek> not corrupted, just good and broken
[01:53] <lamont> slangasek: semnatics
[02:28] <gnomefreak> the cupsys error is on gb mirror as well
[02:28] <mneptok> gnomefreak: looks like a patch has been pushed. testing now.
[02:29] <gnomefreak> mneptok: ah ok im fixing mine locally like i have done all day
[02:29] <gnomefreak> something is wrong this is 2nd or 3rd packages to do this today
[02:30] <slangasek> mneptok: pushed where?
[02:30] <mneptok> slangasek: to us.arch.
[02:31] <gnomefreak> mneptok: it cant be us mirrors
[02:31] <gnomefreak> mneptok: than i wouldnt see it
[02:32] <mneptok> and no, package is still b0rked in the us repos
[02:32] <slangasek> mneptok: er, it most certainly hasn't, 1ubuntu4 is still the current version of the cupsys package in gutsy and the bug report is still open
[02:34] <gnomefreak> mneptok: i am blaming buildds becasue this isnt the 1st one today so if they were built on same on and it corrupted the binaries there is your error
[02:35] <slangasek> gnomefreak: no, it's not a buildd bug.
[02:37] <slangasek> it's a "sloppy last-minute changes to package contents to try to reduce package sizes, upload without testing and disappear into the European night" bug
[02:37] <mneptok> slangasek: your PDT is showing ;)
[02:37] <gnomefreak> slangasek: for 3 of them?
[02:38] <gnomefreak> eh maybe gimp and cupsys i thought a 3rd but maybe not
[02:39] <slangasek> 3 of what?  I'm only talking about cupsys, I haven't heard about any other packages with this problem.
[02:39] <cjwatson> gnomefreak: a series of uploads were made to reduce package size, in a manner which could cause this problem if got slightly wrong.
[02:40] <gnomefreak> cjwatson: ah ok just seemed too easy to be single uploads
[02:40] <cjwatson> gnomefreak: you can try to blame buildds but you will usually be wrong. :-)
[02:40] <cjwatson> likewise, mirrors never cause this kind of corruption
[02:40] <cjwatson> s/corruption/breakage/
[02:41] <cjwatson> slangasek: are you working on a cupsys fix or should I?
[02:41] <cjwatson> since I appear to be awake
[02:42] <slangasek> cjwatson: probably quicker for you to do it, I'm still not clear what the intentions were given the mismatch between what was uploaded and what was discussed in mail
[02:42] <cjwatson> gnomefreak: also, you should never blame buildds in the *first* instance because such a diagnosis means it can't be fixed in the package
[02:42] <gnomefreak> true
[02:43] <gnomefreak> ok gimp is still failing here
[02:53] <cjwatson> gnomefreak: I don't see a bug report on gimp
[02:55] <cjwatson> urgh, I don't think doko looked at this rules file before editing it
[03:00] <gnomefreak> gimp broke earlier today i over-wrote deb now its failing again so im gonna assume it was --force-overwite that caused the fixed version to fail
[03:01] <gnomefreak> but it broke in the last batch i got
[03:04] <cjwatson> if you're on #ubuntu-devel, you should never use --force-overwrite without ensuring that a bug report is filed
[03:06] <cjwatson> bug 148985
[03:06] <ubotu> Launchpad bug 148985 in gimp "package gimp 2.4.0~rc3-1ubuntu4 failed to install/upgrade: trying to overwrite `/usr/share/doc/libgimp2.0/README', which is also in package libgimp2.0" [Medium,Fix released]  https://launchpad.net/bugs/148985
[03:09] <gnomefreak> bug report was filied early today
[03:09] <gnomefreak> they were marking dupes when i ran into issue
[03:13] <cjwatson> it would have saved me time if you'd mentioned that here, then, rather than making me go look
[03:14] <gnomefreak> sorry i didnt have bug number
[03:14] <cjwatson> or mentioned that there was a bug at all
[03:14] <cjwatson> sigh. whatever. I'll go finish fixing cupsys
[03:14] <gnomefreak> point taken
[03:24] <cjwatson> gnomefreak: yes, if you --force-overwrite and name the wrong package, chances are you'll have to --force-overwrite again to put it back
[03:25] <cjwatson> I'll put a Replaces in libcupsys2 because I'm feeling nice
[03:25] <gnomefreak> cjwatson: ty
[03:25] <cjwatson> I don't think it's really obligatory to dig people out of that hole they dug themselves though :)
[03:25] <gnomefreak> mneptok: i would do it before it happend
[03:25] <gnomefreak> cjwatson: i can fix it but ty for feeling nice
[03:25] <jdong> mneptok: preventative, nice
[03:26] <jdong> mneptok: gonna grab -motu? :)
[03:26] <mneptok> no access. i'll get Hobbsee to add me when she awakens.
[03:26] <cjwatson> gnomefreak: it's been advised to everyone subscribed to the enormous pile of bug reports ...
[03:27] <gnomefreak> ok ty
[03:46] <Hobbsee> sladen: ping
[03:48] <slangasek> soren: linux64... a... no-op on 32-bit? <twith>

[03:49] <cjwatson> yeah, it's, er, a bit odd
[03:49] <lamont> slangasek: "linux64" == "make my personality my native one.  kthxbye"
[03:49] <slangasek> lamont: <twitch>
[03:50] <lamont> it's not a no-op.  it changes your personality back to the native one... the fact that you didn't change it to something else beforehand is the strange part....
[03:50] <slangasek> right... :)
[03:51] <lamont> I didn't write it, I just accidentally hijacked it.
[03:54] <lamont> it was maybe an unfortunate choice of name... but remember that the author was kinda focused on 64-bit architectures
[03:55] <lamont>         PER_LINUX =             0x0000,
[03:55] <lamont>         PER_LINUX_32BIT =       0x0000 | ADDR_LIMIT_32BIT,
[03:55] <lamont> including in the kernel...
[03:55] <slangasek> right
[03:56] <lamont> and you'd give us different crap if we called the command /usr/bin/linux :)
[03:56] <slangasek> pff, why couldn't it be sane like prctl
[03:56] <lamont> if it helps, linux32's links were the final straw that convinced me it was time to move util-linux to debhelper
[03:57] <lamont> and thereby make the Makefile readable again
[03:58] <slangasek> heh
[04:01] <slangasek> oh, hah, there is a generic "setarch" that it's a symlink to?  well, that's a bit saner
[04:02] <cjwatson> well, the Debian bug has the appropriate variant of the patch now
[04:02] <lamont> slangasek: setarch $arch options
[04:02] <lamont> or $arch options
[04:03] <lamont> slangasek: so what brought the subject up, anyway
[04:03] <lamont> ?
[04:04] <slangasek> lamont: the mbr ftbfs
[04:04] <lamont> oh, right
[04:05] <lamont> I also get an 'i386' symlink. :)
[04:06] <cdm10> Hi, is there any known issue with Samba on Gutsy?
[04:06] <slangasek> I want a "sparc32" symlink on amd64
[04:06] <slangasek> cdm10: https://bugs.launchpad.net/ubuntu/+source/samba will show you any number of known bugs; would you care to be more specific?
[04:07] <lamont> slangasek: submit a patch.
[04:07] <cdm10> slangasek: Thanks, I didn't know where to look.
[04:07] <lamont> the biggest samba bug is that it talks to windoze?
[04:08] <bddebian> haha
[04:09] <slangasek> lamont: there's a setting you can use to work around that
[04:12] <slangasek> tkamppeter: so is bug #99372 something you're working on, or should I try to find a kubuntu person to take it on?
[04:12] <ubotu> Launchpad bug 99372 in kdebase "MASTER: [Feisty]  KDE Printing Manager does not list the PPDs of Gutenprint" [High,Confirmed]  https://launchpad.net/bugs/99372
[04:14] <Hobbsee> oh yay, cimmo's commented on that bug.
[04:17] <slangasek> Hobbsee: ?
[04:18] <Hobbsee> slangasek: sorry, you must have missed my sarcasm there.
[04:18] <slangasek> I just have no idea who cimmo is
[04:18] <Hobbsee> slangasek: (cimmo thinks that there are infinite developers, and that the reason all bugs arent dealt with immediately is because people are lazy)
[04:27] <bddebian> Hobbsee: Yeah, get ta work ya bum ;-)
[04:27] <Hobbsee> bddebian: now you get going on that universe queue, else you'll get poked with teh Long Pointy Stick of DOOM!!!!!!!!!!!!!!!
[05:04] <mpt> Hobbsee, in the old days the bugzilla.mozilla.org approach to those sort of people was to assign the bug to them
[05:04] <Hobbsee> mpt: true that.  which people object to, for some reason :P
[05:07] <mekius> http://pastebin.com/mb63fed2 <--known?
[05:11] <gnomefreak> mekius: yes known
[05:12] <gnomefreak> mekius: bug 149188
[05:12] <ubotu> Launchpad bug 149188 in cupsys "[GUTSY BETA]  error when updating cupsys (dup-of: 149106)" [Undecided,Confirmed]  https://launchpad.net/bugs/149188
[05:12] <ubotu> Launchpad bug 149106 in cupsys "package cupsys 1.3.2-1ubuntu4 failed to install/upgrade: trying to overwrite `/usr/share/doc/libcupsys2/CREDITS.txt', which is also in package libcupsys2" [High,Fix released]  https://launchpad.net/bugs/149106
[05:13] <mekius> gnomefreak: thx
[05:13] <gnomefreak> np
[05:13] <mekius> working on a custom live cd, not a fan of debian based systems personally heh
[05:13] <gnomefreak> freeze is today isnt it?
[05:13] <mekius> custom ubuntu live cd that is
[05:13] <mekius> no clue heh
[05:13] <mekius> if it is that is good cause we've been running into packaging issues daily :/
[05:14] <gnomefreak> i was thinking about trying to make a livecd
[05:14] <mekius> guess that is what we get for basing on gutsy heh
[05:15] <gnomefreak> i havent seen anywhere near the problems we had in dapper edgy and feisty, in gutsy to date
[05:16] <mekius> that's good to hear :)
[05:16] <mekius> it hasn't been too bad
[05:16] <mekius> just in the last couple days
[05:16] <mekius> maybe the rush to get packages in before freeze :)
[07:29] <Mithrandir> asac: is it known that firefox seems unhappy if you change themes while it's running?
[07:30] <mekius> Mithrandir: usually not too unhappy for me
[07:35] <Mithrandir> mekius: I see it on both amd64 and i386 here
[07:36] <mekius> don't use gnome though so that might be it
[07:36] <mekius> what do you mean by unhappy?
[07:38] <frostburn> anthropomorphized browsers, it's all the rage
[07:38] <pitti> Good morning
[07:39] <slangasek> morning
[07:40] <pitti> hi slangasek
[07:42] <mvo> hey pitti
[07:53] <Mithrandir> locks up for a long time.
[07:55] <StevenK> pitti: Do you have a moment? I've discussed the promotion list with Mithrandir, and I'd like you to take another look if you have time?
[07:56] <pitti> StevenK: yeah, can do
[07:56] <StevenK> pitti: http://wedontsleep.org/~steven/big-promotion
[07:57] <StevenK> pitti: That list is the more important stuff for -mobile, with two simple apps
[07:58] <pitti> StevenK: no frozen-bubble any more? :(
[07:59] <StevenK> It'll come up, it's just not first.
[07:59] <pitti> StevenK: this list looks absolutely appropriate to me
[07:59] <StevenK> pitti: Okay, shall I sign it and submit it as a bug?
[08:00] <StevenK> pitti: Or do you really want me to re-add frozen-bubble? :-)
[08:00] <pitti> StevenK: pull the trigger
[08:00] <Mithrandir> pitti: we figured that starting with a smaller list of less controversial items would be easier.
[08:00] <pitti> StevenK: it needs some quite large dependencies, so maybe not for the initial rush
[08:00] <Mithrandir> pitti: as for l10/i18n, that's something we want to discuss at UDS.
[08:00] <StevenK> pitti: *nods* Understood
[08:01] <pitti> Mithrandir: is there a chance to avoid one of the two mozilla copies (xulrunner) and clamav?
[08:01] <pitti> Mithrandir: i18n> yeah, good opportunity; I'm interested to learn how it works ATM, then I'm sure we can figure something out
[08:01] <Mithrandir> pitti: yes, xulrunner will be going, and I'm not completely convinced of claws yet, so those can wait.
[08:02] <StevenK> claws looks like a pig to me
[08:02] <pitti> Mithrandir: oh, and sendmail? Is that just a wrong prefered dependency or so?
[08:02] <StevenK> pitti: sendmail is due to clamav Build-Depend'ing on libmilter-dev
[08:02] <pitti> Mithrandir: I just thought that if the devices we are talking about can digest firefox/midbrowser, then thunderbird shouldn't be too big either?
[08:03] <Mithrandir> pitti: sendmail is a build-dep for clamav which has a milter plugin.
[08:04] <pitti> eww
[08:04] <Mithrandir> well, libmilter-dev is a build-dep
[08:04] <Mithrandir> and comes from sendmail
[08:04] <pitti> well, since clamav itself is pretty much a no-go for main, it doesn't matter that much
[08:04] <Mithrandir> as for thunderbird, that's an option, but it haven't been hildonised by anybody TTBOMK.
[08:05] <Mithrandir> StevenK: claws isn't hildonised in current lpia due to a bug; Adilson is working on fixing that.
[08:11] <StevenK> How do I stop vim indenting stuff when I paste it in? It's very irritating.
[08:12] <StevenK> I was quite tempted to say, "I will use it to choke you."
[08:14] <bryce> hehe
[08:15] <Mithrandir> StevenK: :set paste
[08:15] <StevenK> Hrm. I was trying :set noai
[08:17] <pitti> StevenK: configure a pastetoggle key
[08:17] <pitti> set pastetoggle=<F9>
[08:17] <pitti> StevenK: ^ in your .vimrc
[08:17] <pitti> StevenK: then I usually do F9 - middle click - F9
[08:18] <StevenK> I like it.
[08:20] <StevenK> pitti, Mithrandir: Bug 149275
[08:20] <ubotu> Launchpad bug 149275 in tasks "First cut of source packages for -mobile promotions" [Undecided,New]  https://launchpad.net/bugs/149275
[08:21] <pitti> ah, thanks
[08:21] <pitti> I'll talk to iwj to coordinate and share the review
[08:21] <StevenK> pitti: Thanks
[08:21] <StevenK> The dropdown lists at the top look impressive
[08:22] <pitti> "frightening" was what came to my mind
[08:25] <kagou> Good morning
[08:31] <calc> is it known that totem isn't descriptive on what it needs to play dvd's, iirc it is for other media types
[08:31] <calc> i installed libdvdcss2 and it doesn't want to play but doesn't say what it needs
[08:32] <pitti> calc: hello
[08:32] <pitti> calc: hm, that should actually be taken care of by simple-codec-installation
[08:32] <pitti> mvo: ^ ?
[08:33] <calc> i don't see that if it is a package on my box
[08:33] <mvo> ?
[08:33] <calc> mvo: i can't play dvd's with totem even with libdvdcss2 installed and it isn't very descriptive as to why
[08:33] <calc> it says "Totem cannot play this type of media (DVD) because it does not have the appropriate plugins to be able to read from the disc."
[08:34] <Mithrandir> calc: libdvdread?
[08:34] <Mithrandir> it's not a codec, it's an access library
[08:34] <calc> yep libdvdread3 is installed too
[08:34] <mvo> calc: oh, no idea. I don't think this is done via gstreamer
[08:34] <calc> i guess i can just install totem-xine but that is cheating
[08:34] <mvo> or is it? if so, we should make sure that the easy codec install gets extended to understand about it
[08:35] <mvo> calc: yes :P
[08:35] <calc> mvo: I don't know how totem does the dvd playing stuff, never examined it before
[08:36] <mvo> calc: seb128 probably has a idea, he should be around in ~1h
[08:36] <calc> ok
[08:38] <StevenK> Hrm. Compiz 0.6.0 finally released
[08:39] <mvo> and already in gutsy
[08:39] <StevenK> Heh, neat
[08:41] <RAOF> ...and already has patches from git applied to fix stuff :)
[08:41] <StevenK> My cat was on my windowsill - until the dog next door starting barking.
[08:41] <StevenK> She jumped a mile and ran off
[08:41] <RAOF> With *hilarious* consequenses!
[08:42] <StevenK> Well, she knocked over one of my speakers in her haste
[08:43] <doko> cjwatson_: ouch, missed the debian/docs file, which installs CREDITS ...
[08:43] <pitti> calc: btw, what's the current status on your local disk wrt. OO.o? do you plan another upload for gutsy?
[08:43] <Burgundavia> calc: afaik, gstream still has no support for DVD menus
[08:44] <calc> for whatever reason even totem-xine seems to not work either
[08:44] <dholbach> good morning
[08:44] <calc> huh i wonder if this is a disc that can't be played under linux
[08:44] <calc> that would really suck :\
[08:47] <calc> hah, i am going to have to pirate the movie to be able to play it, its a damn sony movie
[08:47] <calc> it won't even play on most standalone dvd players
[08:48] <calc> now i know why i hadn't rented this movie yet even though its old, i used to know which ones to avoid
[08:48] <pitti> check for rootkits :)
[08:48] <calc> heh
[08:56] <TheMuso> c
[08:56] <TheMuso> ugh
[08:59] <kwwii> about half of my system is upgraded
[08:59] <kwwii> and when I start adpet-manager to finish it is says that it cannot because it would break things
[09:01] <slangasek> calc: so pitti had talked to me about needing some fixes to bibliography handling before we could consider dropping oo-base from the CDs; is this something you're working on, is there a bug number for it, and is there anything you could use help with?
[09:03] <calc> slangasek: i don't have a bug number for it yet, and not sure what i should do as far as warning or just not crash, etc?
[09:03] <calc> if i warn then i would need translations right?
[09:03] <calc> also i am not even sure what all parts of the code will trigger crashes, at least bibliography and mail merge
[09:03] <calc> maybe more
[09:04] <calc> ooo upstream is considered to be one thing to install so they are intertwined quite a lot
[09:05] <slangasek> translators wouldn't thank us for an additional string, but an error message in English would be better than an error message in "C++ backtrace"
[09:05] <calc> yea
[09:06] <mdke> there aren't any Ubuntu translations for ooo, I think
[09:06] <calc> something really simple like "Install openoffice.org-base" would be fairly easy to understand across languages since it would be just one word to translate... ;)
[09:06] <slangasek> so in what kind of timeframe would you be able to answer the question of which parts of the code will trigger it?
[09:06] <mdke> it's all upstream
[09:06] <calc> mdke: we're talking about adding another string to ooo
[09:07] <calc> mdke: or a few probably all with the same basic message
[09:07] <mdke> calc: right, my point was that since Ubuntu doesn't translate ooo, it can't be translated
[09:07] <calc> mdke: ok
[09:07] <calc> mdke: long term it will be but that is in hardy timeframe
[09:07] <mdke> probably that helps, doesn't it, because you don't have to worry about notifying translators
[09:07] <slangasek> because we're kinda supposed to have the CDs sorted, er, today
[09:07] <calc> slangasek: i will try to have the list done today (Friday)
[09:07] <calc> slangasek: oh shit, ok didn't realize that was today :\
[09:08] <slangasek> mdke: well, just because the translations aren't primarily done in LP doesn't mean that the translation teams wouldn't have taken a stab at it had they been given a chance
[09:10] <mdke> slangasek: ok, if there is translation activity in Ubuntu OOo then it becomes a consideration again :) still, I wasn't aware of such
[09:10] <pitti> mvo: what's the status of bug 120957? it looks quite confusing
[09:10] <ubotu> Launchpad bug 120957 in update-manager "UpdateManager fails to fetch dist-upgrade tarball" [High,Invalid]  https://launchpad.net/bugs/120957
[09:12] <mvo> pitti: the original bug is fixed with 0.59.25, the last comment indicates that it got hijacked for something else
[09:12] <pitti> soren: any news about bug 119908?
[09:12] <ubotu> Launchpad bug 119908 in dovecot "Dovecot crashes on index files" [Undecided,Fix released]  https://launchpad.net/bugs/119908
[09:13] <pitti> mvo: can you please update the gutsy and feisty tasks appropriately? (I think the import os issue is fixed in feisty, right?)
[09:13] <mvo> yes
[09:13] <pitti> mvo: if the last commenter has a different problem, he needs to file a new bug
[09:13] <pitti> hijacking SRU bugs is way too confusing
[09:13] <pitti> mvo: danke sehr! *hug*
[09:14] <mvo> yes again :)
[09:14] <pitti> I approved the feisty task
[09:15] <calc> slangasek: oh another issue is if a document uses base for something already it will likely crash writer as soon as it is opened
[09:15] <soren> pitti: No, I'm afraid it slipped under my radar at some point. I remember I found the diff for you, but it was something like 18k lines :/
[09:15] <slangasek> calc: <sigh>
[09:15] <pitti> it sounds like writer should actually Depends: -base, or so
[09:16] <calc> pitti: yea more or less
[09:16] <pitti> if someone uninstalls -base on his system, he'd get the same result
[09:16] <calc> pitti: yep, that is why we have been installing openoffice.org which pulls it all in, in the past
[09:16] <pitti> calc: doko also mentioned that we could make gij optional; do you know what that would chnage?
[09:16] <slangasek> well, it's not just embedding databases in text documents either, is it?
[09:17] <slangasek> you can embed spreadsheets in a text doc, or $mumble in a presentation?
[09:17] <dholbach> debian bug 439843 fixes my evolution crashing on startup (and other occurences of crashers with other gnome apps) - is http://daniel.holba.ch/temp/libxml2.debdiff OK for upload?
[09:17] <ubotu> Debian bug 439843 in libxml2 "libxml2: Version 2.6.30.dfsg-1 breaks Azureus and evolution (until now)" [Critical,Fixed]  http://bugs.debian.org/439843
[09:17] <doko> pitti, calc: only if we can give the user a hint when opening the wizards in writer (i.e. opening a dialog box when we cannot find a jvm)
[09:17] <calc> slangasek: true, also if you do envelope or bibliography related stuff it doesn't directly look like database stuff but would probably crash it as well, i haven't verified for the simple case with just those things though
[09:18] <calc> doko: ah
[09:18] <doko> dholbach: there is another libxml2 upload pending ...
[09:18] <pitti> ah, seems doko managed to shove off 8 MBs from our alternates; thanks a lot!
[09:18] <pitti> so, 10 MB to go
[09:18] <dholbach> doko: since I don't have your changes to libxml2, would you mangle the fix into yours?
[09:18] <dholbach> it seems to fix __xmlParserInputBufferCreateFilename() sort of crashers
[09:19] <calc> so far with a manual gui inspection the only things that crash are related to envelopes and bibliography which I had found initially
[09:19] <doko> dholbach: bug 147144, which includes your fix
[09:19] <ubotu> Launchpad bug 147144 in libxml2 "xslt:copy element is broken in 2.6.29" [Medium,Confirmed]  https://launchpad.net/bugs/147144
[09:19] <StevenK> pitti: If I could actually remember how to do /usr/share/doc links properly, libsnmp10 should kill another 1Mb
[09:20] <doko> StevenK: where's the problem?
[09:20] <StevenK> doko: I think the problem is me. :-)
[09:20] <pitti> StevenK: most important thing to remember is that you need a preinst to replace a dir with a symlink
[09:20] <dholbach> doko: is that a merge of 2.6.30.dfsg-2
[09:20] <pitti> StevenK: (since dpkg won't do it)
[09:21] <mdke> pitti: with the next upload of ubuntu-docs, there is an increase in the package size, just to warn you. It's due to adding translations
[09:21] <dholbach> doko: ok, looks good then
[09:21] <dholbach> yoohoo
[09:21] <dholbach> no libxml2 breakage anymore
[09:21] <StevenK> pitti: My problem at the moment is it won't stop shipping /usr/share/doc/libsnmp10
[09:21] <dholbach> thanks doko
[09:22] <doko> mdke: even when not shipping the not needed xml files?
[09:22] <pitti> mdke: TBH, I'd like to do a ban of package size increase until we sort out the 10 MB we need to chop off
[09:23] <Trewas> aren't all packages supposed to have changelog.Debian.gz? I am wondering why my laptop started failing to suspend and I suspect the recent xserver-xorg-video-intel upgrade but noticed that it has no changelog
[09:23] <mdke> doko: yes, including those. Translations are very large
[09:23] <pitti> Trewas: for native packagages they might just have a changelog.gz
[09:23] <mdke> pitti: alright, it's your call.
[09:24] <mdke> the package I built as a test was 2.1MB over about 1MB for the previous version
[09:24] <doko> mdke: would it be possible to upload ubuntu-docs without new translations first?
[09:24] <Trewas> pitti: it has only files "copyright" and "README.gz" (dated months ago) in its /usr/share/doc directory
[09:25] <doko> pitti: want to have a look at 147144?
[09:25] <mdke> doko: I presume so, although we might have to completely rework the package. It is always set up to ship translations if they are present in the repository
[09:25] <pitti> Trewas: that's a bug then
[09:26] <mdke> an alternative would be to slim down the package size by only shipping translations which have a very high percentage of translation
[09:26] <pitti> doko: the changelog only has bug fixes, so it's not subject to freeze
[09:27] <mdke> lemme see how big the package is with only 90% complete translations
[09:27] <doko> pitti: ok thanks, uploading
[09:27] <pitti> thank you
[09:28] <\sh> doko, can you make a sense of this, while starting up oofice ??  ** (process:6067): WARNING **: Unknown error forking main binary / abnormal early exit ...
[09:28] <Trewas> pitti: should I file a bug about it? and preferably for ubuntu or for debian (assuming they are missing the changelog too)?
[09:28] <\sh> doko, I have it on two of my gutsy machines...(lt43 and a hp desktop)
[09:28] <pitti> mdke: ah, would certainly be an interesting figure (although 90% is certainly a bit high)
[09:28] <mdke> pitti: yes, I would not envisage releasing with that, it would be very unfair to translators
[09:29] <pitti> Trewas: on Debian preferably, when it is missing there
[09:29] <doko> \sh: restricted graphics driver?
[09:29] <\sh> doko, nope...ati oss and compiz-fusion
[09:29] <Trewas> pitti: ok
[09:29] <pitti> mdke: also, if we can chop off enough, 1 MB for added translations is well worth the space
[09:29] <\sh> doko, and on the second one ati oss and dual head setup without compiz
[09:29] <pitti> mdke: so I'm not refusing the new upload at all, I just like to ask you to stall it a bit
[09:29] <pitti> hi \sh
[09:29] <\sh> moins pitti :)
[09:30] <doko> \sh: no idea, please ask calc
[09:30] <mdke> pitti: ok, but it has some important fixes too, so if we can upload at 90% now and then reduce it say on Monday, that would be good
[09:30] <doko> \sh: or better file a bug report
[09:30] <\sh> doko, will do :)
[09:30] <calc> \sh: try without compiz and see if it goes away
[09:30] <pitti> mdke: works for me, too
[09:31] <calc> \sh: i've seen compiz do weird stuff with various other apps like firefox/thunderbird as well
[09:31] <\sh> calc, I don't have compiz enabled on the other machine :)
[09:31] <calc> \sh: oh fun
[09:31] <\sh> calc, same error
[09:31] <mdke> pitti: ok, it's 1.3MB with >90%  translations (compares with 1.0MB for the current package in the archive)
[09:31] <calc> \sh: i've seen someone mention an issue like yours (maybe it was you) but haven't been able to reproduce it
[09:31] <pitti> mdke: that's fine
[09:31] <mdke> ok, I'll commit the change and comment on the bug report
[09:32] <\sh> calc, nope...I just wanted to start up ooO today to write my CV ...
[09:32] <pitti> \sh: did you have a chance to test bug 103291 in gutsy? we need to put this into dapper soon for dapper.2
[09:32] <ubotu> Launchpad bug 103291 in lilo-installer "lilo-installer fails on HP (Compaq) SmartArray controllers (/dev/cciss)" [Medium,In progress]  https://launchpad.net/bugs/103291
[09:32] <mdke> pitti: that trick of yours with the translation percentage is very useful :)
[09:32] <calc> \sh: both i386?
[09:32] <\sh> calc, yepp
[09:32] <pitti> mdke: \o/
[09:32] <StevenK> \sh: Oh pfeh, CVs should be done in LaTeX. :-)
[09:33] <\sh> pitti, thx for reminding me :) I wanted to update it :)
[09:33] <calc> \sh: hmm :( whatever it is it must be uncommon since i don't have an inbox full of reports, file a bug report with as much detail as you can get about it
[09:33] <pitti> \sh: oh, does it work now?
[09:33] <\sh> pitti, well, works for me ;) I'm, updating the bug now :)
[09:33] <pitti> cool
[09:34] <\sh> StevenK, I have my CV ready on the web...I need to transform it properly into PDF...and push my other stuff as well in
[09:35] <StevenK> \sh: Yes, so use LaTeX. :-)
[09:35] <\sh> calc, I'll file a bug against ooffice...what do you need to have good infos?
[09:35] <pitti> calc: sleep well!
[09:36] <calc> \sh: package version, arch, if you can manage to get a good gdb backtrace that would be helpful, but the other person wasn't able to get one
[09:37] <StevenK> I thought OOo resisted debugging? :-P
[09:37] <\sh> calc, I'm trying to get them..hopefully it works :)
[09:37] <calc> \sh: maybe kernel version as well, not sure what would be causing it to not to fork
[09:37] <calc> \sh: whatever the problem is its uncommon :-(
[09:37] <calc> StevenK: heh yea a bit
[09:39] <\sh> calc, will give you everything you want :) let's see what's coming out
[09:44] <pitti> cjwatson_: do you have the dapper update for bug 103291 at hand for upload?
[09:44] <ubotu> Launchpad bug 103291 in lilo-installer "lilo-installer fails on HP (Compaq) SmartArray controllers (/dev/cciss)" [Medium,In progress]  https://launchpad.net/bugs/103291
[09:44] <\sh> calc, no backtrace possible....
[09:49] <dholbach> MOTU Q&A session in #ubuntu-classroom in 10 minutes
[09:58] <doko> mdke, pitti: currently looking at ubuntu-docs
[10:00] <dholbach> doko: bug 149040?
[10:00] <ubotu> Launchpad bug 149040 in ubuntu-docs "waste of disk space" [Medium,In progress]  https://launchpad.net/bugs/149040
[10:00] <doko> dholbach: yes
[10:00] <Hobbsee> hiya dholbach
[10:01] <dholbach> hey Hobbsee
[10:01] <doko> dholbach: no, please go ahead (if the package is smaller than the current one)
[10:01] <dholbach> doko: it contains a lot of new translations, that's why it's hard to judge
[10:02] <seb128> dholbach: is that you who do ubuntu-docs uploads?
[10:02] <dholbach> seb128: ubuntu-main-sponsors does it, I did it all the time 'historically'
[10:02] <doko> dholbach: ohh, right, and those get stripped for the binary ...
[10:03] <seb128> dholbach: bug #146832
[10:03] <ubotu> Launchpad bug 146832 in ubuntu-docs "ubuntu-docs: undefined "’" in /usr/share/omf/windows/windows-C.omf" [Undecided,Fix committed]  https://launchpad.net/bugs/146832
[10:04] <seb128> dholbach: the current version breaks update, would be nice if somebody could sponsor quickly
[10:04] <dholbach> seb128: I'll do the upload then - bug 149040 and bug 146832 should be fixed that way
[10:04] <ubotu> Launchpad bug 149040 in ubuntu-docs "waste of disk space" [Medium,In progress]  https://launchpad.net/bugs/149040
[10:04] <ubotu> Launchpad bug 146832 in ubuntu-docs "ubuntu-docs: undefined "’" in /usr/share/omf/windows/windows-C.omf" [Undecided,Fix committed]  https://launchpad.net/bugs/146832
[10:04] <seb128> dholbach: thanks
[10:11] <dholbach> seb128, doko: uploaded
[10:13] <seb128> dholbach: danke
[10:19] <dholbach> mvo: can you update command-not-found-data before the release again?
[10:21] <mvo> dholbach: yes
[10:21] <dholbach> mvo: gracias
[10:23] <mvo> dholbach: that and a app-install-data-update is on my list
[10:23] <mvo> dholbach: the list that is too long ,)
[10:26] <dholbach> hehe Hobbsee
[10:28] <Hobbsee> dholbach: now stay there, or else it will be the duct tape :P
[10:28] <dholbach> Hobbsee: gotcha :)
[10:29] <Hobbsee> Mithrandir: you'd have to get up there yourself!
[10:30] <Mithrandir> Hobbsee: I have climbing equipment.
[10:30] <Hobbsee> Mithrandir: depends how climable it is, though.
[10:31] <Mithrandir> true
[10:31] <Hobbsee> which, at least that one wasnt.
[10:32] <Hobbsee> and, last i checked, you cant put a scissorlift into your suitcase.
[10:32] <Mithrandir> you can rent one locally?
[10:33] <Hobbsee> sure, if you have connections.
[10:33] <Mithrandir> like, a phone and a bit of money? :-P
[10:33] <Hobbsee> you'd have to know the number to ring :P
[10:35] <liw> start with a random number and go from there
[10:38] <slangasek> uh. why does acpi-support depend on finger? :)
[10:39] <Mithrandir> special :-)
[10:39] <seb128> dholbach, Mithrandir: any opinion on bug #131530?
[10:39] <ubotu> Launchpad bug 131530 in bluez-gnome "'Browse device...' in the bluetooth applet is useless without gnome-vfs-obexftp" [Medium,Confirmed]  https://launchpad.net/bugs/131530
[10:40] <Mithrandir> seb128: bluez-gnome should depend on gnome-vfs-obexftp?
[10:40] <dholbach> seb128: yes, I agree with the bug report
[10:40] <Mithrandir> it's about 160k, so I think we can safely do that.
[10:41] <seb128> Mithrandir: that's what the bug suggests
[10:41] <pitti> Riddell: do you want to seed hplip-gui to Kubuntu, or shall we demote it?
[10:42] <Mithrandir> seb128: do you feel like doing it or should I?
[10:42] <seb128> Mithrandir: if you could do it that would be nice, I'm in the middle of several other things at the moment
[10:43] <Mithrandir> sure
[10:43] <seb128> Mithrandir: but gnome-vfs-obexftp is an universe package which is slightly problematic
[10:43] <Mithrandir> seb128: oh?
[10:43] <Mithrandir> as in, what's problematic?
[10:44] <seb128> as in need an MIR and pitti approval before adding a Depends? ;)
[10:44] <doko> pitti: looking into libservlet2.4-java, libtiff, libsane to move the docs to another packge (-dev, or -doc), 5.5MB uncompressed
[10:44] <Mithrandir> well, yes.
[10:51] <tkamppeter> hi pitti
[10:51] <pitti> doko: ooh, *hug*
[10:51] <pitti> hi tkamppeter
[10:52] <tkamppeter> pitti, do you know how the usblp kernel module gets loaded?
[10:52] <pitti> tkamppeter: it has modaliases, so just via the usual module autoloading, I figure
[10:55] <tkamppeter> pitti, thanks I have found the problem. I have "blacklist usblp" in /etc/modprobe.d/blacklist. Probably I have added that for testing the libusb-based CUPS backend.
[10:55] <pitti> ah :)
[10:56] <tkamppeter> And so subsequent boots did not load the backend.
[10:58] <tkamppeter> pitti, another thing: bug 138776. It seems that on an update to Gutsy the privileged user(s) do not stay in the "lpadmin" group.
[10:58] <ubotu> Launchpad bug 138776 in system-config-printer "[gutsy tribe 5]  a user with sudo privileges cannot change printer settings" [Wishlist,Confirmed]  https://launchpad.net/bugs/138776
[10:59] <tkamppeter> problem most probably caused by bug 26338
[10:59] <ubotu> Launchpad bug 26338 in gnome-system-tools "Adding a user to a group modifies other users' groups and passwords" [Critical,Confirmed]  https://launchpad.net/bugs/26338
[11:02] <dholbach> soren: submittodebian is missing from the package, I guess it's not in setup.py - I can fix that; shall I also apply the patch from bug 148526?
[11:02] <ubotu> Launchpad bug 148526 in ubuntu-dev-tools "submittodebian should follow Bugs/Debian/Usertagging" [Undecided,New]  https://launchpad.net/bugs/148526
[11:05] <seb128> mjg59: could you look at bug #148291? That's another g-s-d crasher due to the synaptic changes
[11:05] <ubotu> Launchpad bug 148291 in gnome-control-center "Unable to start the settings manager 'gnome-settings-daemon'." [Medium,New]  https://launchpad.net/bugs/148291
[11:05] <slangasek> lool: do you know why gedit depends on iso-codes?  changelog only mentions build-depends
[11:06] <asac> pitti: when you do your next NEW batch, there is lightning-extension-locales, xulrunner-1.9, firefox-3.0 in NEW ... if you want any infos on those let me know.
[11:07] <pitti> slangasek: there are quite a few other reverse dependencies on iso-codecs on the CD, though (language-selector, oem-config, ubiquity, etc.)
[11:07] <lool> slangasek: Looking at SVN history, I can tell you that HE added the dep at the same time he added the b-dep; no idea why yet
[11:08] <slangasek> pitti: right, moving on
[11:08] <slangasek> but yeesh, iso-codes is fat
[11:08] <pitti> asac: does firefox-3.0 replace -granparadiso?
[11:08] <asac> pitti: yes ... and it has a _small_ orig ... because it builds against xulrunner-1.9
[11:08] <lool> slangasek: iso-codes is also used in totem and epiphany IIRC
[11:08] <pitti> asac: \o/
[11:08] <asac> pitti: build of firefox-3.0 takes about 2 minutes now :)
[11:09] <pitti> rock
[11:09] <lool> slangasek: totem is probably missing a dependency on iso-codes in ubuntu
[11:09] <lool> slangasek: I think this is used to display the localized name of languages in e.g. DVD menus
[11:10] <DktrKranz> could an archive-admin look at bug 112729 ? it should be already fixed
[11:10] <ubotu> Launchpad bug 112729 in bootcd "[bashism]  /usr/share/bootcd/bootcd-run.lib: 144: Syntax error: "(" unexpected" [Medium,Fix committed]  https://launchpad.net/bugs/112729
[11:11] <pitti> slangasek: we would win 0.5 MB by bzip2'ing it
[11:11] <lool> slangasek: I confirm iso-codes is a required dependency for the gedit spell checking
[11:11] <lool> slangasek: Presumably displaying localized names of languages to spell check against
[11:11] <lool> At least it was required in 2.18.0
[11:12] <slangasek> lool: that's pretty sad given that when I try to configure the spellchecker in gedit, all the language options it gives me are "English" :)
[11:12] <lool> seb128: Do you agree totem-gstreamer and xine should depend on iso-codes?
[11:12] <sladen> Hobbsee: !just ask
[11:12] <lool> src/totem-menu.c will open #define ISO_CODES_DATADIR ISO_CODES_PREFIX"/share/xml/iso-codes"
[11:13] <seb128> lool: yes
[11:13] <Hobbsee> sladen: i've effectively hijacked -motu from you
[11:13] <lool> slangasek: But please note that English is localized as English in your English locale
[11:13] <Hobbsee> sladen: hope you dont mind :)
[11:13] <lool> ;)
[11:13] <lool> seb128: Should I open a bug with debdiff?
[11:14] <sladen> Hobbsee: oh excellent, I wish somebody had done that a long time ago
[11:14] <seb128> lool: feel free to open a bug or to upload a new revision somewhere (I'll sponsor it)
[11:14] <Hobbsee> sladen: even better :)
[11:14] <Hobbsee> sladen: it's the irc council's domain now anyway
[11:14] <sladen> Hobbsee: even even better :)
[11:14] <Hobbsee> :D
[11:15] <fabbione> seb128: did anybody ever reported that the "Force quit" option kicks in waaaay to fast?
[11:16] <fabbione> seb128: very often when I close an apps that takes more than 2 seconds (like.. OOo) bam.. i get immediatly the dialog
[11:16] <seb128> fabbione: no, it takes like 10 seconds which is usually not too fast
[11:16] <fabbione> is it a config option by any chance?
[11:16] <seb128> fabbione: on gutsy? what arch?
[11:16] <seb128> fabbione: no
[11:16] <fabbione> it kicks much faster than 10 seconds..
[11:16] <fabbione> gutsy/i386
[11:16] <slangasek> pitti: by bzip2ing the .deb?
[11:16] <fabbione> very latest..
[11:16] <Amaranth> #define PING_TIMEOUT_DELAY 2250
[11:16] <pitti> slangasek: right
[11:17] <seb128> fabbione: right, it's around 3 seconds
[11:17] <pitti> slangasek: well, data.tar.bz2
[11:17] <doko> StevenK: do you have a proposed fix for the duplication in snmp?
[11:17] <Hobbsee> doko: (he's gone)
[11:17] <pitti> slangasek: I'll do that unless you want to?
[11:17] <doko> StevenK, Hobbsee, ok, looking then
[11:17] <slangasek> pitti: I don't think I even know how
[11:17] <slangasek> (or could do it if I knew?)
[11:18] <fabbione> seb128: would it be possible to increase that one just a bit like to 5/6 seconds?
[11:18] <lool> seb128: Weird, how do you people build totem?  I get /usr/share/gnome-pkg-tools/1/rules/check-dist.mk:19: Unknown distribution: gutsy
[11:18] <pitti> slangasek: dh_builddeb -i -- -Z bzip2 mainly
[11:18] <Amaranth> In compiz the ping timeout is configurable but the default is 5 seconds
[11:18] <slangasek> pitti: ah
[11:18] <seb128> lool: unknown distributions don't stop the build
[11:19] <lool> It makes "clean" fail here; I thought buildds would fail in this case as well
[11:19] <seb128> lool:
[11:19] <seb128> ALLOWED_DISTS ?= experimental
[11:19] <seb128> DISALLOWED_DISTS ?= unstable
[11:19] <seb128> # unknown distribution; warn
[11:19] <lool> Ah no wait, it's not the error; I miss dpatch on this box but only read the first error
[11:19] <lool> Sorry
[11:19] <seb128> no problem ;)
[11:20] <StevenK> doko: Thanks. I tried to sort it out, and failed.
[11:21] <pitti> slangasek: uploaded; thanks for spotting this
[11:21] <asac> doko: do you know if myspell-dictionaries is still the right virtual package to depend/recommend if you want myspell/hunspell dictionary?
[11:21] <slangasek> pitti: cheers
[11:21] <doko> asac: hmm, can't remember
[11:24] <doko> seb128: do you know julian blaches nick?
[11:25] <seb128> doko: the xsane maintainer?
[11:25] <seb128> or somebody else with a similar name?
[11:25] <tkamppeter> Is there any chance that bug 26338 will get fixed? It especially causes bug 148526.
[11:25] <ubotu> Launchpad bug 26338 in gnome-system-tools "Adding a user to a group modifies other users' groups and passwords" [Critical,Confirmed]  https://launchpad.net/bugs/26338
[11:25] <ubotu> Launchpad bug 148526 in ubuntu-dev-tools "submittodebian should follow Bugs/Debian/Usertagging" [Undecided,New]  https://launchpad.net/bugs/148526
[11:25] <lool> doko: "jb"
[11:26] <doko> ahh, ok
[11:26] <slangasek> doko: "jb", but I don't know that he IRCs much these days?
[11:26] <lool> doko: At least on oftc
[11:26] <Amaranth> wow, idle almost a week
[11:26] <slangasek> pitti: curious dependency from drdsl to libcapi20-dev insted of libcapi20
[11:27] <doko> ok, not online.
[11:27] <doko> slangasek: that seems to be wrong, but I didn't follow the debian changes recently
[11:27] <slangasek> also, why does ubuntu-desktop pull in a bunch of perl libs that nothing else uses? :)
[11:28] <slangasek> oh, my bad, it's the debconf gnome frontend
[11:28] <mjg59> seb128: I /suspect/ that they've got an old version of the Synaptics driver
[11:28] <mjg59> In any case, I'll work around it
[11:28] <slangasek> 4 copies of libdb on the CD
[11:28] <slangasek> what is this, Debian??
[11:29] <seb128> mjg59: thanks
[11:30] <StevenK> I daresay 2 or 3 of those libdb versions should bugger off to universe.
[11:30] <pitti> slangasek: we cleaned up libdb from time to time, but at the rate new ones are introduced into Debian it's almost impossible to keep up to date
[11:30] <pitti> slangasek: and of course there are always a few packages which use on-disk transactions, and are therefore stuck to one version
[11:30] <slangasek> well, two of the versions of db are named explicitly in server-ship
[11:30] <pitti> until someone figures out a way to upgrade those dbs in the postisnt
[11:30] <slangasek> sure
[11:31] <slangasek> well, db4.4 should be the lowest-hanging fruit; let's have a look at that
[11:32] <pitti> slangasek: do you know checkrdepends?
[11:32] <slangasek> yes, though it hadn't occurred to me
[11:33] <pitti> slangasek: you can use it on rookery (~pitti/bin/checkrdepends) or drescher (as lp_archive)
[11:34] <doko> tkamppeter: $ ls -l /usr/share/doc/cupsys-driver-gutenprint/samples/
[11:34] <doko> total 592
[11:34] <doko> -rw-r--r-- 1 root root 598930 Jul 19  2004 profile.jpg
[11:34] <doko> can this be removed?
[11:36] <dholbach> soren: I'll do the upload of ubuntu-dev-tools (patched submittodebian)
[11:36] <slangasek> ok, so db4.4 isn't the low-hanging fruit it ought to be :)
[11:36] <soren> dholbach: You ROCK!
[11:40] <mjg59> seb128: Argh. Is gnome-control-center really not rebuildable more than once?
[11:40] <mjg59> seb128: Write patch, test build, dpkg-buildpackage -S and then it fails to reverse-apply the autoreconf patch
[11:40] <seb128> mjg59: might be, several packages are buggy in that regard
[11:41] <MacSlow> ups... just updating and cupsys_1.3.2-1ubuntu4 tries to overwrite /usr/share/doc/libcupsys2/CREDITS.txt, which is also claimed by libcupsys2
[11:41] <mjg59> The next patch, when reversed, would delete the file config.h.in~,
[11:41] <pitti> MacSlow: fixed in ubuntu5
[11:41] <Hobbsee> MacSlow: known, lots of bugs and dupes already.
[11:41] <MacSlow> pitti, Hobbsee: so just rerun the update?!
[11:41] <pitti> MacSlow: yep, with ubuntu5
[11:42] <mjg59> seb128: How about if I just delete the ~ file from the autoreconf patch?
[11:42] <seb128> mjg59: right *~ are removed during the clean target and should not be in the patches
[11:42] <seb128> mjg59: that would be a good idea ;)
[11:42] <seb128> we should teach cdbs-edit-patch to exclude those
[11:42] <doko> pitti: about libsane, most of it is documentation about supported devices and configuration help/examples. split it out anyway into a libsane-doc package which doesn't land on the CD?
[11:42] <pitti> slangasek: db4.5 does not look too bad; it's OO.o, pyhton2.5 and pam which affects CDs
[11:43] <pitti> doko: sounds great
[11:43] <pitti> slangasek: those could certainly go to db4.6
[11:43] <mjg59> seb128: Yeah, that looks better
[11:43] <doko> pitti, slangasek: OOo can use 4.4, python as well, but we do have existing databases (like spamassassin) which need to be converted
[11:44] <doko> no db4.6 is not an option, it's too buggy
[11:44] <pitti> ah, ok
[11:44] <slangasek> pitti: libdb4.3 would need two rebuilds to drop it from alternate, exim4 and iproute.  iproute doesn't need any changes but a rebuild; exim4 I'm not sure about, the maintainer is doing some upgrade stuff but based on the changelog I'm not sure it's actually sensible
[11:44] <pitti> but SA is perl
[11:44] <mjg59> seb128: Uploaded
[11:44] <seb128> mjg59: thanks
[11:44] <slangasek> I don't know about "too buggy", but db4.6 is currently not one of the ones on the CD so rebuilding stuff for it isn't a win
[11:44] <pitti> slangasek: exim4 is on the alternates?
[11:45] <pitti> slangasek: iproute sounds safe
[11:45] <slangasek> pitti: whoops, no -- so just iproute needs rebuilt
[11:45] <pitti> deal!
[11:45] <doko> slangasek: http://mail.python.org/pipermail/python-dev/2007-September/074522.html
[11:45] <pitti> slangasek: doing
[11:46] <pitti> slangasek: I'll rebuild it against 4.4 then? just in case we want to get rid of 4.5, too
[11:46] <slangasek> doko: well, "can lockup a process" doesn't prove it's a bdb bug rather than an app bug, but ok, point taken :)
[11:47] <slangasek> pitti: ISTR that db4.4 was a dud release and db4.5 would be the better choice
[11:47] <pitti> slangasek: ok; so maybe we move over the 4.4 bits on the CD to 4.5 then?
[11:48] <slangasek> the things that depend on db4.4 look harder to move
[11:49] <pitti> meh @ archive.u.c. slowness; checkrdepends is slooooooow
[11:49] <slangasek> apache, apt-utils, libedata-book1.2-2?
[11:49] <doko> Hobbsee, Riddell: could you have a look at http://people.ubuntu.com/~doko/tmp/fdupes-kubuntu.out if there are some low hanging fruit (duplicates to remove for Kubuntu)?
[11:49] <doko> mvo should know about apt-utils
[11:50] <slangasek> perl depends on db4.4
[11:50] <pitti> ISTR that seb128 and I already had the db discussion for e-d-s
[11:50] <pitti> last time it just worked IIRC
[11:50] <seb128> yes
[11:52] <StevenK> pitti: Should we sync in new upstream version of clutter-perl?
[11:53] <pitti> StevenK: would make sense, now that we have all the other bits
[11:53] <StevenK> pitti: Yup. I'm not certain it builds, should I check first?
[11:54] <pitti> StevenK: please
[11:54] <StevenK> pitti: Aye, I shall let you know - I'm being called for dinner.
[11:56] <pitti> slangasek: iproute uploaded
[11:57] <pitti> StevenK: isn't postfix in ship?
[11:57] <soren> StevenK: server-ship, isn't it?
[11:57] <pitti> ah, no
[11:57] <pitti> and that was directed to slangasek actually
[11:57] <Riddell> doko: what does the figure on the left mean?
[11:58] <pitti> slangasek: so that should drop libdb4.3 and give us another 440 kB
[11:58] <slangasek> nice
[11:59] <doko> Riddell: the size of all duplicates
[12:02] <doko> Riddell: so installing these files into a kdebase-common package, which all packages can depend on, then it saves this amount of space (uncompressed), so looking at all dupes in kdebase this is abotu 3MB uncompressed
[12:02] <slangasek> sigh, why is libgtkhtml2.0-cil still built against gtkhtml3.8?
[12:03] <pitti> ah, I remember that discussion
[12:03] <pitti> didn't get ported to 3.14 at that time
[12:03] <slangasek> blah
[12:03] <pitti> not sure aobut the current status
[12:12] <pitti> asac: hmm, firefox-3.0 ships some transitional packages firefox-trunk-*, but they do not exist in gutsy
[12:13] <slangasek> hahaha, pidgin depends on *zephyr*?
[12:14] <dholbach> "This is the Project Athena Zephyr notification system 2000/04/21 snapshot."
[12:14] <dholbach> Version: 2.1.20070719.SNAPSHOT-1 :-)
[12:15] <dholbach> I remember some users requested gaim to be built with --enable-zephyr
[12:15] <doko> dholbach, seb128: please check if the documentation in libbonoboui-common is really needed and suggest a package where it can be moved to
[12:15] <torkel> is anyone _still_ using that? :-)
[12:15] <seb128> doko: still not enough place on the CD?
[12:15] <dholbach> doko: best to ask lool and seb128
[12:15] <slangasek> there are still a few sites that use zephyr, yes
[12:15] <doko> seb128: no
[12:16] <seb128> doko: how much is still required?
[12:16] <pitti> seb128: I guess we still need to chop off some 7 MB
[12:16] <pitti> I'll build new CDs in the afternoon, once our current changes are in
[12:16] <slangasek> I'm more amused because libzephyr depends on libhesiod, which is the last package I expected to see on the CD
[12:16] <sladen> it shouldn't need to depend on it;  it's probably perfectly possible to have zephyr /support/ but not demand it's installed
[12:17] <torkel> I thought it died with all krb4 cross-realm vuln. a couple of years ago
[12:18] <asac> pitti: its a package we had in ppa (next to granparadiso)
[12:18] <paran> is something wrong with security.ubuntu.com? I am getting invalid signature warnings for the latest feisty updates
[12:18] <asac> pitti: both will be dropped for hardy
[12:18] <pitti> paran: it's just hammered due to the current OO.o security update
[12:18] <pitti> asac: ok, I see
[12:19] <sladen> pitti: isn't squashfs already doing merging (of duplicate files) on the livecd;  so the -common work would only help the alternate CD and not the livecd
[12:19] <pitti> asac: firefox-3.0 still contains .dlls; can we pretty please stop introducing more instances with those?
[12:19] <pitti> sladen: that's the idea
[12:20] <pitti> sladen: desktop CDs are fine, alternate amd64 is overflown
[12:20] <sladen> pitti: it's the alternates which are over?
[12:20] <pitti> asac: that bug was marked for gutsy beta AFAIR
[12:21] <asac> pitti: yes, i still wait for upstream reply on those. i will bug him today again
[12:21] <paran> pitti: ok
[12:22] <StevenK> pitti: You need to stop confusing me and slangasek. :-)
[12:22] <pitti> asac: I'll accept firefox-3.0 under the assumption that I can remove -granparadiso in exchange, so it's just moving the problem, not adding one
[12:22] <pitti> asac: ok?
[12:23] <asac> pitti: thats correct
[12:23] <asac> pitti: just send a ping to mconnor
[12:23] <slangasek> pitti: fwiw, Clint says db4.3 is the one that was the dud, not that it should matter much for something as straightforward as iproute
[12:23] <asac> pitti: if i don't get a reply, I will start to strip the origs on my own.
[12:23] <pitti> slangasek: I guess higher versions are generally more preferable, so I rebuilt it against 4.5
[12:23] <pitti> slangasek: moving the remaining 4.4 stuff to 4.5 shouldn't be too hard?
[12:24] <pitti> asac: danke
[12:24] <slangasek> pitti: yes, higher versions are generally preferred, since there are other packages already built against db4.5 and I don't remember if we could cleanly rebuild them against db4.4 without a migration
[12:25] <slangasek> pitti: db4.4 -> db4.5 is an on-disk log format change, so it would require a scan for transactional uses
[12:26] <pitti> right
[12:26] <pitti> as with every other db4.x update
[12:26] <pitti> slangasek: I checked iproute, taht was fine (grep -r TXN)
[12:26] <slangasek> well, in theory they could someday do an update w/o a transaction format change :)
[12:28] <pitti> calc: any chance to build OO.o with an older compiler on sparc, or so? it pretty much ruins sparc installability
[12:28] <pitti> "it" being the FTBFS
[12:33] <asac> pitti: xulrunner needs to go in in order to build ffox ... just in case you missed that ;)
[12:33] <slangasek> pitti: perl depends on db4.4 and appears to expose DB_TXN in its API
[12:34] <slangasek> not that I think we've ever dealt with perl+db4 upgrades, but there it is
[12:34] <doko> pitti, calc: I doubt it, and we don't have an older compiler anymore in main. maybe try with 4.2? I'll start a build over the weekend
[12:34] <pitti> asac: already accepted
[12:34] <pitti> slangasek: yeah, it's utterly hard to check
[12:35] <asac> pitti: oh ... thanks have just received ffox mail
[12:40] <StevenK> pitti: clutter-perl looks great, and there are no Ubuntu changes.
[12:40] <pitti> StevenK: is there a sync bug?
[12:41] <StevenK> pitti: There can be.
[12:41] <sladen> pitti: if you're willing to accept a larger on-disk size;  there's probably a fair bit to be saved by repacking all the openoffice templates/jar files using zero-compression and letting the higher-level .deb and squashfs compression take care of it
[12:41] <pitti> Riddell: I take it you noticed the kdeguidance FTBFS? (patch didn't apply)
[12:42] <pitti> StevenK: synced
[12:42] <StevenK> pitti: Great. Do you want a bug after the fact, or don't care?
[12:42] <pitti> StevenK: nah, I just asked whether I need to close a task
[12:42] <pitti> StevenK: it wasn't on the clutter meta-sync-bug from this morning
[12:42] <slangasek> pitti: looks like perl DB_File doesn't have txn support after all
[12:42] <pitti> ooh
[12:43] <slangasek> that would still leave apache and apt-utils, I think
[12:43] <pitti> apache is not a concern for the CDs, or is it?
[12:43] <pitti> apt-utils, hmm, mvo?
[12:43] <StevenK> And rebuilds of apt are a pain
[12:43] <slangasek> apache2-mpm-worker is on alternate
[12:43] <slangasek> StevenK: not apt, just apt-utils
[12:44] <pitti> slangasek: I'll rebuild/test perl and wait with the upload
[12:44] <pitti> StevenK: only for ABI breakages, right?
[12:44] <slangasek> oh, apt-utils is from apt, n/m :)
[12:44] <StevenK> I thought aptitude, adept had to be rebuilt if apt was played with?
[12:45] <slangasek> StevenK: only if apt's soname changes
[12:45] <slangasek> which it shouldn't on a simple rebuild
[12:45] <slangasek> though apt's soname still changes in some cases it shouldn't, such as a glibc minor version bump
[12:46] <pitti> ok, with the next one or two publisher cycles, gutsy_outdate should be under control again
[12:47] <slangasek> pitti: ok, that's as much as I can do tonight; if we're still stuck on space when I wake up, I'll have another look
[12:48] <pitti> slangasek: there are some changelog entries like "Update to DB_File to db4.4"; I'll try it, though
[12:48] <pitti> slangasek: thanks
[12:55] <pitti> erk, emacs21 is still in main
[12:55] <pitti> is someone interested in doing some transitions? (mostly dependency changes and tests)
[12:55] <StevenK> What transistions?
[12:55] <elmo> what's wrong with keeping it in main, JOOI?  it's not on the CD is it?
[12:56] <pitti> change deps of gnus, python-mode and calc, and check that they DTRT with emacs22 (most of them have alternative dependencies already, so it doesn't seem to matter much)
[12:56] <pitti> elmo: general version duplication
[12:57] <elmo> see, don't change gnus, that's TWTTD
[12:57] <StevenK> pitti: You want to be able to kill emacs21?
[12:57] <pitti> I accepted emacs22 to main and as default under the condition that 21 would be dropped
[12:57] <pitti> StevenK: demote at least, if possible
[12:57] <elmo> the version of gnus in emacs22 is >> the version in the package
[12:57] <elmo> the wrong thing to do
[12:58] <StevenK> Ah
[12:58] <elmo> will it was in my head, it doesn't actually work, but details
[12:58] <elmo> if you're going to demote emacs21, demote gnus too
[12:58] <StevenK> Heh
[12:58] <StevenK> pitti: Way cool, we don't need to fiddle with gnus
[01:00] <StevenK> pitti: I'll take python-mode if you'll take calc?
[01:01] <pitti> StevenK: hmm, ok
[01:02] <StevenK> pitti: Yup, I had to twist your arm. :-P
[01:05] <pitti>  Emacs 22 has a newer version of this package, so the built in calc
[01:05] <pitti>  should be used with newer versions of Emacs.
[01:05] <pitti> StevenK: \o/
[01:05] <cjwatson> pitti: lilo-installer done
[01:05] <StevenK> Yay
[01:06] <pitti> cjwatson: ah, thanks; I'll mangle it
[01:07] <StevenK> pitti: * Do not install for emacs22, which has it's own incompatible python-mode.
[01:07] <pitti> StevenK: oh, doko is the maintainer for python-mode
[01:07] <pitti> debian bug #424973
[01:07] <ubotu> Debian bug 424973 in python-mode "python-mode: please support emacs22" [Normal,Open]  http://bugs.debian.org/424973
[01:08] <Riddell> pitti: hmm, missed that guidance problem, thanks
[01:08] <pitti> StevenK: so, seems we should drop that, too
[01:08] <Riddell> pitti: I added hplip-gui to the kubuntu seeds
[01:08] <StevenK> pitti: Indeed.
[01:08] <pitti> Riddell: thanks
[01:08] <pitti> StevenK: seed changes committed, thanks
[01:09] <StevenK> pitti: No problem
[01:09] <doko> pitti, StevenK: yes, we could drop taht, there's another python-mode in emacs22
[01:10] <tkamppeter> doko, I got an answer regarfing profile.jpg in Gutenprint. One can really remove it.
[01:10] <seb128> doko:
[01:10] <seb128> dpkg: error processing /home/buildd/build-403193-990906/chroot-autobuild/var/cache/apt/archives/libtiff4-dev_3.8.2-7ubuntu1_i386.deb (--unpack):
[01:10] <seb128>  trying to overwrite `/usr/lib/libtiff.so.4.2.1', which is also in package libtiff4
[01:10] <pitti> Riddell: http://people.ubuntu.com/~ubuntu-archive/component-mismatches.txt also has some binary-only demotions for KDE
[01:10] <kwwii> doko: will the splash and about pics for OOo that I sent middle of last week be included soon?
[01:10] <pitti> Riddell: can we walk though them quickly?
[01:10] <kwwii> doko: Jane was asking about it
[01:10] <dholbach> kwwii: probably best to ask calc?
[01:10] <seb128> doko: do you test your changes before uploading? that's 3 conflicts you create in a day now
[01:11] <doko> kwwii: I hope so, at least calc did look at them
[01:11] <kwwii> calc: will the splash and about pics for OOo that I sent middle of last week be included soon?
[01:11] <kwwii> doko: just thought I should check up on it in case it was forgotten
[01:14] <Riddell> pitti: let me look
[01:14] <pitti> ah, perl builds fine with db4.5
[01:14] <pitti> Riddell: lines 3 to 5 of 'binary-only demotions'
[01:15] <pitti> Riddell: we either need to demote them or seed them explicitly
[01:15] <pitti> Riddell: the latter is preferable for innocent stuff, to not desync main/universe so much
[01:15] <doko> seb128: confirmed, I have the new package installed, so this probably was a last-change before upload ...
[01:19] <pitti> cjwatson: btw, new l-u-m for -13 has built everywhere, so I guess we could rebuild d-i now
[01:19] <cjwatson> ok, I'm just catching up, I was up part of the night and then slept in :-/
[01:20] <cjwatson> will take care of it
[01:20] <pitti> thank you
[01:21] <StevenK> pitti: When clutter-perl builds I think that all of libclutter* can be NBS'd
[01:21] <pitti> ok
[01:22] <cjwatson> gar, why did mbr still ftbfs
[01:24] <cjwatson> elmo: what kernels are zirconium and rothera running? are they 64-bit kernels?
[01:25] <elmo> cjwatson: 32-bit
[01:25] <elmo> cjwatson: rothera is 32-bit hardware too, it _can't_ run 64-bit anything
[01:25] <elmo> (modulo qemu or something)
[01:25] <cjwatson> hmm
[01:26] <cjwatson> elmo: what kernel version?
[01:26] <cjwatson> oh, wait, the i386 failure isn't just "vm86 not supported
[01:26] <cjwatson> "
[01:26] <elmo> cjwatson: rothera == latest dapper, custom build, zirconium == latest edgy server (distro)
[01:26] <cjwatson> nor is the lpia one
[01:27] <cjwatson> they're both failing because efl |= 0x00200000 from what it should be
[01:30] <bluefoxicy> is it just me or does synaptic not actually configure unattendend-upgrades
[01:31] <bluefoxicy> Unattended-Upgrade::Allowed-Origins gets set; but the script needs APT::Periodic::Unattended-Upgrade set to actually run unattended-upgrades and thus install the packages
[01:31] <bluefoxicy> strangely enough, my /var/log/unattended-upgrades is full of stuff; so I have no idea how this works :)
[01:32] <bluefoxicy> oh it's in peridoic ok.  On the server it didn't actually create that file... wonder why.
[01:33] <pitti> Hobbsee: it does
[01:34] <Hobbsee> pitti: oh, but it doesnt check the latest on a.u.c - it only checks on your mirror.
[01:34] <Hobbsee> which is why we're still getting bugs like https://bugs.edge.launchpad.net/ubuntu/+source/cupsys/+bug/149384 i suspect
[01:34] <ubotu> Launchpad bug 149384 in cupsys "package cupsys 1.3.2-1ubuntu1 failed to install/upgrade: trying to overwrite `/usr/share/doc/libcupsys2/CREDITS.txt', which is also in package libcupsys2" [Undecided,Fix released]
[01:34] <Hobbsee> pitti: when we're now up to ubuntu5 - even my au mirror only has ubuntu2
[01:34] <Hobbsee> er, ubuntu3
[01:36] <pitti> Hobbsee: it only checks apt-cache policy
[01:37] <Hobbsee> pitti: perhaps it shouldnt
[01:37] <pitti> Hobbsee: I don't want to do network checks, way too expensive and brittle
[01:37] <Hobbsee> pitti: perhaps it should have to check rmadison -u ubuntuor something
[01:37] <Hobbsee> pitti: hm
[01:37] <pitti> nah
[01:37] <pitti> we screwed up, now we just have to play whack-a-bug long enough
[01:44] <doko> tkamppeter: ok, will remove it for gutsy, didn't have we our own test image, which can be used to test? (if this image is used at all)
[01:44] <pitti> doko: we have test postscripts in system-config-printer
[01:45] <doko> pitti: well, this is a 600k jpeg
[01:46] <pitti> doko: right; I'm all for ditching it
[01:50] <Kmos> elmo: archive.ubuntu.com is down ?
[01:50] <pitti> Kmos: just hammered; it's known
[01:50] <Kmos> :)
[01:53] <mvo_> bluefoxicy: software-properties let you configure unattended-upgrades
[01:54] <pitti> wb mvo_
[01:55] <pitti> mvo_: did you see above question about migrating apt-utils to db4.5?
[01:56] <RicardoPerez> pitti: ping
[01:56] <pitti> !ask | RicardoPerez
[01:56] <ubotu> RicardoPerez: Don't ask to ask a question. Just ask your question :)
[01:56] <RicardoPerez> oh, sorry :)
[01:57] <RicardoPerez> pitti: hi! the latest ubuntu-doc doesn't have the translations for the serverguide
[01:57] <pitti> RicardoPerez: hm, mdke has prepared another upload, which might fix that
[01:57] <RicardoPerez> pitti: great
[01:57] <pitti> ah, it's that already
[01:58] <pitti> RicardoPerez: we temporarily raised the bar to 'must be 90% translated' until we solved the space issues on CD
[01:58] <pitti> RicardoPerez: it'll get dropped again
[01:58] <RicardoPerez> pitti: but the serverguide is 100% translated into Spanish...
[01:58] <pitti> RicardoPerez: hmm; please talk to mdke then
[01:59] <RicardoPerez> pitti: ok... he appears to be away now
[01:59] <pitti> RicardoPerez: yes, mail would probably work better
[01:59] <RicardoPerez> pitti: i'll try later
[01:59] <RicardoPerez> pitti: ok
[01:59] <RicardoPerez> pitti: thanks!
[02:03] <bluefoxicy> mvo_:  non-gui?
[02:11] <cjwatson> mjg59: do you know anything about interactions of the ID flag and vm86?
[02:11] <cjwatson> mjg59: mbr's tests are failing because the ID flag is mysteriously set
[02:11] <cjwatson> mjg59: I'm wondering if I can just forcibly clear that in the test harness output and ignore the problem ...
[02:12] <cjwatson> I can't reproduce it here, but it's probably processor-dependent
[02:13] <mvo_> bluefoxicy: see the README
[02:14] <bluefoxicy> nods.
[02:14] <bluefoxicy> mvo_:  got fed up with CentOS5 so I dropped an Ubuntu Feisty Server onto a machine ;)
[02:14] <bluefoxicy> better security that way
[02:14] <bluefoxicy> i.e. I had over a dozen (and still going) packages hand-built (rpm-rebuild) and was like "No no no screw this bad patch management"
[02:24] <tkamppeter> doko, we have our own Ubuntu test page in the system-config-printer package and for unsupported page sizes system-config-printer uses the standard CUPS test page. These test pages are small, as they are PostScript with vector drawing instructions inside (no bitmap images). So there is no problem removing profile.jpg.
[02:25] <doko> tkamppeter: thanks for checking
[02:25] <MacSlow> argl!
[02:26] <MacSlow> can anyone confirm that the Viewports-section in the properties-dialog of the wnck-applet also shows up if you're running metacity atm?
[02:27] <cjwatson> is the wnck-applet the pager thing?
[02:27] <seb128> cjwatson: workspace switcher
[02:27] <cjwatson> I don't see a Viewports section here
[02:28] <cjwatson> running metacity
[02:28] <seb128> cjwatson: he's speaking about this one, technically wnck-applet is also the tasks list applet also
[02:28] <seb128> cjwatson: did you restart your gnome-panel since the upgrade from yesterday?
[02:28] <seb128> just to be sure
[02:28] <cjwatson> oh, probably not
[02:29] <Kopfgeldjaeger> pitti: could you have a look at bug #144390 any my comment?
[02:29] <ubotu> Launchpad bug 144390 in cryptsetup "use entire disk with lvm/encrypted partitioning fails to boot" [High,Fix released]  https://launchpad.net/bugs/144390
[02:30] <janimo> are the iso builds on manual? There are no xubuntu live for today
[02:31] <cjwatson> janimo: the Xubuntu live build should only have started 13 minutes ago, according to the normal schedule
[02:31] <cjwatson> actually, I'm reading it the wrong way round
[02:32] <cjwatson> janimo: it won't happen for another 5 hours or so
[02:32] <seb128> doh, the archive is so sloooow today
[02:32] <janimo> cjwatson: ok, for some reason I thought they were done in the morning when the CD sanity report arrives
[02:32] <cjwatson> you know, I should just go back to bed
[02:32] <cjwatson> janimo: the health checks are asynchronous; but reading the crontab a THIRD time there may be a problem
[02:33] <cjwatson> janimo: did you check the build logs before asking?
[02:33] <cjwatson> http://people.ubuntu.com/~ubuntu-archive/cd-build-logs/
[02:33] <cjwatson> looks like it got stuck on a lock
[02:34] <janimo> cjwatson: no, I know yesterday's iso contained pakcages from 25th of sep or so and tollef said that there was a problem on the build servers
[02:34] <cjwatson> that's already fixed
[02:34] <cjwatson> you should always check the build log first, and then your questions can be better :)
[02:34] <cjwatson> janimo: I've kicked off a new build now
[02:34] <janimo> I thought it had just been fixed yesterday and was expecting to see the image today. And I thought it may be on manual as ubuntu and edubuntu have images today
[02:34] <janimo> cjwatson: thanks
[02:34] <cjwatson> it's not on manual
[02:35] <janimo> cjwatson: re build logs, noted
[02:35] <gnomefreak> i have dapper and edgy backport of flash to fix a couple of bugs. they were acked by jdong and uploaded by hobbsee, i was told to ping an archive admin for the push, is there a policy for doing this or just ping one of the admins?
[02:37] <cjwatson> gnomefreak: it shouldn't need a manual ping, the queue should get processed on admins' archive days
[02:37] <gnomefreak> ah ok ty ill let jdong know when i see him
[02:37] <cjwatson> pitti: just trying to get a kickseed fix in before d-i
[02:43] <TheMuso> cjwatson: I don't know whether I missed something as to what you said about the metapackages being in the wrong section, as I changed ubuntustudio-meta to the metapackages section. Yet the same behavior exists, in that desktop gets installed as a dependency of the other tasks, but its recommends still don't get installed.  Users wont want that. So for this release we'll just remove the depend og ubuntustudio-desktop from the metas and blindly install all the tasks.
[02:51] <cjwatson> _MMA_: well, it's what you told me to do *shrug*
[02:51] <_MMA_> cjwatson: And thanx for all the help. Really.
[02:51] <cjwatson> feel free to undo it, your choice
[02:52] <_MMA_> cjwatson: Sure sure. We just realized after testing it that it doesnt work. :) at this point we cant spend any more time trying to fix it.
[02:52] <Kopfgeldjaeger> hi
[02:53] <seb128> ogra: I managed to get the update now ;)
[02:53] <ogra> cool
[02:53] <ogra> i got the release files but not te packages my pbuilder needs
[02:53] <ogra> still hanging in "connecting" state
[02:57] <pitti> Kopfgeldjaeger: looking (and yes, I know it's still broken)
[02:57] <pitti> Kopfgeldjaeger: oh, that would be something else then
[02:57] <MacSlow> cjwatson, hm... then I wonder if that's a left-over of my testing-around over the recent days.
[02:57] <lamont> oh.  failed all arches.. cool
[02:58] <seb128> MacSlow: the new gnome-panel seems to work correctly under metacity, no compiz options listed
[02:58] <Kopfgeldjaeger> lamont: i guess there's no configure script ;)
[02:58] <MacSlow> seb128, ok thanks
[02:59] <lamont> seb128: you know about gnome-control-center b0rkage, I assume?
[02:59] <seb128> lamont: which one?
[02:59] <lamont> -0ubuntu3
[02:59] <seb128> lamont: just curious, what changed on hppa that you need to rebuild that many packages?
[02:59] <seb128> lamont: how does it break I mean
[02:59] <lamont> seb128: launchpad
[03:00] <seb128> ?
[03:00] <ogra> seb128, http://launchpadlibrarian.net/9805079/buildlog_ubuntu-gutsy-ia64.gnome-control-center_1%3A<IP_ADDRESS>-0ubuntu3_FAILEDTOBUILD.txt.gz
[03:00] <lamont> running CONFIG_SHELL=/bin/bash /bin/bash /tmp/gnome-control-center-<IP_ADDRESS>/./configure  --build=x86_64-linux-gnu --prefix=/usr --includedir=${prefix}/include --mandir=${prefix}/share/man --infodir=${prefix}/share/info --sysconfdir=/etc --localstatedir=/var/lib --libexecdir=${prefix}/lib/gnome-control-center --disable-maintainer-mode --disable-dependency-tracking --srcdir=. --disable-mime-cache --disable-scrollkeeper --enable-aboutme --en
[03:00] <lamont> able-gstreamer=0.10 --disable-update-mimedb build_alias=x86_64-linux-gnu CC=cc CFLAGS=-g -Wall -O2 LDFLAGS=-Wl,-z,defs -Wl,-O1 -Wl,--as-needed CPPFLAGS= CXX=g++ CXXFLAGS=-g -Wall -O2  --no-create --no-recursion
[03:00] <lamont> /bin/bash: /tmp/gnome-control-center-<IP_ADDRESS>/./configure: No such file or directory
[03:00] <lamont> make[1] : *** [config.status]  Error 127
[03:00] <cjwatson> seb128: launchpad isn't creating build records for hppa properly
[03:00] <seb128> cjwatson: ah, ok
[03:00] <lamont> cjwatson: s/isn't/didn't/
[03:00] <cjwatson> seb128: long story, but no-change uploads are one workaround that's possibly less scary than changing launchpad at this point
[03:00] <pitti> "in-field rebuild test" :)
[03:00] <cjwatson> lamont: still isn't
[03:00] <seb128> cjwatson: ok, I was just wondering
[03:00] <cjwatson> the bug fix, AIUI, has not yet been rolled out
[03:01] <seb128> mjg59: ^ your g-c-c update doesn't build
[03:01] <lamont> cjwatson: well, isn't generating build records for things that it didn't generate build records for when we lit it, true.
[03:01] <lamont> any new upload works just fine
[03:01] <cjwatson> right, but new P-a-s changes will have the same problem
[03:02] <Kopfgeldjaeger> pitti: should i open a new bug for that? or did i something wrong?
[03:02] <lamont> seb128: and I'm being good... you're taking care of re-uploading gnome for me (thanks) :-), with that and kde, there were only about 180 packages in main that are missing.
[03:02] <lamont> so I'm only uploading enough to tickle launchpad into getting ubuntu-server current
[03:02] <pitti> Kopfgeldjaeger: that might not a bug, just a way the (admittedly confusing) way partman works
[03:03] <lamont> db, db4.3, and db4.4 are currently doing the "test-build before upload" step
[03:03] <lamont> and then I _THINK_ I'm done.
[03:04] <lamont> cjwatson: new PaS changes that add an architecture _may_ experience the problem, depending on the nature and state of the package
[03:04] <lamont> likewise, if we lit m68k, we'd see the same issues there...
[03:06] <Riddell> tkamppeter: I'm looking at bug 99372
[03:06] <ubotu> Launchpad bug 99372 in kdebase "MASTER: [Feisty]  KDE Printing Manager does not list the PPDs of Gutenprint" [High,Confirmed]  https://launchpad.net/bugs/99372
[03:06] <Riddell> tkamppeter: where should KDE be looking to find information on the "Epson Stylus DX3850" (for example)
[03:08] <cjwatson> pitti: partman> what's the problem?
[03:09] <pitti> cjwatson: I don't know; Kopfgeldjaeger had a problem with manually configuring encrypted partitions, but I didn't investigate it yet
[03:10] <Kopfgeldjaeger> pitti / cjwatson: alternate cd->partitioning->create boot partition, create "physical volume for encryption" -> "next" -> "no root file system specified"
[03:10] <pitti> Kopfgeldjaeger: yes, you need to select "configure encrypted devices" first (or so)
[03:10] <Kopfgeldjaeger> where is this? in the partitioning menu?
[03:13] <pitti> Kopfgeldjaeger: it should appear there, yes (at the top)
[03:13] <Kopfgeldjaeger> ok, i will try this. thanks
[03:13] <pitti> soren: in your lvm/crypt install yesterday, did a mere update-initramfs help to get it boot?
[03:14] <pitti> soren: it did here
[03:19] <pitti> Kopfgeldjaeger: just tried it, and it works ("Configure encrypted devices..." is at the top)
[03:20] <Kopfgeldjaeger> ok, thanks
[03:20] <Kopfgeldjaeger> :)
[03:21] <pitti> soren: hah! I managed again to find the magic combination of steps to get autopartitioning without erasing the disk; I set up the encrypted volume manually, set erase to false, and then chose "guided partitioning" again, which seems to do the trick
[03:24] <tkamppeter> riddell, KDE should ask CUPS for available drivers, doing "lpinfo -l -m" or the equivalent IPP call. Then it will find all PPDs including the mentioned one.
[03:25] <tkamppeter> Riddell, mistyped your name, see my previous message which is perhaps not in red for you.
[03:27] <Riddell> tkamppeter: as usual KDE printing seems to be behind the times, it just searches for PPD files to read
[03:27] <Riddell> tkamppeter: installing foomatic-db-gutenprint solves the missing files problem, should we just promote that to main and put it on the kubuntu CDs for a quick fix?
[03:28] <Kopfgeldjaeger> pitti: i chose this entry, was asked for the passphrase etc., but now i am back at the partitioning menu
[03:28] <pitti> tkamppeter: curious, why isn't that package in main anyway? don't we need it?
[03:29] <MacSlow> seb128, I've this issue here still with the current gnome-panel (ubuntu5) and the visible viewports-frame under metacity when I open the wnck-applet's properties-dialog
[03:31] <Kopfgeldjaeger> pitti: i chose the entry again, and atm it is creating the ext3 fs.
[03:32] <lamont> mvo_: I assume you saw  libcompizconfig-backend-gconf is ftbfs everywhere?
[03:33] <seb128> MacSlow: did you start the session using metacity?
[03:33] <seb128> MacSlow: or did you start the panel under compiz and hotswitched?
[03:33] <MacSlow> no
[03:33] <MacSlow> yes
[03:33] <seb128> ok, so that's probably it
[03:33] <seb128> it's probably not clever about windows manager changes
[03:34] <MacSlow> but the check (also reloading of the glade-file) should happen as the dialog is opened, should it not?
[03:35] <seb128> I didn't look at the code, mvo did sponsor this upload
[03:35] <seb128> I'll have a look
[03:35] <Riddell> pitti: I think cupsys-driver-gutenprint has all the data, foomatic-db-gutenprint has the same data as ppd files but cups no longer needs them
[03:35] <MacSlow> well I leave that for later... first I want to get the other three issue regarding gnome-control-center done
[03:35] <Riddell> (I'm guessing mostly)
[03:35] <pitti> Riddell: ah, right
[03:36] <pitti> Riddell: yep, cups 1.3 generates them on the fly
[03:37] <Riddell> pitti: yeah, and KDE's make_driver_db_cups doesn't
[03:37] <seb128> MacSlow: right, dynamic switching is a corner case anyway
[03:37] <MacSlow> ok
[03:38] <sabdfl> hey Hobbsee
[03:40] <zul> hi sabdfl
[03:41] <jono> what is the current state of work solving this insane trackerd processor use?
[03:42] <seb128> jono: do you have the current version?
[03:42] <seb128> hey sabdf1
[03:42] <pitti> jono: what's the insanity about it? does it slow down your apps?
[03:42] <seb128> jono: it should create some load while indexing for the first time but behave correctly then
[03:42] <pitti> jono: it's supposed to stop on battery, and to be nice
[03:42] <jono> pitti: it thrashes the processor constantly
[03:43] <pitti> jono: and it should finally use some ionice, too
[03:43] <jono> I upgraded to gutsy a week ago, and it is still thrashing my processor
[03:43] <jono> let me check if there are updates
[03:43] <seb128> 0.6.3 is supposed to be nicer
[03:43] <seb128> what version do you have?
[03:43] <pitti> jono: the latest version (0.6.3) needed a complete reindex, that might be it
[03:43] <jono> 0.6.3
[03:43] <pitti> jono: the new version uses a different (more efficient) db
[03:43] <pitti> hm
[03:43] <jono> pitti: right
[03:43] <bddebian> Heya
[03:43] <lamont> morning sabdf1
[03:43] <jono> I do have 32GB of music to index :)
[03:44] <pitti> jono: the most important question is: does it steal cpu from apps, or does it just use the otherwise idle cycles?
[03:44] <kylem> jnothat's it?
[03:44] <pitti> jono: hm, I'd expect that to be very fast
[03:44] <jono> pitti: the system feels pretty sluggish at times
[03:44] <jono> is it possible to see what it is indexing?
[03:44] <pitti> jono: that would be a problem indeed; although I figure that's more due to I/O trashing
[03:45] <pitti> jamiemcc: ^ any idea how to debug that?
[03:46] <jamiemcc> pitti: start trackerd -v 2 will log all output of whats it is indexing
[03:47] <jamiemcc> jono: when did you start indexing?
[03:47] <jono> jamiemcc: not sure - I guess when I installed the last update - few days back?
[03:48] <jamiemcc> did you stop old trackerd ?
[03:48] <jono> jamiemcc: I killed it a few times when it thrashed my system
[03:48] <jamiemcc> jono: music filers should not cause any thrashing - maybe its emails?
[03:48] <Kopfgeldjaeger> pitti: no matter what i do, i get the "no root fs" error or get back to the partitioner
[03:48] <jono> jamiemcc: might be - I have a rather large inbox
[03:49] <pitti> Kopfgeldjaeger: but you did define a root partition?
[03:49] <jamiemcc> jono: can you get me file list in ~/.cache/tracker
[03:49] <Kopfgeldjaeger> pitti: you.. say.. aaaah! i understand!
[03:49] <jono> do we have a pastebin I can use?
[03:49] <pitti> Kopfgeldjaeger: well, there was no root fs? :-)
[03:49] <asac> jono: paste.ubuntu.com ?
[03:50] <Kopfgeldjaeger> yeah... now i understand what this crypt device entry above my hd is for :D
[03:50] <mvo_> lamont: yes
[03:50] <jono> jamiemcc: http://paste.ubuntu.com/622/
[03:50] <jono> asac: :)
[03:50] <asac> jamiemcc: i really think that a tray icon for trackerd showing its status and allowing you to suspend the indexing temporarily would help a lot.
[03:51] <jamiemcc> asac: thats coming this weekend
[03:51] <asac> jamiemcc: really? do you use dbus to communicate?
[03:51] <jono> asac: I agree, the lack of indexing status is odd
[03:51] <jamiemcc> asac: yes applet is in svn
[03:52] <jamiemcc> jono: the email db is pretty big so that means its indeixng emails and has finished indexing files
[03:52] <pitti> Kopfgeldjaeger: as I said, setting this stuff up manually is still some low-level wizardry
[03:52] <jono> jamiemcc: so its indexing mail right?
[03:52] <jamiemcc> jono: yes - you have mbox or imap?
[03:52] <jono> jamiemcc: imap
[03:53] <jamiemcc> jono: ok looks like you have millions of emails!
[03:53] <jono> jamiemcc: I do have quite a few :)
[03:53] <mvo_> lamont: I fix the libcompizconfig thing in a minute. funny thing, I send the patch to upstream but forgot to include it in my upload
[03:53] <jamiemcc> jono: how sluggish is system?
[03:54] <mvo_> (for some definition of funny anyway)
[03:54] <jono> jamiemcc: not hugely, just a little at times
[03:54] <lamont> mvo_: lol
[03:54] <asac> jamiemcc: how do you measure sluggishness?
[03:54] <jamiemcc> asac: does it slow other apps
[03:54] <Kopfgeldjaeger> pitti: atm it's "checking ext3 filesystem on encrypted volume", since some minutes at 0%.. is this normal?
[03:54] <jamiemcc> jono: only time it gets sluggish is when it does index merges which can hammer the disk
[03:54] <asac> jamiemcc: i sometimes had a system load of 6 or even 8 ... i blame trackerd IO for that
[03:55] <jono> jamiemcc: right
[03:55] <jono> thanks for your help folks :)
[03:55] <jono> much appreciated :)
[03:55] <jamiemcc> np
[03:55] <jamiemcc> asac: I blame ext3!
[03:56] <jamiemcc> asac: im switching to reiser much faster at disk writes
[03:56] <asac> jamiemcc: well without trackerd i don't have these massive issues ;)
[03:56] <asac> jamiemcc: but i see your point
[03:57] <pitti> Kopfgeldjaeger: sure that it isn't erasing it? that takes a while
[03:57] <pitti> Kopfgeldjaeger: you can switch this off, btw
[03:58] <pitti> Kopfgeldjaeger: it's only for paranoia
[04:00] <Kopfgeldjaeger> pitti: now, i know what you mean, that isnt it. but its now at 50%
[04:01] <Kopfgeldjaeger> s/now/no
[04:02] <soren> pitti: Yes, at one point an update-initramfs -u did the trick.
[04:03] <soren> pitti: I've got a hunch about what makes it fail. I've only just got back from the doctor now, so I need to get it swapped back into my working memory.
[04:03] <pitti> soren: I updated the bug; I hope to find some time to find out why
[04:03] <pitti> oh
[04:03] <pitti> soren: the initial initramfs is very different from the one produced by another update
[04:03] <soren> pitti: Yes, I noticed.
[04:03] <pitti> so maybe this is done too early, or without /proc mounted in /target, or whatnot
[04:04] <pitti> soren: I'm still working on libgnome, but that beast is next on my list
[04:04] <soren> pitti: I looked at the syslog from the installer, and it runs the finish-install.d/05cryptroot things after the last update-initramfs call.
[04:04] <cjwatson> yes, it will
[04:04] <cjwatson> if that's supposed to fiddle the initramfs, it's done far too late
[04:04] <soren> pitti: so I'm thinking the magic config stuff from cryptroot doesn't get written until then.
[04:05] <soren> cjwatson: Yes, exactly. I don't know if that's the case, though.
[04:05] <cjwatson> use /usr/lib/post-base-installer.d if you want it to affect the initramfs
[04:05] <cjwatson> assuming that everything else you need is done by that point (the kernel won't be installed yet, but the rest of the base system will be installed)
[04:05] <cjwatson> anything selected by apt-install won't be present yet
[04:06] <asac> ogra: i have issues with virtual box ... somehow setup fails with /usr/lib/virtualbox/src/build_in_tmp: No such file or directory
[04:06] <asac> any idea?
[04:06] <ogra> not really, which packages do you use ?
[04:06] <pitti> cjwatson: just wondering, won't installing the kernel and l-u-m trigger an initramfs update anyway?
[04:06] <asac> ogra: apt-get install virtualbox :)
[04:06] <ogra> i use the ones from their website
[04:07] <pitti> ah, wait, kernel is installed before cryptsetup
[04:07] <StevenK> virtualbox-ose is in Gutsy
[04:07] <ogra> (didnt notice we had them until last week)
[04:07] <StevenK> I need to sit down and figure out how to package up the modules properly for virtualbox so users will stop bitching
[04:07] <asac> ogra: so you use the non-free package?
[04:07] <asac> ogra: is there a gutsy build available?
[04:08] <cjwatson> pitti: sure, but ideally you want to get the necessary bits in place before that
[04:08] <cjwatson> pitti: and finish-install.d is WAY after the kernel is installed
[04:08] <pitti> soren: hm, where is that script? it's not in the udeb, and neither in cryptsetup itself
[04:09] <tepsipakki> any release-manager: a lot of fixes for x-x-o-ati from upstream, tormod has kept a version on his PPA, and I've merged it here: http://users.tkk.fi/~tjaalton/dpkg/ati/ati.debdiff
[04:09] <pitti> soren: cryptsetup itself only ships the initramfs hook, but I don't see where it controls when the initramfs is updated?
[04:09] <ogra> asac, i could tell you if my FF wouldnt hang :P, i think it was the feisty version
[04:09] <mjg59> seb128: Sigh. Built fine here.
[04:09] <StevenK> pitti: It's like booting - magic
[04:10] <pitti> StevenK: except that I at least now understand the booting part :)
[04:13] <soren> pitti: initramfs seems to use triggers these days?
[04:13] <pitti> soren: right
[04:13] <pitti> soren: and both cryptsetup and the actual kernel bits trigger an update-initramfs
[04:13] <pitti> soren: so whenever that stuff gets installed in the /target chroot, it should run
[04:13] <soren> pitti: Yeah.. Hm...
[04:13] <pitti> that's why I wonder how this could fail
[04:14] <pitti> soren: this shuold have nothing to do at all with the udeb or the installer environment, unless there is some initramfs specific magic in d-i
[04:14] <cjwatson> the finish-install script doesn't trigger an initramfs update though
[04:15] <cjwatson> cryptsetup is installed way earlier
[04:15] <pitti> cjwatson: so it has to? i. e. does d-i somehow inhibit update-initramfs when it installs stuff into /target?
[04:15] <cjwatson> you're all confused
[04:15] <pitti> I certainly am, sorry
[04:15] <cjwatson> if there is a finish-install.d script that's expecting to affect the initramfs, it shouldn't
[04:15] <cjwatson> it should be moved earlier
[04:15] <ogra> asac, i used this one http://www.virtualbox.org/download/1.5.0/virtualbox_1.5.0-24069-1_Ubuntu_feisty_i386.deb
[04:15] <soren> cjwatson: Right, of course. As I said: I'm not sure it does.
[04:15] <asac> ogra: thanks ... lets see
[04:16] <pitti> hm, I guess that's a script in partman-crypto then; it's not in the cryptsetup udeb
[04:16] <cjwatson> exactly what script are we talking about here?
[04:16] <cjwatson> finish-install.d/05crypto? soren said 05cryptroot
[04:16] <soren> cjwatson: I just guessed that was the case as that would explain why the config is not in the initial initramfs.
[04:16] <doko> pitti: please accept python-xml (NEW) 300k less on the CD
[04:16] <soren> cjwatson: That was from memory.
[04:16] <soren> cjwatson: finish-install.d/05crypto sounds right.
[04:16] <cjwatson> 05crypto does nothing for us
[04:16] <cjwatson> it's only relevant for loop-AES installs
[04:17] <cjwatson> (and it's too late there too, but that's not important for us)
[04:17] <cjwatson> pitti: d-i used to divert update-initramfs away and run it once at the end, but now that we have triggers it doesn't do that any more
[04:18] <pitti> ok
[04:18] <doko> dholbach, seb128: 337356 2 168678 usr/share/doc/gnome-games/changelog.gz usr/share/doc/gnome-cards-data/changelog.gz usr/share/doc/gnome-games-data/changelog.gz
[04:18] <pitti> so I'm back at the beginning, wondering why it apparently doesn't happen
[04:18] <cjwatson> so the problem is that update-initramfs -u after installation fixes something?
[04:19] <pitti> right
[04:19] <doko> asac: 209246 2 104623 usr/share/doc/network-manager/changelog.gz usr/share/doc/libnm-glib0/changelog.gz usr/share/doc/libnm-util0/changelog.gz (if you make an upload)
[04:19] <pitti> it creates a very different initramfs which then has the necessary bits
[04:19] <cjwatson> pitti: ok, so what's missing?
[04:20] <pitti> most importantly, the /conf/conf.d/cryptroot file
[04:20] <pitti> let me create a complete diff
[04:20] <cjwatson> what generates that?
[04:21] <pitti> cjwatson: /usr/share/initramfs-tools/hooks/cryptroot
[04:21] <pitti> and that works now when calling it in the installed system
[04:21] <pitti> it grabs the necessary bits from fstab and crypttab and writes that file
[04:21] <mjg59> seb128: I really don't understand this build failure. Where does configure go?
[04:22] <mjg59> seb128: Especially since it builds fine here
[04:22] <cjwatson> pitti: could you put the installer syslog somewhere?
[04:22] <pitti> also, right after installation I have an initrd.img-2.6.22-12-generic and a different initrd.img-2.6.22-12-generic.bak
[04:22] <pitti> so u-i -u is called at least twice
[04:22] <cjwatson> it will be, but that's not important
[04:23] <seb128> mjg59: I'm getting the source to have a look
[04:23] <pitti> http://people.ubuntu.com/~pitti/tmp/syslog
[04:23] <soren> pitti: Does the .bak work for you?
[04:23] <cjwatson> soren: I wouldn't bother
[04:23] <cjwatson> it's very unlikely that the .bak will be better
[04:23] <cjwatson> pitti: 403
[04:24] <pitti> cjwatson: sorry, fixed
[04:24] <soren> cjwatson: I know. But it does for me.
[04:24] <soren> cjwatson: I just noticed that.
[04:24] <pitti> ah, so the missing conf/conf.d/cryptroot is in fact the only difference
[04:25] <pitti> weird, yesterday it was much more, but I did a slightly different installation mode now
[04:25] <soren> pitti: Do you happen to have the .bak file that was there right after install?
[04:25] <pitti> soren: yes
[04:25] <pitti> I saved them all
[04:25] <soren> pitti: Try booting with that.
[04:25] <cjwatson> ok, so cryptsetup is installed between the base system and the kernel, as expected
[04:25] <pitti> soren: indeed, that thing does have a cryptroot file
[04:25] <pitti> to the *earlier* call gets it right, and the latest call doesn't; humm
[04:26] <cjwatson> is it possible that the initramfs hook is expecting a kernel to be installed?
[04:26] <soren> Could it be a bug in initramfs-update that doesn't move the .bak and non-.bak files around properly?
[04:26] <cjwatson> or perhaps that it's being broken by some other initramfs hook, from what pitti said
[04:26] <pitti> soren: it could very well be
[04:26] <soren> pitti: I'll check the timestamps..
[04:26] <pitti> soren: since the .bak did *not* get updated on update-initramfs -u
[04:26] <cjwatson> soren: I'd rather bet on a hook invocation bug
[04:26] <seb128> mjg59: http://pastebin.ubuntu.com/624/
[04:26] <pitti> soren: I made backups of both the file and the .bak, and the .bak didn't change
[04:26] <seb128> mjg59: that's your update
[04:27] <cjwatson> you guys need a set -x trace
[04:27] <cjwatson> of mkinitramfs probably
[04:27] <cjwatson> but maybe update-initramfs as well
[04:27] <pitti> cjwatson: will the output of that appear somewhere in the installer logs?
[04:27] <seb128> mjg59: I think that shipping the config.log config.status and Makefiles make it do a clean and remove the configure
[04:27] <soren> The syslog, I think.
[04:28] <cjwatson> pitti: yes (as soren says), but I meant just on the regular system to see why .bak isn't being update
[04:28] <cjwatson> d
[04:28] <cjwatson> when is crypttab created?
[04:28] <mjg59> seb128: Hm. make clean (or even make distclean) shouldn't do that, should they?
[04:28] <pitti> ah, that
[04:28] <seb128> mjg59: yes, should
[04:28] <cjwatson> pitti: also check the state of /target/dev/mapper while cryptsetup is being installed
[04:28] <seb128> mjg59: might be buddy, I didn't try to investigate
[04:29] <cjwatson> pitti: there's specific code in base-installer to deal with that and it could be broken
[04:29] <cjwatson> http://paste.ubuntu.com/625/
[04:29] <mjg59> seb128: I've just unpacked what I uploaded and done debuild, and can't get it to fail like that
[04:29] <pitti> when crypttab created> intersting question, I'll check it
[04:29] <seb128> mjg59: like because you have the autotools installed and configure get regenerated?
[04:30] <mjg59> Hm.
[04:31] <seb128> mjg59: I can fix that if you want by doing with an update without the changes that you did out of the debian directory
[04:31] <mjg59> seb128: Yeah, that would be good
[04:31] <seb128> mjg59: ok, doing that
[04:31] <pitti> soren: main difference between the .bak and the uptodate initramfs are ntfs-3g, fuse, and apparmor (and the removed cryptroot, of course)
[04:32] <soren> pitti: Yes, that's what I see, too.
[04:32] <mjg59> seb128: Thanks!
[04:32] <pitti> soren: right, booting with the original .bak works
[04:32] <cjwatson> how do I go about reproducing this in vmware?
[04:32] <soren> cjwatson: Alternate installer, choose autocryptolvm partitioning.
[04:32] <pitti> cjwatson: installing CLI speeds it up
[04:32] <soren> cjwatson: (go for commandline installation)
[04:32] <cjwatson> that's it?
[04:32] <soren> Yes.
[04:32] <cjwatson> mkay
[04:33] <mdz> tepsipakki: anything with "a lot" in it is unlikely to be attractive to a release manager at this late hour, especially when it needs to be tested on a variety of hardware.  better to go for SRU
[04:33] <pitti> cjwatson: right; that'll fail to boot, the initramfs .bak works, and so does update-initramfs
[04:33] <pitti> cjwatson: to make it boot, do "cryptsetup luksOpen /dev/sda5 sda5_crypt" in the initramfs shell and then ^D
[04:33] <tepsipakki> mdz: well, that's what tormod has been doing, asking people to test his versions :)
[04:33] <cjwatson> I won't bother going that far
[04:34] <mathiaz> soren: can you take a look at my dovecot merge ?
[04:34] <soren> mathiaz: Sure thing. Where?
[04:34] <mathiaz> soren: it's on p.u.c/~mathiaz/pacakges
[04:34] <mathiaz> soren: http://people.ubuntu.com/~mathiaz/packages/
[04:35] <mathiaz> soren: there is the merge from debian, with a FFe.
[04:35] <mathiaz> soren: there is also a change for bug https://bugs.launchpad.net/ubuntu/+source/dovecot/+bug/146648
[04:35] <ubotu> Launchpad bug 146648 in dovecot "Suboptimal defaults in dovecot.conf" [Medium,Triaged]
[04:36] <mathiaz> soren: I'm not 100% sure about my proposal. I've attached a patch to bug 146648
[04:36] <ubotu> Launchpad bug 146648 in dovecot "Suboptimal defaults in dovecot.conf" [Medium,Triaged]  https://launchpad.net/bugs/146648
[04:36] <mathiaz> soren: that I used in my merge.
[04:37] <pitti> soren: ah, update-initramfs indeed runs twice
[04:37] <pitti> soren: first after setting up linux-image, then after linux-ubuntu; I wonder why that doesn't use triggers
[04:37] <soren> pitti: Only twice?
[04:37] <pitti> soren: no, four times actually
[04:38] <cjwatson> pitti: only -u uses triggers; the kernel package uses -k VERSION
[04:38] <pitti> ah
[04:38] <soren> pitti: It's probably because of multiple dpkg runs.
[04:38] <cjwatson> not really worth fixing, IMO
[04:38] <soren> I agree.
[04:38] <pitti> no, just trying to understand where it could get wedged
[04:38] <soren> if the result is correct, no problem.
[04:39] <soren> It should be fixed at some point, though, but it's not important enough to try to pull it off at this point.
[04:40] <dholbach> can somebody put a comment on http://lwn.net/Articles/253340/ or http://www.my10sen.com/2007/10/05/ubuntu-a-speedup-guide/ and tell people why the things mentioned on the page are bad for them?
[04:41] <tepsipakki> mdz: what about just enabling those patches with confirmed success?
[04:42] <lool> Do you people sign all your bzr revisions by default for Ubuntu repos?
[04:42] <mvo> lool: I don't but I guess I should
[04:43] <dholbach> lool: nope
[04:43] <mdz> tepsipakki: I won't speak for the release team, but "works for someone" is not very compelling.  wouldn't you prefer to upload something better tested after release, rather than pushing in something less tested before release?
[04:44] <tkamppeter> Riddell, KDE searches for physical PPD files and also for Foomatic XML data by itself, it is not prepared for the PPD generator concept of CUPS 1.2 and newer. foomatic-db-gutenprint would add Foomatic data, but take a lot of additional disk/CD space. The best would be patching KDE Printing Manager to run "lpinfo -l -m" (or do equivalent IPP call) and remove any direct PPD file and Foomatic scans.
[04:44] <tkamppeter> Riddell, sorry for the long delays, but here is a holiday and so I am not at the IRC continuously.
[04:45] <cjwatson> lool: I do
[04:45] <cjwatson> I don't have create_signatures = always though, but I use gnupg-agent and it always seems to sign anyway
[04:46] <tepsipakki> mdz: of course, but.. it's still just one driver with active upstream and people testing it :P
[04:47] <tepsipakki> and the issues to be fixed are like bug 132716, bug 144297, bug 144011
[04:47] <ubotu> Launchpad bug 132716 in xserver-xorg-video-ati "ATI Driver Gets Black Screen on Radeon 7500 Mobile (Regression)" [High,Fix committed]  https://launchpad.net/bugs/132716
[04:47] <ubotu> Launchpad bug 144297 in xserver-xorg-video-ati "[RC410]  Xpress 200m with pci id 1002:5a62 and Linux 2.6.22 - X will not start" [Undecided,Fix committed]  https://launchpad.net/bugs/144297
[04:47] <ubotu> Launchpad bug 144011 in xserver-xorg-video-ati "GUTSY. No video output firing up X." [Undecided,Fix committed]  https://launchpad.net/bugs/144011
[04:48] <pitti> soren: ah, the .bak handling is a bit special in update-initramfs; it only keeps the original as .bak if it was used for booting; that explains why it is sometimes not updated
[04:48] <Riddell> tkamppeter: the format KDE needs is like this http://paste.ubuntu-nl.org/39641/
[04:48] <Riddell> tkamppeter: but I don't know how to get that information (e.g. the manufacturer) out of "lpinfo -l -m"
[04:49] <soren> pitti: That sounds... special?
[04:50] <lool> cjwatson: Weird, I have an agent too, but querying the signature_text as in James' blog post results in an exception
[04:50] <pitti> soren: it is; but I don't think it's important for that bug, it just makes it unclear when the .bak was actually generated
[04:50] <cjwatson> lool: which blog post?
[04:50] <cjwatson> lool: I don't have any special configuration here
[04:51] <lool> http://blogs.gnome.org/jamesh/2007/10/04/signed-revisions-with-bazaar/
[04:51] <lool> It works with his repo, but not with the bzr repo where I last pushed
[04:51] <soren> What does it mean if /var/lib/dpkg/status lists a conffile with "obsolete" at the end of the line?
[04:51] <tepsipakki> mdz: upstream just confirmed that there should be a release this weekend, and that we "definately want master" :)
[04:52] <cjwatson> I suppose it's possible I thought I was signing but am not ;-)
[04:52] <lool> cjwatson: How did you check you were?
[04:52] <lool> cjwatson: jamesh writes that there's no command to do this by default and gives a Python snippet to test it
[04:52] <cjwatson> lool: if I commit and my agent doesn't have my passphrase cached, it asks me for it ...
[04:53] <cjwatson> (well actually it fails because I'm using pinentry-curses but never mind that
[04:53] <cjwatson> )
[04:53] <cjwatson> so it's clearly signing *something*
[04:53] <jamesh> John's plugin can check the signatures on a branch, but there isn't a builtin command
[04:54] <lool> cjwatson: I didn't ask me until I had create_signatures = always
[04:54] <lool> cjwatson: pinentry-gtk2 works here though :)
[04:55] <mdz> tepsipakki: I'm talking about the Ubuntu 7.10 release
[04:57] <cjwatson> lool: I'm sure it works, doesn't mean I like it ;)
[04:57] <tepsipakki> mdz: sure, I meant ati :) Anyway, I'll do a FFe request once the new driver release is out (called either 6.7.195 or 6.8.0..)
[04:59] <pitti> doko: python-xml and bzip2 binary-NEWed, thanks (right in time for publisher)
[05:01] <ivoks> cjwatson: what happens with udev when /dev/ and /var/log/ are on different partitions?
[05:02] <ivoks> cjwatson: and if /var/log/ is lvm, and doesn't get mounted before mv /dev/.udev.log to /var/log/udev
[05:02] <cjwatson> ivoks: -> Keybuk
[05:03] <ivoks> ok :)
[05:03] <ivoks> ah, sorry...
[05:03] <Keybuk> err ?
[05:03] <Keybuk> how can /var not get mounted before that happens?
[05:03] <Keybuk> oh, because I'm an idiot
[05:03] <ivoks> i'm not sure, but there is a bug about empty 70-persistent-net
[05:04] <ivoks> and when udev is restared, it's full
[05:04] <Keybuk> ?
[05:04] <Keybuk> bug#?
[05:04] <Keybuk> (and what's that got to do with udev.log)
[05:04] <ivoks> 149319
[05:04] <ivoks> i don't know, but that's one more thing this user notices
[05:05] <Keybuk> ok, well the first bit is colin's busybox bug
[05:05] <tkamppeter> Riddell, the proceeding of CUPS is as folows:
[05:05] <tkamppeter> 1. lpinfo -l -m
[05:06] <ivoks> it's possible, ruben installed trough beta version
[05:07] <soren> ivoks: Yes, this was fixed post-beta.
[05:07] <Keybuk> so he wiped the file, and then rebooted
[05:07] <Keybuk> and the file remained empty?
[05:07] <tkamppeter> 2. Extract manufacturer from "make-and-model" field replacing Hewlett-Packard by HP and "Lexmark International" by Lexmark and then taking the first word as the manufacturer name
[05:07] <soren> Keybuk: Yeah.
[05:07] <Keybuk> eek
[05:07] <Keybuk> who told him to udev stop && start? :p
[05:07] <soren> Keybuk: Well, actually, it wasn't touched at all. If he trunc'ed it, it stayed emtpy. If he removed it, it didn't reappear.
[05:08] <tkamppeter> 3. List manufacturers alphabetically, case-insensitively
[05:08] <ivoks> Keybuk: I did :p
[05:08] <Keybuk> ivoks: yeah, that's err, bad
[05:08] <Keybuk> don't tell people to do that :p
[05:08] <tkamppeter> 4. After user selects manufacturer, list all
[05:08] <ivoks> ok
[05:08] <Keybuk> udev stop = "I'm uninstalling udev"
[05:10] <Keybuk> hmm
[05:10] <Keybuk> I can see the problem
[05:10] <Keybuk> cjwatson: are we frozen yet?
[05:10] <soren> What does it mean if /var/lib/dpkg/status lists a conffile with "obsolete" at the end of the line?
[05:11] <Keybuk> soren: lost from the package, but still on the disk
[05:11] <soren> Keybuk: Thanks.
[05:11] <soren> what's the proper way to see if a file is a conffile? I usually grep through /var/lib/dpkg/status, but that doesn't feel right :)
[05:12] <Keybuk> that works for me :p
[05:12] <tkamppeter> Riddell, 4. After user selects manufacturer, list all PPD entries which match this manufacturer case-insensitively.
[05:14] <tkamppeter> 5. User chooses an entry, take its name field and use this for the "-m" option in the "lpadmin" command.
[05:15] <tkamppeter> Note that "lpinfo" and "lpadmin" can also be replaced by IPP calls, see system-config-printer or KDE's code itself.
[05:17] <soren> Keybuk: Hehe.. I just think I remember someone doing some clever dpkg-query trickery which I of course forgot.
[05:19] <cjwatson> Keybuk: no
[05:19] <Hobbsee> soren: somethign with grep-dctrl?
[05:21] <soren> Hobbsee: That would make sense, yes.
[05:22] <Hobbsee> as for what....i dont remember :
[05:25] <Keybuk> update-initramfs: deferring update (trigger activated)
[05:25] <Keybuk> every time I see that, a kitten comes back to life
[05:25] <ivoks> :)
[05:26] <Keybuk> amitk: you can follow up to your bug here if you like :)
[05:35] <doko> pitti: sane-backends and xsane in NEW (the last ones for today)
[05:35] <pitti> doko: did you see cjwatson's list with broken /usr/share/doc/ symlinks?
[05:36] <pitti> doko: processing, thanks
[05:36] <doko> pitti: yes, working on these
[05:36] <seb128> Riddell: is anybody working on gtk-qt-engine?
[05:37] <seb128> Riddell: I start being tired of all the GNOME apps crashers we get about it, I'm considering adding an apport hook to refuse bugs when it's installed
[05:37] <Kopfgeldjaeger> pitti: i now have 2 partitions on the "real" disk (/boot [ext3]  and the "physical volume for encryption). i created a / partition in the encrypted partition, but i cannot add another. (auto partitioning tells me that i probably have too much primary partitions...)
[05:38] <pitti> Kopfgeldjaeger: no, you can only put one thing into an encyrpted partition
[05:38] <pitti> Kopfgeldjaeger: i. e. one PV for an LVM, or one partition (/)
[05:38] <seb128> pitti: would it be easy to make apport refuse to open bugs on GTK applications when gtk-qt-engine is installed and the backtrace has a defined symbol?
[05:38] <Kopfgeldjaeger> aaah. i have to create the lvm myself, ok. thanks
[05:38] <pitti> Kopfgeldjaeger: if you want to enclose several partitions in an encyrpted container, use LVM
[05:39] <pitti> seb128: easy when the package is installed (just add to blacklist), doable with a custom hook
[05:39] <seb128> pitti: ok, maybe something to consider next cycle then, thanks
[05:40] <pitti> seb128: we're switching off apport anyway, so right
[05:40] <seb128> pitti: yes
[05:49] <Riddell> seb128: not that I know of, can't say I've noticed any problems, but feel free to point me at relevant bugs
[05:49] <seb128> Riddell: there is 50 open bugs on the package
[05:50] <seb128> so for sure there is some problems
[05:50] <seb128> the most frequent one is that it makes gtk applications crash to gdk_events functions, not sure of why though
[05:51] <seb128> 46 opens bugs now, I closed some duplicates
[05:54] <seb128> Riddell: maybe that's a strategy to convince KDE users that GNOME is not stable, make it crash ;)
[05:54] <Hobbsee> hah.
[05:55] <bddebian> heh
[05:55] <seb128> Hobbsee: maybe that's one of the reason why GNOME was not stable when you tried it BTW
[05:55] <Hobbsee> seb128: the gtk-qt engine?
[05:55] <seb128> yes
[05:55] <Hobbsee> seb128: i tried to use all gtk apps, when on gtk.
[05:56] <seb128> well, most of crashes we get happens under GNOME
[05:56] <seb128> but KDE writes some gtkrc config to use gtk-qt-engine
[05:56] <seb128> and that creates issues under GNOME
[05:56] <Hobbsee> true - which is why i tested a clean install, iirc.
[05:56] <Hobbsee> (no config)
[05:56] <seb128> usually those crashes are fixed when they apt-get remove gtk-qt-engine
[05:56] <seb128> Hobbsee: ok
[05:57] <Hobbsee> but noted, for if i try them together :)
[06:01] <LaserJock> seb128: would that cause pidgin to crash, by chance?
[06:02] <soren> cjwatson: Will d-i need a rebuild to catch the fixed busybox?
[06:02] <seb128> LaserJock: could, but that's not the most common crasher cause, usually those are due to applications bugs, do you have a backtrace?
[06:02] <LaserJock> seb128: no, pidgin just seems to disappear a few minutes after I start it
[06:03] <seb128> apport should be triggered and offer to send a bug
[06:03] <LaserJock> nope
[06:03] <pitti> soren: we need a rebuild anyway for the new kernel, btw
[06:03] <seb128> weird, dunno why
[06:03] <soren> pitti: point
[06:03] <pitti> LaserJock: anything in /var/log/apport.log?
[06:03] <pitti> LaserJock: maybe you ignored crashes for that version, etc.?
[06:03] <LaserJock> seb128: btw, that problem I had in Feisty with the logout dialog freezing up went away when I dist-upgraded to gutsy
[06:04] <cjwatson> soren: yes
[06:04] <soren> cjwatson: Okay. do you plan on doing one soon?
[06:04] <cjwatson> soren: yes!
[06:04] <cjwatson> :-)
[06:04] <cjwatson> I was just waiting for kickseed to land
[06:04] <cjwatson> which it has now
[06:05] <soren> cjwatson: Ok. Um.. I have a change for module-init-tools that I need to do..
[06:05] <LaserJock> pitti: hmm, I do see a few pidgins in the apport log
[06:05] <soren> cjwatson: I can't really tell if that will need to be done before.
[06:05] <cjwatson> soren: oh?
[06:05] <cjwatson> soren: yes, it will
[06:05] <soren> Ok, I'll do it right away.
[06:05] <LaserJock> I wonder why it never asked me about them
[06:05] <cjwatson> build/pkg-lists/base:28:module-init-tools-udeb
[06:05] <pitti> asac: https://bugzilla.mozilla.org/show_bug.cgi?id=398728 -> or "3. ship them under BSD/MIT"
[06:05] <ubotu> Mozilla bug 398728 in General "mozilla/firefox source tarballs ship binary only files - conflicts with GPL/LGPL license terms" [Normal,New]
[06:06] <soren> cjwatson: Where's that from?
[06:06] <Kopfgeldjaeger> pitti: installation works now fine! i hope the system will boot :-]
[06:07] <cjwatson> soren: debian-installer
[06:07] <lool> Hmm on resume from suspend and hibernate, I get a popup that there was "Sleep Problem" but ... everything was fine
[06:07] <pitti> Kopfgeldjaeger: chances are it won't; if not, please /query me, and we'll debug it
[06:07] <lool> I tried searching for bug reports along these lines, but it's flooded by real problems
[06:07] <lool> Does that ring a bell to someone?
[06:07] <soren> cjwatson: *headdesk* of course.
[06:08] <soren> Woo! My first upload to main. :)
[06:10] <soren> Yeah, it'll probably break all sorts of stuff. I'm that clever^Wlucky.
[06:11] <soren> mathiaz: Sorry for the delay. Your patch looks sensible. I just want to run a few tests and I'll upload if it's good.
[06:11] <soren> mathiaz: Great stuff!
[06:16] <ScottK> pitti: Are you archive admin'ing today?  If so, I'd appreciate you doing Bug #149496.
[06:16] <ubotu> Launchpad bug 149496 in dapper-backports "Please backport Postfix 2.4.5-3build1 from Gutsy to Dapper" [Wishlist,In progress]  https://launchpad.net/bugs/149496
[06:16] <pitti> ScottK: ok, I didn't see that this morning
[06:16] <ScottK> pitti: It wasn't there this morning.  I just finished with testing it.
[06:18] <pitti> ScottK: done
[06:18] <ScottK> pitti: Thanks.
[06:22] <mathiaz> ScottK: you're part of the -backport team right ?
[06:22] <ScottK> Yes.
[06:22] <ScottK> Mostly the one that whines about backports not being for fixing serious bugs.  That's what SRUs are for.
[06:22] <mathiaz> ScottK: I was thinking about the request we receive regarding samba upgrade.
[06:23] <mathiaz> ScottK: yeah - I remember that :)
[06:23] <ScottK> mathiaz: How about --> #ubuntu-server
[06:27] <Keybuk> I have a desktop full of ~ files
[06:32] <tkamppeter> Riddell, still there?
[06:41] <tkamppeter> Riddell, see my Kubuntu Gutsy solution in bug 99372
[06:41] <ubotu> Launchpad bug 99372 in kdebase "MASTER: [Feisty]  KDE Printing Manager does not list the PPDs of Gutenprint" [High,Confirmed]  https://launchpad.net/bugs/99372
[06:50] <Kopfgeldjaeger> pitti: error while installing LILO
[06:51] <lamont> anybody know a package off the top of their head that has the same version in feisty and gutsy, but different version in edgy?
[06:52] <minghua> lamont: xfonts-wqy seems so. :-)
[06:53] <pitti> Kopfgeldjaeger: oh, lilo?
[06:53] <lamont> minghua: thanks
[06:54] <pochu> lamont: xqf too.
[06:54] <lamont> just needed an existance case.  thanks.
[06:54] <Kopfgeldjaeger> pitti: thought the same. if i go into the menu with all options (i think you know what i mean), i cannot see grub anywhere
[07:00] <pitti> seb128: ugh, that libgnome thing is much harder than I thought :/
[07:00] <seb128> pitti: oh :(
[07:01] <pitti> seb128: I fixed the logic for the aplay fallback, but I noticed that libgnome itself does not do the filename -> sound name mapping; apparently that's pre-filled by gnome-session
[07:01] <pitti> seb128: for aplay I need the file names
[07:02] <Kopfgeldjaeger> pitti: any idea?
[07:02] <pitti> Kopfgeldjaeger: no, sorry
[07:03] <seb128> pitti: /etc/sound/events has the mapping (or .gnome2/sound/events/ for user changes)
[07:04] <pitti> seb128: oh, wait; nevermind, I think I found it
[07:04] <seb128> ok
[07:04] <pitti> seb128: yeah, problem is that this gets called by gnome-session, which pokes it into esd; apps call a different instance of the library, so I need to write it out somewhere
[07:05] <ion_> keybuk: I got around to creating ion-meta, thanks again for the idea. :-) http://codebrowse.launchpad.net/~ion/+junk/ion-meta/files
[07:06] <Keybuk> thank mdz :)
[07:06] <pitti> meh, I *so much* don't want to reintroduce esound into the default install
[07:07] <ion_> pitti: pulseaudio-compat-esound? :-)
[07:08] <pitti> ion_: not ten days before the release, and our pulseaudio still sucks; we need a new version
[07:08] <pitti> seb128: I can fix the login and logout sounds, but fixing the general plops and plings is going to be hard without esound
[07:09] <seb128> pitti: login and logout would already be nice, we don't active other sounds by default anyway
[07:09] <seb128> and people who need those can still install esd
[07:09] <pitti> I can write out the cache to a file somewhere, but that's so icky
[07:09] <pitti> or that
[07:10] <pitti> and break their videos and get lockups on their desktop
[07:14] <LaserJock> have we frozen for RC yet?
[07:26] <cjwatson> LaserJock: if https://launchpad.net/ubuntu/gutsy says "Active Development", then we haven't frozen
[07:35] <tepsipakki> uh, lame adobereader package.. "no $HOME/Desktop.. ok, let's create one as root"
[07:36] <lamont> db (4.6) is universe? ok
[07:36] <minghua> tepsipakki: Why does adobereader has root privilege in the first place?  Is it suid?
[07:39] <tepsipakki> minghua: sudo dpkg -i?-)
[07:41] <amitk> Keybuk: err, what bug?
[07:41] <minghua> tepsipakki: Huh?  Is the $HOME/Desktop/ dir created at installation time?  Or when you run Adobe reader?
[07:46] <tepsipakki> minghua: installation time, since it tries to install a launcher there
[07:47] <Keybuk> amitk: udev bug?
[07:47] <Keybuk> maybe wrong nick :p
[07:47] <minghua> I see.  Although that doesn't make sense to me at all.  Many people install packages as root (or sudo -H).
[07:51] <ion_> A package writing *anything* to $HOME is evil.
[07:52] <ion_> Especially for such a stupid reason as polluting the desktop with its icons.
[07:54] <minghua> True, but that's what you get for using third-party packages.
[07:54] <minghua> I personally never trust third-party binary packages.
[08:03] <mdke> what's the syntax for closing bugs automatically with uploads? I see the ubuntu-docs upload today didn't do it
[08:04] <evand> mdke: (LP: #00000)
[08:04] <mdke> hmm, that's what I used
[08:05] <evand> mdke: did the Launchpad-Bugs-Fixed header show up in the changes file?
[08:06] <mdke> lemme see
[08:06] <mdke> evand: no, I don't see it (http://launchpadlibrarian.net/9802239/ubuntu-docs_7.10.1_i386.changes)
[08:07] <evand> mdke: you're missing the hash sign.  I think it has to be (LP: #00000)
[08:07] <mdke> gah
[08:07] <mdke> thanks evand
[08:07] <evand> you're welcome
[08:11] <Kopfgeldjaeger> does anyone have a working menu.lst for gutsy, luks/cryptsetup and lvm?
[08:11] <Kopfgeldjaeger> i think i got grub installed manually, but i have no idea what to write to the menu.lst
[08:12] <cjwatson> the hash is indeed mandatory
[08:12] <cjwatson> see /usr/lib/dpkg/parsechangelog/debian for the implementation
[08:12] <mdke> thanks
[08:16] <soren> mathiaz:  Two things for the dovecot patch: If you could reload dovecot in dovecot-{pop3d,imapd}'s post{inst,rm}'s, that would be good.
[08:17] <soren> mathiaz: and I still think we should do something to make dovecot work properly even when neither pop3d or imapd is installed.
[08:17] <mathiaz> soren: yes. I noticed that too... I think there is even a bug about it.
[08:17] <soren> There is.
[08:17] <soren> It suggests to change the default from "" to "none".
[08:18] <soren> I agree with that approach.
[08:18] <soren> I doesn't agree with your rewriting magic in postinst, thought.
[08:18] <mathiaz> soren: well - none won't work. It seems that it's still looking for imapd.
[08:18] <soren> mathiaz: Oh, really? I'll look into that when I get back. I'm on my wait out the door to get some food.
[08:18] <mathiaz> soren: ok.
[08:19] <soren> mathiaz: How long are you around for?
[08:19] <mathiaz> soren: hum.. another 2 hours.
[08:19] <soren> mathiaz: That should suffice.
[08:19] <soren> ttyl
[08:19] <mathiaz> soren: ttyl
[08:27] <Kopfgeldjaeger> i have no vmlinuz-* file in my /boot directory. how can create it?
[08:34] <geser> Kopfgeldjaeger: then you have no kernel installed, vmlinuz-* is the kernel
[08:35] <Kopfgeldjaeger> geser: i found it out just now, too. but the kernel is installed, but i created the whole /boot stuff etc. myself, so theres no vmlinuz file. currently im reinstalling linux-image-2.6.22-12-generic
[08:40] <elmo> GAH, someone broke a2ps in gutsy
[08:50] <nicolai> _Y_A_Y_! i got it working! cryptsetup/luks, LVM and gutsy!
[09:00] <cjwatson> mdz: do you think it would be worth disabling fglrx and nvidia on the live CD for gutsy? the facilities to do that are already in lrm-manager, so it should be straightforward
[09:00] <cjwatson> as you observe, they aren't used anywayon the live CD anyway
[09:02] <sladen> elmo: file a bug!  ;-)
[09:02] <evand> Can someone in core dev sponsor this: http://people.ubuntu.com/~evand/upload/gobuntu-meta_1.3.dsc .  Thanks in advance.
[09:04] <kylem> evand, ok.
[09:33] <soren> mathiaz: Do you have a bug reference for the thing about dovecot starting the imap server even though protocols was set to none?
[09:38] <mathiaz> soren: nope.
[09:38] <soren> mathiaz: Ok, here's what I'd like to happen: Default (if only dovecot-common is installed) should be "protocols = none". In pop3d's postinst, "none" should be replaced with "pop3 pop3s". Similar for imapd, of course. In their postinst, they should get removed and detect if protocols = would become empty and if so, add "none".
[09:38] <mathiaz> soren: I discovered it while doing some tests.
[09:38] <soren> mathiaz: I can't reproduce it.
[09:39] <mathiaz> soren: try to install dovecot-common and dovecot-pop3, but not dovecot-imap
[09:39] <soren> With your patches?
[09:39] <soren> Or does that matter?
[09:40] <soren> Ok, done.
[09:40] <soren> Now what?
[09:40] <mathiaz> soren: hum.. I'm checking.
[09:41] <mathiaz> soren: ok. Set none to the protocols line and try to restart
[09:41] <soren> Done.
[09:41] <soren> Oh.
[09:42] <mathiaz> soren: yop...
[09:44] <heno> *** I've posted a custom entry on for tacking a custom ISO with unionfs 1.4. Please help test! ***
[09:56] <soren> mathiaz: Ok, I'll be looking into that this weekend.
[09:58] <soren> mathiaz: Will you look into the protocols rewriting thing?
[09:59] <mathiaz> soren: well - I can. But I though it was pointless as the none option doesn't work.
[10:02] <soren> mathiaz: I'll fix it.
[10:33] <slangasek> cjwatson: how often is germinate output regenerated?
[10:33] <cjwatson> slangasek: four-hourly
[10:33] <cjwatson> 2 */4 * * *             update-germinate
[10:33] <slangasek> ok
[10:34] <cjwatson> (ubuntu-archive@rookery; you should have access to that account I think, in case you want to kick a more urgent update)
[10:34] <slangasek> hmm, I think that's the wrong question anyway; I can see that the germinate output is more recent than the CDs
[10:34] <cjwatson> but the rookery mirror only updates once every six hours anyway, IIRC
[10:34] <slangasek> the right question would've been, is it possible to get another rebuild of alternate CDs to confirm libdb4.3 is gone?
[10:35] <cjwatson> actually, the germinate output on rookery runs off archive.ubuntu.com ...
[10:35] <cjwatson> slangasek: sure, I think you can do it yourself, but best wait until the new debian-installer lands or the images will be useless
[10:35] <slangasek> ok
[10:35] <cjwatson> slangasek: as cdimage@antimony, 'for-project ubuntu cron.daily'
[12:03] <bluefoxicy> ok
[12:03] <bluefoxicy> what in the hell logic is this?
[12:03] <bluefoxicy> [ "$1" != "" ]  && runlevel=$1
[12:03] <bluefoxicy> if [ "$runlevel" = "" ]
[12:04] <mjg59> bluefoxicy: One of those is assignment, not equality
[12:04] <slangasek> it's [ "$1" = "" ]  || runlevel=$1, written backwards
[12:04] <bluefoxicy> and the runlevel=$RUNLEVEL line before that too, and then the usage note that's a result of that if statement.. I'm not sure exactly what that script is checking for
[12:04] <mjg59> Or is sh more confusing than I remember?
[12:05] <cjwatson> [ foo = bar ]  is equality. foo=bar is assignment.
[12:05] <knix> ....
[12:05] <bluefoxicy> mjg59:  no, the thing is I'm confused on what the rc script is doing.  It looks like it's (get current runlevel) => (if user gave a runlevel as an argument, then use that instead) => (if neither is assigned, tell the user he's supposed to give us one!)
[12:05] <slangasek> bluefoxicy: that's correct
[12:05] <bluefoxicy> there's always a current runlevel though, isn't there....
[12:05] <slangasek> not always
[12:06] <slangasek> not if pid 1 isn't init, e.g.
[12:06] <bluefoxicy> ah, right.
[12:06] <bluefoxicy> ok, makes sense now.
[12:07] <bluefoxicy> (that's from /etc/init.d/rc)
[12:14] <tkamppeter> Someone knows the IRC nick of Steve Langasek?
[12:14] <Mithrandir> tkamppeter: slangasek
[12:14] <kylem> slangasek could possibly be it
[12:14] <bryce> slangasek
[12:15] <tkamppeter> Sorry, I have seen a posting fromn him now.
[12:15] <tkamppeter> <slangasek
[12:15] <tkamppeter> slangasek, you have mail.
[12:16] <slangasek> aigh my screen
[12:16] <slangasek> :)
[12:16] <tkamppeter> slangasek, it is about system-config-printer. I have packaged it to fix bug 149264 and bug 149529
[12:17] <slangasek> tkamppeter: while I do have mail, I don't seem to have any from you yet.  I had a good idea that's what it would be about though :)
[12:17] <tkamppeter> slangasek, I will resend it, as I accidentally sent it to the list, and there it gets auto-discarded
[12:18] <slangasek> though these bugs are different than what I thought you were going to say, hmm
[12:18] <Kopfgeldjaeger> maybe #144390 should be milestone=rc?
[12:19] <Kopfgeldjaeger> argh, sorry ;)
[12:19] <Kopfgeldjaeger> it already is
[12:22] <bryce> slangasek: we have several high priority updates for the -ati drivers to fix "X won't start" issues reported recently and validated in testing.  timo had been going through finding more bugs the update fixes, and just missed the freeze cutoff
[12:23] <tkamppeter> slangasek, resent the mail.
[12:23] <slangasek> bryce: "freeze" only means "release team reviews and judges"; if they're high priority updates, upload them :)
[12:23] <mjg59> bryce: Oh, btw, thanks for the X fix
[12:23] <bryce> ok cool
[12:23] <tkamppeter> slangasek, current s-c-p does not set up any Canon inkjet properly and messes up the menus.
[12:24] <bryce> mjg59: no prob; I also have a list of synaptic bugs that I think that, plus your new gui tool, renders closable...  I'll go through them probably next week
[12:24] <mjg59> bryce: I'm planning on doing quite a lot of synaptics work once I've got the thesis done
[12:24] <mjg59> Should be doable in the hardy timeframe
[12:25] <bryce> mjg59: awesome :-)
[12:26] <bryce> mjg59: I also hope to spend more time on the input side of things in hardy, with xserver 1.4 in place
[12:28] <donspaulding> I'm making a virtual package which only consists of a control file with dependencies and a changelog, is there anything I absolutely have to put in the rules file?
[12:31] <slangasek> tkamppeter: ah, so as far as uploads are concerned, please subscribe ubuntu-main-sponsors to the bugs; they don't trust me to upload yet, just to block things that others upload ;)