[12:38] <LaserJock> is there an RM about?
[12:52] <jason> hello i was wondering if any of you people program in C++
[12:52] <ikonia> most of the applications in ubuntu are written in c++, so mosst of the developers can
[12:52] <ikonia> jason: as I mentioned in the other channel
[12:53] <Amaranth> mjg59: ack, sorry
[12:53] <LaserJock> ikonia: most?
[12:53] <Amaranth> mjg59: yeah using nvidia but it happens if i blacklist the nvidia driver too
[12:53] <LaserJock> ikonia: if you include C I think I would agree, but I'm not sure about C++ specifically ;-)
[12:53] <jason> ok i wanted to learn C++ for linux and ive been having a harder time googling for specific real world examples
[12:53] <ikonia> LaserJock: couple of pythons slip thorugh the net ;)
[12:53] <LaserJock> heh
[12:53] <jason> any help pointing me in the right direction would be great
[12:54] <ikonia> jason if you can't find any resources to learn c or examples, then your not going to have the aptidue to learn c
[12:54] <LaserJock> jason: actually sourceforge I believe lets you filter projects by language
[12:54] <Amaranth> ikonia: almost zero apps in ubuntu are written in C++
[12:54] <Amaranth> well, in the default desktop, anyway
[12:54] <ikonia> Amaranth: C yes, apologies
[12:54] <LaserJock> Amaranth: there's gotta be some
[12:54] <jason> sourceforge is for projects im not looking for projects im looking for example sites
[12:54] <ikonia> Amaranth: I was picking up a conversationwith jason from another chanel where he was rambling
[12:55] <ikonia> I was trying to highlight an example, badly
[12:55] <LaserJock> jason: well, a program is an example
[12:55] <jason> its a more complex example
[12:55] <mjg59> Amaranth: Try it from the console (sudo /etc/acpi/sleep.sh force) without nvidia loaded. You'll be unlikely to get a console back, but you can then see if the machine is still alive.
[12:55] <ikonia> jason: amazon.com - there are books
[12:55] <Amaranth> LaserJock: gnome-system-monitor
[12:55] <Amaranth> mjg59: alright
[12:55] <Amaranth> mjg59: do the pm-trace thing?
[12:55] <mjg59> No
[12:56] <jason> i currently program in php OOP just want to stear into c++ for app development
[12:56] <LaserJock> jason: so maybe just google C++ tutorial?
[12:56] <jason> or C
[12:56] <Amaranth> ok, brb
[12:56] <jason> thanks that did the trick for c++ tutorial
[12:56] <jason> http://www.cplusplus.com/doc/tutorial/
[12:59] <Lamego> well, most of the ubuntu specific apps are written in python, not C++ :)
[01:00] <jason> python has a gui
[01:00] <jason> or i mean can create one?
[01:01] <Lamego> yes, it does not have a gui, it has libraries which provide a gui, same as for C++
[01:01] <jason> neat
[01:01] <jason> what IDE do you use for it
[01:02] <Lamego> a plain text editor :)
[01:02] <LaserJock> same as for C++ ;-)
[01:02] <LaserJock> emacs/vim FTW
[01:02] <Lamego> give a try either to wxpython or wxpython
[01:03] <Lamego> I personally found wxGTK easier to learn
[01:03] <Lamego> ops, i mean, pygtk or wxpython
[01:05] <Lamego> jason, you have plent of examples your system, more /usr/bin/update-manager :)
[01:05] <jason> is that a binary file or text
[01:06] <Lamego> it is a text, more was the command to read it
[01:06] <jason> sorry didnt see the more
[01:07] <Lamego> when in doubt: file /usr/bin/update-manager ;)
[01:07] <jason> i see the could pretty neat
[01:07] <jason> /usr/bin/update-notifier is not readable though
[01:07] <Lamego> uh ?
[01:07] <Lamego> hum
[01:07] <Kmos> kmos@bash:~$ file /usr/bin/update-manager
[01:07] <Kmos> /usr/bin/update-manager: python script text executable
[01:07] <Kmos> :)
[01:08] <Lamego> hum, there is something strange, randomly, more is reporting as not executable
[01:08] <jason> so update-notifier is python
[01:09] <Lamego> ops, i mean't manager
[01:09] <Lamego> erm, meant
[01:09] <Lamego> update-manager, is
[01:10] <Lamego> or /usr/bin/gdebi , etc, etc
[01:10] <jason> ok
[01:12] <Amaranth> mjg59: even if i blacklist nvidia and ipw3945 and boot in recovery mode it fails, no caps lock, sound stays muted (hardware light)
[01:13] <LaserJock> jason: python is a scripted language so you have many many examples already on your computer
[01:14] <LaserJock> jason: there is also a book called Dive Into Python which you can install (if it isn't already) in Ubuntu
[01:15] <Amaranth> LaserJock: diveintopython is a dependency of ubuntu-desktop :)
[01:16] <LaserJock> ah, good, I thought maybe they removed it
[01:16] <LaserJock> so you can just go into the Help and search for dive into python
[01:16] <jason> which IDE can i use for this python
[01:20] <LaserJock> jason: I just use a text editor, but I think python may come with one (IDLE) and I think SPE is decently popular
[01:20] <LaserJock> I believe there are also python plugins for eclipse
[01:23] <Lamego> hum,  python plugin for eclipse would be handy
[01:26] <MrMazda> Does gutsy have a startup option that allows to use legacy drivers instead of libata for IDE HDs?
[01:28] <ryanakca> umm... why do we have ddate in util-linux, or on the default install... it seems like the biggest waste of 7.7k :P
[01:37] <Amaranth> MrMazda: no, afaik those drivers are gone
[01:39] <cjwatson> ide-generic is still there
[01:40] <MrMazda> What's the secret to using them? I did modprobe -r ata_piix but the installer just reloaded it. My installation target is hda22
[01:41] <cjwatson> hmm, it's true piix.ko isn't built any more
[01:41] <cjwatson> MrMazda: what problem are you trying to solve? it's usually better to move forward than back ...
[01:41] <MrMazda> installation target is hda22
[01:49] <MrMazda> cjwatson: forward is not substituting a 14 partition limit for a 62 partition limit. SUSE and Mandriva furnish legacy drivers so people can continue to use existing partitioning.
[01:51] <cjwatson> my point was that it would be good to report bugs on the current drivers so that they can be fixed, because they do resolve other problems
[01:51] <cjwatson> I agree the limit is unfortunate, and it's not a problem that had occurred to me before
[01:52] <cjwatson> as for legacy drivers, you'd need to ask the kernel team
[01:52] <cjwatson> hmm, there is a pata_oldpiix.ko
[01:53] <cjwatson> though drat, that's still libata
[01:54] <cjwatson> MrMazda: I think the best you're likely to be able to do at present is to build the module yourself and blacklist the other in modprobe configuration so that it doesn't get reloaded
[01:54] <MrMazda> cjwatson: libata cannot be fixed because the limit is in the kernel to use the same limits that plague real SCSI. The only possible kernel fix (already planned) is actually a complete libata rewrite that doesn't depend on SCSI. Until either that rewrite or a device mapper solution, only legacy drivers are possible solution for systems requiring access to all existing partiitons.
[01:54] <MrMazda> cjwatson: how would that help getting installed in the first place?
[01:55] <cjwatson> I didn't say it would be easy ...
[01:55] <mjg59> MrMazda: Yeah. I'm afraid there's currently no practical way to install on devices with more than 16 partitions.
[01:56] <mjg59> You're the first person to have complained, amazingly
[01:56] <cjwatson> I think if I needed that many partitions I'd be inclined to move to LVM
[01:56] <MrMazda> mjg59: not exactly: https://bugs.launchpad.net/ubuntu/+bug/134983
[01:57] <ubotu> Launchpad bug 134983 in ubuntu "Cannot mount /home on /dev/hda16" [Undecided,New] 
[01:57] <cjwatson> (I'm not saying that your situation isn't a problem, understand - but this isn't going to change for 7.10 at this point)
[01:57] <cjwatson> I should probably make the installer check the partition count so that it fails earlier / more obviously
[01:58] <mjg59> MrMazda: Heh. Ok, second.
[01:59] <MrMazda> there's an even bigger problem in that it is a booby tray for upgraders who have no clue it's a problem
[01:59] <mjg59> Yes.
[02:00] <mjg59> But it's an issue that was introduced with the previous release, so I suspect it's hit about as many people as it's likely to now
[02:00] <MrMazda> mjg59: SUSE & Mandriva at least offer a clue: e.g. http://wiki.mandriva.com/en/Releases/Mandriva/2008.0/Notes#Changes_to_the_Mandriva_installer
[02:00] <cjwatson> if somebody could file a bug on update-manager to add a check, that would be good
[02:00] <cjwatson> MrMazda: TBH it simply hadn't occurred to me up to now. Now that you've mentioned it we can release-note it in various places
[02:02] <MrMazda> mjg59: a google for the subject of libata partition limit or somesuch does turn up a lot of discussion from people who hit the problem in SUSE & Mandriva beta testing, and people who simply can't with Fedora, plus other distros affected
[02:02] <mjg59> MrMazda: I'm not denying it's a problem. I just don't think the number of people it hits is large.
[02:03] <mjg59> For those it does hit, it's obviously a major issue and we ought to be communicating that.
[02:03] <mjg59> But since you're only the second person to have raised it as an issue with us, it's something that hasn't featured as a high priority...
[02:03] <MrMazda> mjg59: I know, like the problem of mousetype on web pages doesn't affect many people, but it's a big problem for those it does hit. :-(
[02:04] <MrMazda> lvm isn't for everyone
[02:05] <MrMazda> I wanted to bring this up on ubuntu-devel@lists.ubuntu.com a long time ago, but my attempts to post there always get rejected by moderators :-(
[02:07] <cjwatson> moderation rejections from ubuntu-devel@ are typically quite clear about where things should go instead
[02:07] <cjwatson> was yours not?
[02:07] <cjwatson> (cf. http://wiki.ubuntu.com/UbuntuDevelModeration)
[02:07] <cjwatson> and ubuntu-devel-discuss@ is always an option
[02:08] <MrMazda> cjwatson: OK thx. I didn't know about the devel-discuss
[02:09] <cjwatson> https://lists.ubuntu.com/archives/ubuntu-devel-announce/2006-December/000227.html
[02:09] <Amaranth> That reminds me, how do I get access to ubuntu-devel?
[02:10] <Amaranth> I was told being in ubuntu-dev automatically whitelisted me but apparently not
[02:11] <cjwatson> Amaranth: can be arranged *clicketyclick*
[02:11] <Amaranth> cjwatson: ok then, amaranth@ubuntu.com
[02:12] <cjwatson> moderation's pretty quick nowadays mind you
[02:12] <cjwatson> Amaranth: done
[02:13] <Amaranth> cjwatson: thanks
[02:28] <MrMazda> cjwatson: OK, I'm now off devel, on devel-discuss :-)
[02:48] <bddebian> Heya
[04:51] <Burgundavia> is the release the 18th or the 17th?
[04:51] <mjg59> 18th
[04:51] <mjg59> Thursday is traditional
[04:52] <Burgundavia> ok, the Fridge calendar is wrong, need to change that
[04:53] <lamont> gcc-3.4 for hppa/gutsy has built, and yet the dapper libstdc++6-dev from dapper is still in the universe Packages file... is that launchpad, or just an archive god that needs to fix that?
[04:58] <StevenK> lamont: Is it in NEW?
[04:58] <lamont> not even close
[04:59] <lamont> it's a real package that turned into a provided package somewhere between dapper and gutsy
[05:11] <LaserJock> gnight lamont
[05:55] <MrMazda> Is anyone not getting dbootstrap failure while installing base packages on beta2 i386? This happens to me on both network and CD installs.
[05:56] <MrMazda> an error was returned while trying to install the initramfs-tools package onto the target system happens every time
[07:38] <pitti> Good morning
[07:40] <LaserJock> hi pitti
[07:42] <mekius> bryce: you still up?
[07:44] <LaserJock> pitti: I've got an edubuntu-docs upload in the queue, can you approve it?
[07:45] <pitti> LaserJock: what does it change?
[07:45] <LaserJock> pitti: adds in the translations
[07:45] <LaserJock> it's hopefully the last upload before release
[07:47] <pitti> LaserJock: done
[07:47] <LaserJock> pitti: thank you
[07:49] <StevenK> pitti: I have something for you to cast an eye over too, if you have a moment?
[07:49] <pitti> StevenK: sure
[07:49] <StevenK> pitti: http://wedontsleep.org/~steven/vbox
[07:50] <StevenK> pitti: Basically, it builds the modules for virtualbox-ose for -generic and -server, since I asked BenC and he said something along the lines of
[07:50] <StevenK> "I've played that game, it was a pain, and we're not playing it again."
[07:51] <pitti> that game -> include them into l-u-m?
[07:51] <pitti> or did he refer to dapper's vmware modules?
[07:52] <mjg59> Ben doesn't want to include modules which have a tight version dependency with userspace
[07:52] <StevenK> That game was including them in l-u-m, which I believe was done for Edgy or Feisty
[07:53] <pitti> the package itself looks sane enough, no problem there
[07:53] <pitti> but if we put it in, this sort of commits us to support it and keep it up to date
[07:53] <pitti> i. e. increases the number of things to do for kernel ABI bumps and testing, etc.
[07:53] <StevenK> pitti: I'm happy to do so, I've no plans at all to update virtualbox-ose during gutsy.
[07:54] <pitti> StevenK: did BenC give his blessing to this approach?
[07:55] <StevenK> pitti: BenC's suggestion was to use DKMS. I've not asked for his blessing for this approach since I was unsure if I could make it work.
[07:55] <StevenK> It fails to build due to an interesting message, I need to track that down
[07:56] <StevenK> dpkg-genchanges: error: badly formed line in files list file, line 1
[07:56] <pitti> StevenK: ah, so I propose: get that build fixed and upload, and we keep it in the queue until we can ask BenC later?
[07:56] <pitti> uh?
[07:56] <StevenK> pitti: Sounds absolutely perfect to me.
[07:56] <pitti> StevenK: debian/files exists and wasn't cleaned or so?
[07:56] <StevenK> It doesn't exist in the source tree.
[07:57] <StevenK> pitti: If you notice, I still need to write a copyright file. :-)
[08:01] <LaserJock> StevenK: "need"? ;-)
[08:01] <LaserJock> I thought they were optional
[08:02] <pitti> LaserJock: hm? they are one of the most important things to get a package through source NEW :)
[08:03] <StevenK> Oh, duh, I know why it fails.
[08:04] <StevenK> % grep Section debian/control
[08:04] <StevenK> Section:
[08:04] <LaserJock> heh
[08:10] <doko> good morning
[08:17] <StevenK> pitti: I've updated the package, would you mind having a closer look at the copyright file, and letting me know if it's okay?
[08:18] <liw> '423 projects found  matching ubuntu' -- that makes it surprinsingly hard to find the real Ubuntu project on launchpad
[08:18] <StevenK> liw: /ubuntu
[08:19] <liw> StevenK, it searches the paths, not the human-readable names?
[08:20] <pitti> StevenK: wow, the copyright file will not exist for another 19 seconds (timestamp in the future)
[08:20] <StevenK> liw: I have no idea. :-)
[08:21] <pitti> StevenK: you need to add an explicit link to the GPL v2 in common-licenses/
[08:21] <StevenK> Leet. My time was -160 seconds off
[08:21] <StevenK> pitti: I do
[08:22] <pitti> StevenK: only for the general GPL for hte packacing, not for the innotek license
[08:22] <pitti> StevenK: (which is GPL 2 only)
[08:23] <StevenK> pitti: Ahh. Package updated.
[08:49] <StevenK> pitti: I've added another line to the copyright about GPL-2, does it look all fine now?
[08:49] <pitti> right at the bottom? yes, that sounds fine
[08:50] <StevenK> Okay. Let me test build it again, and then I'll upload it.
[09:00] <dholbach> good morning
[09:01] <Burgundavia> morning dholbach
[09:01] <dholbach> hey Burgundavia
[09:02] <mdke> hiya dholbach
[09:03] <dholbach> hey mdke
[09:07] <\sh> moins
[09:08] <StevenK> pitti: virtualbox-ose-modules uploaded, thanks for your help.
[09:08] <pitti> thanks
[09:09] <StevenK> Oh drat. I forgot to mention the LP bug. Oh well, I'll close it manually with the virtualbox upload.
[09:09] <StevenK> (After this is sorted out, I'm plotting to upload virtualbox-ose that Suggests virtualbox-ose-modules)
[09:14] <superm1> pitti, lirc's source package sits in main, but the interesting binaries end up elsewhere (and should be under the hard freeze right now).  would it be possible (er would you guys be opposed ) to fix a few minor changes regarding configurations that aren't available still, like bug 148756 and bug 145847 and bug 147440?
[09:14] <ubotu> Launchpad bug 148756 in lirc "lirc_gpio module cannot be loaded in Gutsy" [Undecided,New]  https://launchpad.net/bugs/148756
[09:14] <ubotu> Launchpad bug 145847 in lirc "Remote codes for Hauppauge Nova-T-500 dual tuner DVB-T PCI card" [Undecided,New]  https://launchpad.net/bugs/145847
[09:14] <ubotu> Launchpad bug 147440 in lirc "cannot make lirc_i2c kernel module" [Wishlist,Triaged]  https://launchpad.net/bugs/147440
[09:16] <pitti> superm1: fixing those sounds appropriate to me
[09:16] <pitti> superm1: I (or slangasek) reserve the right to judge based on the debdiff, though
[09:16] <superm1> pitti, of course.
[09:16] <superm1> just wanted to make sure before i put the effort forward
[09:31] <pitti> cjwatson: for debugging the cryptroot initramfs problem with set -x, do I need to create a customized alternate CD, or is it possible to sneak in a modified cryptsetup deb somehow?
[09:36] <StevenK> pitti: Oh yeah, NBS has 3 -12 packages living it in, input-modules-2.6.22-12-{hppa{32,64},lpia}-di
[09:37] <StevenK> Sigh, living in it
[09:37] <pitti> done
[09:38] <StevenK> pitti: Thanks!
[09:50] <cjwatson> pitti: I'd just edit the script on the fly if I were you ...
[09:50] <pitti> cjwatson: just hit the right moment?
[09:51] <cjwatson> you should have a reasonable window
[09:55] <pitti> cjwatson: ok, I'll try that first, thanks
[10:03] <superm1> pitti, would you prefer that i go through a core-dev sponsor before you have a look at the debdiff, or would you like to look it over directly yourself?
[10:04] <pitti> superm1: a review from your usual sponsor would be good, since I don't know LIRC myself
[10:04] <superm1> pitti, okay will do. thanks
[10:17] <dholbach> hey mvo
[10:18] <mvo> hey dholbach
[10:25] <mdz> cjwatson: yes, I do, and I see you already did it, thanks
[10:25] <mdz> cjwatson: I thought we had decided that ages ago, but if we did, it apparently didn't get implemented until now
[10:38] <heno> *** 20071008 ISO images are now candidates for RC *** Please test and report results at https://iso.qa.stgraber.org/
[10:38] <heno> Current test subscriptions: https://iso.qa.stgraber.org/qatracker/subscription
[10:39] <pitti> hi heno
[10:40] <pitti> heno: hm, I'm just moderating the unapproved queue
[10:40] <pitti> heno: e. g. there is a new ubiquity, and such
[10:40] <pitti> heno: I'll probably re-roll new images today
[10:41] <heno> pitti: ok, I got a mail from Steve asking me to start the testing
[10:41] <heno> pitti: but things change obviously :)
[10:41] <pitti> heno: well, that's fine :)
[10:41] <pitti> heno: just saying that those aren't the final RC images yet
[10:41] <heno> do you think you'll rebuild just desktops for now?
[10:42] <pitti> heno: the langpack export should also finish at some point today, so we'll get new langpacks and thus new alternates, too
[10:42] <Amaranth> mvo: did the compiz fixes get in already?
[10:42] <pitti> heno: but testing the current images is very important to verify fixes and find new grave bugs
[10:42] <heno> pitti: Right. I think it's useful to start mobilising people though :)
[10:42] <pitti> heno: absolutely
[10:43] <mvo> Amaranth: the current bzr is not uploaded yet, because of #122549
[10:43] <heno> pitti: so we are agreed. I should find a word for almost-candidates :)
[10:43] <Amaranth> bug 122549
[10:43] <ubotu> Launchpad bug 122549 in compiz "[gutsy]  unredirect-fullscreen-windows option breaks gnome-screensaver locking behavior" [High,In progress]  https://launchpad.net/bugs/122549
[10:43] <mvo> Amaranth: there is some progress, but I'm not sure if my approach for the fix is correct, it seems to work for me though.
[10:43] <Amaranth> mvo: ah, that one
[10:44] <Amaranth> I still can't reproduce that
[10:44] <Amaranth> That guy using synergy can probably be ignored if the patch you have doesn't fix it for him
[10:45] <mvo> Amaranth: the trouble is that I change findTopLevelWindowAtScreen() and that may cause undesired side-effects
[10:45] <mvo> indeed
[10:45] <mvo> I was able to reproduce it here with out synergy or anything
[10:46] <RAOF> I've just checked, I easily get it without Xgl.
[10:46] <Amaranth> I don't use Xgl
[10:46] <RAOF> I get it with and without Xgl, so :P
[10:47] <Amaranth> *sigh* I wish the -rt kernel would not lock my CPU to C0
[10:47] <Amaranth> I just did an apt-get upgrade and didn't even notice
[10:49] <RAOF> Now, to test whether nvidia resumes-from-suspend...
[10:49] <persia> dholbach: Thank you.
[10:49] <mvo> RAOF: if you easily get it, could you please test if the patch http://launchpadlibrarian.net/9847233/030_fix_screensaver fixes it for you? (against compiz)?
[10:49] <RAOF> mvo: Certainly; it'll have to wait 'till I get home though.
[10:50] <Amaranth> mvo: It is an interesting fix
[10:51] <dholbach> persia: de rien
[10:52] <Amaranth> mvo: But you should probably make it exclude tooltips and menus
[10:53] <mvo> Amaranth: yeah, that is my concern. I was wondering if those are InputOnly or InputOutput
[10:54] <Amaranth> mvo: You could just explicitly check for them and not have to worry about it
[10:54] <ogra> pitti, are you crazy ? what am i eversupposed to do with 50Mb spare space on my CDs ?
[10:54] <pitti> ogra: :)
[10:54] <Amaranth> ogra: How did you get free space?
[10:54] <pitti> ogra: thank doko
[10:54] <Amaranth> No fair :P
[10:54] <pitti> ogra: fill them with langpacks
[10:55] <ogra> pitti, yeah :)
[10:55] <doko> ogra: you could add icedtea ... (including java plugin for amd64)
[10:55] <pitti> ogra: and/or ship nvidia-glx-new, or anythign
[10:55] <ogra> doko, how much is that ?
[10:55] <ogra> (i'D love to :) )
[10:55] <doko> 27mb
[10:56] <doko> but not yet in the archive ...
[10:56] <ogra> ah, that still leaves space for the major langs
[10:56] <doko> and still universe
[10:56] <cjwatson> icedtea -> hardy
[10:57] <cjwatson> much though I think it's great to have free hopefully-fully-working Java, it still needs to get into the archive and there are 10 days to go. :-)
[10:57] <cjwatson> to clarify I mean icedtea in main / on CDs -> hardy
[11:11] <pitti> cjwatson, mvo "useDevelopmentRelease=False" in the dist-upgrader is not yet done for the release candidate, right?
[11:11] <ogra> if [ -e $COMPRESS_LOG ] ; then
[11:11] <ogra>     mv $COMPRESS_LOG /taget/var/log/
[11:11] <ogra> fi
[11:11] <ogra> how disconcerting ...
[11:15] <tkamppeter> hi, pitti
[11:15] <\sh> remoins
[11:15] <pitti> hi tkamppeter
[11:16] <tkamppeter> pitti, I have put up fixed gutenprint packages, see mail
[11:16] <pitti> thanks
[11:16] <tkamppeter> Riddell, ping
[11:16] <pitti> I'd like to hear Riddell's confirmation first, though
[11:17] <tkamppeter> pitti, the ijsgutenprint package is for sure needed by foomatic-db-gutenprint. The PPDs from foomatic-db-gutenprint NEED ijsgutenprint. Therefore I have reverted Riddell's change.
[11:19] <pitti> tkamppeter: no doubt about that
[11:19] <pitti> tkamppeter: I meant, the alternative solution you proposed
[11:20] <tkamppeter> pitti, this is confirmed by users in the bug report. They got the problem solved by installing foomatic-db-gutenprint (which pulled in ijsgutenprint).
[11:20] <pitti> ok
[11:24] <Riddell> pitti: on the whole I trust tkamppeter when it comes to printing :)
[11:25] <pitti> Riddell: ok
[11:28] <tkamppeter> Riddell, so take in foomatic-db-gutenprint and ijsgutenprint and leave out cupsys-driver-gutenprint in the Kubuntu Gutsy seeds.
[11:29] <Riddell> the trouble with ijsgutenprint is it depends on gs
[11:29] <tkamppeter> Riddell, but note that it is a workaround for the totally outdated KDE Printing Manager. For Hardy the KDE-P-M must get fixed and the seed change reverted.
[11:30] <Riddell> which means moving it and one of the gs packages to main
[11:30] <Riddell> tkamppeter: are you going to UDS?
[11:31] <tkamppeter> Riddell, the gs dependency in ijsgutenprint I have fixed now.
[11:32] <tkamppeter> pitti, do not upload gutenprint, I need to do still a little fix.
[11:32] <pitti> tkamppeter: alright, I'll wait for it
[11:36] <kagou> Hi
[11:36] <tkamppeter> Riddell, I have done it in the upcoming gutenprint 5.0.1-0ubuntu8. Now I have added the new package name "ghostscript" as alternative for this dependency.
[11:36] <tkamppeter> kagou, thanks for the bug report with the Canon printers, so I could fix this in the last minute.
[11:37] <kagou> tkamppeter, your welcome ^^
[11:37] <ogra> pitti, there is an ltsp upload waiting for approval, debdiff is on http://people.ubuntu.com/~ogra/debdiff-5.0.38-5.0.39.diff
[11:37] <ogra> (ailly typo)
[11:37] <ogra> *silly even gah
[11:38] <pitti> ogra: NP, I'll get the diffs directly from the queue
[11:38] <tkamppeter> Riddell, I will not be on the UDS, as the same week there is an OpenPrinting Meeting in Tokyo (Oct 31 - Nov 2). I will show the work of OpenPrinting to the japanese printer manufacturers.
[11:42] <liw> mvo, I just filed https://bugs.launchpad.net/ubuntu/+bug/150500 -- I didn't find anything about it yet, but is it a known issue?
[11:42] <ubotu> Launchpad bug 150500 in ubuntu "update-manager fails upgrading feisty to gutsy, Python "import os" is missing" [Undecided,New] 
[11:42] <mvo> liw: do you use update-manager from feisty-updates?
[11:43] <liw> mvo, I installed feisty from the iso, then installed updates with update-manager, then rebooted, so I assume that was the one
[11:43] <mvo> liw: could you please check the version number?
[11:43] <mvo> liw: and add that information to the bugreport?
[11:43] <liw> sure, just a minute
[11:45] <liw> mvo, I added "import os" at the top of the problematic file, that made it work (at least past the point where it crashed before)
[11:46] <liw> mvo, 1:0.59.19
[11:48] <mvo> liw: that is not the version from -updates, maybe something was missing from the update-manager update run you did before?
[11:48] <liw> mvo, if so, update-manager's failure mode for that was not evident; I'll try the experiment from scratch
[11:49] <mvo> liw: thanks, that is appreciated
[11:49] <liw> mvo, this is what I'm here for :)
[11:51] <RAOF> Mvo; your fix doesn't work
[11:52] <mvo> RAOF: that makes me unhappy. you still get the problem?
[11:53] <RAOF> mvo: Yes.  I typed that on a locked screen.
[11:55] <RAOF> mvo: I'm just trying to find the build log to ensure that the patch was actully applied; sbuild doesn't seem to want to email me reports anymore :/
[11:57] <Amaranth> So how did doko get 50MB free space for ogra to fill?
[11:57] <Amaranth> Drop OOo? :)
[11:57] <pitti> that would have given us half of the CD, no
[11:57] <ogra> Amaranth, removing file duplicates
[11:57] <pitti> mainly, getting air out of duplicated changelogs, files, etc.
[11:57] <Amaranth> Oh, still just that
[11:57] <Amaranth> apparently evolution was a big one
[11:58] <ogra> pitti, did you change anything wrt oo.o in ubuntu now ?
[11:58] <pitti> ogra: no; removing -base is too complicated surgery for this point
[11:58] <ogra> Amaranth, localized screenshots are the biggest one i guess ... they should go into special langpacks imho
[11:59] <ogra> but thats nothing for "dawn of release" time :)
[12:00] <Amaranth> Is OOo really half the CD?
[12:00] <pitti> including all the java, db, and other dependencies it pulls in, it's very large
[12:01] <pitti> (not half of the CD, but I'd guess in the order of ~ 200 MB?
[12:01] <Amaranth> ouch
[12:01] <Fujitsu> Ow.
[12:01] <Amaranth> Is it compiled with -Os?
[12:01] <Amaranth> :)
[12:01] <Amaranth> I don't remember what ubuntu's default CFLAGS and such are
[12:01] <pitti> -O2
[12:02] <Amaranth> Huh, I thought for sure it'd be -Os since we're always fighting for more space
[12:02] <Fujitsu> Noooo, OOo is slow enough without Os
[12:02] <Amaranth> Fujitsu: It would go faster?
[12:03] <elmo> Fujitsu: err, -Os is often faster than -O2
[12:03] <pitti> Amaranth: IIRC only -O3 might make binaries bigger; -O2 only has optimizations which don't increase size
[12:03] <Fujitsu> Ah.
[12:03] <Amaranth> pitti: But -Os makes it smaller than -O0
[12:03] <pitti> yeah, maybe
[12:03] <Amaranth> Fujitsu: Less data to load from disk, better chance of fitting in cache
[12:03] <Fujitsu> Amaranth: True.
[12:05] <Amaranth> Someone should try it
[12:05] <Amaranth> I would but all I have is this laptop and I don't want it burning a hole in my leg for the 6 hours or whatever OOo takes to build :P
[12:06] <Fujitsu> Isn't 6 hours waaaay to conservative?
[12:06] <Fujitsu> *too
[12:07] <Amaranth> Fujitsu: Someone with a dual dual core Xeon built it in 6 hours, iirc :P
[12:07] <Fujitsu> That might do it.
[12:07] <RAOF> mvo: Is it possible that some plugin set up is why I see this problem?
[12:10] <mvo> RAOF: I don't think so, but it might be
[12:11] <RAOF> mvo: Want a tarball of my gconf tree?
[12:11] <tkamppeter> pitti, the fixed gutenprint is in place now. Ready for uploading.
[12:12] <liw> mvo, ok, seems that my first attempt to upgrade to current feisty had failed, upgrading and continuing
[12:13] <mvo> liw: what was/is the issue with the update?
[12:13] <ogra> liw, s/to/from/ ?
[12:16] <liw> mvo, I have no idea, I thought I did all the same steps as just now
[12:16] <liw> ogra, from system installed from feisty iso to feist-updates
[12:17] <ogra> ah
[12:40] <pitti> soren: FYI, I now found the most convenient way how to circumvent erasing the encrypted partition
[12:41] <pitti> soren: use the autopartitioning method, say "No", flip the erase flag, choose "guided partitioning", and say "yes" for confirmation
[12:47] <soren> pitti: Uh.. How do you flip the erase flag before it shows you the page where you can alter the partition layout?
[12:47] <pitti> soren: in the 'manual' dialog
[12:47] <soren> pitti: Ah.. Clever.
[12:48] <soren> pitti: did you track down the initramfs issue yet?
[12:48] <pitti> soren: at it
[12:49] <pitti> soren: I know the reason, now I'm looking for the cause
[12:49] <pitti> Oct  8 07:57:28 apt-install: + [ -L /dev/disk/by-uuid/bb796e0a-307c-4129-a152-8cf6bda3cb5d ] 
[12:49] <pitti> fails
[12:49] <pitti> my current theory is that there is no /dev in /target, at least not the same dynamic one we have in /
[12:49] <pitti> (in the installer environment)
[12:50] <pitti>  /target/dev/mapper/ is fine, but there is no /target/dev/disk/by-uuid/
[12:50] <soren> pitti: Makes sense.
[12:50] <soren> Any reason why we're not bind mounting it in the /target ?
[12:50] <cjwatson> pitti: that's very possible, actually
[12:51] <cjwatson> sounds like a straight bug
[12:51] <pitti> well, I guess bind-mounting it would be a good answer
[12:51] <pitti> for the long-term solution
[12:51] <pitti> but I'm not sure whether that's appropriate at this point of the release
[12:51] <cjwatson> try mount -o bind'ing it in the install_extra function in /var/lib/dpkg/info/base-installer.postinst
[12:51] <cjwatson> and umounting it on return from that function
[12:51] <pitti> I currently have a test install going
[12:51] <pitti> and I SIGSTOPed the kernel installation by apt
[12:52] <pitti> so I have time to poke around
[12:52] <cjwatson> maaaaaaybe around bits of install_linux too
[12:52] <cjwatson> bit worried about doing it for the whole of base-installer at this point, as it's a touch fragile
[12:53] <pitti> unless there's an easier method to resolve an UUID to a device node?
[12:53] <soren> pitti: What does it need it for anyway?
[12:53] <pitti> soren: it needs to feed the device node to dmsetup
[12:53] <pitti> soren: so that it can find out the physical device of the root lvm
[12:53] <soren> Ok.
[12:54] <pitti> soren:  deps=$(dmsetup deps "$node" 2> /dev/null | sed 's/[^:] *: *//;s/[ (] //g;s/)/ /g')
[12:54] <pitti> if $node is a UUID, this fails
[12:54] <pitti> so in the recent cryptsetup I added that UUID resolution
[12:54] <soren> ah, yes, I remember.
[12:54] <pitti> above command will cut out the major and minor device number of the PV
[12:54] <pitti> cjwatson: I'll give this a try
[12:55] <Keybuk> pitti: resolving a UUID is easy (iterate block devices and peek)
[12:55] <pitti> cjwatson: when is that postinst called?
[12:55] <Keybuk> ensuring that the UUID is for the device that udev would have picked is hard
[12:55] <Keybuk> (since udev applies priorities to UUIDs)
[12:56] <pitti> Keybuk: that sounds like an issue for ambiguous UUIDs only?
[12:56] <Keybuk> pitti: such as any involving devmapper :p
[12:57] <cjwatson> pitti: the postinst implements the "install the base system" menu item
[12:58] <pitti> cjwatson: I mean, is it installed into /target, or run within the installer? when can this change be made in the installer env?
[12:58] <Riddell> mvo: you're the man for sru-verification?
[01:00] <cjwatson> pitti: it's run within the installer
[01:01] <cjwatson> pitti: you can make the change at any point between "retrieving additional components" ending and "installing the base system" starting. The hostname prompt is usually a good time
[01:01] <\sh> hmmm...after a reinstall of latest gutsy daily, all my ooffice crashes are gone (at least on one machine) strange
[01:01] <pitti> cjwatson: ah, sweet
[01:02] <pitti> Keybuk: vol_id seems to be a good tool for getting the UUID (just in case we don't want the bind-mount approach); however, iterating over all block devices sounds a bit painful
[01:02] <Keybuk> pitti: vol_id is *the* tool for getting the UUID :-)
[01:03] <Keybuk> but as I said, don't do it that way if anything involving devmapper, lvm or md comes into play
[01:03] <Keybuk> lvm especially, since with snapshots, you might not know which of the four block devices with identical UUIDs you need
[01:04] <pitti> ok
[01:04] <Keybuk> or if evms is likely to be installed
[01:05] <soren> Keybuk: This is in the alternate installer if you choose encrypted lvm.
[01:05] <Keybuk> ahh
[01:05] <soren> So evms is not very likely to be around :)
[01:05] <Keybuk> so yes, do NOT NO NOT use vol_id for that
[01:05] <soren> (I know, you missed the start of the conversation)
[01:05] <Keybuk> since you need udev to sort out the duplicate UUIDs for you
[01:08] <pitti> Keybuk: ok, so it's bind-mounting or nothing
[01:11] <kyja> pardon me.. anyone home? :) I seem to have a double entry of the Desktop menu item in Places menu in Gnome. How can I remove one?
[01:12] <kyja> I should probly ask this elsewhere folks here are rather busy for the development of core software.
[01:13] <pitti> kyja: that's a known bug, and marked for gutsy release candidate
[01:13] <kyja> oh thank you. I wont hack then hehe
[01:13] <tepsipakki> pitti: I have a fix for ati (pulled from upstream); the latest update changed to default on CVT mode, but this change reverts that (back to LVDS) and adds an option to use CVT if needed. I have a package on my ppa and people have verified it works
[01:13] <seb128> pitti: it's already fixed
[01:14] <seb128> kylem: that's a gtk bookmark, you can remove it from nautilus
[01:14] <kyja> k
[01:14] <seb128> the package is fixed, new installation or upgrade will not add the bookmark to desktop
[01:14] <seb128> but if you used a buggy version you have to remove it yourself now
[01:23] <asisak> mvo: if I use pbuilder-satisfydepends-gdebi with unsigned local repositories, it will fail, since "E: There are problems and -y was used without --force-yes". Do you want to accept a patch that fixes this? I would not be afraid of security issues, since a pbuilder user should know what he wants to do.
[01:29] <bigon> hi, is it still possible ton sync gtk-doc from debian (new upstream version)? I've an issue with the version currently in gutsy and the version of debian fix the probleme
[02:03] <pitti> tepsipakki: please get it uploaded and make sure the relevant bug is properly milestoned, u-release sub'ed, etc.
[02:03] <pitti> tepsipakki: slangasek will take a look later
[02:04] <pitti> (or me)
[02:04] <tepsipakki> pitti: just uploaded that, I'll milestone those bugs etc
[02:07] <tepsipakki> done, phew
[02:09] <tepsipakki> strange bug actually, it had three symptoms; 1) misplaced desktop, 2) nearly monochrome graphics, or 3) blank screen :)
[02:12] <bluekuja> pitti: dont need to check lightning-locales, I'm working on them with seb128
[02:12] <bluekuja> so you can move to other tasks
[02:13] <bluekuja> thanks for bittornado :)
[02:13] <pitti> bluekuja: appreciated, thanks
[02:18] <seb128> pitti: lightning-extension-locales is good to approve if you want, that's only a section fix (technically I could process it but since I'm not a r-t member I prefer to let you do it ;)
[02:20] <pitti> seb128: if it's only that, then we don't actually need it; we need to use the soyuz override anyway
[02:21] <seb128> pitti: the binary upload has been rejected by soyuz because of the incorrect section if I understand it correctly
[02:21] <seb128> pitti: it's using a non valid section
[02:21] <seb128> not a valid but wrong one
[02:21] <pitti> seb128: I rejected it manually on bluekuja's request
[02:22] <seb128> ah, ok
[02:22] <seb128> I didn't understand correctly what he told me or he was not clear then
[02:22] <pitti> he asked me to so that he could fix the section
[02:22] <seb128> sorry for the noise
[02:22] <pitti> np :)
[02:23] <bluekuja> seb128: yeah, there was a control template inside debian/
[02:23] <seb128> pitti: btw people argue on the nautilus vfat bug that the patch should be reverted because it's better to have the freeze on mount that during a copy (because if you try closing it before it's frozen it can lead to data loss apparently)
[02:23] <bluekuja> seb128: which was still set on internet section (wrong)
[02:23] <seb128> s/before/while
[02:24] <seb128> bluekuja: well, as pitti said that's no big deal and can be override on soyuz without a new upload for now
[02:24] <asac> heno: i run update-manager -d -c in my feisty vbox install, but no upgrade happens (e.g. update-manager claims to be up-to-date)??
[02:24] <asac> heno: nevermind :)
[02:24] <bluekuja> seb128: ok then :)
[02:25] <asac> heno: hmmm ... there is indeed no upgrade version button :/
[02:25] <heno> asac: which distro flavour?
[02:25] <liw> asac, strange, it just worked for me
[02:26] <heno> I just completed an Ubuntu upgrade, which was fine
[02:26] <bluekuja> seb128: what will you do with that revision then? will be rejected as well?
[02:26] <heno> doing kubuntu now
[02:26] <seb128> bluekuja: up to pitti
[02:26] <bluekuja> seb128: ok, I'll ask pitti for it then
[02:26] <bluekuja> thanks
[02:27] <pitti> bluekuja: it's only the source section? or any binaries as well?
[02:28] <bluekuja> pitti: only source
[02:28] <pitti> bluekuja: that's about the least important thing anyway, but let me change it
[02:29] <bluekuja> pitti: ok thanks
[02:31] <asac> heno: desktop ... feisty i386
[02:31] <mvo> asac: do you have the update-manager from feisty-updates
[02:31] <asac> mvo: hmm let me see ... just default feisty install + all upgrades
[02:32] <mvo> asac: that should be fine, but please check the version to be sure
[02:32] <asac> mvo: updates is in sources.list ... i try to upgrade (i setup this install on fri/sat)
[02:33] <pitti> bluekuja: oh, failed-to-upload; that's more serious; I'll accept this
[02:34] <bluekuja> pitti: yeah, it was a failed-to-upload
[02:34] <mvo> asac: please check for update-manager and update-manager-core, it should be 0.59.25
[02:34] <bluekuja> pitti: for that error in the section
[02:34] <bluekuja> pitti: thanks
[02:34] <pitti> bluekuja: accepted and overridden, thanks
[02:35] <asac> mvo: hmmm ... both have that version ... but apparently my vbox has lost network access ... could this hide the upgrade button?=
[02:35] <bluekuja> pitti: thanks for your work on it martin
[02:35] <mvo> asac: yes, no network will result in this
[02:36] <xjkx> will you ever create an ubuntu comming with mp3 codecs?
[02:36] <asac> mvo: ok that explains it then
[02:36] <bluekuja> pitti: it's normal I see Section: misc in gutsy-changes mail?
[02:36] <carlos> pitti: would be possible that you block some locales to be used in language packs?
[02:37] <pitti> bluekuja: I think yes; might be souyz' fallback for an invalid section
[02:37] <carlos> pitti: it will take me a while to get it done in Launchpad to stop exporting them, so if you could do it in your side for Gutsy, would be wonderful
[02:37] <pitti> bluekuja: the override does not get active until after the next publisher run
[02:37] <Riddell> mvo!
[02:37] <bluekuja> pitti: oh ok, perfect :) , sounds fine then
[02:37] <pitti> carlos: for this one langpack build I can remember it, but not in general
[02:38] <mvo> asisak: yeah
[02:38] <mvo> hello Riddell!
[02:38] <Riddell> mvo: I'd like to move kdebase update to -updates, I believe I need your backing as sru-verification man? bug 117731
[02:38] <ubotu> Launchpad bug 117731 in python-kde3 "Python crashes after attaching pty to a konsole kpart" [High,Fix committed]  https://launchpad.net/bugs/117731
[02:38] <carlos> pitti: yeah, just talking about gutsy final
[02:39] <carlos> pitti: if we ship those locales once, even if I don't ship new updates from Launchpad, those old files will remain
[02:39] <mvo> Riddell: mine or bdmurrays. I'm currently debugging a very nasty compiz issue with the screensaver
[02:40] <pitti> carlos: ok, can do (assuming that you speak about particular languages, not locales)
[02:40] <mvo> RAOF: anything new trying the patch? do you want me to prepeare a updated package that you can test?
[02:40] <pitti> carlos: however, what do we use instead?
[02:40] <pitti> carlos: we can't just entirely kill a language like Spanish
[02:40] <seb128> pitti: the issue fr_FR taking over fr
[02:40] <pitti> eww
[02:41] <seb128> and fr is the correct domain, which has updated translation
[02:41] <pitti> carlos: you mean I should locally modify the tarball before importing; yes, that's doable, too
[02:41] <seb128> and the fr_FR has some randomly broken outdated files
[02:41] <pitti> carlos: can you please mail me a list of all those cases?
[02:41] <carlos> pitti: I'm talking about remove all languages that use '_' as part of the locale, except a good known list like 'zh_*' 'en_*' and  'pt_*'
[02:41] <carlos> pitti: sure
[02:42] <pitti> alright
[02:42] <pitti> carlos: export is still running? time is pressing...
[02:43] <carlos> pitti: if it takes as much time as last one, it will finish around 1:00AM tonight
[02:43] <pitti> eww
[02:43] <pitti> I thought I would have had the tarball this morning
[02:43] <carlos> and yes, still running
[02:44] <pitti> carlos: my error might have been that I assumed that "start it on Saturday" would mean 0200, not 2200
[02:44] <carlos> pitti: yeah, sounds like that
[02:44] <carlos> pitti: again, should I change the start time to 02:00 ?
[02:44] <pitti> too late now
[02:45] <carlos> we should fix this performance issue soon, but not in time for Gutsy
[02:45] <mvo> Riddell: woah, the out of memory  issue is nailed down? that is GREAT!
[02:45] <pitti> right, and changing the cronjob now wouldn't retroactively fix the time pressure
[02:45] <carlos> ok
[02:45] <carlos> pitti: I will send you that email after lunch
[02:46] <carlos> later!
[02:50] <Treenaks> hi Hobbsee
[02:50] <realist> Hobbsee o/
[02:52] <Hobbsee> :)
[02:52] <Riddell> mvo: well
[02:52] <Riddell> mvo: to some extent, I don't think it fixes it entirely, but it helps
[02:53] <Treenaks> Hobbsee: you were in one?
[02:53] <Hobbsee> yeah
[02:59] <bluekuja> pitti: how long does it take to get published on lp starting build?
[02:59] <pitti> bluekuja: publisher starts 3 minutes past the hour
[02:59] <pitti> bluekuja: so, the next :03 after it finished building
[03:00] <bluekuja> pitti: ok, was looking inside lp and watched a 0ubuntu1 pending
[03:00] <bluekuja> pitti: and I dont see a 0ubuntu2
[03:02] <bluekuja> pitti: https://edge.launchpad.net/ubuntu/+source/lightning-extension-locales/
[03:03] <bluekuja> pitti: got published right now
[03:03] <bluekuja> on lp
[03:03] <bluekuja> ;)
[03:04] <bluekuja> a small delay then
[03:04] <pitti> the source gets known to LP immediately, yes
[03:05] <bluekuja> yeah, after 10 mins from being accepted wasnt on lp
[03:05] <Hobbsee> soyuz may have eaten it
[03:05] <pitti> seb128: vfat patch> not sure; but if it does more bad than good, then let's revert it and hope that we can fix the kernel side in -updates
[03:05] <Hobbsee> (or did it get stuck in NEW?)
[03:06] <bluekuja> Hobbsee: wasnt NEW :)
[03:06] <seb128> pitti: ok, I would do that then
[03:06] <bluekuja> Hobbsee: so got eaten from soyuz
[03:06] <bluekuja> Hobbsee: :)
[03:07] <Hobbsee> i said may :)
[03:07] <bluekuja> :D
[03:11] <dholbach> asac: I subscribed you to bug 150529
[03:11] <ubotu> Launchpad bug 150529 in firefox-3.0 "firefox.sh: unexpected operator ()" [Undecided,New]  https://launchpad.net/bugs/150529
[03:11] <dholbach> cjwatson: I subscribed you to bug 145852
[03:11] <ubotu> Launchpad bug 145852 in ntfs-3g "[UVFe]  please merge ntfs-3g (1:1.913-1) from Debian unstable (main)" [Undecided,In progress]  https://launchpad.net/bugs/145852
[03:13] <cjwatson> dholbach: yeah, I've been working on it for the last couple of hours
[03:13] <cjwatson> thanks
[03:13] <dholbach> cjwatson: thank YOU :)
[03:14] <asac> dholbach: why don't i have that? strange.
[03:15] <dholbach> asac: nobody is bug contact for it
[03:15] <dholbach> https://bugs.launchpad.net/ubuntu/+firefox-3.0/+subscribe
[03:15] <dholbach> https://bugs.launchpad.net/ubuntu/+source/firefox-3.0/+subscribe
[03:15] <asac> dholbach: no:) ... i mean why does ffox just start fine here?
[03:15] <asac> :)
[03:16] <dholbach> oh ok :)
[03:17] <gnomefreak> dholbach: asac mozilla-bugs is now the contact for firefox-3.0
[03:19] <asac> gnomefreak: ok thanks
[03:19] <gnomefreak> np
[03:19] <asac> gnomefreak: please do the same for xulrunner-1.9
[03:20] <gnomefreak> ok one sec
[03:20] <gnomefreak> done
[03:50] <bddebian> Heya
[03:53] <Whoopie> mjg59: did you look at uswsusp for the usplash patch?
[04:04] <sabdfl> BenC: sound is not working for me at all on X60. I found #95940 but that is for 2.6.20, should I file a new bug or add a new link to 2.6.23?
[04:04] <mjg59> sabdfl: Make sure the modem is turned on in the bios
[04:06] <mvo> RAOF: I have a update for the screensaver issue, would you be able to test ?
[04:07] <bluekuja> pitti: built and published fine ;)
[04:08] <StevenK> It isn't explicitly mentioned .... :-P
[04:09] <Hobbsee> yeah, well.  this guy is about to cop a stabbing.  or a kickban
[04:09] <Hobbsee> "yes, i should be allowed to repeat my question in #ubuntu every minute, because people who join may know the answer!  and isnt it lucky that everyone else isnt doing it, so the channel stays useful...."
[04:10] <StevenK> Twitch
[04:10] <StevenK> Oh look, you made sabdfl quit. :-P
[04:10] <realist> Perhaps a gentle warning Hobbsee?
[04:10] <zul> Hobbsee, hah
[04:10] <Hobbsee> realist: he's already had it, over and over.
[04:10] <Hobbsee> hahaha, nice.
[04:10] <ScottK> Gentle warnings aren't Hobbsee's speciality.
[04:10] <realist> Otherwise there's /ignore or /part
[04:10] <Hobbsee> realist: there's /kb.
[04:10] <Hobbsee> solves all
[04:11] <realist> ScottK: /k then /kb constitutes a gentle warning
[04:11] <Hobbsee> ScottK: no, no, this had a gentle warning - across 3 channels.
[04:12] <Hobbsee> ScottK: and has already been kickbanned across 2 (although not by me)
[04:12] <zul> Hobbsee: does the /kb include the option to electrocute?
[04:12] <Hobbsee> zul: i wish.
[04:12] <ScottK> Hobbsee: Given your reputations for genteel subtleness, I've no doubt at all. ;-)
[04:12] <realist> Hobbsee: As long as it's accompanied with a brief yet specific reason, it's perfectly reasonable
[04:13] <Hobbsee> bah.  gone.
[04:13] <realist> zul: that would deprecate *stab in the face* though?
[04:14] <zul> realist: Hobbsee is  a bit evil so its up to Hobbsee's discretion
[04:14] <Hobbsee> haha
[04:16] <Keybuk> bdmurray: what do you use "Triaged" to mean?
[04:18] <Kopfgeldjaeger> hi
[04:19] <soren> What's the process for getting an upload approved these days?
[04:19] <asisak> soren: I guess upload & wait :)
[04:20] <Hobbsee> soren: ask a member of the release team
[04:20] <Hobbsee> soren: oh, main or universe?
[04:20] <soren> Hobbsee: Main
[04:20] <pitti> soren: make sure the changelog has a milestoned bug #
[04:20] <Hobbsee> and if it doenst, milestone the bug first :P
[04:20] <pitti> and that the debdiff doesn't make us weep
[04:20] <soren> pitti: Oh, I didn't bother to file the bug first. Should I do that for bookkeeping?
[04:20] <pitti> no, don't milestone every small itch
[04:21] <pitti> that will make the milestone list even worse than it is
[04:21] <pitti> soren: what this meant was: "make sure you only work on bugs which are already milestoned"
[04:21] <soren> pitti: It's a fresh dovecot merge with a few additions to post{rm,inst}
[04:22] <soren> The fresh dovecot thing was already approved, afaik.
[04:22] <pitti> soren: I just have that on my screen incidentall
[04:23] <pitti> mvo: oh, btw, do you plan another update-notifier upload? we need one today to switch off apport by default
[04:23] <mvo> pitti: ok, I can take care of this
[04:24] <pitti> mvo: thanks
[04:24] <pitti> soren: there is no bug number in the changelog, and intrusive changes
[04:25] <soren> pitti: The dovecot upload fixes bug 149049, bug 146648 and another one that I discovered but didn't bother to file.
[04:25] <ubotu> Launchpad bug 149049 in dovecot "FFe request: 1.0.5" [Undecided,In progress]  https://launchpad.net/bugs/149049
[04:25] <ubotu> Launchpad bug 146648 in dovecot "Suboptimal defaults in dovecot.conf" [Medium,Triaged]  https://launchpad.net/bugs/146648
[04:25] <soren> pitti: There are two bug numbers?
[04:26] <pitti> soren: sorry, I mean milestoned bugs
[04:28] <soren> pitti: Oh.
[04:28] <pitti> soren: the changes look ok, though; how much testing did you give this?
[04:29] <soren> pitti: My changes (the post{inst,rm} stuff) have been tested quite a bit, I'd say. mathiaz tested the new dovecot version.
[04:29] <soren> mathiaz: Oy, great timing!
[04:29] <soren> mathiaz: You tested the new dovecot version, did you not?
[04:29] <mathiaz> soren: mornin' - I knew it :)
[04:30] <mathiaz> soren: I've tested the upgrade.
[04:30] <pitti> hi mathiaz
[04:30] <mathiaz> soren: but not the functionalities - why ?
[04:30] <mathiaz> hi pitti
[04:30] <soren> mathiaz: Rock. I've fixed the "protocols = none" bug and redid the post{inst,rm} stuff to do what we agreed would be best.
[04:30] <soren> mathiaz: Because pitti just asked :)
[04:31] <mathiaz> soren: I think there is a small testcase in the security test package
[04:31] <mathiaz> soren: to test that dovecot is working correctly.
[04:31] <soren> "the security test package"?
[04:31] <pitti> cjwatson: is the installation step where "additional packages" are installed (like update-manager-core and fuse) still covered by base-installer?
[04:32] <mathiaz> soren: sftp://rookery.ubuntu.com/home/pitti/bzr/package-tests/
[04:35] <pitti> cjwatson: ah, ignore my previous question; that can't be it
[04:35] <soren> mathiaz: Oh.
[04:37] <TomaszD> pitti, after the latest updates r-m is still in English, I thought this was fixed?
[04:37] <pitti> TomaszD: there is no update yet; the langpack export is still going
[04:37] <TomaszD> pitti, alright.
[04:38] <pitti> mathiaz, soren: NB that dovecot has an autopkgtest
[04:39] <pitti> mathiaz, soren: pretty much the one like in my package-tests branch
[04:40] <soren> pitti: When is that run? At build time?
[04:41] <mathiaz> soren: yes.
[04:41] <sabdfl> mjg59: modem is switched on in BIOS, yes
[04:41] <sabdfl> i'll file a new bug
[04:41] <sabdfl> i wonder if we can close some of the older kernel ALSA bugs?
[04:41] <pitti> soren: you have to invoke it manually
[04:42] <sabdfl> they are all either wontfix, or fixed, or invalid i assume
[04:42] <mathiaz> pitti: aren't they run automatically on the buildd ?
[04:42] <pitti> no
[04:42] <pitti> it's still a separate entity on iwj's
[04:44] <Hobbsee> sabdfl: didnt mean to scare you off :P
[04:45] <soren> pitti: They all fail.. Hm.. That can't be good :)
[04:45] <\sh> so...time to go to another interview...new job I'm coming, or not
[04:45] <pitti> soren: did you run them as root?
[04:46] <pitti> soren: they assume that you have a pristine installation
[04:46] <pitti> soren: and the default configuration changes might need an update of the test suite
[04:46] <pitti> soren: I suggest running the test on the current gutsy version first
[04:46] <pitti> for compariso
[04:46] <pitti> n
[04:47] <soren> pitti: I'm running it in schroot
[04:47] <soren> pitti:  I'll see how it works on current version.
[04:47] <pitti> not sure if that works
[04:51] <soren> note to self: Don't have a proper dovecot running while trying to do dovecot testing inside schroot.
[04:52] <lool> iwj: Heya, if you're subscribed to ubuntu-desktop, do you think you could offer some suggestions on the topic of search engines enabled in deskbar-applet?  (Re: bug #131182)
[04:52] <ubotu> Launchpad bug 131182 in deskbar-applet "search applet has inconsidered list of searches" [Medium,Confirmed]  https://launchpad.net/bugs/131182
[04:54] <cjwatson> pitti: no, that's pkgsel
[04:55] <pitti> cjwatson: anyway, /target/dev/disk was bind-mounted at that time still, so that's not it
[04:55] <pitti> cjwatson: it works fine when the kernel is retrieved and installed, and the later run for fuse ruins it
[04:55] <pitti> still debugging, if I could ever get 30 minutes without interruption :)
[04:56] <Hobbsee> pitti: try /quit.  solves all.
[04:57] <StevenK> Turn off the phone, tell your wife you're dead and quit IRC. Problem solved.
[04:59] <soren> pitti: Yay, all the tests pass.
[05:02] <BenC> sabdfl: We have an entire backport of alsa 15rc3 going into linux-backports-modules
[05:03] <Hobbsee> BenC: what's your opinion on https://launchpad.net/bugs/130208 (apoligies if you'v ealready seen ti)
[05:03] <ubotu> Launchpad bug 130208 in linux-restricted-modules-2.6.22 "package nvidia-glx None failed to install/upgrade: subprocess post-removal script returned error exit status 2" [Undecided,Confirmed] 
[05:03] <BenC> sabdfl: I can get you a .deb to test if you want
[05:03] <StevenK> BenC: I've got a quick question, if you have a moment?
[05:03] <BenC> StevenK: sure
[05:03] <BenC> Hobbsee: checking...
[05:03] <StevenK> (It's 1am, but what the hell)
[05:04] <ivoks_wii> BenC: i think nvidia-glx-new and nvidia-settings both have /usr/bin/nvidia-settings, but don't conflict as packages
[05:04] <StevenK> BenC: I've packaged up the virtualbox-ose modules in virtualbox-ose-modules that builds vboxdrv.ko for -server and -generic. pitti wanted to get your approval about this approach before approving it out of NEW. Could I get you to check it over?
[05:05] <pitti> cjwatson, soren: re cryptroot> ah, I know what's wrong; in the d-i environment, /dev/disk/by-uuid/ does not have LVM devices
[05:05] <StevenK> BenC: It's built against -13, and I'm happy to do the hard yards for any ABI bump during Gutsy, I just need to be pinged and told about it.
[05:05] <BenC> StevenK: it's going to suck because it'll need re-upload on -security ABI bumps
[05:05] <StevenK> BenC: ^ :-)
[05:06] <BenC> StevenK: ah, sounds good then :)
[05:06] <pitti> BenC: good morning
[05:06] <BenC> StevenK: if we have to ping you, then we might as well do the upload :)
[05:06] <BenC> pitti: hey
[05:06] <soren> pitti: So why doesn't it fail until fuse is being installed?
[05:06] <BenC> ivoks: sounds like a conflict is needed between them
[05:06] <StevenK> BenC: To be honest, it would be s/-13/-14/ in control, rules adding a changelog entry and uploading.
[05:06] <ivoks> BenC: yes, -new lacks Conflict: nvidia-settings
[05:06] <pitti> soren: the trick with the .bak is that this initramfs only has the swap device
[05:07] <StevenK> I could be convinced to just get that down to control. :-)
[05:07] <pitti> soren: it doesn't actually have the root device
[05:07] <soren> pitti: I'm not sure how that answers my question.
[05:07] <pitti> soren: fortunately this is not even necessary, due to the udev magic we have nowadays; but at least one of them need to be mentioned
[05:07] <BenC> StevenK: yeah, but we already have 5 packages to do that with...you'd need to just check on such things
[05:07] <pitti> soren: and the entire thing breaks if swap and root are not on the same LVM
[05:07] <pitti> soren: I do not yet know why it breaks further (your actual question)
[05:08] <soren> pitti: You mean vg?
[05:08] <pitti> soren: yeah
[05:08] <soren> Ok.
[05:08] <StevenK> BenC: Fair enough, I can just bug pitti/kees about what to do when -security does an ABI bump.
[05:08] <StevenK> BenC: If you're okay breaking it with -security uploads, I'm happy enough to fix it and slam bugs shut.
[05:08] <cjwatson> pitti: by-uuid> why's that?
[05:09] <pitti> cjwatson: I have no idea
[05:09] <BenC> happy happy
[05:09] <pitti> cjwatson: but it doesn't look like any trivial fix any more
[05:09] <BenC> new lum uploaded with fixed unionfs
[05:09] <StevenK> BenC: Cool.
[05:09] <StevenK> BenC: Er, wait, was that 'happy happy' directed at my conversation? :-)
[05:10] <pitti> BenC: ooh
[05:10] <soren> BenC: Just now? Did you happen to see my mail to kernel-team about half an hour ago?
[05:10] <BenC> StevenK: you're good with that package, as long as I don't get blamed for it breaking :)
[05:10] <BenC> soren: no
[05:10] <StevenK> BenC: Works for me. :-)
[05:10] <pitti> BenC: and with rolled-back apparmor? or what's the current approach for that?
[05:10] <StevenK> pitti: Can you NEW it? *flutters eyelashes* :-)
[05:10] <bdmurray> Keybuk: I use triaged to mean that all the documented debugging information for that package / area has been gathered and that the bug should be looked at by a developer.
[05:11] <BenC> pitti: no, this is just a unionfs-1.4 (reverted from 2.1) to work with current apparmor
[05:11] <BenC> pitti: no other changes needed
[05:11] <pitti> BenC: oh, and that's it? great
[05:11] <soren> BenC: Could you take a look? Pretty, please?
[05:11] <BenC> soren: sure, I thought someone had put it in
[05:11] <soren> BenC: Yes, me too :)
[05:15] <pitti> cjwatson: oooh, I just noticed that there are UUIDs in /dev/disk/by-id/dm-uuid-LVM-<something strangely encoded that is not an UUID>; how weird
[05:15] <pitti> the <something strange> could be the base64 encoding of an UUID
[05:16] <pitti> well, I think I give up at this point
[05:17] <pitti> this isn't anywhere near trivial any more
[05:17] <Keybuk> bdmurray: ah, that explains it then
[05:17] <Keybuk> I use "Confirmed" for that :)
[05:17] <Keybuk> "Triaged" to me means that there's enough information in the bug to fix it
[05:17] <Keybuk> (Confirmed being enough information to replicate it)
[05:19] <sabdfl> BenC: seems like sound is the #1 issue reported against the kernel
[05:19] <bdmurray> Keybuk: Do you have a bug that you would consider Triaged?  I'm curious to see one with your criteria.
[05:20] <Keybuk> not off-hand
[05:20] <StevenK> pitti: Could I beg you to NEW virtualbox-ose-modules at your leisure? Maybe even binary NEW it when it builds on amd64 and i386?
[05:20] <Keybuk> I've got lots which should only be Confirmed :)
[05:21] <pitti> StevenK: yep, in a minute
[05:21] <StevenK> pitti: Sure, thanks.
[05:21] <BenC> sabdfl: it always is...stock alsa in the kernel is always way behind upstream :/
[05:21] <Keybuk> e.g. any of the fsck/swap issues -- we have lots of information and can repeat the problem in vmware and see the bug
[05:21] <Keybuk> but we have no idea what causes it
[05:21] <Keybuk> at the point we know, I'd use the higher status
[05:21] <Hobbsee> Keybuk: introduce YALPS!
[05:22] <Hobbsee> Keybuk: ("Yet Another Launchpad Status")
[05:22] <Keybuk> so to me, that's Confirmed because we've confirmed the bug exists and is replicable -- but not Triaged, because we don't know what's wrong with it
[05:22] <BenC> sabdfl: cherry picking individual fixes is way too time consuming, which is why we're opting for a linux-backports-modules of the current alsa for people that want to install it
[05:22] <Keybuk> otherwise if that's Triaged, it's not clear to be what Confirmed is for
[05:22] <Keybuk> since that should be the same as New?
[05:22] <Hobbsee> Keybuk: others can reproduce it / it is reproducible
[05:22] <Hobbsee> or so the logic goes, anyway.
[05:22] <cjwatson> the distinction as I've heard it explained is that Confirmed means that somebody can reproduce it, and Triaged means a developer can reproduce it
[05:23] <cjwatson> which is, I concede, a non-trivial distinction (often reproducing a problem is 90% of the way to solving it)
[05:23] <StevenK> Which is oh so clear from the name.
[05:23] <cjwatson> but it's not clear that it's exactly what we want
[05:23] <Hobbsee> just blame sabdfl.
[05:23] <Amaranth> cjwatson: I thought Confirmed was we can reproduce, Triaged means we know what's wrong, In Progress means we're working on a fix
[05:23] <Keybuk> Amaranth: that's how I try and use them
[05:23] <StevenK> That way makes sense to me.
[05:24] <Keybuk> (Triaged but not yet In Progress bugs being good things for other people to pick up, since there's everything they need except the actual patch)
[05:24] <Hobbsee> although that does cause trouble for the bug triagers, i concede
[05:24] <sabdfl> kiko produced this: http://news.launchpad.net/general/of-bugs-and-statuses
[05:25] <Hobbsee> sabdfl: yes.  havent you seen the mailing list thread after it?
[05:25] <sabdfl> which doesn't really do as neat a job of confirmed vs triaged as Amaranth did above
[05:25] <sabdfl> Hobbsee: i've heard of this thread
[05:26] <sabdfl> BenC: why don't we generally go with upstream alsa, rather than putting it in backports?
[05:26] <Hobbsee> sabdfl: then you'd know that there's reasonable amounts of disagreement and discussion about the statuses :0
[05:26] <bdmurray> I think it will become much harder for a triager to determine when a bug is triaged.
[05:26] <pitti> Keybuk: any idea how to interpret "/dev/disk/by-id/dm-uuid-LVM-KJO4ugYyA4nFPEw5btZXayQjDRI8VPeP" ?
[05:26] <bdmurray> And the concept behind the extra status was to offload some work from developers.
[05:26] <BenC> sabdfl: if we had done it in time (for testing), I'd be happy to put it into linux-ubuntu-modules, but it's too late now
[05:27] <Keybuk> pitti: devmapper device with the devmapper UUID LVM-KJO4ugYyA4nFPEw5btZXayQjDRI8VPeP
[05:27] <pitti> Keybuk: ah, that's from 65-dmsetup.rules:ENV{DM_UUID}=="?*", SYMLINK+="disk/by-id/dm-uuid-$env{DM_UUID}"
[05:27] <BenC> sabdfl: I've never liked the idea of tracking such a huge set of modules out-of-tree, but things the way they are, we made this last minute decision to handle it this way
[05:27] <Keybuk> pitti: right
[05:27] <BenC> sabdfl: probably be something we do from the start past gutsy
[05:27] <Keybuk> it's part of an LVM wotsit
[05:28] <Keybuk> LVM passes in the LVM UUID when it sets up the device
[05:28] <Keybuk> probably the VG UUID
[05:28] <Keybuk> (rather than the UUID of the filesystem *inside* the VG)
[05:28] <pitti> Keybuk: so, I wonder why I don't get proper /dev/disk/by-uuid/ in the installer for LVMs
[05:28] <Amaranth> bdmurray: I honestly get annoyed with someone other than me or mvo sets a compiz bug to triaged
[05:28] <cjwatson> bdmurray: which in many cases is a bit misguided anyway - until developers can count on 100% triaging coverage, they'll often look at everything coming in anyway :-)
[05:28] <Keybuk> pitti: no filesystem UUID available at the point the device is created?
[05:28] <Keybuk> pitti: e.g. because it's formatted after being set up? :p
[05:28] <cjwatson> (not that it's not a noble goal)
[05:28] <Amaranth> bdmurray: It seems like the QA team just assumes valid output from apport is enough to mark a crash bug as triaged
[05:28] <pitti> Keybuk: that's most likely
[05:28] <BenC> sabdfl: kind of the obvious thing when most sound bug reports end with "it works with current alsa" :)
[05:29] <cjwatson> BenC: didn't we have to back out current alsa because it regressed a bunch of intel chips?
[05:29] <pitti> Keybuk: can it be poked somehow? (udevtrigger doesn't)
[05:29] <cjwatson> or did I misunderstand that reversion?
[05:29] <Keybuk> pitti: udevtrigger should poke it
[05:29] <Keybuk> though you might have to poke something surprising
[05:29] <Keybuk> echo -n change > /sys/block/dm-NN/uevent
[05:29] <Keybuk> ?
[05:29] <BenC> cjwatson: we backed out snd-hda-intel because of that...we couldn't just include that one module without a lot of core alsa API changes
[05:29] <pitti> Keybuk: ah, wait, i was still in chroot /target
[05:30] <BenC> cjwatson: hence the reason for doing a full backport
[05:30] <pitti> Keybuk: yes, udevtrigger in the outside chroot did the trick
[05:30] <cjwatson> BenC: oh, it was because we tried to pick and choose? ok
[05:30] <bdmurray> cjwatson: Right, but the triaged bugs should be a better starting point.
[05:30] <BenC> cjwatson: right
[05:30] <cjwatson> bdmurray: yeah, it depends on the time of the release cycle
[05:30] <pitti> Keybuk: thanks
[05:30] <cjwatson> bdmurray: early on that makes sense - near the end response time is key
[05:30] <BenC> snd-hda-intel is the fastest moving target in alsa
[05:31] <BenC> all the new codecs and wiring for every freaking new laptop ever made (AMD and Intel)
[05:31] <BenC> snd-hda-intel needs to be renamed to snd-hda...nothing Intel specific about it
[05:31] <bdmurray> Amaranth: What detailed output should the QA team be looking for to distinguish between a crash report that should be Triaged vs one that is Confirmed?
[05:32] <Amaranth> bdmurray: I think it'd require knowledge of the compiz code for compiz bugs
[05:32] <Amaranth> bdmurray: For other packages I dunno, I don't know their code :P
[05:33] <bdmurray> Amaranth: Then it seems to me that we have limited the work the QA team can do if all compiz crashes should be confirmed.
[05:33] <cjwatson> bdmurray: my understanding of http://news.launchpad.net/general/of-bugs-and-statuses is that the QA team shouldn't generally set Triaged?
[05:33] <cjwatson> (which makes it a very misleading status name, but ...)
[05:34] <Keybuk> bdmurray: what work do you do on other packages to distinguish between Confirmed and Triaged?
[05:34] <Keybuk> do you have any examples how you differ the statuses?
[05:34] <Amaranth> Confirmed should be locked so users can't confirm their own bugs
[05:34] <Amaranth> That is so annoying
[05:35] <StevenK> It's much better when people file -uvf reports, and then another person "Hey, wow, great! I want this, so I'm going to set to Confirmed" - which for a motu-uvf request means "Two people have looked at this and rubber stamped it"
[05:35] <Hobbsee> Keybuk: the equivalent of the australian decision dice
[05:36] <bdmurray> Keybuk: because anybody can confirm the bug it is possible that someone may have confirmed an X bug without obtaining the necessary log and configuration files.  So after confirming that everything is there and that the reporter is not making a mistake I would set the status to triaged.
[05:36] <Kopfgeldjaeger> pitti: any progress with the cryptsetup stuff? can i help you somehow?
[05:37] <soren> pitti: So, the dovecot update passes the tests (when the person doing the tests is not an idiot), and I've tested the dovecot-{pop3,imap}d.post{inst,rm} magic quite a bit. What else do I need to do?
[05:37] <Keybuk> bdmurray: so if use of Confirmed was limited to members of qa, assignee or package contacts - that would solve the problem?
[05:37] <bdmurray> cjwatson: I disagree with what kiko wrote up about triaged
[05:37] <Amaranth> bdmurray: I suppose Triaged could mean "the QA team thinks this has enough info" then I could bounce the bug through Incomplete or Confirmed as needed
[05:38] <Keybuk> (or we need YALS between Triaged and In Progress ... maybe "Understood"?)
[05:38] <bdmurray> Keybuk: I don't think limiting the way people can help out even more is the solution
[05:38] <pitti> Kopfgeldjaeger: I have another attempt in the pipeline
[05:38] <Keybuk> bdmurray: my concern is that there doesn't appear to be any difference between those two Statuses
[05:38] <Keybuk> can anyone set Triaged?
[05:38] <pitti> soren: sounds fine
[05:39] <Hobbsee> Keybuk: no
[05:39] <Amaranth> Keybuk: no
[05:39] <Keybuk> who is it limited to?
[05:39] <Hobbsee> ubuntu-q
[05:39] <Hobbsee> a
[05:39] <Keybuk> Hobbsee: can the assignee or package contacts set it?
[05:39] <Hobbsee> no idea, tbh
[05:39] <Amaranth> Which is somewhat annoying, I joined the QA team just so I could manage compiz bugs
[05:39] <bdmurray> I don't think so
[05:39] <Keybuk> hmm
[05:39] <Hobbsee> Keybuk: the package contacts cant select importance, so i doubt they can do that either.  apparently that's a lp "feature" - although i've long debated how it isnt.
[05:40] <Hobbsee> (there's a bug open, but little to no progress on it)
[05:40] <mvo> glatzor!
[05:41] <bdmurray> Amaranth: In regards to has enough info yes.  If there wasn't enough info than debugging documentation for the QA team needs to be improved.
[05:41] <Kopfgeldjaeger> pitti: um... hum? im not thaat familar with english phrases :/
[05:41] <glatzor> evening mvo!
[05:41] <Amaranth> bdmurray: I can just say generically "these things are useful" but then some bug report comes that needs some very specific info
[05:41] <cjwatson> Kopfgeldjaeger: "in the pipeline" => "on its way"
[05:41] <Amaranth> bdmurray: Or would you rather waste time getting all possible stuff from the user at once even though almost none of it gets used?
[05:42] <pitti> Kopfgeldjaeger: I'm on it
[05:42] <Riddell> heno: how was your kubuntu upgrade?
[05:42] <Amaranth> We need something like bug buddy's scripting
[05:42] <cjwatson> there is a point when QA debugging shades over into "developer needs to sit and stare at the code and then ask the user very specific questions to try to isolate codepaths"
[05:42] <bdmurray> Amaranth: I think getting what is necessary most of the time is appropriate it.
[05:43] <Amaranth> So if you file a bug on a certain package it can have a script associated with it that apport runs to collect package-specific info automatically
[05:43] <Kopfgeldjaeger> ok, thanks ;)
[05:43] <cjwatson> which I don't think indicates that the documentation needs to be improved
[05:43] <bdmurray> cjwatson: absolutely, I meant that if there is a trend of bugs being incorrectly triaged
[05:44] <cjwatson> right ...
[05:45] <glatzor> mvo: sorry, but I cannot come to the ubucon, since I have got night shift before :/
[05:45] <bdmurray> Amaranth: apport does have per-package hooks for crash reports
[05:47] <Amaranth> bdmurray: Oh? I need to figure out how to write one of those
[05:47] <mvo> glatzor: oh :/
[05:47] <Amaranth> bdmurray: Although I suppose it's not as nice as 'attach this file to the bug report'
[05:49] <bdmurray> Amaranth: I'm not sure what you mean but it auto uploads whatever files you want
[05:50] <Amaranth> bdmurray: ah, cool
[05:50] <bdmurray> For ubiquity it grabs stuff like /var/log/partman
[05:50] <Amaranth> I'll just setup apport to upload files for all the info we need from a crash report then
[05:50] <bdmurray> Amaranth: That'd be great
[05:51] <mathiaz> Keybuk: During an upgrade to gutsy with update-manager yesterday, I was hit by bug 115616.
[05:51] <ubotu> Launchpad bug 115616 in evms "Device-mapper errors: dm-linear, lookup failed" [High,Fix released]  https://launchpad.net/bugs/115616
[05:51] <heno> Riddell: not so good. I'm filing a bug
[05:52] <mathiaz> Keybuk: However update-manager never prompted me to remove the evms package (which I did afterwards).
[05:52] <mvo> mathiaz: could you please put your /var/log/dist-upgrade/* files somewhere?
[05:53] <mathiaz> mvo: sure.
[05:54] <mathiaz> mvo: The reason I think is bebause there was a failure on python-apt.
[05:54] <bdmurray> heno: Just one - that's good. ;)
[05:54] <mvo> mathiaz: that would a error with dpkg-querry form pycentral I guess?
[05:54] <mvo> mathiaz: anyway the logs are interessting
[05:54] <heno> bdmurray: yeah, just crashed once
[05:55] <mathiaz> mvo: yes.
[05:55] <mathiaz> mvo: http://people.ubuntu.com/~mathiaz/dist-upgrade/
[05:55] <mvo> mathiaz: checking, thanks
[05:56] <mathiaz> mvo: let me know if you need something else.
[05:59] <Riddell> bdmurray: can you give me sru verification on 117731?
[06:00] <bdmurray> Riddell: I'm working on that I am downloading a Kubuntu Feisty image
[06:01] <Pierre> Hi
[06:01] <Pierre> http://pierre.libgd.org/update_gusty_bug_size.png
[06:02] <Amaranth> mvo: looks like the size calculation is a little screwy
[06:02] <Pierre> the required size in /boot was first 115MB, then I removed 2.6.17 and now I still have this error, but different size
[06:03] <mvo> Pierre: looks not too bad to me, what do you have still installed in /boot
[06:03] <Pierre> nothing but feisty stuff
[06:03] <mvo> Pierre: i mean, how many kernels
[06:04] <mvo> Pierre: it looks like all that is needed is to remove one old feisty kernel
[06:05] <heno> Riddell, mvo: bug 150162
[06:05] <ubotu> Launchpad bug 150162 in update-manager "update-manager feisty-> gutsy besta failed with instruction" [Undecided,New]  https://launchpad.net/bugs/150162
[06:05] <pitti> yay!
[06:05] <pitti> soren, cjwatson: got it!
[06:05] <soren> pitti: What was/is it?
[06:05] <Pierre> mvo: trying
[06:05] <pitti> soren: calling udevtrigger did the trick
[06:05] <mvo> heno: thanks, Failed to fetch http://wine.budgetdedicated.com/apt/dists/feisty/main/binary-i386/Packages.gz 403 Forbidden
[06:05] <Pierre> mvo: but still looks weird :)
[06:05] <soren> pitti: That's... odd, isn't it?
[06:06] <mvo> Pierre: what exactly? the error message, the fact that it requires this amount of memory?
[06:06] <Pierre> mvo: both
[06:06] <heno> mvo, Riddell: woops. it's bug 150612
[06:06] <ubotu> Launchpad bug 150612 in update-manager "[kubuntu]  Method http has died unexpectedly" [Undecided,New]  https://launchpad.net/bugs/150612
[06:06] <iwj> lool: I'm not subscribed to ubuntu-desktop right now but I'll reply anyway.  Thanks, and sorry for the delay.  (I've been struggling with rsync this afternoon.)
[06:06] <Pierre> mvo: notice the background, df -h was run, the /boot partition is 95MB
[06:07] <Pierre> mvo: the 1st error asked me to free 115MB there
[06:07] <pitti> soren: no, it isn't actually; the devices are formatted after creating them
[06:07] <Riddell> heno: that's a new one to me
[06:07] <Riddell> heno: did your network go down?
[06:07] <soren> pitti: so why does the .bak work?
[06:08] <mvo> Pierre: there may be a error left in the size calculation, if file a bug, please include "ls -l /boot " and df -h and the file in /var/log/dist-upgrade/main.log
[06:08] <Pierre> mvo: but removing one more old kernel did it. Amaranth is right, it is only about the size calculation being wrong :)
[06:08] <heno> Riddell: not that I know. It works now. How could I check?
[06:08] <pitti> soren: that bit is still a mystery to me
[06:08] <Pierre> mvo: ok
[06:08] <Pierre> Amaranth: mvo: thx for the help
[06:08] <Pierre> upgrading, bbl :)
[06:08] <mvo> Pierre: each kernel requires ~10mb for its initramfs, on update each already existing initramfs gets backed up (that requires an additional 10mb)
[06:09] <Riddell> heno: dunno, try it again maybe
[06:11] <heno> Riddell: ok, I have the system up now. Any logs I should gather before rolling it back to try again?
[06:11] <soren> pitti: Ah, ok.
[06:11] <heno> so network activity logs?
[06:11] <heno> *some
[06:11] <soren> bbia few hours.
[06:12] <mathiaz> soren: thanks for the dovecot upload
[06:12] <mathiaz> soren: do you think it's worth forwarding to debian ?
[06:12] <soren> mathiaz: Thanks for doing most of the work :)
[06:12] <pitti> soren: I prepare an updated base-installer and do a full test install including UI, for final testing
[06:12] <soren> mathiaz: Yes, very much so.
[06:12] <Riddell> heno: don't think so, mvo might know
[06:12] <soren> pitti: Rock!
[06:12] <mathiaz> soren: I'll look into that then.
[06:16] <bdmurray> mvo: I had an automatic crash report when updating Edubuntu to Gutsy regarding gaim-data however apport would not let me report because it was about and invalid version.  Is that something you would want to look at?  If so which information would you want?
[06:17] <pitti> mvo: is the update-notifier "disable apport" still on your list, or shall I do it?
[06:20] <mvo> bdmurray: the files in /var/log/dist-upgrade/* would be the ones i'm interessted in
[06:21] <bdmurray> mvo: okay, the apport crash report is unnecessary?
[06:21] <mvo> bdmurray: as far as I'm concerned yes, the logs contain all interessting bits
[06:21] <pitti> cjwatson, soren: I attached a base-installer debdiff to bug 144390; WDYT?
[06:21] <ubotu> Launchpad bug 144390 in debian-installer "use entire disk with lvm/encrypted partitioning fails to boot" [Undecided,In progress]  https://launchpad.net/bugs/144390
[06:22] <lool> iwj: No problem; as you're the person who brought this up, I thought you might have some ideas on how to best handle this
[06:24] <cjwatson> pitti: I would prefer bind-mounting all of /target/dev rather than just .../disk
[06:24] <cjwatson> pitti: there's some tab/space damage in there too
[06:24] <cjwatson> pitti: also please commit that to bzr if you upload it
[06:24] <pitti> cjwatson: XS-Vcs-Svn: svn://svn.debian.org/d-i/trunk/packages/base-installer
[06:24] <pitti> hmm
[06:25] <cjwatson> pitti: but I'm OK with it; I think it's a bit weird that udev doesn't notice the partitioning stuff for itself, I thought we already told it to update, but whatever
[06:25] <mvo> heno: re #150612> was a crash file produced? did you hit ctrl-c by any chance ;) ?
[06:25] <pitti> cjwatson: all of /dev/ seems more intrusive, but it does make some sense, yes
[06:25] <cjwatson> pitti: yeah, it's wrong, I'll fix it after gutsy
[06:25] <cjwatson> bzr+ssh://bazaar.launchpad.net/~ubuntu-core-dev/base-installer/ubuntu
[06:25] <pitti> cjwatson: thanks
[06:25] <cjwatson> it's more intrusive, but it also feels less likely to break than bind-mounting just a bit of /dev
[06:25] <pitti> cjwatson: ok, I do a test with bind-mounting the full /dev
[06:25] <pitti> and fix the tabs
[06:27] <heno> mvo: I did hit 'Right-ctrl' at some point which is the key used to recapture focus from vbox
[06:30] <heno> mvo: there is indeed a crash file. attached
[06:30] <mvo> heno: cool, thanks
[06:31] <heno> or, will be soon
[06:32] <pitti> cjwatson: thanks for review; new patch attached (now with UNRELEASED, will commit to bzr and fix once my test finished)
[06:32] <mvo> heno: I have a idea what might have caused this. the interessting questions is what triggered it for you and why I have not seen it myself yet
[06:32] <glatzor> thanks riddell for guidance
[06:34] <cjwatson> pitti: looks good
[06:34] <heno> mvo: ok. crash log really attached now
[06:35] <heno> annoying that the crash log is only readable by root, so you have to chown or chmod to upload it
[06:36] <pitti> cjwatson: thanks
[06:37] <mvo> pitti: will the apport retracer pick up a manually uploaded crash file (bug #150612) automatically?
[06:37] <ubotu> Launchpad bug 150612 in update-manager "[kubuntu]  Method http has died unexpectedly" [Undecided,New]  https://launchpad.net/bugs/150612
[06:37] <pitti> mvo: unfortunately not
[06:38] <pitti> mvo: you have to pipe them through the UI once, since they are incomplete otherwise
[06:38] <pitti> mvo: and that one doesn't have a core dump, so no retracing possible
[06:39] <bdmurray> mvo: it is bug 150626
[06:39] <ubotu> Launchpad bug 150626 in update-manager "gaim-data failed to upgrade during dist upgrade of Edubuntu to Gutsy" [Undecided,New]  https://launchpad.net/bugs/150626
[06:39] <mvo> pitti: no? http://launchpadlibrarian.net/9883209/_usr_lib_apt_methods_http.0.crash <- that one seems to have a field CoreDump
[06:40] <rexy_> tepsipakki: i tried the ati-update for this morning, it fixed the garbled screen for me but it still has some issues, crash on relog via gdm/compiz , not sure where on LP to file that under and what info to attach?
[06:40] <heno> mvo: another data point I had had kde sticky keys turned on, which is not so common, and may have done unpredictable things with Ctrl+<other key> when combined with vbox
[06:40] <pitti> mvo: right, I missed that
[06:40] <mvo> pitti: heno had the bug, I would love to get the full backtrace, will it be enough if he calls /usr/share/apport/apport-gtk?
[06:40] <pitti> mvo: yes; you can call it with -c /path/to/crash/file, or touch the .crash file to get the UI again
[06:41] <pitti> mvo: I think I'll do the update-notifier change now, if you are fine with that?
[06:41] <mvo> heno: ----^ could you please do that ?
[06:41] <mvo> pitti: new update-notifier is already uploaded
[06:41] <heno> do I need to install that first (this is kubuntu)
[06:41] <pitti> mvo: oh, you rock
[06:41] <heno> ?
[06:41] <pitti> heno: s/gtk/qt/ will work, too
[06:41] <heno> ok, cool
[06:42] <pitti> Riddell: can you please change adept-notifier to not report apport crashes by default?
[06:44] <heno> pitti: where do I find the output of that? (I doesn't offer to upload it)
[06:44] <pitti> heno: oh, that's strange; what does it say?
[06:45] <heno> pitti: nothing at all
[06:45] <pitti> heno: you might alternatively try apport-cli -c /path/to/crash/file if the Qt UI is broken somehow
[06:45] <pitti> heno: did you call it with -c? or without arguments?
[06:45] <heno> ok
[06:45] <iwj> lool: cat -> pigeons, thanks.
[06:46] <heno> pitti: ok, let me retry, sorry
[06:46] <pitti> heno: if you call it without arguments, you need to touch the .crash file before
[06:46] <pitti> heno: (and then apport shuold come up automatically)
[06:48] <pitti> seb128: ah, interesting feedback on bug 133567
[06:48] <ubotu> Launchpad bug 133567 in linux-source-2.6.22 "nautilus hangs on accessing vfat drives - statfs() blocks for a long time" [Medium,Confirmed]  https://launchpad.net/bugs/133567
[06:48] <seb128> pitti: indeed
[06:48] <pitti> seb128: so let's revert the natuilus hack, and instead I'll fix hal to use that option instead maybe?
[06:49] <seb128> pitti: that looks like a good idea yet
[06:49] <seb128> yes
[06:50] <heno> mvo, pitti: here we are; bug 150630
[06:50] <ubotu> Launchpad bug 150630 in apt "[apport]  http crashed with SIGSEGV in __kernel_vsyscall()" [Undecided,New]  https://launchpad.net/bugs/150630
[06:55] <pitti> cjwatson: argh, I'm a muppet; unmounting /dev in install_extras() is too early, since as you said, those extra packages are installed later
[06:55] <pitti> cjwatson: so we either move that to a different place, or not unmount it at all?
[06:58] <tepsipakki> rexy_: search x-x-v-ati bugs if you find a match.. we will clean it up after gutsy has been released, and forward upstream those that are valid
[07:03] <lool> iwj: I'm afraid i'll need help decoding "cat -> pigeons"; I like Agatha Christie, but I'm not sure I'm making the right connection
[07:03] <iwj> I have put the cat amongst the pigeons.  It's a metaphor for err, stirring up a hornets nest.
[07:04] <iwj> Saying or doing something likely to cause commotion etc.
[07:04] <iwj> You'll see what I mean when you read my message ...
[07:04] <lool> Ok; I tried googling for the expression, but I'm afraid Google isn't of much help to improve one's english
[07:04] <lool> *English
[07:05] <lool> Perhaps Amazon.com, Answers.com, Yahoo.com or Wikipedia would be better?  ;-)
[07:05] <mc44> lool: urbandictionary.com ;)
[07:05] <lool> mc44: That's not included in Firefox or deskbar-applet!
[07:08] <pitti> cjwatson: new patch attached, take III
[07:12] <pkern> mjg59: The "disable the fglrx module" is not a viable workaround. IMHO 2d rendering got significantly worse and I *think* I had xvideo before.
[07:12] <iwj> lool: ROTFL
[07:12] <mjg59> pkern: Shrug.
[07:13] <mjg59> Little we can do at this point.
[07:13] <pkern> I still don't get why a SLAB flavour was refused but I don't think it's a pleasure to run Gutsy on >R5xx at this point but well.
[07:13] <Riddell> heno: install what?
[07:13] <pkern> There is still no official response from the kernel team.
[07:14] <pkern> Which makes me sad too.
[07:14] <mjg59> pkern: Because a SLAB flavour would be insane
[07:14] <rexy_> tepsipakki: am looking at it, noticed you reffered me to 150278, so i'll post there.
[07:14] <iwj> lool: Anyway, I have to go and find my dinner now.  I'll keep an eye on that thread.  Thanks for bringing it up.
[07:15] <lool> iwj: bon apptit
[07:15] <pkern> mjg59: At this point: Yeah, probably.
[07:15] <mjg59> No, at any point
[07:15] <pkern> It's not that I hadn't spoke up earlier.
[07:15] <heno> Riddell: hm? context?
[07:15] <pkern> mjg59: Technical point of that?
[07:15] <pkern> mjg59: SLAB ran fine for years.
[07:15] <mjg59> We're not offering multiple flavours based on different memory allocators
[07:16] <Keybuk> linux-image-2.6.22-config-69efa2c20c510e0f0416c9e254c706899cbcefbd
[07:16] <mjg59> The number of flavours we already have is fairly unmanigable
[07:16] <Keybuk> (where the latter is the sha1sum of the config :p)
[07:16] <mjg59> (urgh, spelling)
[07:16] <Hobbsee> bad keybuk!  :P
[07:17] <Keybuk> (that's actually not a bad idea for user-generated kernel images)
[07:18] <StevenK> pitti: virtualbox-ose-modules failed on amd64, and built on i386 - I'll fix it when I wake up and bug you about it when you surface tomorrow.
[07:18] <sladen> Keybuk: config + time_t
[07:18] <pitti> StevenK: that's fine; there's still plenty of time to fix universe
[07:19] <sladen> teach grub about UUIDs, then it can go looking across all the available partitions for a kernel with the right UUID
[07:20] <Riddell> heno: never mind, seems not to have been for me
[07:21] <superm1> cjwatson, I was trying to debug further why BulletProofX wasn't working on the mythbuntu live disks and discussing with bryce a little bit.  It appears that the results from casper-reconfigure xserver-xorg apply fine to the live env's debconf database, but are never replicated over to the resultant system.  Could you speak to what mechanism is supposed to be handling that?
[07:23] <pochu> should I poke anybody if a package in universe failed to build because of unmet dependencies of its build-dependencies? It was when beta, and it should be Ok now.
[07:23] <Hobbsee> pochu: it usually gets given back
[07:23] <pochu> BTW the package is listen, and it built fine on 4 archs, and failed on 3: https://edge.launchpad.net/ubuntu/+source/listen/0.5-4ubuntu3
[07:23] <pochu> Hobbsee: automatically?
[07:24] <Hobbsee> oh, it seems it isnt
[07:24] <pochu> Hobbsee: hppa built fine :p
[07:24] <pochu> Although it's possible it was in DEPWAIT
[07:24] <pochu> dunno why the others weren't
[07:25] <Hobbsee> that's a failed to build.  that's not depwait.
[07:25] <Hobbsee> which means it'll need a manual giveback
[07:26] <Hobbsee> assuming the package isnt broken
[07:26] <pochu> Yeah, but it failed because its build-dependencies couldn't be installed because its dependencies weren't satisfied...
[07:26] <Hobbsee> so the answer is yes, you want to ask for a giveback of listen on {insert arches here}
[07:28] <Hobbsee> you're looking for a buildd-admin
[07:29] <pochu> Hobbsee: should that be enough, or is there any kind of policy such as filling a bug report?
[07:29] <Hobbsee> nah
[07:29] <Hobbsee> no idea if any are around, though
[07:29] <pochu> Mithrandir: ^ if you have a moment. Thanks
[07:32] <Lure> mjg59: what is status of ubuntu-laptop-mode - it wants to remove acpi-support here...
[07:33] <Pierre> mvo: looks like one already met this issue: #104337
[07:34] <Hobbsee> mvo: did you ever end up making the dist-upgrader not upgrade with automatix installed?
[07:34] <mjg59> Lure: Yes. Don't use it right now.
[07:34] <mjg59> I haven't had time to sort that out.
[07:34] <Lure> mjg59: ok, and laptop-mode-tools is still not good, right?
[07:34] <Pierre> mvo: sounds weird that it is seen as a feature request...
[07:35] <Riddell> mvo: is the dist upgrader on the CDs?
[07:35] <mvo> Riddell: yes
[07:35] <mjg59> Lure: laptop-mode-tools is what should be used for the moment
[07:35] <mvo> bug #104337
[07:35] <ubotu> Launchpad bug 104337 in update-manager "[MASTER]  /boot free space check message misleading and space requirement too big" [Low,Fix committed]  https://launchpad.net/bugs/104337
[07:35] <Riddell> mvo: where do I find it?
[07:36] <mvo> Riddell: dists/stable/main/dist-upgrader/binary-all
[07:36] <mvo> iirc
[07:37] <Riddell> mvo: it's not there
[07:37] <mvo> Riddell: only on the altnerative cd
[07:37] <Riddell> mvo: oh, duh, of course
[07:37] <mvo> Riddell: it does not make a lot of sense on the desktop CD because there are no packages (or almost no packages)
[07:38] <Riddell> sure
[07:38] <tepsipakki> rexy_: you had the same symptoms as reported in that bug, but it's already fixed as you said :)
[07:38] <Riddell> mvo: are we going to use meta-release-proposed for RC?
[07:45] <rexy_> tepsipakki: logging out back to gdm crashes X still, it half paints the gdm images but stops
[07:46] <rexy_> simply killing X and restarting it via startx does not have that problem though
[07:46] <rexy_> altough admitedly that's not listed in that bug
[07:46] <pitti> cjwatson, soren: bug updated, this is a mess :/ I demoted partman-auto-crypto again to disable that feature
[07:48] <tepsipakki> rexy_: yes, maybe open a new one then..
[07:48] <tepsipakki> rexy_: and attach xorg.conf, Xorg.0.log and 'lspci -vvnn'
[07:50] <rexy_> tepsipakki: ok, thanx, i'll see if i can find a current bugrp on that or file a new one, thanx
[07:51] <tepsipakki> rexy_: sure, np
[08:14] <mvo> Riddell: that is a good idea, yeah, lets do that
[08:15] <superm1> Riddell, any chance you would be able to pull the fix from svn for this bug: https://bugs.edge.launchpad.net/ubuntu/+source/kde-guidance/+bug/139603 ?  It is causing a few other odd ones to crop up in ubiquity for mythbuntu
[08:15] <ubotu> Launchpad bug 139603 in kde-guidance "installer crashed just after vnc server url return 404 error" [Undecided,New] 
[08:15] <mvo> superm1: sorry that I didn't managed to followup on the install issue with python-apt, what is the current status there?
[08:16] <superm1> mvo, give me a moment to glance back at the code and then i can tell you what we were thinking last
[08:17] <mvo> superm1: so its still a problem?
[08:17] <superm1> mvo,  well a few things.  in short yes
[08:18] <superm1> mvo, if i remove the call for cache.open(None), it appears that things work correctly unless a package really is broken
[08:18] <superm1> mvo, if you look at http://codebrowse.launchpad.net/~ubuntu-installer/ubiquity/trunk/annotate/cjwatson%40canonical.com-20071007200415-j69ftz0zr82h58w4?file_id=copy.py-20051205084030-2802314aaac6fca0 around line 1418
[08:18] <superm1> removing that call for cache.open(None) causes that broken packages list to not populate correctly
[08:18] <superm1> in line 1422
[08:19] <mvo> superm1: yeah, that is sort-of-expected, libapt needs to sync itself with /v/l/d/status after a commit()
[08:19] <superm1> but if i leave the cache.open(None), it has random tendencies to hang still.
[08:19] <mvo> ok
[08:19] <superm1> mvo, so does a sleep need to be put in there for some length of time?
[08:19] <superm1> to work around that, or is there a call to wait for?
[08:23] <mvo> superm1: out of curiosity, could you try to replace "cache.open(None)" with "cache = apt.Cache()" ?
[08:23] <Keybuk> doko: err, is python-mode bust or is it just me?
[08:23] <Keybuk> I opened a .py file and it stayed in Fundamental
[08:23] <mvo> Keybuk: you need to purge python-mode
[08:23] <superm1> mvo, not immediately at this moment (i'm on campus), but i'd be glad to when i get home and have access to a VM again
[08:23] <mvo> Keybuk: the latest emacs has a build-in one
[08:24] <superm1> mvo, should that have the same result?
[08:24] <mvo> Keybuk: and they seem to conflicts for some reason
[08:24] <Riddell> superm1: ubiquity uses guidance?
[08:24] <mvo> superm1: yes, I'm curious if you see the hang with this too
[08:24] <doko> Keybuk: emacs22?
[08:24] <pitti> hm, shuoldn't emacs22 Conflicts: python-mode then?
[08:24] <superm1> Riddell, ubiquity-frontend-mythbuntu does.
[08:24] <mvo> superm1: or if it goes away. if so, I have at least a clue where to start debugging
[08:24] <superm1> mvo, i'll check later and catch up with you tomorrow on it then
[08:24] <Keybuk> doko: emacs21-nox
[08:24] <mvo> superm1: sure, thanks
[08:24] <Keybuk> we don't *have* emacs22 do we?
[08:25] <doko> we do
[08:25] <mvo> ignore me then, I was thinking of emacs22
[08:25] <Keybuk> oh, wow
[08:25] <Keybuk> I didn't even know that had been released
[08:25] <doko> well, usually you only need to check for new emacs releases once a decade
[08:25] <Riddell> superm1: interesting.  well that fix has been in the archive for 10 days
[08:26] <superm1> Riddell, hm that is particularly interesting then, because ubiquity on our beta disk was built right about then.  I'll have to check the version of guidance that is on the disk
[08:27] <superm1> Riddell, do you know what version the commit was added offhand?
[08:27] <superm1> Riddell, i'm guessing 0.8.0svn20070928-0ubuntu1
[08:27] <pitti> Keybuk: it's the default for quite some time, and emacs21 is in universe now
[08:27] <Riddell> superm1: yes
[08:28] <pitti> Keybuk: the 'emacs' metapackage pulls it in, too
[08:28] <superm1> Riddell, okay, i'll double check with that tonight
[08:28] <Riddell> mvo: does dist upgrade tool work without an internet connection?  it seems to add feisty-backports as a source
[08:29] <mvo> Riddell: it should work, yes. but only if you use it from the CD, either via "sudo sh /cdrom/cdromupgrade" or when update-notifier ask if you want to perform a upgrade
[08:29] <mvo> Riddell: it will ask you if you want to use network or not in this case
[08:29] <bigon> hi, is it still possible to sync gtk-doc from debian (new upstream version)? I've an issue with the version currently in gutsy and the version of debian fix the problem
[08:32] <RicardoPerez> pitti: hi! is there any way to translate the gnome-access-guide via Launchpad?
[08:35] <sladen> RicardoPerez: is it in gnome-user-docs?
[08:36] <RicardoPerez> sladen: yes, but gnome-user-docs has no templates at all in Launchpad...
[08:36] <RicardoPerez> sladen: see https://translations.launchpad.net/ubuntu/gutsy/+source/gnome-user-docs
[08:38] <superm1> Riddell, actually it looks like our disk was mastered with the newer version.  i'll have to poke around with that bug then and see what else is breaking
[08:38] <superm1> thanks
[08:38] <sladen> RicardoPerez: there's some commentary on http://www.mail-archive.com/launchpad-users@lists.canonical.com/msg02064.html perhaps mdke or the #ubuntu-docs can give you the final outcome
[08:39] <mdke> RicardoPerez: yes, I've been discussing with danilo a way to try and do it but we haven't reached a solution yet
[08:39] <mdke> (thanks sladen)
[08:39] <RicardoPerez> mdke: oh, thanks! I only want to translate one only string: "Assistive Tools", which shows in the Yelp main menu... It's the only untranslated string in the Ubuntu help center
[08:40] <mdke> RicardoPerez: damn, yes
[08:40] <RicardoPerez> mdke: can you include the translation in the final gnome-user-docs?
[08:40] <RicardoPerez> mdke: it's only one string...
[08:41] <RicardoPerez> mdke: my goal is to have the Yelp main string fully translated into Spanish...
[08:41] <mdke> RicardoPerez: it's a worthy goal; I'd like to find a way for each language to do it though
[08:42] <RicardoPerez> mdke: of course, I know that including my string translation as a patch is that... a patch, not a solution
[08:42] <mulima> hi
[08:42] <mulima> i couldn't play mp3 files using gstreamer appz is there a known bug about this issue ?
[08:43] <mulima> i have all gstreamer plugins isntalled and i get this error with totem "Message: don't know how to handle application/x-id3"
[08:43] <mulima> using gutsy
[08:44] <RicardoPerez> mdke: what about send a proposal in ubuntu-translators mailing list in order to get the string "Assistive Tools" translate in the main languages, and then to incorporate the translations directly into the package?
[08:44] <Keybuk> hmm
[08:45] <mdke> RicardoPerez: I'll mail the list in a bit. do you know how to manipulate po files and such?
[08:45] <Keybuk> with emacs22 and no python-mode, I get no indenting
[08:45] <donspaulding> mulima: read the topic, then take that question over to #ubuntu+1
[08:45] <RicardoPerez> mdke: I do that regularly with gtranslator...
[08:45] <mulima> donspaulding, yes sorry
[08:45] <RicardoPerez> mdke: and then to generate the corresponding .mo file with msgfmt
[08:47] <mdke> RicardoPerez: if you do, grab the pot file from http://launchpadlibrarian.net/9836563/gnome-access-guide.pot and the es po file from LP at http://tinyurl.com/2yuggw; merge and send me the updated po file
[08:47] <RicardoPerez> mdke: ok, i'm doing that just now
[08:48] <mdke> apparently diff doesn't work properly on po files, so best just to send me the whole new po file
[08:48] <RicardoPerez> mdke: one question: how can I merge one .pot and one .po files?
[08:48] <mdke> I don't know
[08:49] <RicardoPerez> mdke: ummm, ok, i'm on the way
[08:49] <donspaulding> Keybuk: I was trying to mimic your minimal debian/rules file for a meta package, but debuild keeps failing with the message here: http://pastebin.org/4431
[08:49] <donspaulding> got a minute to take a look?
[08:50] <mvo> heno: if you could test wesnoth again with the latest compiz, that would be cool. please also check if /apps/compiz/general/screen0/options/unredirect_fullscreen_windows is set (gconftool -g /apps/compiz/general/screen0/options/unredirect_fullscreen_windows)
[08:52] <heno> mvo: mind if I check it at the end of my day today? It may well crash my whole world here
[08:52] <Keybuk> donspaulding: why do you have %s in debian/control? :)
[08:53] <ion_> donspaulding: Btw, i implemented the same thing a bit differently: http://codebrowse.launchpad.net/~ion/+junk/ion-meta/files
[08:53] <donspaulding> doh!  I should've seen that, I just thought the error message didn't pick up the character it was choking on correctly, wasn't looking for an actual % sign, sorry.
[08:54] <donspaulding> ion_: I'll take a look
[08:55] <Keybuk> donspaulding: sometimes error messages are helpful, rather than a hinderance :p
[08:56] <donspaulding> yeah, I'm just so used to looking at python tracebacks where error messages complaining about %s really mean they're choking on a variable that was supposed to be in %s.
[08:58] <donspaulding> ion_: where do you end up specifying all the ${ion-base:Depends}  lines at?
[08:58] <ion_> donspaulding: Theyre read by debian/rules from ion-base in the packages root directory.
[08:59] <donspaulding> gotcha, so that way you can just keep a flat text file with all the dependencies, interesting
[08:59] <ion_> Yeah, with comments etc.
[09:01] <donspaulding> ion_: well you just rendered several hours worth of work useless.  thanks for that :-P
[09:03] <RicardoPerez> mdke: i think i have it now
[09:03] <RicardoPerez> mdke: can I send you and try it?
[09:03] <donspaulding> ion_: it's nice how that takes dependencies out of the control file, makes editing them programmatically much easier :-)
[09:03] <mdke> RicardoPerez: alright, tell me how you did it
[09:04] <RicardoPerez> mdke: using the msgmerge tool
[09:04] <RicardoPerez> mdke: msgmerge es.po gnome-access-guide.pot > final.po
[09:04] <RicardoPerez> mdke: and then translating the final.po file using gtranslator
[09:04] <mdke> that sounds right
[09:04] <mdke> RicardoPerez: if it works, I can't promise that the release managers will allow another upload of the package, but we'll try
[09:05] <RicardoPerez> mdke: ok, great!
[09:05] <RicardoPerez> mdke: how can i send you? via email?
[09:05] <mdke> sure
[09:06] <RicardoPerez> mdke: ok, just now
[09:06] <Mithrandir> pochu: given-back
[09:08] <RicardoPerez> mdke: i just email you with the updated es.po
[09:08] <soren> pitti: Aw... I'm really sorry to see it go.
[09:08] <mdke> RicardoPerez: fine, I'll see if it works later
[09:09] <RicardoPerez> mdke: great, email me if there's news :) thanks a lot!
[09:09] <mdke> thanks to you
[09:13] <pochu> Mithrandir: ty
[09:14] <geser> pitti: is it worth to merge libservlet2.4-java 5.0.30-6 right now? it contains a fix for CVE-2007-4724
[09:14] <ubotu> Cross-site request forgery (CSRF) vulnerability in cal2.jsp in the calendar examples application in Apache Tomcat 4.1.31 allows remote attackers to add events as arbitrary users via the time and description parameters. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4724)
[09:17] <cjwatson> superm1: I believe I answered that question a day or two ago; perhaps you missed my reply
[09:18] <superm1> cjwatson, that's possible.
[09:18] <superm1> which channel was it in?  I'll look through logs
[09:18] <cjwatson> superm1: casper/ubiquity-hooks/20xconfig copies /etc/X11/xorg.conf over to the target system. It doesn't copy over the relevant bits of the debconf database because that isn't supposed to be necessary; if not copying bits of the debconf database is causing a problem, then that's a bug
[09:18] <cjwatson> (was approximately my answer from the other day)
[09:19] <superm1> that would be causing a problem (not copying over the relevant bits of debconf).  Since they aren't copied over, any effort to regenerate xorg.conf using dexconf will fail
[09:19] <cjwatson> superm1: that's a horrible, horrible bug
[09:20] <cjwatson> superm1: the debconf database is not supposed to be canonical in any way, shape or form
[09:20] <cjwatson> superm1: the canonical thing is the configuration file on the filesystem, /etc/X11/xorg.conf
[09:20] <superm1> cjwatson, then perhaps some of the underlying principles of BulletProofX have issues then.
[09:20] <cjwatson> superm1: are you calling dexconf directly by hand?
[09:21] <superm1> cjwatson, yeah i've called it by hand to verify this issue.
[09:21] <cjwatson> superm1: I don't think that's a good idea - try dpkg-reconfigure xserver-xorg instead?
[09:21] <cjwatson> I was under the impression that dexconf wasn't something you were typically supposed to call directly
[09:22] <cjwatson> but rather something that the xserver-xorg maintainer scripts call, and that's just provided as a separate binary for debugging convenience
[09:22] <superm1> cjwatson, that works properly and will generate a new xorg.conf properly.  the problem is that when a xorg.conf.failsafe is made for BulletProofX, it pulls the data from debconf
[09:22] <superm1> i have only been using dexconf for debugging indeed
[09:22] <cjwatson> superm1: I think we may be unable to fix this at this point for 7.10, and should revisit the problem for 8.04
[09:23] <cjwatson> pitti: urgh, gross
[09:23] <superm1> cjwatson, that's rather unfortunate.
[09:23] <ivoks> mvo: there's a bug in latest upload of update-notifier - typo in schema
[09:24] <cjwatson> pitti: another possibility: go back to the previous code in base-installer, reinstate the update-initramfs diversion in pkgsel, and change pkgsel to run update-initramfs with a bind-mounted /dev (but the rest of pkgsel can run without that)
[09:26] <superm1> cjwatson, since the new debconf pieces aren't copied over at all during the live install, what data *should* be in those debconf variables after you first boot into the new system?  The data gathered from the cdimage buildd's local machine?
[09:27] <cjwatson> um, goodness knows, probably not very well-defined
[09:27] <cjwatson> with the exception of the special uses to which the installer puts it, the contents of the debconf database aren't really expected to be well-defined outside maintainer script runs
[09:28] <superm1> well i wonder if bryce is aware of the issues this can be causing then.  i'll discuss this more with him later
[09:28] <cjwatson> in fact you're supposed (theoretically, it doesn't *quite* work right) to be able to nuke the db without much harm done - that's why it's in /var/cache
[09:28] <superm1> i see
[09:29] <superm1> would you be entirely opposed to adding a step to copy this debconf data over in ubiquity as an interim fix (provided it didn't break anything)?
[09:29] <superm1> and then for 8.04 coming up with a better solution
[09:30] <cjwatson>        You can also use debconf in  other,  standalone  programs.  The
[09:30] <cjwatson>        issue  to watch out for here is that debconf is not intended to
[09:30] <cjwatson>        be, and must not be used as a registry. This is unix after all,
[09:30] <cjwatson>        and programs are configured by files in /etc, not by some nebu
[09:30] <cjwatson>        lous debconf database (that is only a cache  anyway  and  might
[09:30] <cjwatson>        get blown away). So think long and hard before using debconf in
[09:30] <cjwatson>        a standalone program.
[09:30] <cjwatson> ^-- debconf-devel(7)
[09:30] <cjwatson> at this point I'm worried about the flakiness of such code in ubiquity too
[09:31] <superm1> i understand.
[09:31] <cjwatson> though it could be done, there's a copy_debconf function in bin/ubiquity which does this
[09:31] <cjwatson> (actually I should get rid of that for exactly the same reasons, of course!)
[09:31] <superm1> haha
[09:31] <cjwatson> console-setup is part of the installer so there's some clash of assumptions there
[09:32] <cjwatson> if a very small change to copy_debconf can make this work, I'd be prepared to upload that
[09:32] <superm1> cjwatson, i'll see what i can come up with
[09:32] <mvo> ivoks: *ick*
[09:32] <cjwatson> if this only affects mythbuntu, though, I'd prefer it to be conditionalised for the mythbuntu frontend?
[09:33] <cjwatson> better safe than sorry at this point
[09:33] <superm1> cjwatson, i wouldn't expect it to only affect mythbuntu based on its basis
[09:33] <superm1> cjwatson, but i'll check with bryce
[09:33] <cjwatson> hmm, you're probably right
[09:33] <cjwatson> I'd like to know a little more about how this failsafe stuff works, but we don't have a lot of time
[09:34] <cjwatson> bryce: ^--
[09:34] <mvo> ivoks: where is the typo?
[09:34] <ivoks> mvo: line 7
[09:34] <ivoks> iirc

[09:35] <mvo> ivoks: thanks, fixing now
[09:35] <ivoks> np
[09:43] <pitti> geser: libservlet> please get it uploaded, if it has a minimal diff
[09:43] <pitti> cjwatson: unfortunately that won't help
[09:43] <pitti> cjwatson: the problem is that this is now a "damned if you do, damned if you don't" situation
[09:44] <cjwatson> pitti: why won't it help?
[09:44] <pitti> cjwatson: i. e. when running with bind-mounted /dev, libraw1394 will fail to install (and god knows what else), and without bind-mount, the next package which update-initramfs'es will trash it
[09:44] <cjwatson> pitti: my suggestion was to bind-mount /dev just around the update-initramfs call
[09:44] <cjwatson> pitti: specifically not around the whole of pkgsel
[09:44] <cjwatson> pitti: diverting update-initramfs in pkgsel will ensure that it's not called when you don't expect it
[09:45] <pitti> cjwatson: ah, I see what you mean
[09:45] <cjwatson> and you can bind-mount /dev around things that update-initramfs in base-installer, just as before
[09:45] <pitti> cjwatson: actually, wouldn't it be easier to use that finish-install hook of cryptsetup?
[09:45] <pitti> cjwatson: this is done as a very last thing, after installing everything else, right?
[09:45] <pitti> cjwatson: so this thing could bind-mount, update-initramfs, unmount
[09:46] <pitti> cjwatson: that would avoid reverting the diversion fix, etc.; seems a little less intrusive to me
[09:47] <cjwatson> the diversion change isn't a problem, I only did that for cleanliness
[09:47] <Keybuk> the docs for the ElementTree API utterly fail to document the Element class
[09:47] <cjwatson> pitti: well, whatever you want, I suppose that would work but it seems a lot more fragile
[09:48] <pitti> cjwatson: ok, if you think so; I was just pondering the possibility
[09:48] <cjwatson> you need to make sure there isn't *another* finish-install hook after it in order, and yet it still needs to be called before unmounting the CD (er, probably); and interesting things happen if the user goes back and forward in the installer menu in expert mode
[09:48] <pitti> ah, I se
[09:48] <pitti> e
[09:49] <cjwatson> we had a security flaw in the past that only happened in the latter situation, iirc :)
[09:49] <cjwatson> pitti: but it's true that solution would be a lot quicker, so ... up to you
[09:49] <cjwatson> quicker to implement that is
[09:51] <pitti> cjwatson: ah, I looked at r87 of pkgsel; reverting that and bind-mounting indeed seems easier
[09:52] <cjwatson> that's the bunny
[09:53] <donspaulding> Keybuk: Python's docs only *appear* useless when all you can see is the problem, once you understand the solution, the docs make perfect sense :-)
[09:53] <mdke> like all good docs
[09:56] <donspaulding> mdke: heh, yes, I suppose you could say other docs implement the "this is simply a reference for the Masters" documentation idealogy, but surely Python came up with it first.
[09:57] <mdke> I don't know much about python, but from what I've seen in error messages, it's a general philosophy rather than just limited to the docs
[09:58] <donspaulding> eh, it's fairly easy to get good at reading tracebacks and finding the problem, but some of the docs take "cryptic technical writing" to a whole new level.
[09:58] <mdke> :)
[09:59] <mdke> RicardoPerez: was "Herramientas de accesibilidad" the string you added?
[10:00] <mdke> RicardoPerez: works :)
[10:02] <geser> pitti: bug #150692 contains the debdiff for the merge (I need a sponsor for the upload)
[10:02] <ubotu> Launchpad bug 150692 in libservlet2.4-java "[Merge]  libservlet2.4-java 5.0.30-6ubuntu1" [Undecided,New]  https://launchpad.net/bugs/150692
[10:03] <RicardoPerez> mdke: yes! that's the string
[10:04] <RicardoPerez> mdke: great!
[10:08] <mdke> RicardoPerez: would you mind filing a bug on gnome-user-docs about that string being untranslated and subscribe me
[10:09] <RicardoPerez> mdke: mmmm... yes, i'll do that
[10:09] <mdke> thanks
[10:09] <Keybuk> donspaulding: the trouble is it applies to all Python afaict
[10:09] <Keybuk> nobody ever bothers to properly document an interface
[10:09] <Keybuk> this is at its worst for bindings
[10:09] <Keybuk> imagine, the python binding for a gnome api to talk to dbus
[10:10] <Keybuk> it actually becomes a documentation black hole! sucking in other useful documentation from nearby and crushing it into nothingness
[10:11] <RicardoPerez> mdke: thanks to you :)
[10:11] <donspaulding> Keybuk: I imagine that's true for the majority of low-level-language to high-level-language bindings though
[10:11] <donspaulding> not that that's an excuse for poor documentation
[10:12] <Mithrandir> donspaulding: fwiw, I generally find Perl module docs quite useful.
[10:12] <donspaulding> and python's claims to enhanced readability (which oftentimes obviates the need for much documentation) only stretch as far as you are writing in python.
[10:12] <donspaulding> so I can see your problem
[10:14] <donspaulding> Mithrandir: I don't do anything low-level, so it's going to be hard for me to get in an argument of Perl vs. Python regarding library api docs.
[10:15] <donspaulding> Keybuk: is there an *easy* way I can include a python script in a meta package?  Can I just add a postinst script and a rules target?
[10:15] <Keybuk> you can do whatever you want in your own packages :)
[10:16] <Keybuk> you could write your postinst *in* Python :p
[10:16] <donspaulding> and just have rules call it?
[10:16] <Keybuk> rules is build-time
[10:16] <Keybuk> postinst is install-time
[10:16] <Keybuk> which do you want?
[10:16] <donspaulding> postinst
[10:17] <Keybuk> easiest way there would be to make your postinst a python script
[10:17] <Keybuk> otherwise you'd have to install the script somewhere and call it from postinst
[10:17] <Keybuk> which gets to be a bit of a pain
[10:17] <Keybuk> since your meta package would ship executables
[10:17] <donspaulding> ok, I have a meta-package that results in about 6 binaries, how do I include a postinst in just one of them?  or do I only get one postinst for the meta?
[10:18] <Mithrandir> put it in debian/binarypackagename.postinst
[10:18] <Keybuk> depends how you made your meta package
[10:18] <Keybuk> whether you're using debhelper, etc./
[10:18] <RicardoPerez> mdke: done :)
[10:18] <Keybuk> (if you just copied mine, just name it as tollef suggests)
[10:18] <RicardoPerez> mdke: https://bugs.launchpad.net/ubuntu/+source/gnome-user-docs/+bug/150696
[10:18] <ubotu> Launchpad bug 150696 in gnome-user-docs "[Gutsy]  "Assistive Tool" string untranslated" [Undecided,New] 
[10:18] <donspaulding> I'm using ion's CDBS rules script and using debuild
[10:18] <Keybuk> yeah, same name then
[10:20] <donspaulding> so just write a python script that shebangs /usr/bin/python and name it binaryname.postinst?  That's really all there is to it?
[10:21] <Mithrandir> donspaulding: yes, and make sure you handle the different values you can be called with.
[10:21] <Mithrandir> (you can find those in the Debian policy manual)
[10:21] <soren> donspaulding: Almost. It gets passed some arguments depending on the action that is being taken.
[10:21] <hunger> update-manager has broken gconf schemas here.
[10:21] <mvo> hunger: yes, I just uploaded a fix
[10:22] <hunger> mvo: Great, thanks!
[10:22] <soren> donspaulding: http://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s-mscriptsinstact
[10:22] <donspaulding> Mithrandir: soren: thanks for teh tips!  I'll go reread that section of the policy manual.  This rocks!
[10:22] <donspaulding> s/teh/the
[10:23] <soren> donspaulding: The entire chapter is what you want to read, actually. That particular section just lists the ways the script might get called by dpkg.
[10:23] <donspaulding> sure, I'll look at it
[10:23] <donspaulding> thanks
[10:24] <soren> np
[10:25] <donspaulding> it looks like all I have to code for are "configure" and "abort-remove", which doesn't seem too bad.
[10:27] <soren> donspaulding: It's very common to only do anything at all for configure.
[10:40] <soren> pitti: So the lvm crypto magic stuff should be in working condition now?
[10:41] <pitti> soren: I just got my first successful test
[10:41] <pitti> soren: with the pkgsel aproach
[10:42] <soren> That's excellent. I'm backing up my laptop right now, so that I can go cryptolvm on it before I leave for Boston.
[10:43] <cjwatson> donspaulding: you should Depends: python too
[10:43] <cjwatson> donspaulding: in debian/control
[10:43] <cjwatson> (I know Ubuntu has essential python-minimal and all that, but it's good style)
[10:44] <donspaulding> cjwatson: ok, thanks
[10:45] <Kopfgeldjaeger> :-)
[10:45] <pitti> soren, cjwatson: pkgsel debdiff attached to bug 144390; phew
[10:45] <ubotu> Launchpad bug 144390 in pkgsel "use entire disk with lvm/encrypted partitioning fails to boot" [Undecided,In progress]  https://launchpad.net/bugs/144390
[10:48] <Kopfgeldjaeger> now i can happily go to bed ;)
[10:48] <cjwatson> pitti: looks good to me. what a hack. :-)
[10:48] <cjwatson> pitti: isn't there a race between you calling udevtrigger and the devices appearing?
[10:48] <pitti> cjwatson: thank you so much for your help; I'm just a d-i noob :(
[10:48] <cjwatson> I can never get my head around that
[10:49] <cjwatson> though Keybuk tells me udevtrigger/udevsettle is useless ... but you might need a better explanation from him
[10:49] <pitti> Keybuk: ^ any idea?
[10:49] <cjwatson> hey, I have an idea
[10:49] <soren> cjwatson: I think he suggested it himself this time.
[10:49] <cjwatson> call update-dev
[10:49] <pitti> cjwatson: last time he explicitly recommended me to call udevtrigger to get the missing uuids
[10:49] <cjwatson> that way at least d-i is wrong consistently :-)
[10:50] <cjwatson> ok, if Keybuk suggested it then I guess it must be OK
[10:50] <pitti> that's a wrapper around udevtrigger plus some magic?
[10:50] <cjwatson> if type udevtrigger >/dev/null 2>&1 && type udevsettle >/dev/null 2>&1; then
[10:50] <cjwatson>         udevtrigger
[10:50] <Kopfgeldjaeger> pitti: are you sure you need /sys for that?
[10:50] <cjwatson>         udevsettle
[10:50] <cjwatson> fi
[10:50] <cjwatson> Kopfgeldjaeger: does no harm
[10:50] <pitti> Kopfgeldjaeger: no, I'm not
[10:50] <pitti> Kopfgeldjaeger: but I definitively need /proc
[10:50] <Kopfgeldjaeger> yeah, thats right.
[10:50] <pitti> so I just added it in case
[10:50] <cjwatson> pitti: if Keybuk suggested udevtrigger, let's just leave it as you have it
[10:50] <pitti> ok
[10:51] <cjwatson> Kopfgeldjaeger: bits of initramfs-tools do walk /sys, so yes, it is needed.
[10:51] <soren> I'm curious: How do you guys test d-i stuff? There must be a simpler way than to build a fresh installer image and try it in a vm?
[10:51] <cjwatson> grep /sys /usr/share/initramfs-tools/hook-functions
[10:51] <pitti> cjwatson: I hope that the changelog is written halfway comprehensible, and that it explains the dilemma
[10:51] <pitti> cjwatson: for hardy, I'd instead fix packages to install cleanly with a dynamic udev and keep /dev bind-mounted (seems much cleaner to me)
[10:51] <cjwatson> soren: typically I either edit it while it's running (you have nano), or I wget or scp in updated versions while it's running
[10:52] <cjwatson> pitti: yeah, I think setting up /dev/.static/dev might be enough
[10:52] <Kopfgeldjaeger> aah, ok. but in my qemu mashine, i didnt need /sys to do a successfull update-initramfs. but things may vary
[10:52] <cjwatson> dunno. anyway
[10:52] <cjwatson> Kopfgeldjaeger: you probably get different results in some circumstances
[10:52] <cjwatson> Kopfgeldjaeger: it won't error out, but it may behave differently
[10:53] <Keybuk> pitti: do you need the UUIDs immediately?
[10:53] <Kopfgeldjaeger> yeah..
[10:53] <cjwatson> though only in MODULES=dep mode
[10:53] <cjwatson> Keybuk: yes, it's basically udevtrigger; update-initramfs -u
[10:53] <soren> cjwatson: Oh, really? I would have thought you had some sort of special environment where you could do things more easily.
[10:53] <pitti> Keybuk: I call update-initramfs immediately after; a few seconds delay won't hurt, but it's not defined
[10:53] <cjwatson> soren: it's easy enough
[10:53] <Keybuk> ok... then he needs a udevsettle in there too
[10:53] <geser> pitti: have you time to sponsor bug #150692 or should I look for an other sponsor?
[10:53] <ubotu> Launchpad bug 150692 in libservlet2.4-java "[Merge]  libservlet2.4-java 5.0.30-6ubuntu1" [Undecided,New]  https://launchpad.net/bugs/150692
[10:53] <pitti> Keybuk: ok, I'll add that, thanks
[10:54] <cjwatson> pitti: ok, use update-dev then please
[10:54] <cjwatson> for consistency
[10:54] <pitti> cjwatson: alright; that's defined in pkgsel.postinst?
[10:54] <Kopfgeldjaeger> good night
[10:54] <pitti> anyway, I'll do another test with that better
[10:54] <Keybuk> trigger tells udev to re-run its rules for devices in the /sys tree
[10:54] <Keybuk> settle actually waits for udev to finish
[10:55] <cjwatson> pitti: no, it's a script shipped by di-utils (which is basically Essential as far as d-i is concerned)
[10:55] <Keybuk> in this case, you're doing it to refresh the information about devices you already know about
[10:55] <Keybuk> so you're not falling into the "udevsettle does not wait for new hardware" trap
[10:55] <cjwatson> aah
[10:55] <cjwatson> now I understand
[10:56] <pitti> ah, got it
[10:56] <cjwatson> soren: sometimes I build a new udeb, grab it, udpkg -i it on the fly
[10:56] <cjwatson> soren: just depends what I'm doing
[10:56] <cjwatson> soren: there's a special monolithic initrd type which I used to use a lot more when I was porting d-i to Linux 2.6 on powerpc, which isn't really something you can hack on the fly; monolithic doesn't rely on a CD or the network for anything
[10:57] <soren> cjwatson: I suppose. To me it all just seems opaque.
[10:57] <cjwatson> soren: but I find that to lengthen the test cycle too much for ordinary work, really
[10:57] <cjwatson> soren: plus I've been working on d-i for 3+ years so I have a head-start in terms of instinct for what will work ;)
[10:58] <soren> cjwatson: Sure :)
[10:58] <cjwatson> (having written big chunks of the infrastructure sure helps in remembering how it works)
[10:58] <soren> pitti: So tomorrow's daily will have working auto-crypto-lvm goodness?
[10:59] <cjwatson> pitti: did you promote partman-auto-crypto back to main?
[10:59] <soren> pitti: Oh, you actually demoted it already?
[11:00] <soren> I thought "I'll demote foo to universe" was just pitti-speak for "/me shakes his fist at foo".
[11:00] <pitti> cjwatson: yes
[11:00] <pitti> soren: that's the problem if you have a drescher account -- shaking your first actually *does* things

[11:01] <pitti> meh, why doesn't vmware support copy&paste in VTs
[11:01] <soren> Is that an actual question?

[11:02] <soren> Oh, good. :)
[11:02] <pitti> wasn't there a trick to get scp in d-i?
[11:03] <cjwatson> pitti: anna-install openssh-client-udeb
[11:03] <pitti> merci
[11:03] <cjwatson> works immediately after "retrieving installer components"; before then, it'll queue
[11:03] <cjwatson> wget and nc are built-in
[11:04] <pitti> ah, wget, that'll do
[11:13] <pitti> BenC: can we please have lbm for -13?
[11:15] <soren> pitti: You discussed bug 119075 with jdstrand recently, right? What did you decide for gutsy?
[11:15] <ubotu> Launchpad bug 119075 in mysql-dfsg-5.0 "Root password policy for mysql" [Undecided,In progress]  https://launchpad.net/bugs/119075
[11:15] <pitti> right
[11:17] <wasabi> soren: What's up with ebox?
[11:17] <wasabi> I notice you're the only uploader in ages.
[11:18] <soren> pitti: I understand that at this point in the release process we should keep things simple, but we've changed things in released versions of Ubuntu to this effect. It seems wrong to have a feature in Dapper, Edgy, and Feisty, not in Gutsy, and then reintroduce it in Hardy.
[11:18] <soren> wasabi: We decided to defer it. It'll be in hardy.
[11:18] <wasabi> Ahh.
[11:18] <pitti> soren: ok; what particular feature do you mean?
[11:18] <wasabi> The packages look like they're not in a complete state. Am I right?
[11:18] <soren> pitti: Adding the resetpassword thing in the init script.
[11:18] <soren> wasabi: Yes.
[11:19] <wasabi> k. Thanks.
[11:19] <pitti> soren: AFAIR we just agreed to make sure to display the debconf question for gutsy
[11:19] <soren> pitti: Ok. Hmm...
[11:20] <soren> I understand the argument, I think. We didn't used to ask for a root password, so gutsy is different w.r.t. to password handling, but you can just tell it that you want an empty password, and it'll accept that.
[11:20] <soren> ..and unlike dapper, edgy, and feisty, it won't make a fuss over it.
[11:21] <soren> Uargh... Has Jamie's patch been uploaded to -security already?
[11:22] <pitti> soren: not sure; keescook?
[11:23] <soren> It seems not.
[11:23] <soren> Phew..
[11:23] <soren> jdstrand: You wouldn't happen to be around, would you?
[11:23] <pitti> \o/ my final pkgsel install test succeeded
[11:23] <pitti> time to upload
[11:23] <soren> Woo!
[11:23] <pitti> wow, my first d-i-ish upload
[11:23] <cjwatson> really?
[11:23] <cjwatson> I thought you'd done something around there before
[11:24] <pitti> I might have forgotten, right
[11:24] <pitti> not something that costed me hours to figure out, though :)
[11:25] <pitti> cjwatson: committed and pushed to bzr, too
[11:25] <cjwatson> ta
[11:25] <Riddell> keescook: I just came across bug 150716
[11:25] <ubotu> Launchpad bug 150716 in pam "libpam0g interrupts upgrade" [Undecided,New]  https://launchpad.net/bugs/150716
[11:28] <pitti> tkamppeter: still here?
[11:28] <pitti> Riddell, tkamppeter:
[11:28] <pitti>   foomatic-db-gutenprint: Depends: ijsgutenprint (>= 5.0.1-0ubuntu8) but it is not installable
[11:29] <pitti> Riddell, tkamppeter: (since it's in universe)
[11:29] <pitti> I'm fine with promoting it if necessary, but please confirm that this is deliberate
[11:29] <pitti> I read something about 'reverting' a change, but this wasn't here before
[11:34] <pitti> Riddell: anyway, promoted
[11:40] <teprrr> tkamppeter, heya, got my private messages?
[11:41] <teprrr> (just joined to be sure you haven't missed them if you're using ignoreoc )
[11:41] <teprrr> ;)
[12:29] <mjg59> slangasek: 149997 probably wants to be milestoned