#ubuntu-devel 2004-10-01
<m_tthew> fabbione: ahoy
<fabbione> hey m_tthew 
<mdz> morning
<fabbione> mdz: for the ati/flrdkjdjds driver...
<fabbione> the script is very simple
<fabbione> is the same as the nvidia one
<fabbione> skip the kernel part
<fabbione> and change the driver names
<fabbione> for now let's keep them separate and "hackish"
<mdz> ok
<fabbione> we will work on a all-in-one integrated solution for hoary
<mdz> I figured they could probably be merged into one script without much trouble
<mdz> but whatever is easiest for you
<fabbione> i was more happy to provide a script from X directly to do so
<fabbione> but not for final
<fabbione> if you feel more happy to merge them, just go ahead
<fabbione> i need to fix X today
<mdz> what issues remain before you do your next upload?
<fabbione> a bunches
<mdz> you said something about 12-16 hours on the list
<fabbione> all small things, but they need to be tested
<fabbione> because they need to be tested
<mdz> we have many interested testers now :-)
<fabbione> I did merge already daniels work yesterday
<fabbione> so i have a few things for KBD from debian
<fabbione> and a bunch of small bug fixes
<fabbione> but again.., no blind uploads
<fabbione> i want to test as much as i can before
<mdz> of course
<fabbione> and X doesn't take like 5 minutes to build...
<mdz> but you can also upload to /~fabbione/ and ubuntu users will help to test
<fabbione> that's just a small detail :-)
<fabbione> mdz the 2 major changes have been tested already
<fabbione> nv and ati
<fabbione> daniels should have tested ati
<fabbione> but the minor bug fixes... first i need to make them :-)
<fabbione> than test the fixes
<mdz> I can test ati as well if i386 binaries are available
<fabbione> mdz: i don't have them. I can build them for you
<fabbione> but it will take approx 40 minutes
<fabbione> will you be around?
<mdz> probably yes
<mdz> I am planning to stay up late tonight
<fabbione> ok
<fabbione> building now :-)
<fabbione> brb
<mdz> my fast i386 is still running unstable
<mdz> I meant to migrate it this weekend, but there have been so many bugs and mailing list traffic
<fabbione> there is no need to migrate to test the driver
<fabbione> or yes..
<fabbione> hmmm
<mdz> well, I need to migrate it
<fabbione> there should be no need
<mdz> currently I need to use either my laptop or a chroot to do warty/i386 builds
<fabbione> ok
<fabbione> almost built
<fabbione> ccache is the r0ck5
<fabbione> mdz: we should probably announce this channel
<fabbione> since we have started using it
<mdz> fabbione: are you sure that 1417 and 840 are the same?
<mdz> yes, ccache is the r00lz
<mdz> xchat won't let me type t-e-h
<mdz> yes, we should
<mdz> we should also announce the ubuntu-devel mailing list
<mdz> since no one seems to use it
<mdz> but i am afraid of all this support traffic coming over to -devel
<mdz> we should at least get the Canonical guys into this channel, though
<fabbione> mdz: I am pretty sure they are the same problem
<fabbione> xchat sucks :-) get a real irc client ;)
<mdz> fabbione: one was about acceleration, and the other about duplicate events
<fabbione> mdz: acceleration is caused also by duplicate events
<fabbione> double data = faster mouse
<mdz> I suppose it could be
<fabbione> mdz: people.nny.com/~fabbione/ati/i386
<fabbione> stick them in /usr/X11R6/lib/modules/drivers
<fabbione> and let us know :-)
<fabbione> take a backup of the old drivers
<fabbione> just in case
<mdz> testing
<mdz> eek, failed
<fabbione> error?
<mdz> segfault
<mdz> (II) LoadModule: "ati"
<mdz> (II) Loading /usr/X11R6/lib/modules/drivers/ati_drv.o
<mdz> (EE) LoadModule: Module ati does not have a atiModuleData data object.
<mdz> (II) UnloadModule: "ati"
<mdz> (II) Unloading /usr/X11R6/lib/modules/drivers/ati_drv.o
<mdz>    *** If unresolved symbols were reported above, they might not
<mdz>    *** be the reason for the server aborting.
<mdz> Fatal server error:
<mdz> Caught signal 11.  Server aborting
<fabbione> is this on the Debian machine?
<mdz> no
<fabbione> ok.. than wait
<fabbione> i will pass you the entire xserver package
<mdz> Version: 4.3.0.dfsg.1-6ubuntu18
<mdz> ok
<mdz> I have bandwidth
<fabbione> there might be more that needs to be installed
<fabbione> it is still building the .debs
<fabbione> i grabbed the driver from the build dir
<mdz> say when
<fabbione> in a few minutes
<fabbione> it's still building the debugging stuff
<fabbione> but if the debug package builds correctly, it means that all the symbols are there
* ..[topic/#ubuntu-devel:mdz] : Ubuntu development -- general discussion on #ubuntu
<fabbione> so it is just "something else" that is missing and the package needs to be fully upgraded
<fabbione> or daniels did a huge fuck up :-)))
<fabbione> mdz: people.nny.com/~fabbione/
<fabbione> there are 2 .deb.
<fabbione> please install both and test again
<fabbione> i need to go out for a hour or so
<fabbione> bbl
<fabbione> ps if it doesn't work lart daniels with a cluestick on the teeth
<fabbione> ;)
<fabbione> i have to run off
<fabbione> ops
<mdz> downloading
<fabbione> re
<fabbione> amazing the bank payed my house twice
<fabbione> mdz: any news?
<mdz> fabbione: locked my machine
<mdz> the X cursor came up on a black screen
<mdz> and that was it
<mdz> same after a reboot
<fabbione> FUCK
<mdz> I have a logfile if you want it
<mdz> but it doesn't show much
<fabbione> is daniel still around?
<fabbione> he did the backport and might know how to fix it
<fabbione> otherwise i will have to do a full backport
<fabbione> i already pinged him
<mdz> me too
<mdz> downgrading
<mdz> I'm back at ubuntu18 for now
<Mithrandir> mdz: permission to upload new lsb with AMD64 support? #1354, patch at http://raw.no/patches/lsb_1.3.amd64.diff
<mdz> Mithrandir: OK
<mdz> Mithrandir: please mention #1354 in the changelog though
<Mithrandir> ok
<fabbione> mdz: yes.. i will see what the status with daniel if he will show up again
<Mithrandir> mdz: permission to upload new libmikmod with AMD64 support? (1409, 1411), patch at http://raw.no/patches/libmikmod_3.1.11-2.amd64.diff ; verified on amd64
<mdz> Mithrandir: approved
<Mithrandir> thanks, uploaded
<jdub> phwoar
<jdub> ROCK AND ROLL
<jdub> this permanent, or a dynamic meeting spot for something important? :)
<fabbione> the former :-)
<jdub> yayayayay
<jdub> ;)
<Mithrandir> .. and there the bug, with patch was filed with Debian.
<pitti> mdz: I have to bother you again with #1345; I did not recognize that there was a new patch 07_init.patch which changed debian/hal.init.md5sum
<pitti> mdz: please see the changelog entry of the new diff
<Mithrandir> mdz: blah, I suck.  1409 wasn't closed by mikmod, they looked like dupes.  Only 1411 was, the other one is against sdl.  Fixing it now.
<mdz> pitti: it would be better to keep the init changes separated in a patch
<mdz> Mithrandir: yes, I had to look twice at it myself
<mdz> the reports were not exactly, er, detailed
<Mithrandir> mdz: permission to upload sdl-mixer1.2; amd64 fix, bug #1309, patch at http://raw.no/patches/sdl-mixer1.2_1.2.5-5.amd64.diff ?
<mdz> Mithrandir: approved
<Mithrandir> thanks, uploaded
<pitti> mdz: but then I have to change the patch anyway because hal.init.in was introduced in Ubuntu
<pitti> mdz: basically the whole hal.init.in file _is_ the patch, it replaces Debian's hal.init file
<pitti> mdz: that's why it does not make much sense to me to have a patch
* Mithrandir whacks evolution
<seb128> hey
<jdub> wassuP!
<jdub> seberino!
<fabbione> hey seb!
<seb128> so many chans !
<jdub> pitti: Subject: hal 0.2.98 released
<jdub> :-)
<pitti> jdub: Hopefully it fixes many of 0.2.97's regressions :-/
<pitti> jdub: but at least it should now have my security changes adopted
<jdub> rocking
<seb128> jdub: nobody replied to my mail, but seriously, I want a NEEDINFO state :)
<jdub> :-)
<jdub> hrm
<jdub> wonder if i cna do that
<jdub> nah
<jdub> bummer
<seb128> jdub: https://bugzilla.ubuntu.com/show_bug.cgi?id=1338
<seb128> permission to upload ?
<jdub> seb128: done
<seb128> thanks
<pitti> jdub: https://bugzilla.ubuntulinux.org/show_bug.cgi?id=1430
<pitti> jdub: can I upload this?
<daniels> mdz: i386 or amd64?
<daniels> (the amd thing)
<fabbione> i386
<fabbione> and we cannot even jump to X.org
<fabbione> because there are changes in drm/dri
<fabbione> daniels: oh btw.. i think i have the fix for Xv on nvidia
<fabbione> trying to do a full backport of ATi gave an insane idea of what the problem could be
<daniels> what's the problem?
<daniels> huh, changes in drm again? i missed that
<daniels> oh, not the api -- i get you
<daniels> yeah, that backport was a bitch to do
<daniels> ahr, that really bites.
<daniels> mdz: can you please install -dbg, run with -core under gdb and see if you can hit the segfault?
<daniels> XFree86 :1 -ac -logverbose 99999999999 -verbose 999999999999999999 -core, would kick arse
<fabbione> daniels: just check the chan logs :-)
<fabbione> daniels: i think the bug in Xv is related to the changes in miRagionEqual
<fabbione> daniels: but i can't be sure 100%
<fabbione> so i need a round of test
<daniels> ah, yeah
<daniels> all the region stuff changing is a pain in the arse
<daniels> and it's different again in kdrive
<daniels> guess how much fun making the xorg ddx run on kdrive's dix was, with a totally different fb layer  :P
<fabbione> daniels: yes. that's why Branden redefines them per driver
<fabbione> no i don't want to guess
<fabbione> to much pain
<fabbione> :-)
<daniels> heh
<daniels> um, which channel logs -- #ubuntu-devel?
<fabbione> yes
<jdub> pitti: do we really want to do that at this stage?
<daniels> fabbione: okay
<pitti> jdub: Matt says so, see the bug trail. I'm not sure, but it probably avoids much confusion for new users
<pitti> jdub: it's major :-/
<daniels> mdz: does not have atimoduledata?!?!?!
<daniels> sweet mother of god
<pitti> jdub: this was my first piece of gnome programming, so I would appreciate a second look at the patch (for me it works well)
<daniels> fabbione: um, where's the module now?
<jdub> ok, if matt reckons g-s-t should do it, then let's do it ;)
<daniels> fabbione: people.nny.com/~fabbione/ati/i386 is empty
<jdub> pitti: can you get seb128 to comment on it?
<daniels> fabbione: i want to disect the module with nm and shit
<fabbione> daniels: yes.. there are the deb packages
<pitti> jdub: yep, will try
<daniels> The requested URL /~fabbione/ati/i386/ was not found on this server.
<fabbione> daniels: a couple of layers up
<daniels> ahr
<daniels> fabbione: could you please put ati_drv for i386 somewhere?
<pitti> seb128: I prepared a patch for https://bugzilla.ubuntulinux.org/show_bug.cgi?id=1430 (attached to the bug)
<fabbione> daniels: it's building right now....
<fabbione> daniels: gimme a few secs
<daniels> fabbione: thanks mate
<pitti> seb128: since this is my first real gnome code hacking, can you please take a look at it and inform jdub and me?
<daniels> i just don't much fancy pulling a whole xserver-xfree86 if I can avoid it ;)
<seb128> pitti: not right now, I'm way too much overloaded, sorry
<pitti> jdub: ^
<seb128> pitti: in about 15min
<pitti> seb128: okay, thanks anyway
<jdub> oh man, FUCK these dell D600 laptops!
<pitti> seb128: ah okay, this is completely sufficient
<jdub> pitti: perhaps grab jamesh if he's around
<fabbione> daniels: they are up on people
<fabbione> daniels: ~fabbione/
<daniels> fabbione: thanks dude
<fabbione> daniels: no problem
<seb128> jdub: http://freedesktop.org/cgi-bin/viewcvs.cgi/gstreamer/gstreamer/gst/gstelement.c.diff?r1=1.300&r2=1.301
<seb128> ^^ fixes the theora streaming reading with gstreamer
<seb128> should we consider this patch ?
<jdub> i wouldn't put it on high priority, myself
<jdub> when are they going to do a new release?
<seb128> good question :)
<daniels> mdz: does setting the driver to radeon instead of ati help?
<thom> jdub: permission for #1286?
<jdub> thom: before you upload
<jdub> thom: bother craige about his camera
<jdub> i think it needs some fdi loving
<thom> jdub: ACK
<fabbione> daniels: i am more and more convinced i fixed the Xv problem
<fabbione> daniels: on one box xvinfo was not even giving output
<fabbione> daniels: now it does :-)
<jdub> thanks thom :-)
<fabbione> ok time to test it
<fabbione> bbl
<daniels> fabbione: sweet :) nice work dude
<daniels> 000003d4 g     O .data  0000000c atiModuleData
<daniels> how the bloody hell can it be undefined?
<daniels> it's unreproducible here
<daniels> mdz: works just fine here with both ati_drv and radeon_drv; could you please get the ati files from people.nny.com/~fabbione and test?
<fabbione> daniels: ok.. Xv working on a box where it was not working before
<fabbione> daniels: i wonder if that fixes all the other crap
<daniels> fabbione: sensational!
<daniels> fabbione: what cards are the problems occurring on?
<thom> jdub: ok, will update the patch to include craige's camera too
<daniels> i have a gf2 here, i think
<thom> daniels: oi, what's happened to freedesktop.org?
<daniels> thom: given clee just dropped off the face of the earth wrt opn (fooish), i can't talk to oftc ... i suspect pdx is having Issues
<daniels> should work OK now, though
<daniels> i suspect half the world is invisible to it
<daniels> try tunneling through amnesiac?
<fabbione> this is a RIVA TNT2
<fabbione> i am preparing a driver to send around for test
<daniels> ok, i can test on the gf2 later
<daniels> i also have sis, mga, r128, and a couple of random cards
<pitti> jdub: jamesh reviewed, found some small issues (memory leak), I will prepare an updated patch
<pitti> jdub: in the meantime I fixed https://bugzilla.ubuntulinux.org/show_bug.cgi?id=1448
<pitti> jdub: ugly, but very unintrusive; can I get permission?
<pitti> seb128: jamesh already reviewed #1430, don't bother
<seb128> ok, thanks
<thom> jdub: updated patch to 1286
<jdub> thom: go for it
<jdub> oh
<jdub> sorry
<jdub> will comment
<jdub> stupid different urls
<fabbione> daniels: can i remove the drivers from ~/fabbione ?
<pitti> jdub: my net connection broke down for a few minutes. Did I miss any reply for #1448?
<fabbione> daniels: and btw.. they are the same i gave to Mdz
<daniels> fabbione: yeah, I have them locally
<daniels> fabbione: that's really weird though -- using ubuntu18, i have no problem with either ati or radeon
<jdub> argh
<fabbione> daniels: he first tried ubuntu18 + drivers
<fabbione> daniels: than ubuntu19
<daniels> mdz: what sort of card do you have?
<daniels> mdz: i need a log of XFree86 :1 -logverbose 99999999999999999 -verbose 9999999999999999999 -ac
<daniels> that should catch all the whacky output
<jdub> pitti: that's the one i just confirmed
<pitti> jdub: thx
<jdub> pitti: i confirm in bz comments, not on irc :)
<pitti> Hi lamont!
<lamont> hi pitti
<fabbione> guys i need someone to build X for me on ppc and amd64 
<Mithrandir> fabbione: sure.  Source?
<fabbione> Mithrandir: uploading them right now..
<Mithrandir> prod me when you're done.
<fabbione> Mithrandir: people.nny.com/~fabbione/
<fabbione> Mithrandir: ubuntu19
<fabbione> can you build also ppc?
<Mithrandir> no, sorry, I don't have any PPC set up.
<fabbione> lamont: do you think you can build it on any of our buildd, WITHOUT getting it in the archive? ;)
<Mithrandir> fabbione: 5.4G should be enough for the build?
<fabbione> Mithrandir: -B -b and it will go down to 3.2Gb
<fabbione> I only need the xserver-xfree86_ package
<fabbione> nothing more than that
<Mithrandir> ok
<Mithrandir> building
<fabbione> thanks :-))
<Mithrandir> I should set up my G3 at home, it's not _that_ fast, but it should be useful to debug stuff
<fabbione> yeah i start to feel the need of a ppc and an amd64
<Mithrandir> amd64 systems are really nice
<fabbione> Mithrandir: ENOMONEY for a loooong shile
<fabbione> while
<Mithrandir> yeah, sucks
<pitti> jdub: I updated the patch for https://bugzilla.ubuntulinux.org/show_bug.cgi?id=1430 according to jamesh's comments
<jdub> approved
<jdub> commented, etc.
<pitti> jdub: thx
<jdub> this is getting *very* busy
<jdub> lots of people
<jdub> lots of mail
<fabbione> jdub: permission to upload Xfree86 for:
<fabbione> #1390, #1492, #929, #1361, #1471, #1425, #1417, #1339, #1117
<Mithrandir> heh, xedit is scriptable in lisp
<fabbione> + a bunch of small bug fixes (not all reported via bugzilla)
<jdub> argh
* fabbione grins evily watching jdub's face
<jdub> fabbione: i'm going to be slightly loose on this one
<jdub> fabbione: given that we have some weeks to go
<jdub> fabbione: and i trust you've tested :)
<jdub> fabbione: please upload
<fabbione> jdub: excuses :-))))
<fabbione> ok
<jdub> indeed ;)
<fabbione> i am waiting daniel/mdz to check the ati driver
<fabbione> otherwise i will ust drop those bits
<fabbione> jdub: you can add 1504 and 1506 to the list ;)
<seb128> jdub: https://bugzilla.ubuntu.com/show_bug.cgi?id=1397 <- NOTABUG ?
<jdub> seb128: NOTABUG :)
<seb128> ok :)
<Mithrandir> fabbione: http://raw.no/tmp/xf/
<fabbione> thanks
<Mithrandir> it's downloading all the amd64 .debs now
<Mithrandir> it takes a little while.. my line sucks, it seems
<fabbione> Mithrandir: the server was more than enough
<Mithrandir> it's there now
<fabbione> thanks
<fabbione> Mithrandir: you can wipe the .deb away
<fabbione> thanks a lot
<Mithrandir> done
<Mithrandir> and np
<fabbione> mdz: you alive?
<lamont> fabbione: so if it's really not supposed to go into the archive, is that because it's debugging?  in which case shouldn't it be -6unbuntu18.1?
<lamont> so that 19 is still new when it hits the street?
<fabbione> lamont: i only need a driver out of it.. yeah well the version concept is correct
<fabbione> lamont: but nobody is using ubuntu19
<fabbione> i am only extracting the nv driver
<fabbione> and traashing the debs
<fabbione> that's all i need atm
<fabbione> lamont: do you think you can build ppc please?
<lamont> email me a pointer to the sources, and I'll get it built
<fabbione> lamont: people.nny.com/~fabbione/
<lamont> fwiw, you're less likely to get the ability to admin the chroot than you are to get a chroot...
<fabbione> lamont: honestly.. i don't mind.. really.. i just don't want to spend half day going around asking people to build X
<fabbione> lamont: if someone can take care of updating the chroot once in a while it's perfect for me
<lamont> 3.2MB of DIFF???  sheesh
<fabbione> when i write "i am dealing to maintain the chroot" is only to remove extra work load from other people
<fabbione> not becuase i want to look cool or becuase i feel privileged ;)
<thom> jdub: is -firefox a release goal now?
<lamont> heh
<lamont> fabbione: just ppc, or do you need amd64 as well?
<jdub> thom: yes
<fabbione> lamont: only ppc
<fabbione> lamont: Mithrandir did amd64
<thom> jdub: so i should be ok to integrate and upload PR1?
<jdub> yes please!
<fabbione> lamont: and please upload only xserver-xfree86_*. I don't need anything else.
<fabbione> s/upload/put somewhere/
<lamont> fabbione: give me about 90 minutes or so,iirc
<fabbione> lamont: super! it's ok for me
<fabbione> UHA UHA UHA the Xv extension fix seems to be working
<fabbione> *ONLY* 4 days of debugging
<lamont> fabbione: you're not debugging features into existance are you???? :-)
<thom> jdub: tomboy looks pretty cool - much funkier than the gnome stickies thing
<jdub> yeah
<jdub> might talk to tseng about packaging it
<seb128> jdub: what do you think about droping gst0.6 ?
<jdub> seb128: probably a good idea
<seb128> ok, I should mail ubuntu-devel about this ?
<jdub> is it controversial? :)
<jdub> seems like just nuking a bunch of stuff
<fabbione> lamont: no no.. it was broken.
<jdub> thom: there you go ;)
<fabbione> lamont: see: #269025, #268759, #271235, #270228, #271071
<fabbione> probably one or two more...
<fabbione> those are the ones i have written down
<thom> who is tseng?
<fabbione> let's hope is not John ;)
<Mithrandir> some gentoo developer
<Mithrandir> Brandon Hale <tseng@gentoo.org>, I'd guess
<jdub> thom: the dude who's doing the mono repo
<thom> ahr
<fabbione> oh
<daniels> tseng's a really cool guy
<daniels> he's a gentoo toolchain guy who's really hyped about ubuntu
<daniels> and he's doing our mono stuff
<daniels> i subverted him :)
<fabbione> daniels: tell me something nice :-)
<fabbione> about the ati driver ;)
<daniels> heh
<daniels> it works for me
<daniels> that's really nice :P
<fabbione> i guess i will have to test it here...
<daniels> if you could, that would be nice
<daniels> want to know if mdz is on speed or if it's actually stuffed
<fabbione> daniels: can you confirm atimisc is at 6.5.5 ?
<daniels> fabbione: i could give you the md5sum
<daniels> but, not having an atimisc card ...
<fabbione> did you dump the driver version?
<daniels> bump?
<fabbione> yes bump sorry
<daniels> ati_drv is 6.5.5
<fabbione> yeah
<daniels> didn't bump the driver version, come to think of it
<fabbione> it works here...
<daniels> would make sense to do so
<daniels> right
<fabbione> apparently :-)
<daniels> RESOLVED/MINDALTERINGDRUGS :)
<daniels> we need a KEEPSIPPING resolution
<fabbione> daniels: would help if i give a -dbg xserver to mdz?
<daniels> fabbione: yeah, it would probably eliminate the problem, which seems to be that the loader is COMPLETE ARSE (news at eleven)
<fabbione> daniels: Subject: NVideo GeForce4 440                                                                                                      
<fabbione> i guess that's the usual xresprobe problem
<daniels> which list?
<fabbione> -users
<daniels> got it
<daniels> oh, arse :\
<daniels> yeah, i think we can add this to the usual nv backport arse
<daniels> if we can't get the panel res from the logs with the new driver, it's not going to display right regardless of what we do
<daniels> which makes me feel better :)
<fabbione> the new driver has a lot of new code for panel detection
<fabbione> either it will work better or X will ask the question
<daniels> yeah, I saw that
<daniels> I was looking through the driver to check out the panel resolution crack to see if it could be trivially added
<daniels> but I was looking at xorg HEAD, so I realied it already was, and cheered up immensely
<daniels> fixed + not my problem == gold ;)
<fabbione> ehehe
<jdub> seb128: had you planned to upgrade pygtk, or should i file a bug?
<seb128> we are supposed to upgrade ?
<seb128> they failed to release 2.4 at time, I thought we were going with 2.2 
<jdub> one sec
<jdub> seb128: one option is to talk to jamesh
<jdub> jdahlin just suggested that
<seb128> talk about what ?
<jdub> pygtk
<seb128> yes, but you want 2.3 in warty ?
<jdub> 2.4
<jdub> if jdahlin or jamesh can do it
<seb128> hum, they have released 2.4 now ?
<seb128> I've talked with jdahlin like 2 days ago
* seb128 hits jdahlin
<seb128> jdub: I'll sort that with jdahlin & jamesh and let you know
<jdub> thanks
<fabbione> daniels: i am reverting the ATI driver for ubuntu19
<fabbione> daniels: it's a FTBFS on ppc
<jdub> seb128: jdahlin is scared of you.
<seb128> ah ah
<seb128> jdub: /j #pygtk dude, so we can sort this out now :p
<jdub> i'm in #twisted ;)
<seb128> jdub: BTW, ok for an upload of trashapplet 0.3 ? Basically all the canonical patches included and some translation updates
<jdub> sure
<mdz> morning
<seb128> hello mdz 
<mdz> daniels, fabbione: the card is a radeon mobility M7
<fabbione>  /me kicks Xv
<fabbione> mdz: doh! i have the same here!
<fabbione> and it works
<fabbione> anyway i reverted the ati patches for ubuntu19
<fabbione> they are a FTBFS on ppc
<fabbione> mdz: http://people.no-name-yet.com/~fabbione/changelog
<fabbione> am I allowed to upload? ;)
<fabbione> anyway the Xv extensions for nv are almost working
<pitti> mdz: good morning!
<fabbione> not for everybody yet.. tought.. still better than now
<mdz> pitti: morning
<mdz> fabbione: so...many...changes :-)
<fabbione> mdz: so many bugs to fix....
<fabbione> :-)
<mdz> gah
<jdub> morning mdz :)
<mdz> the Closes: # are a mixture of Debian bugs and Ubuntu bugs
<pitti> mdz: yes, I'm afraid I sent you a shipload of mails to dig through. Sorry :-/
<fabbione> mdz: the Debian ones are a copy and paste from debian trunk
<jdub> now mdz's up, i think i can safely go to bed ;)
<fabbione> mdz: the others are ubuntu specific
<pitti> jdub: sleep well!
<jdub> pitti: some interesting things happening on hal list
* mdz tosses ubuntu-* in the "later" pile
<fabbione> mdz: nothing i can do about it without resync the 1000 bugs on X
<jdub> mdz: bz has been fucking crazy
<pitti> jdub: you mean utoia?
<pitti> jdub: utopia
<mdz> fabbione: my preference would be to upload it to /~fabbione/ and ask people to test it
<jdub> pitti: hal
<mdz> fabbione: especially those who encountered the bugs
<pitti> jdub: hmm, I'm not subscribed to it. I take a look into the archves
<pitti> jdub: interestingly, today a patch went in which supports device locking
<pitti> jdub: I'm currently working at a similar locking mechanism for pmount
<jdub> mmm
<fabbione> mdz: than please someone provides me access to amd64 and ppc to build the packages. I already did a request to Mark this morning
<fabbione> mdz: i can't keep going around asking people to build X
<fabbione> it's not something people *like* to do
<daniels> fabbione: argh! how?
<fabbione> missing simbol
<fabbione> mdz: ok I am compiling (again) and put the stuff on people.
<daniels> fabbione: which symbol?
<fabbione> daniels: check the backlog.. i can't remember.
<fabbione> something like RADEONPPL*
<mdz> fabbione: send me an ssh public key
<fabbione> mdz: done..
<daniels> fabbione: oh, right
<daniels> i can get you a fix in a couple of hours
<fabbione> daniels: ubuntu20 stuff.
<fabbione> it needs to be tested
<daniels> good choice
<fabbione> anyway ubuntu19 is going on people
<fabbione> we have no green light
<fabbione> too many changes
* mdz weeps at his inbox
<jdub> i'm going to sleep for like four hours
<jdub> so it can't build up
* pitti will file a bug about mail DOS attacks against mdt
<pitti> mdz, even
<fabbione> i do.. on a regular base
<fabbione> ops
<mdz> pitti: upload approvals should go to both me and jdub
<mdz> pitti: because at least one of us will be awake
<mdz> no one should block on upload approval
<pitti> mdz: I thought you wanted to review it since you had some reservations
<jdub> mdz: what are these -3 kernels mentioned on the wiki?
<mdz> pitti: #1345 approved
<mdz> jdub: (linux-restricted-modules) they're either waiting in NEW, or something happened to the upload
<jdub> ah, ok
<mdz> I mailed  james about it last night
* jdub is writing the most excellent troll ever
<mdz> he may have replied, I have more to read
<jdub> perhaps we need an RM alias or something?
<mdz> fabbione: http://bugzilla.ubuntu.com/show_bug.cgi?id=468
<mdz> fabbione: that finally explains the mystery!
<mdz> fabbione: it makes a difference which VC is currently displayed
<fabbione> ah
<fabbione> that's real crap
<pitti> mdz: that hal locking patch was proposed and put into CVS HEAD today, so our version does not yet contain it
<pitti> mdz: and it does not support locking by pid
<mdz> pitti: does it have some other way of dealing with stale locks?
<pitti> mdz: as far as I understood the patch, no
<pitti> mdz: if a device is locked, you have to explicitly unlock it again
<mdz> hmm
<pitti> hmm too
<mdz> this is really Hoary material :-/
<pitti> mdz: maybe, but we have to fix this burning stuff for warty
<pitti> mdz: I hacked at pmount today, pid-locking is ready
<mdz> pitti: maybe nautilus could tell gvm to disable all automounting temporarily
<pitti> mdz: I don't know, npmccallum should tell his opinion about this
<pitti> mdz: you mean the cd burning app tells gvm?
<mdz> pitti: he should be in this channel anyway
<mdz> pitti: yes, as a temporary measure
<pitti> mdz: then we only need to cross our fingers that the cd burning app is not killed/crashed
<fabbione> am i still alive?
<mdz> yes
<pitti> fabbione: <philosophy>What does "alive" mean?</philosophy>
<fabbione> pitti: i lost connection.. and i tought i did a ping timeout
<pitti> mdz: I think its ugly and confusing if you cannot plug in your usb devices while burning a cd
<pitti> mdz: this lasts about 15 minutes, at least I don't want to watch this :-)
<fabbione> mdz: ok.. i am on the ppc...
<fabbione> mdz: is that uml or something?
<mdz> fabbione: no, G4
<npmccallum> woah, didn't know this channel existed... ;)
<mdz> pitti: locking is notoriously complex, and adding locking to existing software _always_ introduces bugs :-/
<pitti> mdz: agreed. But I don't have any better idea
<pitti> mdz: do you?
<pitti> npmccallum: welcome in the channel :-)
<pitti> mdz: we have three weeks for testing left
<mdz> pitti: those are three weeks of bug fixing and stabilization, not adding new code that needs to be debugged
<fabbione> mdz: ok...
<mdz> fabbione: xfree86 build-deps are already on there
<fabbione> mdz: anyway to get access to amd64 too?
<fabbione> cool
<mdz> fabbione: yes, booting it now
<pitti> mdz: I know... So do you want to leave cd burning broken?
<fabbione> mdz: good
<truk_away> hi, is this a open channel?
<mdz> it is, but please keep the signal/noise ratio high
<fabbione> mdz: do you have ccache installed on that ppc?
<fabbione> mdz: it might turn to be useful
<truk_away> mdz: no problem
<mdz> fabbione: installing now
<mdz> fabbione: I reinstall that machine every few days
<fabbione> mdz: ok
<fabbione> ah ok
<fabbione> mdz: do you preserve /home or do you wipe it away?
<sivang> npmccallum : i figured this channel would open someday or another after release :)
<mdz> fabbione: I used to restore it
<mdz> fabbione: but this takes a long time, since herbert often has kernels on it
<mdz> fabbione: I prefer to wipe it
<npmccallum> pitti: I must have just missed the memo :)
<mdz> fabbione: amd64 is on port 20222 on the same host
<fabbione> mdz: ok.
<mdz> fabbione: added your keys
<fabbione> mdz: ok.. working on it..
<fabbione> ppc is building
<fabbione> mdz: can you copy xfree86 source from ppc to amd64? it will save you a few MB of data
<mdz> fabbione: they are on the same LAN; you can do it
<mdz> fabbione: ok, I put it in /tmp
<mdz> I already had it on the machine in my homedir
<fabbione> mdz: ok thanks
<fabbione> done.. thanks
<fabbione> mdz: eheh but i don't like to sneak around in other people machines/homedir
<fabbione> ok.. i386 is uploading, ppc and amd64 building
<fabbione> i am off
<mdz> bye
<npmccallum> mdz: I have the ubuntu-audio theme package ready, if you'd like to take a look at it
<npmccallum> Should we create a LaptopInstall page on the wiki to detail how various laptop installs went?
<npmccallum> and tricks to get stuff working
<mdz> npmccallum: I'd like to have a basic hardware compatibility list in the wiki
<mdz> laptops, sound cards, video cards, etc.
<mdz> basically, yes, please do
<npmccallum> mdz: do you want me to create a bug for the ubuntu-sounds package?
<mdz> npmccallum: please have someone else review it; I am swamped
<npmccallum> mdz: ok
<mdz> npmccallum: lamont and thom should be awake
<mdz> maybe seb128 as well
<npmccallum> mdz: thanks
<npmccallum> seb128, lamont, thom: ping
<seb128> pong ?
<npmccallum> seb128: If you have time, I need someone to review the ubuntu-sounds package
<seb128> where is it ?
<npmccallum> do we have access to people.* yet?
<sivang> npmccallum : i can help you review it
<mdz> npmccallum: people.no-name-yet.com still works fine
<npmccallum> mdz: where are we ssh'ing to these days? chinstrap is not responding for me
<mdz> npmccallum: it's there, it's just loaded
<fabbione> mdz: NOOO
<fabbione> are you rebooting the ppc??
<mdz> fabbione: I copied the packages off
<mdz> fabbione: they are uploading now
<fabbione> I was already uploading
<mdz> crap
<mdz> I cannot cook my lunch with that machine on
<mdz> and I am starving
<mdz> fabbione: how much had you uploaded?
<fabbione> 2/3 packages..
<mdz> I thought you were gone
<truk_away> if you write in wiki about laptops, write about hibernate and its actual status in ubuntu
<fabbione> mdz: i was wathing a movie.. and it just finished
<mdz> fabbione: I've uploaded 10 packages
<fabbione> mdz: did you upload the others somewhere else?
<mdz>  /~mdz/xfree86
<fabbione> machine?
<mdz> rookery
<fabbione> ok
<fabbione> well
<fabbione> we need all of it
<mdz> it is going
<mdz> I only have 256k up, so it takes a long time
<fabbione> ok
<fabbione> well ppc is still building
<fabbione> when it finish can you upload the .deb to roockery too?
<fabbione> i am off to sleep pretty soon
<mdz> fabbione: are there even any amd64- or powerpc-specific fixes?
<fabbione> mdz: the nv driver is arch all
<fabbione> s/all/any
<fabbione> so yes
<fabbione> i need all of them
<mdz> probably no one will even download amd64 or powerpc, honestly
<mdz> you should announce the i386 packages
<mdz> don't wait for amd64 and powerpc
<mdz> if it works for people on i386, I am happy for you to upload it
<mdz> it takes hours and hours to get the others
<fabbione> mdz: all the changes have been tested... it's 10pm and i have been working with this stuff since 6am
<fabbione> mdz: + the 3 days before
<fabbione> mdz: i am going to generate the Packages file
<fabbione> if anybody can be so kind to announce them I will be very happy
<fabbione> ah great
<fabbione> there is no dpkg-scanpackages on roockery
<daniels> fabbione: want me to do an announce?
<daniels> fabbione: i think i'll go back and do some more ati work and announce it separatemy for testing
<daniels> separately, even
<mdz> fabbione: there will be apt-ftparchive
<fabbione> daniels: i am creating the archive.. just a sec
<mdz> powerpc build is making debs
<fabbione> deb http://people.no-name-yet.com/~fabbione/X warty main
<fabbione> mdz: well no problems.. we have i386 up as you said..
<daniels> man, so much arse. i had to get up at ~7:30am, so i decided to stay up through the night.
<daniels> and what do I get, but an email saying 'hi guys! have an urgent meeting in sydney, can't make it, hope we can catch up again soon. cheers.'
<daniels> #()$U*
<mdz> daniels: yes, please make an announcement, and add comments to the bugs affected so that the submitters and CC get them
<daniels> mdz: will do
<fabbione> mdz: there are at least 11 bugs that will be closed
<daniels> fabbione: could you please just drop me a changelog in /msg?
<fabbione> some submitters won't be able to test the fixes
<mdz> fabbione: "change several bugs at once" makes it trivial
<daniels> mdz: ... how do you do that?
<fabbione> mdz: that was not the point :-)))
<fabbione> <fabbione> some submitters won't be able to test the fixes
<fabbione> ^^^
<mdz> fabbione: so you don't think we should tell them??
<daniels> oh, the link's there, only on certain pages
<mdz> daniels: you do a search, and then click the link, checkbox the bugs
<fabbione> mdz: never mind.. 
<fabbione> daniels: http://people.no-name-yet.com/~fabbione/changelog
<fabbione> that's the full changelog
<fabbione> mdz: i think we can tell them, but they won't see "anything" happening, because some of the bugs show up only at first install time
<fabbione> daniels: do you need anything else?
<daniels> fabbione: that's it -- thanks dude
<fabbione>   A 858 Sep 20 Fbio Mendes                         (4895) . x configuration                                                      
<fabbione> daniels: it looks like the xresprobe problem
<daniels> yeah, I'll deal with that one
<daniels> yah
<fabbione> do you mind to take a look?
<fabbione> ok
<fabbione> I am off to bed
<fabbione> good night
<daniels> night dude :) sleep well
<mdz> fabbione: night
<azeem> ah, it's filling up
* daniels sleeps.
<daniels> hm
<daniels> mdz: do you know what the undefined symbol was on ati for powerpc?
<mdz> daniels: I pasted the log here
<mdz> er
<mdz> that was i386
<daniels> ARSE
<mdz> powerpc, fabio said it FTBFS
<daniels> a stupid typo
<daniels> yeah
<daniels> paramaters
<mdz> but ubuntu19 builds fine on powerpc
<mdz> haven't tried to run it yet
<daniels> yeah, ubuntu19 doesn't contain my ati crack
<daniels> but it's ok, it will build if i learn to type
<daniels> fabbione: ok, i've started ubuntu20 locally, just with the ati changes
<daniels> fabbione: when I wake up, I'll drop you the diff so we can work together on 20
<daniels> fabbione: the pll thing was just a typo :\
#ubuntu-devel 2004-10-02
<mdz> daniels: did you announce ubuntu19?
<daniels> mdz: yes, to -users
<daniels> gone now
<thom> npmccallum: wassup?
<npmccallum> thom: seb128 is taking care of it, thanks
<Kamion> mdz: much quieter, thanks, didn't know we'd started this
<Kamion> mdz: the d-i builds that are used are all in debian-cd/tools/boot/warty/; if you regard those scripts as configuration files, it's configurable
<mdz> could someone send an announcement to the ubuntu-devel list?
<mdz> lamont: is linux-restricted-modules happily building?
<lamont> nope.  missing build-depends: bzip2
<lamont> that'd be 1.1-4
<lamont> bzip2 -c fireglcontrol.qt3.gcc3.3.4 >fireglcontrol.qt3.gcc3.3.4.bz2
<lamont> /bin/sh: line 1: bzip2: command not found
<lamont> make[1] : *** [fireglcontrol.qt3.gcc3.3.4]  Error 127
<lamont> but it got that far...
<lamont> did daniels get his ftbfs info?
<mdz> dunno
<mdz> I'll fix l-r-m now
<lamont> hanks
<lamont> thanks, even
* lamont wanders back over to his test machine to stare at postfix some more
<lamont> oh, so samba... do we just want to disable sendfile?
<mdz> lamont: if in doubt, we should do what debian and upstream say is the right thing
<mdz> lamont: new l-r-m uploaded; please keep an eye on it, people are waiting
<mdz> Kamion: still here?
<mdz> Kamion: I'm looking for bug #13009
* lamont grumbles at kamion, d-i, and postfix.
<lamont> Kamion: could it possibly be that postfix's postinst gets run before the hostname gets set?
<lamont> that would explain it.
<mdz> postfix gets installed by debootstrap
<mdz> where the hostname is set, as far as I know
<lamont> was just able to reproduce the bug (aliases not built), but purge/reinstall postfix and all is well.
<lamont> sigh.\
* lamont wonders how painful it is to take an ubuntu archive and produce a CD image...
* lamont finds a, um, clever solution to his postfix issues.
<mdz> lamont: l-r-m happy now?
<lamont> yep
<lamont> and uploade.
<lamont> d
<lamont> ls lrm still i386 only?
<mdz> lamont: yes, for now
<mdz> nvidia, at least, comes in amd64 as well
<jdub> ahr
<jdub> morning
<mdz> morning
<mdz> jdub: are you going to follow up to Subject: Common Desktop goals
<mdz> ?
<mdz> jdub: (cross-posted to debian-desktop and ubuntu-devel)
<jdub> yeah
<jdub> (and userlinux discuss!_
<mdz> hah, yeah
<jdub> (that's where i first saw it)
<jdub> (bleagh)
* lamont_r screams
<mdz> reinstall, back later
<fabbione> morning guys
<jdub> yo fabbione 
<fabbione> hey jdub 
<fabbione> mdz: are you still around?
<fabbione> daniels: you around?
<bob2> I think he's netless
<bob2> for now
<fabbione> ok
<daniels> fabbione: hey dude
<daniels> i just had to pop out for like 4 hours
<daniels> so I started uploading my ubuntu20 stuff just before I left
<daniels> it's on xfree86_4.3.0.dfsg.1-6ubuntu20.diff.gz now
<daniels> (no .orig.tar.gz, just the binaries and diffs and stuff)
<fabbione> daniels: what did you add to ubuntu20?
<fabbione> because i have the fix for the brasilian keyboard too
<fabbione> can you send me the usual interdiff too?
<fabbione> so i can resync the repo here?
<fabbione> and btw.. since 19 is not in the archive we shouldn't bump to 20
<fabbione> (just cosmetic)
<fabbione> at the end nobody cares of a missing version
<daniels> fabbione: all that's in 20 is my ati stuff (the backport, plus fwpll, plus the #911 resync)
<daniels> a patch for s/synaptic/synaptics/ in dexconf
<daniels> that's it
<daniels> if you drop me the brazilian keyboard diff, i'll merge that and throw you an interdiff
<fabbione> just throw me the interdiff and i will merge here
<daniels> er, xlibmesa-dri-dbg is uploading right now
<daniels> you could have to wait a while :)
<fabbione> no problem :-)
<daniels> xlibmesa-dri-dbg_4.3.0.dfsg.1-6ubuntu20_i386.deb                                                 8% 4236KB   1.4KB/s - stalled -
<fabbione> but i think we should let users test ubuntu19 for a little while before pushing another update
<daniels> (it's not really stalled, it's just that the uplink is saturated)
<daniels> yeah
<daniels> i totally agree
<daniels> that's why i'm not pimping this yet :) i just want to get this out there to some specific ati people
<jdub> daniels: you've done rad ati stuff?
<daniels> jdub: r4xx support and tv out on ibooks
<jdub> tv out on ibooks!
<jdub> oh, not with rage128 though, right?
<daniels> jdub: um, that should already work
<jdub> oh?
<daniels> yeah, with aty128fb
<fabbione> daniels: did you check for that RADEONPPL symbol missing on ppc?
<fabbione> daniels: otherwise it would be a really good idea to get the packages built on ppc too
<daniels> fabbione: yeah, that was me being a tool
<daniels> note to self: 'paramaters' is not a word
<fabbione> eheh
<daniels> it was a one-character fix
<daniels> that I just hand-hacked the diff for
<fabbione> you suck :P
<jdub> daniels: whoa.
<fabbione> mdz: ping
<fabbione> mdz: deping ;)
<mdz> gack
<mdz> this ext3 filesystem has a strange layout, parted can't resize, yada yada
<mdz> s/ext2/ext3/
<mdz> though the filesystem is ext3 and recognised as such
<mdz> jdthood: hi
<jdthood> Hi there
* jdthood guesses that mdz has questions about ALSA packaging
<mdz> I do?
<mdz> actually I have questions about parted :-/
<mdz> it can't resize my ext3 filesystem, which has brought by install to a screeching halt
<jdthood> mdz: I think you are mistaking me for someone else.  :)
<mdz> you are not Thomas Hood?
<jdthood> mdz: Yes, but I don't have any special knowledge about parted.
<mdz> nah, I didn't mean to imply it
<mdz> before you /joined I was moaning about my parted problems
<jdthood> mdz: The reason I thought you were going to ask me questions about ALSA packaging is that (1) you uploaded alsa-utils 1.0.5-1ubuntu2 and (2) I was involved in putting out the new upstream alsa-utils 1.0.6-1.
<jdthood> Congratulations on ubuntu, by the way.
<mdz> thanks; have you tried it?
<mdz> I don't think we'll be pushing in a new upstream alsa-utils this close to release unless it fixes something important
<mdz> though we are considering backporting the kernel stuff
<jdthood> mdz: Re: trying ubuntu -- No, I haven't tried it but I will follow its progress.
<jdthood> mdz: Re: alsa-utils -- You have to make judgments with one eye on your schedule, I know.  It may be helpful if I tell you a bit about what's been going on.  I was recently recruited to the alsa packaging team.  I have made a few changes that I thought were important to make before sarge.  One of them was fixing alsaconf.  ubuntu has removed alsaconf entirely, so that won't affect you.
<mdz> alsaconf scares me
<jdthood> mdz: What may interest you more is that I have improved the alsa initscript.  This ships in the alsa-base package, of course.  I am pretty sure that the new script is less buggy than the previous one.
<mdz> jdthood: oh, what sort of bugs did you fix?
<jdthood> mdz: force-stop is now more useful, for one thing.
<mdz> as you probably noticed, we've just made a couple of small changes to it
<mdz> the unmuting is probably of general interest, but I wanted to get it right (including multiple cards) before sending it upstream
<jdthood> mdz: Yes, unmuting is a headache.
<jdthood> mdz: An important change to alsaconf is that it writes an /etc/modprobe.d/sound file that contains an "install" line that makes the module loader call a hook script after loading the sound card driver.  This hook can be used to do "alsactl restore".
<jdthood> Thus, alsactl restore happens after module load.
<jdthood> We still do "alsactl restore" in the initscript start method too because integral sound card drivers are never loaded by the module loader.
<jdthood> The above doesn't work properly on a udev system, though.
<jdthood> On a udev system the "alsactl restore" has to be done from a dev.d script.
<jdthood> We haven't implemented that yet.  Supporting udev isn't a priority for sarge.
<seb128> morning
<jdub> hey seb128 
<seb128> hey hey jdub 
<seb128> jdub: n-c-b 2.8.2, ok for update ?
<jdub> yes thanks
<seb128> thanks to you :)
<fabbione> daniels: how is the upload going?
<seb128> jdub: I need to update gnome-cups-manager the current version doesn't include the .mo files ... I think that's ok ? :)
<seb128> version = package, a missing line in the .install to fix, that's all
<daniels> fabbione: good good
<daniels> fabbione: do you need the interdiff now?
<daniels> i can throw it to you if you need it
<jdub> seb128: sure
<Kamion> mdz: #13009? if it's not on bugs.debian.org, we don't have it :(
<Kamion> lamont: I'm *fairly* sure the hostname gets set before debootstrap nowadays ...
<lamont> Kamion: hrm.
* lamont up way to damn early.
<lamont> actually just up for a minute, checking to see if I'm back online or not...
<Kamion> lamont: holy crap, man
<daniels> lamont: dude, that's inhuman
<lamont> well, the 12 year old wanted up early to work on homework...
<lamont> sleep is good.
* lamont goes back to bed. back in about 35 minutes or some such.
<fabbione> Kamion: thanks for the procmail stuff.. i managed to move everything out of MUA's filters
<fabbione> daniels: please upload the patch now if you can so we don't desync the trees
<Kamion> fabbione: cool. my procmailrc is a bit gnarly, I should tidy it up
* lamont giggles.
<fabbione> Kamion: ehehe well.. i didn't use all the bits, but it works fine
<lamont> I'm associated with the _other_ hilltop.
<fabbione> hey lamont 
<fabbione> you are supposed to go back to sleep
<daniels> fabbione: ok, i'll start uploading to people.nny.com/~daniels/
<lamont> fabbione: check.  later
<fabbione> daniels: ok thanks
<fabbione> the interdiff should be pretty small anyway
<daniels> yeah
<daniels> it's ojust 099j, 099k, the dexconf synaptics tuff, and, a resync of 911
<daniels> that's tit
<daniels> fabbione: interdiff uploading now
<daniels> ok, it's up at http://people.no-name-yet.com/~daniels/xfree86/xfree86_4.3.0.dfsg.1-6ubuntu19-to-20.diff
<fabbione> tahnks
<fabbione> daniels: patch is merged
<fabbione> daniels: you need to ask somebody to build ubuntu20 on ppc
<fabbione> and verify the fix
<fabbione> brb
<Kamion> mdz: did you get a chance to test with a modified debootstrap script for pcmcia-cs?
<jdub> so this wacky acpi stuff
<jdub> does the -26 patch mean we'll be able to load DSDT foo to make pooey laptops work?
<jdub> "allow config to specify custom DSDT"
<jdub> (hope that's not build time)
<thom> you append the DSDT to the initrd AIUI
<jdub> i thought that was a different patch?
* jdub can't even build the stupid intel iasl thingy
<pitti> Yeah, another stupid hal bug found and fixed
<jdub> pitti: have you looked at the latest release?
<pitti> jdub: not yet
<pitti> jdub: we cannot sync that anyway, don't?
<pitti> I debugged the stuff on mojo's computer
<pitti> (he let me access it as root)
<jdub> pitti: if we thought it safe enough and important enough, we probably could sync it.
<pitti> jdub: hmm. 0.2.97 had severe regressions
<pitti> jdub: I hope that 0.2.98 is better
<pitti> jdub: anyway, I don't trust this hal thingy too far, I would really prefer backporting bug fixes instead of syncing
<pitti> jdub: or just fixing the things on our own, as we have done until now
<jdub> pitti: probably worth checking some of the bugfixes tho :)
<pitti> jdub: yes
<pitti> jdub: actually I tried to download it yesterday, but my URL is outdated.
<pitti> have to google for it, I suppose
* jdub is surprised by disk speed once hdparm is set up nicely
<jdub> pitti: hal.freedesktop.org?
<pitti> jdub: this is impressively, I agree
<Kamion> just a shame it seems to break some systems
<pitti> jdub: actually I thought I looked there. Anyway, thanks
<pitti> jdub: yep, I looked there. It has hal-0.2, from Dec 2003
<jdub> hrm, bong
<jdub> http://freedesktop.org/~david/dist/
<pitti> jdub: thanks!
<pitti> jdub: the buffer overflow I just fixed is still present in 0.2.298
<pitti> 0.2.98, that is
<pitti> jdub: I will send the patch to David
<jdub> cool
<fabbione> daniels: diff -Naurd xc.orig/ xc > ../debian/patches/991_ubuntu_mga650_hack.diff 
<fabbione> daniels: it might even work :-)
<pitti> jdub: #1450, request for upload permission
<Kamion> mdz: did you intend to remove binutils from Base along with ksymoops?
* Kamion is wary of that change
<seb128> jdub: what do you think about #1550 ?
<jdub> seb128: i can take that one
<seb128> jdub: you don't need, I just want to know what do youn think ... nautilus as default ?
<jdub> seb128: yeah, i think the ftp handling is good enough now
<jdub> seb128: especially with the keyring support
<seb128> ok, I'll make a patch and send it upstream
<jdub> thanks :)
<seb128> np :)
* lamont wonders if his connectivity is as crappy as it seems..
<Kamion> thom: would you be available to do some jigdo stuff for me today?
<thom> sure
<Kamion> instructions are:
<Kamion>   * Make ISO images as normal, and generate jigdo files (using either
<Kamion>     mkisofs and jigdo, or mkisofs with the included JTE patch)
<Kamion>   * Copy the .jigdo and .template files to a machine exporting the
<Kamion>     mirror via HTTP
<Kamion>   * On that machine, run mkjigsnap (see the man page) against those
<Kamion>     files to generate the needed snapshot ready for download. I'd
<Kamion>     suggest http://<mirror>/jigit/ as a download point.
<Kamion> I'm working on the first bit now
<Kamion> does having an ssh trigger to do steps 2 and 3 sound feasible?
<thom> yeah, sounds like the best way
<seb128> jdub: gnome-vfs 2.8.1  ... ok for upload ? (dunno if I have to ask for each gnome 2.8.n releases :)
<Kamion> hey Sledge
<Sledge_> hey guys
<jdub> seb128: ...
<seb128> jdub: ....
<seb128> :p
<jdub> seb128: yes, ok
<Kamion> so, need to make debian-cd on little generate jigdos, and therefore need to give it some URLs
<Sledge_> Kamion: yup
<jdub> seb128: in general, it's okay unless you think a change is controversial
<seb128> ok
<jdub> seb128: or too big
<Kamion> Sledge_: should I set the fallback URL to http://archive.ubuntulinux.org/cdimage/jigit/, then?
<Kamion> (assuming that's where we're going to put the snapshot archive)
<seb128> don't worry, I don't make quick upload of new versions without testing :)
<Kamion> seb128: aww
<Sledge_> Kamion: I think you need to add a /snapshot/ in there too
<jdub> seb128: ehhhhxcellent :)
<Sledge_> just checking
<seb128> :)
<Kamion> Sledge_: hm, presumably we'd want to have a snapshot tree per release; we want to keep the one for warty around when we're developing hoary
<Sledge_> yup
<Kamion> so maybe http://archive.ubuntulinux.org/cdimage/jigit/warty/snapshot/
<Kamion> yay long URLs :)
<Sledge_> yes, something like that
<Sledge_> the mkjigsnap script is set up to create dated snapshots in fact
<jdub> seb128: upstream are killing wifi applet, using netstatus instead ;)
<Kamion> Sledge_: do I leave JIGDOFALLBACKPATH unset? I guess mkjigsnap creates that
<Sledge_> so the easiest way to use that would be to put symlinks in
<seb128> jdub: yes, I've read that
<Sledge_> Kamion: JIGDOFALLBACKPATH is used when creating the jigdos in the first place
<Sledge_> mkjigsnap reads that jigdo rather than modifying it
<Sledge_> the JIGDOFALLBACKPATH can be added by hand easily, in fact
<Kamion> right, but it looks like debian-cd creates a hardlink tree yourself if you set that
<Kamion> s/yourself/itself/
<Sledge_> yes, it does
<Kamion> JIGDOFALLBACKURLS I understand I need to set
<Sledge_> gah, sorry
<Sledge_> misparsed what you wrote
<Sledge_> JIGDOFALLBACKPATH doesn't need to be set unless you're going to generate the images on the mirror
<Sledge_> otherwise it wastes time creating a snapshot tree on the CD build machine
<Sledge_> JIGDOFALLBACKURLS wants to point to the right place so that people downloading the jigdo bits by hand get the right stuff
<Kamion> export JIGDOFALLBACKURLS="Ubuntu=http://archive.ubuntulinux.org/cdimage/jigit/$CODENAME/snapshot/"
<Kamion> let's try that, then
<Sledge_> yup
<Kamion> I think I'll need to frob debian-cd a bit to deal with the Ubuntu label though
<Sledge_> ok
<Kamion> leaving JIGDOINCLUDEURLS unset until I figure out what needs to happen there ...
<Sledge_> you probably don't want it anyway
<Kamion> well, we do have a few mirrors
<Sledge_> it's in case you want to include a standard block in all the jigdo places
<Sledge_> ok
<Sledge_> Kamion: the normal setting tat manty uses is JIGDOFALLBACKURLS="Debian=http://gluck.debian.org/cdimage/snapshot/cd/$ARCH/Debian/
<Sledge_> on gluck
<Sledge_> you may need to s/Debian/Ubuntu/ on that
<Sledge_> or set it to Ubuntu=http://archive.ubuntulinux.org/cdimage/jigit/$CODENAME/snapshot/Ubuntu
<Kamion> I was thinking of dropping /Ubuntu from the path actually ...
<Sledge_> ah, ok
<Kamion> we don't have a Non-US equivalent
<Kamion> but yeah, I've done s/Debian/Ubuntu/ on tools/jigdo_create
<Sledge_> fine
<Kamion> just trying build.sh i386 now
<Kamion> jigdo-file --cache=/srv/cdimage.no-name-yet.com/scratch/tmp/jigdo-cache.db make-template --force --files-from=/srv/cdimage.no-name-yet.com/scratch/tmp/jigdofilelist --image=/srv/cdimage.no-name-yet.com/scratch/debian-cd/i386/warty-i386-1.raw --jigdo=/srv/cdimage.no-name-yet.com/scratch/debian-cd/i386/warty-i386-1.jigdo --template=/srv/cdimage.no-name-yet.com/scratch/debian-cd/i386/warty-i386-1.template --merge=/srv/c
<Kamion> that's a command-and-a-half
<Sledge_> :-)
<thom> yow
<Kamion> Sledge_: any way to convince it not to look at installer-$(arch-that-isn't-the-current-one)?
<Kamion> Match of `dists/warty/main/daily-installer-amd64/20040801ubuntu13.0.20040918/doc/INSTALLATION-HOWTO' at offset 14006272
<Kamion> Match of `dists/warty/main/daily-installer-i386/20040801ubuntu13.0.20040918/doc/manual/cs/apa.html' at offset 14024704
<Sledge_> remove those from the jigdofilelist
<Kamion> ah, right
<Kamion> I think I might well end up switching to JTE, this isn't so fast ...
<Sledge_> :-)
<Sledge_> you noticed...
<Kamion> it's bearable for daily builds certainly, but our preview release from start of CD builds through downloads and testing to release took an hour and five minutes
<Sledge_> ok
<Kamion> I didn't realize earlier that I was going to be under quite such time pressure :)
<Kamion> anyway, will start out with plain jigdo and speed it up later
<Kamion> Sledge_: what does the Filename= field in the .jigdo do?
<Sledge_> it specifies the default output filename for the .iso file
<thom> Kamion: btw, there's a file called make-torrent.sh in my ~ on little, and bittornado is installed
<thom> Kamion: so you can integrate BT into the build too :-)
<Kamion> thom: awesome, will wait until after I've finished my side of the jigdo stuff though :)
<thom> sure
<thom> mdz_: are you happy for me to upload the new bittornado to warty? (upgrade from 0.2.0 to 0.3.0)
<mdz_> thom: universe, right? sure
<thom> mdz_: nod
<Kamion> mdz_: have you been following the parted stuff on #ubuntu?
<Sledge_> Kamion: how's the jigdo thing going?
<Kamion> Sledge_: just been rebuilding a couple of times to try to get all the filenames right, usual debian-cd tediousness
<Kamion> um, "tedium"
<Sledge_> :-)
<Sledge_> sorry, that should be :-(
<Kamion> mdz_: it looks like we may have to upgrade to parted 1.6.11 plus a Debian patch to fix it, which involves a soname change
<sivang> bittornado is a full fledged BT gui?
<Kamion> mdz_: the current version in unstable contains all our fixes, so in principle it's syncable, but I will have to review the entire diff
<thom> sivang: no
<Kamion> Sledge_: what's the SNAPSHOT= thing in the generated .conf file
<Kamion> Sledge_: er, sorry, pressed Enter too soon
<thom> it's much faster than bittorrent
<Kamion> Sledge_: what's the SNAPSHOT= path in the generated .conf file relative to?
<Sledge_> Kamion: relative to the place where the <foo>.conf is found
<Kamion> Sledge_: ah, I think I see how to lay it out now
<Sledge_> ok
<mdz_> Kamion: no, I have been offline a great deal
<mdz_> Kamion: what breakage does 1.6.11 fix?
<mdz_> Kamion: if it fixes the "this ext2 filesystem has a rather strange layout", I might be sold
<Kamion> mdz_: destruction of partition tables generated by modern versions of Windows
<mdz_> eek
<mdz_> elmo: I removed it from base and forgot to add it back to supported
<elmo> ok
<sivang> thom : conflicts with bittorent. just tried it and it "killed" the original client
<Kamion> Sledge_: is there any way to have the final .jigdo and .template files generated on little (our actual CD image build machine) rather than on auckland (the machine where mkjigsnap's going to be run)?
<thom> sivang: yep, the programs all have the same name
<mdz_> elmo: fixed
<Kamion> Sledge_: hm, actually, never mind, I'm being confused
<azeem> sivang: this is fixed in unstable, AFAIK
<Sledge_> Kamion: absolutely, that's exactly what I was expecting you to do
<Kamion> mdz_: did you intend to remove binutils from base too?
<mdz_> Kamion: it should go away on its own, shouldn't it?
<mdz_> I think it was only there for ksymoops
<Kamion> ok, as long as that's what you intended
<Kamion> I saw it and went "eek" :)
<Kamion> will need a new debootstrap upload, then
<Kamion> ack/nack?
<mdz_> ack
<sivang> thom : we'd better change them? it it reasonable for someone to have both clients present?
<sivang> thom : *is
<doko> npmccallum: I see you changed the bash prompt in skel.bashrc, but not in etc.bashrc. what was the reason for the change?
<Kamion> thom: could you grab little:~cjwatson/jigit/mkjigsnap?
<thom> sivang: as azeem said, it's fixed in the version i'm uploading
<Kamion> thom: I think it needs to be run as 'mkjigsnap -n warty-i386 -m <path to archive mirror> -o <path to cdimage mirror>/jigit/warty -j <path to cdimage mirror>/daily/current/warty-$(arch).jigdo -t <path to cdimage mirror>/daily/current/warty-$(arch).template -k Ubuntu', for arch in amd64 i386 powerpc
<npmccallum> doko: the only difference I can see is the ':', right?  Probably just a typo...
<thom> Kamion: 'k, will look in a sec
<doko> ok. then I'll sync that. thanks for the color prompt anyway.
<Kamion> thom: I think you'll also need to change the cdimage archvsync trigger to exclude jigit from the sync, otherwise it'll get trashed
<npmccallum> doko: yeah, I hate bw prompts -- when you do ls 2x, you cant tell where one ls ended and one begain
<doko> is there any reason that we don't source /etc/bash.bashrc from /etc/profile? I'd like to sync that with the skeleton files
<npmccallum> doko: I have no idea
<Kamion> thom: ok, there are now .jigdo and .template files in /cdimage/daily/current/ which should be usable
<Sledge_> Kamion: how do I go about getting the jigit package into ubuntu?
<Kamion> Sledge_: in general, mail ubuntu-devel@lists.ubuntu.com; will need to convince mdz/jdub
<Kamion> Sledge_: once we've demonstrated it to work with our ISOs it should be a much easier sell
<Sledge_> of course
<Kamion> anyway, I think the ball's in thom's court for the time being, I'll wait until he bounces it back to me :)
<Sledge_> :-)
<Sledge_> Kamion/thom: can you mail me when the bits are in place on archive.ubuntulinux.org so I can d/l and test too?
<Kamion> Sledge_: will do
<thom> yep.
<thom> just having some tea
<elmo> oi
<thom> and celebrating australia losing to england at cricket
<elmo> what the hell are you guys running on auckland
<Kamion> uh, not me?
<elmo> no, talking about running I mean
<Kamion> elmo: hardlink snapshot of the archive at CD generation time so that jigdo is even possible
<elmo> we need to not be doing stuff on auckland - the torrent stuff was a mistake that happened 'cos it was at the last minute. 
<Kamion> elmo: correct, all the jigdo stuff will happen on little, and bittorrent is being moved there
<elmo> kamion: what needs the harlinks?  jidgo server or jidgo user?  does the snapshot need to be publicly available?
<elmo> kamion: okay, if it's happening on little, what's thom doing?  his r00t powers scare me :P
<Kamion> elmo: in order to do a jigdo download, the client *must* have access to a fallback snapshot of the archive at the point when the CD was generated
<Kamion> elmo: most of the downloads happen from a local mirror, but you have to have the fallback snapshot otherwise the download will fail as soon as anything in the archive changes
<elmo> kamion: so jidgo users all come hit up our BW?  reeeesult
<Kamion> elmo: no more than they would by grabbing the ISO, usually much less
<elmo> yeah
<Kamion> (this is the same as what gets done on gluck, BTW)
* Sledge_ hides from elmo
<elmo> I thought most of the cdimage stuff had moved to maswan?
<Kamion> the jigdos are built on gluck; if maswan syncs the snapshot archives too, it's his bandwidth I guess
<Kamion> see gluck:/org/cdimage.debian.org/www/snapshot/
<Kamion> elmo: the thing I wanted done on auckland is little:~cjwatson/jigit/mkjigsnap, which is Sledge's script to hardlink-snapshot an archive; I need to have auckland run it after it finishes the cdimage archvsync
<Kamion> (it's a bit of a race technically, but as long as the CD build time doesn't exceed the archive's StayOfExecution then it works)
<Sledge_> Kamion: how long are you thinking of keeping each snapshot around?
<elmo> SOE is a day
<Kamion> well, we're building stuff daily, so absolutely not more than a week except for say the warty release jigdo
<Sledge_> ok
<Kamion> or sounder-test images I guess :-/
<Sledge_> the mkjigsnap code deliberately creates dated snapshots, so it should be easy to clean up old ones with rm -rf <DATE>
<Kamion> elmo: are we still in "AARGH NO RUN AWAY" territory?
<Sledge_> time to go home and eat...
<elmo> kamion: one sec
<Kamion> thom: I think I've got bittorrent integration working now
<Kamion> pretty easy once I had the script
<sivang> Kamion : how much time after a package has been uploaded until it's on the archive for downloading?
<Kamion> it's better to direct questions to the channel rather than to me personally
<Kamion> sivang: anyway, the archive's "cron.daily" runs once every half-an-hour, source uploads get installed then, after each cron.daily run the buildds pick it up and then the binaries get installed at the next cron.daily after that
<sivang> ofcourse :)
<Kamion> sivang: so absolute minimum 30-something minutes
<sivang> ok, thanks
<sivang> yeah. figured that.
<sivang> tnx
<Kamion> elmo: who's the admin of the Italian mirror, and shouldn't that mirror be listed in Archive on the wiki?
<elmo> kamion: md
<elmo> and probably sure, he just mentioned it on irc so it got added to the website by jane/lu/someone
<Kamion> seems to be just a mirror of the preview release
<Kamion> it doesn't have MD5SUMS which is why my attention got drawn to it
<Kamion> thom: does the bittorrent tracker need any extra magic?
<Kamion> thom: I've tried starting a download, but it's just sitting at "connecting to peers"
<Kamion> thom: or do things get strange when the client is behind NAT?
<thom> it doesn't like nat at all
<thom> well, unless you can forward the ports correctly
<thom> Kamion: hrm, i think the mirror script is going to have to kick off the bt seeders
<Kamion> thom: what are those?
<thom> you have to have something to seed the tracker, ie you run a bt client on the local machine to get the file into the torrent
<daniels> elmo: dude, thankyou so very much
<Kamion> thom: that really wants to be done on auckland rather than little, right?
<daniels> elmo: source-only uploads absolutely rock my world
<daniels> elmo: so, I uploaded i386+source+all xfree86 to rookery (not including the orig)
<daniels> elmo: 18 hours on, it's just finished
<thom> Kamion: yep
<thom> so the mirror script would need to kick them off when it finishes the rsync
<thom> (we pushed 1500 i386 isos of the preview via BT, btw :-) )
<Kamion> nice
<Kamion> thom: that's entirely auckland-side, isn't it? little doesn't know when the rsync is finished
<thom> yep
<thom> but little logs in to the archvsync user and runs a script auckland side to run the rsync, doesn't it. i'm saying we tack it on that
<Kamion> thom: right, absolutely
<Kamion> I've never seen that script
<thom> Kamion: it's exactly what you'd expect :-)
<Kamion> thom: also, presumably the torrents need to be regenerated when I copy a daily build to release
<Kamion> thom: so it isn't just 'cp -a' any more
<Mithrandir> npmccallum: what TZ are you in?
<npmccallum> Mithrandir: EST
<npmccallum> Mithrandir: my hours are a little funky though (not too bad)
<Mithrandir> that's UTC-5 or so?
<Mithrandir> ok, I'm at fairly-normal CEST.
<Mithrandir> but I prefer to do work-work in the evening, so if UTC16-ish is ok with you?
<npmccallum> Mithrandir: depends on the day, but generally
<npmccallum> Mithrandir: check my time schedule on the company wiki
<Mithrandir> ok
<npmccallum> Mithrandir: I'm going to run to the store, should be back in about 10 if you need anything
<Mithrandir> sure, I have a problem with evo I need to track down..
<Mithrandir> man, I love corba. :/
<npmccallum> what is the best way to download the entire archive (warty/main)?
<Mithrandir> rsync?
<npmccallum> I just only want the newest stuff, I was wondering if there was some debian tool to do it
<Mithrandir> you can use debmirror or some other mirroring tool as well
* Kamion wonders why partman's progress bar for resizing a partition doesn't update from 0%
<Mithrandir> perhaps parted is busted?
<Kamion> probably
<Kamion> or partman, who knows :)
<Kamion> kernel          /boot/vmlinuz-2.6.8.1-2-386 root=/dev/hda6 ro vga=771 acpi=force quiet splash
<Kamion> hooray, the user-params stuff works for me
<sivang> Is there a specific doc for PXE install for ubuntu? or plain 'o debian would suffice?
* lamont_r wonders if his mail to ubuntu-devel actually made it through...
<sivang> lamont_r : it made it. about the buildlogs right?
<lamont_r> yeah
* lamont_r is out of the log-db-query-engine business
<lamont_r> which is good, since my router appears to have not survived the power hit this morning... :(
<sivang> ohh, i am going to build myself a ubuntu router , you want me thorugh in another for you ? (trying to encourage lamont_r)
<lamont_r> that's probably what I'll do - I have a more hardened x86 box, will probably switch from the hppa router to an ubuntu-powered x86 box
* lamont_r heads to town for a while, just to get away from everything...
<lamont_r> back on in a while.
<sivang> lamont_r : you feeling better since that nasty virus? I'm on pills for the last couple of days. only that fixed my dizziness
<lamont_r> running at about 80-90% I'd guess
<sivang> if only we could patch those..:)
<lamont_r> yeah
<lamont_r> anyway, back on in a while
<doko> Mithrandir, mdz: is there an overview, which packages use spell checking? or just get the reverse dependencies on aspell/ispell/myspell?
<Mithrandir> doko: i$language is the norm for ispell at least, aspell-$langcode and myspell-$langcode seems to be the norm for those
<mdz> doko: the ones which are high priority are evolution, openoffice and mozilla-thunderbird
<mdz> doko: let's say evolution and openoffice, those are in desktop
<mdz> followed by mozilla-thunderbird, abiword, and other stuff in Supported
<mdz> I believe gaim also does spell checking
<doko> ok, that's a starting point.
<Mithrandir> mdz: it does.
<Mithrandir> spellchecking should Just Work for those, in major languages
<Mithrandir> ?
<Mithrandir> we need to install extra dictionaries based on $LANG
<mdz> but does it?  please check
<mdz> we need to get a handle on which are working and which are not, and which spell checking libraries they use
<Mithrandir> mdz: yes, I'm talking about the goal, not the current state. :)
<mdz> and ensure that at least the english dictionary is installed by default
<mdz> then we can think about ways to get additional dictionaries
<mdz> for warty, I am not sure if it is feasible to select them at install time automatically
<Mithrandir> we need to check that the dictionaries work properly as well
<mdz> we may need to choose between including them by default, or requiring that they be installed later
<Mithrandir> yeah
<doko> dictionaries: these are the w<language> packages? or the aspell-$LANG, ispell-$LANG packages
<Mithrandir> doko: w$lang is just wordlists
<mdz> fabbione: here?
<sivang> mdz : from how it looks curerntly, most 2004 universe DSAs would be fixed by a sync from sid. :) (halfway finished)
<mdz> sivang: great, so it all comes down to whether they can be synched without changing main
<mdz> thom: ping?
<Mithrandir> mdz: you are going to want to kill me.
<Mithrandir> mdz: evolution needs a TLS enabled glibc.
<mdz> Mithrandir: on amd64?
<sivang> mdz : yes, however i havn't still reviewed 2002 and 2003, but 2004 is highest priority.
<thom> mdz: hi
<Mithrandir> mdz: yes.
<mdz> thom: hey. what's the good word on firefox?
<sivang> mdz : that is, the universe relavent parts.
<Mithrandir> mdz: or rather, in general
<mdz> Mithrandir: our glibc is TLS-enabled on i686 (with libc6-i686), is it not?
<mdz> Mithrandir: is it only a matter of turning some bits on, or something worse?
<Mithrandir> mdz: it's always TLS-enabled on i686
<Mithrandir> mdz: well.. it hasn't been _that_ much tested..
<Mithrandir> (on amd64)
<thom> mdz: i've got a few more rejects to clean up, and then a lot more testing
<mdz> Mithrandir: TLS is something which is only used when the application specifically uses it, is it not?
<Mithrandir> mdz: it uses the DB backend with DB_THREAD and that requires "fast mutexes" to be available.
<Mithrandir> mdz: nope.
<Mithrandir> mdz: you can turn it off with LD_ASSUME_KERNEL=2.4.1
<mdz> thom: what's the story with the localisation?  I was thinking that even if they are outdated upstream, we should relax the deps and at least get partial translations
<thom> (mostly because they seem to have funted with the l10n support since the last release)
<mdz> thom: then it will feed into the warty translation effort
<mdz> s/warty/ubuntu/
<Mithrandir> mdz: another option is to rewrite the backend for evo.  (No, I'm not doing that)
<thom> mdz: that's what i'm planning to test; i'm not sure how much they've changed - hopefully not so much that the old packages won't work at all
<mdz> thom: ah, I see
<mdz> Mithrandir: the glibc changes should only affect amd64, right?
<mdz> (please say yes)
<Mithrandir> mdz: yes, they should
<Mithrandir> it's a very trivial change to the source package, and I can test it for a few days before we upload if you want that)
<mdz> Mithrandir: please do test it, of course :-)
<Mithrandir> obviously, yes.
<Mithrandir> :)
* thom goes for an early night and vanishes
* Mithrandir has learnt far too much about evo today
* sivang is going for PXE warty install, and than to bed. Night everybody
<thom> 'night
<mdz> Kamion: how does the pcmcia-cs magic work?  does it use laptop-mode, or something else?
<Kamion> mdz: it tries to start up pcmcia, then looks in /sys/class/pcmcia_socket
<mdz> hmm
<Kamion> (it needs to start up pcmcia anyway)
<mdz> Kamion: I had forgotten that pcmcia starts during the installer too...
<mdz> Kamion: I wonder how it is that it worked in d-i but failed during a normal boot (https://bugzilla.ubuntu.com/show_bug.cgi?id=581)
<Kamion>        -f     Foreground:  do not fork and run as a daemon until after config
<Kamion>               uring any cards that are already present.
<Kamion> it uses that option, maybe that's relevant
<Kamion> (cardmgr)
<mdz> that's exactly the opposite of what I'd expect, how weird
<mdz> the problem in #581 was that it sat there in the foreground forever
<Kamion> although actually apparently that's to avoid a race condition
<mdz> if it's harmless to start pcmcia under d-i, it should be harmless to install it too
<mdz> but given the symptoms, it does sound like this would solve the problem anyway
<Kamion>                 CARDMGR_OPTS="-f" /etc/init.d/pcmcia start </dev/null 3<&0 2>&1 \
<Kamion>                         | logger -t hw-detect
<Kamion> that's the actual invocation
<mdz> I have (remote) access to the machine where it was failing before
<mdz> anyway, in the interest of solving this upstream's way, I'm OK with pcmcia-cs moving to ShipSeed
<Kamion> it definitely doesn't have PCMCIA? that would rule out having any cards that are causing problems
<Kamion>     - Add a new template, hw-detect/start_pcmcia, as a kind of workaround for
<Kamion>       systems where starting pcmcia hangs the system (Dell inspirons..).
<Kamion> (ddetect 0.87)
<Kamion> hw-detect/start_pcmcia=false is documented in the boot screens as a workaround for systems where starting PCMCIA crashes
<Kamion> there's no similar workaround for post-install if we have pcmcia-cs in Base, though
<Kamion> I think the submitter of #581 must just have been lucky pre-reboot :-/
<Kamion> so yeah, I think there are enough arguments
<mdz> I'm fairly certain it doesn't have pcmcia
<mdz> hmmm
<mdz> unfortunately, someone uses that machine as their primary desktop to do work
<mdz> so I've been trying to schedule a time when I could (potentially) break it for testing
<Mithrandir> we don't ship any 2.4 amd64 kernels?
<Kamion> Mithrandir: no
<Mithrandir> good
<Kamion> *are* there any 2.4 amd64 kernels? :) I thought 2.4 was totally unsupported on amd64
<Mithrandir> there are kernels, but nobody should use them
<Kamion> in fact, we don't have any 2.4 kernels in supported for any architecture
<Mithrandir> I'm removing support for < 2.6 for glibc for amd64, that's why I was asking
<mdz> Kamion: ubuntu-base needs to be added to base; do you have an upload pending or shall I do it?
<Kamion> no upload pending, but I'm used to debootstrap uploads and can do it easily
<Kamion> I should put my magic autoupdate script somewhere
<Kamion> half of it's in the debootstrap package ...
<Kamion> the other half relies on germinate though
<mdz> Kamion: ok, I'll leave it to you, then
<Kamion> mdz: hm, you closed that util-linux bug with "we haven't fixed this yet", but LaMont backported that fix to warty already
<mdz> Kamion: he did?  he didn't close the bug
<Kamion>  util-linux (2.12-7ubuntu3) warty; urgency=low
<Kamion>  .
<Kamion>    * Incorporate patch from Samuel Thibault via Debian.  Closes warty#468
* Kamion is catching up on warty-changes
<mdz> 468   	maj   	P2   	Oth   	lamont.jones@canonical.com   	ASSI   	  	delay in spawning new getty after logging out on console
* mdz growls at lamont
<mdz> Kamion: if you have the bug number handy, please reopen
<Kamion> mdz: what sort of things do you foresee going into ubuntu-base?
<Kamion> mdz: done
<mdz> Kamion: the little script to enable universe, an upgrade tool for warty->hoary if we need one, stuff like that
<Kamion> ok
<Mithrandir> mdz: 1545 will be fun to track down when I don't have such a box. :/
<Kamion> mdz: ubuntu-base doesn't seem to have built
<Kamion> Mithrandir: I'll forward you mail from Robert and Goswin if either of them replies
<Mithrandir> Kamion: thanks.
#ubuntu-devel 2004-10-03
<elmo> mdz: do you need me to do anything else WRT #1080 or can I remove myself from the Cc list?
<mdz> elmo: I think you can safely remove yourself
<elmo> hey, has anyone got a smart bookmarks thing for warty BTS?
<elmo> mdz: k, thanks 
<elmo> [+bye ;)] 
* Kamion has a ubug keyword
<elmo> I don't understand #1561 - it WFM(tm)?
<elmo> I mean I can "fix" it, but I'd like to know why it's broken for you guys
<Kamion> what would "fixing" involve?
<mdz> mizar:[~]  host home.ubuntu.com
<mdz> home.ubuntu.com         CNAME   www.no-name-yet.com
<mdz> www.no-name-yet.com does not exist, try again
<elmo> shiri 23:04 ~ % host home.ubuntu.com
<elmo> home.ubuntu.com is an alias for www.no-name-yet.com.
<elmo> www.no-name-yet.com has address 82.211.81.132
<mdz> mizar:[~]  host www.no-name-yet.com
<mdz> www.no-name-yet.com does not exist, try again
<elmo> kamion: not CNAME-ing
<elmo> titan.is.co.za (196.33.171.36)          www.no-name-yet.com -> 82.211.81.132
<elmo> demeter.is.co.za (196.26.5.8)           www.no-name-yet.com -> 82.211.81.132
<elmo> jupiter.is.co.za (196.4.160.3)          www.no-name-yet.com -> 82.211.81.132
<elmo> all 3 NSes are giving me the right answer?
<Mithrandir> don't use host for debugging DNS, use dig. :)
<elmo> or 'dnstracer -o'
<elmo> [for slightly less "REAL MEN USE CAT < /DEV/AUDIO" maschoism ;-)] 
<Mithrandir> heh
<Mithrandir> never heard of dnstracer before
<elmo> mdz: what's dnstracer/dig saying for you?
<mdz> mizar:[~]  host www.no-name-yet.com demeter.is.co.za
<mdz> www.no-name-yet.com     A       82.211.81.132
<mdz> mizar:[~]  host www.no-name-yet.com jupiter.is.co.za
<mdz> www.no-name-yet.com     A       82.211.81.132
<mdz> mizar:[~]  host www.no-name-yet.com titan.is.co.za  
<mdz> www.no-name-yet.com     A       82.211.81.132
<mdz> mizar:[~]  host www.no-name-yet.com
<mdz> www.no-name-yet.com does not exist, try again
<mdz> what the hell
<mdz> elmo: dnstracer is useless, dig gives the same results as host
<mdz> hmm
<mdz> no-name-yet.com.        4759    IN      SOA     ns0.blackcatnetworks.co.uk. hostmaster.blackcatnetworks.co.uk. 2004081000 21600 7200 604800 86400
<mdz> dig returns that for an SOA
<elmo> what's useless about dnstracer? *pout*
<mdz> should that be ns1.is.co.za?
<mdz> rather than ns0.blackcatnetworks.co.uk?
<elmo> yeah, it certainly shouldn't be blackcat
<mdz> is the domain moving/has it moved recently?
<elmo> no, I never bothered
<mdz> probably the SOA is still cached
<elmo> since we migrated away from it
<mdz> and yet they've deleted the zone
<mdz> querying the .za servers gives a reasonable SOA
<elmo> who's deleted it?
<elmo> blackcat have never hosted nny.com
<mdz> then where did I get that SOA record from?
<mdz> or was that in the zone even though it was served from is.co.za?
<elmo> I've no idea where you got it from
<elmo> tsig.c:293: REQUIRE(targetp != ((void *)0) && *targetp == ((void *)0)) failed.
<elmo> zsh: abort      nsupdate
<elmo> rock on
<mdz> so canonical.com and ubunutlinux.org are served by blackcatnetworks, and nny by is.co.za?
<elmo> yes
<elmo> we have dynamic dns setup with blackcat, so all our critical domains are with them
<mdz> it's very odd
<mdz> <everything else>.no-name-yet.com resolves
<mdz> it's specifically www which is fucked
<mdz> here's the lovely dnstracer output:
<mdz> mizar:[~]  dnstracer -o www.no-name-yet.com 
<mdz> Tracing to www.no-name-yet.com via 192.168.0.1, timeout 15 seconds
<mdz> 192.168.0.1 (192.168.0.1) 
<mdz> which queries my local DNS server and then quits
<elmo> oh, that's interestingly broken
<elmo> anyway, it could be that I broke the CNAME of home.ubuntu.com but since 'update delete' is broken.. well I'm a little stuck
<mdz> it does the same with any other server I point it to
<mdz> hmm, not any
<mdz> but my ISPs
<mdz> workrave
<elmo> mdz: can we import #269157?  I'd like to see if it can be fixed before warty as it'd suck to ship with an nsupdate that's add-only
<pitti> mdz: Today I uploaded a new hal package to fix a buffer overflow (#1450); nautilus-cd-burner contains exactly the same flaw, can I upload a new version?
<pitti> mdz: it's already fixed in upstream's cvs, he also read my message on utopia
<mdz> elmo: imported
<mdz> pitti: yes
<pitti> mdz: interdiff is www.piware.de/ncb.segfault.diff
<pitti> mdz: okay, thanks
<npmccallum> can dpkg extract a single file from a binary package?
<elmo> don't think so
<elmo> you can dpkg -x to a tmpdir tho
<mdz> npmccallum: indirectly
<pitti> npmccallum: you can do that manually using ar
<mdz> npmccallum: dpkg --fsys-tarfile | tar 
<elmo>        --fsys-tarfile
<elmo>               Extracts  the filesystem tree data from a binary package and sends it to standard output in tar format.  Together with tar(1) this can
<elmo>               be used to extract a particular file from a package archive.
<Mithrandir> npmccallum: ar pf foo.deb data.tar.gz | tar xvzf ./file
<npmccallum> great, thanks!
<Mithrandir> TIMTOWTDI
<mdz> Kamion: is there any way to convince parted to resize a partition, ignoring the filesystem?
<mdz> parted doesn't know how to resize my root fs on this machine
<mdz> but resize2fs does
<mdz> so I could shrink the filesystem first, and then the partition, if I could convince a tool to do the latter
<Mithrandir> fdisk can do it
<mdz> fdisk will let me _delete_ it and re-add it; that's much scarier :-)
<npmccallum> thats all parted does when it resizes it
<npmccallum> all you are doing is removing the sector referances from the partition table
<Kamion> npmccallum: parted resizing the filesystem too
<Kamion> resizes
<npmccallum> I know
<mdz> parted is paranoid about it
* jdub reads meeting logs
<mdz> fdisk is shoot-yourself-in-the-foot compliant
<npmccallum> I meant that parted does the two steps seperately
<Kamion> mdz: not that I know of, but I'm no parted guru
<npmccallum> the partition table really just tells the os the bounds of the FS
<npmccallum> mdz: you can't force parted to do it
<npmccallum> mdz: though, you can install pyparted and have access to the lower level api
<npmccallum> mdz:  you could do it that way ;)
<mdz> parted works in megabytes, resize2fs in filesystem blocks (4k), and fdisk in cylinders
<mdz> that is a recipe for MDZ DATA GO BYE-BYE
* jdub fears single universe with non-free stuff
<npmccallum> mdz: only if you do a fsck on the new setup
<jdub> seb128: dude
* Kamion fears the enormous d-i manual
<jdub> seb128: did you see about-me on ddl?
<jdub> http://topos.ath.cx:8080/~diego/about-me-v2.png
<mdz> well, the reason I want to shrink it is so that I can put Ubuntu in the free space
<npmccallum> mdz: deleting/re-adding the partition doesn't do anything to the data
<mdz> and transition over
<seb128> jdub: I've not read this thread yet
<seb128> looks nice
<npmccallum> mdz: if you screw up the partition remake, just remake it again... just don't reboot until you know you have it right
<npmccallum> if you reboot, fsck will try to fix the filesystem in the new partition bounds, which will corrupt data
<mdz> npmccallum: it's my root filesystem; I can only get the kernel to re-read the partition table if I reboot
<npmccallum> mdz: do it from the install cd
<mdz> no resize2fs on the install CD
<Mithrandir> mdz: using an NPTL enabled glibc introduces a new set of problems called "stability issues". :(
<npmccallum> thats dumb
<mdz> I'd need to bring it, and its libraries over into the ramdisk...
<npmccallum> get a live cd then... knoppix or my favorite: SystemRescue
<Kamion> npmccallum: dude, there's only so much space for multiple implementations of everything
<mdz> I wish parted just didn't suck about this
<npmccallum> mdz: its not parted that sucks about this, its e2fs
<mdz> they went and reimplemented libe2fs
<mdz> npmccallum: there's already a library that does this stuff
<mdz> and some subset of its functionality is duplicated in parted
<jdub> mdz: upstream are actively talking about a panel applet for dynamic device mount/unmount
<npmccallum> the e2fs guys told andrew clausen they had no interest in working with him
<npmccallum> Kamion: I'm not criticizing the choice to have it on the liveCD, just that is suck for matt to not have it there, I know that space is limited :)
<Kamion> ITYM install CD
<mdz> it is on the live CD
<mdz> but this machine's CD-ROM drive is old, and can't read CD-RWs, and I'm low on CD-Rs :-)
<Kamion> This document contains installation instructions for the Ubuntu 4.10 system, for the Intel x86 (i386) architecture. It also contains pointers to more information and information on how to make the most of your new Debian system.
<Kamion> hm, well, it's a start of sorts ...
* Mithrandir goes to bed.  Frustrated.
<pitti> night, guys!
* pitti goes to bed. Exhausted from Tae Kwon Do and a one hour remote debugging session
<mdz> Kamion: do you know what Tobias Engvall's bug is?
* jdub replies in length to the epiphany/firefox q
<mdz> jdub: with a tear-stained letter?
<seb128> jdub: are we allowed to reply that we suck at picking the non-desktop/non-translated/not-integrated browser ? :p
<mdz> jdub: is there a magic button somewhere which can turn the GNOME open file dialog into something you can type a path into?
<seb128> ctrl+L
<mdz> ah, thanks
<seb128> works in nautilus too
<jdub> argh
<jdub> you guys gave half answers so it could turn into an argument ;)
<seb128> I didn't reply !
<seb128> we make the wrong choice, I don't want to reply :p
<jdub> heh
<jdub> sorry seb128 :-)
<jdub> seb128: i will link up my answer when i mail the ephy guys :-)
<jdub> seb128: i take full responsibility ;)
<seb128> I still don't catch why we are getting with a non-integrated browser
<seb128> we loose translations
<seb128> and we don't win any cool feature
<jdub> seb128: brand and familiarity.
<jdub> seb128: see my reply. ;)
<seb128> bah
<seb128> this decision sucks
<seb128> familiarity ? 
<seb128> that's not a good argument to drop the desktop integration
<jdub> well, the world is familiar with firefox, not with gnome
<seb128> people are not familiar with evolution neither ...
<seb128> yeah
<jdub> remember, i'm not saying this from a point of full agreement here :-)
<seb128> they have a whole new desktop, what's so different with the browser ?
<jdub> seb128: firefox has a very strong brand, very strong momentum
<jdub> maybe we should talk about it after you read my reply
<seb128> if everybody say that, yes :)
<seb128> ok
* seb128 reads
<jdub> dude, it's beyond linux distribution choices :-)
<jamesh> seb128: web designers are very conservative, despite advocating the use of standards
<jamesh> seb128: if a website doesn't work well and you tell them you are using Epiphany, they will probably tell you they don't support it
<jamesh> seb128: they've got a much better chance of looking into the problem if you are using Firefox
<jamesh> (which is about as good as you can get, given that IE isn't an option :)
<seb128> that's the same engine, isn't it ?
<jamesh> yes
<seb128> so that's not an argument :p
<jamesh> yes it is.
<seb128> jdub: "to compete with Firefox on features,"
<seb128> jdub: which cool feature is missing in epiphany ?
<jdub> seb128: firefox is getting a lot of third party support via extensions and so on, and has features that are familiar to browser users and are appropriate to enterprise deployments.
<seb128> BTW epiphany's "familiarity, depth of community" is not going to happen. If everybody picks firefox that's ruined for epiphany
<jdub> but remember, 'everybody picks firefox' isn't just a linux distribution issue
<jamesh> seb128: also, some of the reasons for choosing OpenOffice apply here
<jamesh> since OpenOffice runs on more than just Linux
<jdub> lots of people are choosing firefox totally independently of any interest in open source or linux :)
<seb128> jamesh: the main reason for that is that abiword sucks at opening word formats, etc 
<jdub> i know companies who are planning deployments of firefox for security
<jdub> they are not even remotely interested in linux desktops or open source ;)
<jdub> seb128: that's not the main reason for OOo
<jdub> it's brand and familiarity again
<seb128> ok
<seb128> I just think that's a hard slap in the face for epiphany
<seb128> and it'll not get better with time
<jdub> (note that i don't fully agree with all of this myself, but i understand the reasons behind it)
<jdub> sure
<jdub> same slap in the face for gnumeric/abiword
<jdub> gotta be adaptable :)
<seb128> yes, but these are not GNOME components
<jdub> they are not officiallly 'in' the desktop
<jdub> but that's always a tenuous issue ;)
<jdub> *everybody* shipped evolution
<jdub> *everybody* ships gaim
<jdub> etc.
<seb128> *nobody* ships epiphany :p
<jdub> red hat are shipping epiphany and putting resources behind it
<jdub> they are not shipping firefox as default
<seb128> good :)
* jdub has been talking to havoc about it
<seb128> not sure about the importance of the brand and familiarity plan (big importance apparently)
<seb128> but on the technical one (integration, translation, release cycle, ...) we are loosing with firefox
<jdub> seb128: it's not cast in stone, we can change in future.
<seb128> yes, but still
<jdub> seb128: i'm going to be talking to the ephy guys about how that can actually happen
<seb128> currently most of the french user complain about the browser being in english
<seb128> keeping mozilla-firefox and the ton of locale-* packages is a pain
<seb128> +in sync
<jdub> seb128: this is cool...
<jdub> http://zzrough.free.fr/emifreq.php
<jdub> the applet display is bong though
<seb128> yeah, one more cool applet :)
<jamesh> remember that all applets are at least slightly crack ridden
<jamesh> especially new ones like trashapplet :)
<seb128> yeah
<seb128> jdub: any news about a NEEDINFO state in bugzilla ? :)
<seb128> it would make the bug list really more easy to read
<seb128> the other solution is close -> reopen with details :)
<jdub> seb128: i can't do that, we'll need to ping justdave - could you?
<jdub> mdz: happy for gftp to shift to supported?
<jamesh> seb128: why do you need NEEDINFO? :)
<mdz> jdub: absolutely
<schweeb> jdub: that's great news... if you have to ftp, gftp rocks
<mdz> jamesh: to keep track of which bugs are blocked on a response from the submitter
<seb128> jamesh: because a big part of my huge list of bugs is waiting for details
<mdz> makes it easier to revisit them periodically
<jamesh> mdz: I usually leave such bugs in UNCONFIRMED state
<jdub> schweeb: this is a move from desktop -> supported, so it's kind of a demotion ;)
<jamesh> if there is enough information to identify the problem, then I move it to NEW
<seb128> and how to know on which bug you have worked or not ?
<schweeb> o_O
<schweeb> it was in desktop
<jdub> jamesh: but if it's confirmed but pending on more info...
* schweeb didn't notice
<seb128> jdub: I'll mail justdave/ubuntu-devel to ask if that's easy to ge
<seb128> get
<jamesh> jdub/seb128: I might find NEEDINFO if it automatically reverted to the previous state when the reporter provided more info
<jamesh> as it is, it is a bit of a black hole
<mdz> jamesh: we don't have an UNCONFIRMED state in our bugzilla
* jamesh finds NEEDINFO too similar to the old "LATER" resolution
<seb128> NEEDINFO is not a resolution
<seb128> that's the point
<seb128> BTW time to sleep
<seb128> 'night guys
<jdub> night seb!
<seb128> later jdub, later guys
<jdub> oh
<jdub> sweet
<jdub> building ephy against firefox is supported now
<jdub> http://mail.gnome.org/archives/epiphany-list/2004-September/msg00049.html
* jdub bugs it
<jdub> boh
<jdub> target isn't listed on the new bugs page
<jdub> mdz: around?
<m_tthew> he is probably trying the desktop migration again :)
<fabbione> morning guys
<jdub> yo fabbione 
<fabbione> mdz, jdub: so what should we do with X?
<fabbione> I really really really unsuggest to wait too long to upload
<fabbione> packages in external repositories do not get the same amount of tests
<jdub> that's how i feel, thus my suggestion to upload it
<jdub> we can always revert the changes in a new upload
<fabbione> jdub: i agree.. mdz doesn't
<fabbione> you two have to agree on it
<fabbione> i think mdz is sleeping now
<fabbione> so that means we need to wait another bunch of hours
<jdub> yeah
<jdub> justdave: whatcha think about my bz requests?
<mdz> jdub: here
<mdz> fabbione: if you're ready to upload, go for it
<fabbione> mdz: I was ready to upload 2 days ago :-)
<mdz> fabbione: what's "sleep"?
<fabbione> which version do you want in?
<mdz> fabbione: what are the choices? 19 vs. 20?
<fabbione> ubuntu19 or ubuntu20?
<fabbione> yes
<mdz> I haven't even seen a changelog for 20
<mdz> but I have tested 19
<fabbione> ok wait a sec.
<fabbione> http://people.no-name-yet.com/~fabbione/changelog
<fabbione> mdz, jdub: that's for you two
<mdz> fabbione: what is this fpwll stuff?
<fabbione> mdz: it's the video output on ppc or something
<fabbione> for TV out on some ATI-based PowerPCs.
<mdz> fabbione: that sounds like a feature to me
<mdz> what is it doing in a strictly bug fix release?
<fabbione> mdz: the ati driver has code for it. It is more complicate to remove that part of the code than just add 2 lines diff
<mdz> there is a specific patch just for that?
<fabbione> yes
<mdz> where can I download the .diff.gz?
<fabbione>  wc -l 099k_ati_use_fwpll.diff 
<fabbione> 82 099k_ati_use_fwpll.diff
<fabbione> probably on people
<fabbione> daniels did an upload there i guess
<fabbione> otherwise i need to do it
<fabbione> http://people.no-name-yet.com/~daniels/xfree86/
<fabbione> there
<fabbione> brb
<fabbione> re
<fabbione> mdz: the .diff on people doesn't contain my changes
<fabbione> just that you know
<fabbione> mdz, jdub: any decision?
<mdz> fabbione: go
<fabbione> mdz: u20 ?
<mdz> yes, if you are confident
<mdz> I am not familiar enough with X to judge the changes, but I hope nothing breaks
<fabbione> yes. we can always revert back if something really goes banana
<mdz> we are in ultra freeze mode right now
<fabbione> that's why we need people to test stuff on a large scale asap
<mdz> so changes need to be more minimal
<fabbione> mdz: i know we are in ultra freeze
<fabbione> but that's why we discuss bug fixes
<fabbione> and i want to have at least the 10 bugs fixed before Final
<fabbione> anyway--
<mdz> which bug does debian/patches/099j_ati_r4xx_support.diff fix?
<fabbione> i will upload ubuntu19 and 5 minutes after ubuntu20
<fabbione> mdz: it was discussed somewhere on the mailing lists and irc
<mdz> you can just upload both at the same time
<mdz> or just 20
<fabbione> mdz: i don't remember a bugzilla entry for it
<fabbione> mdz: ok
<fabbione> mdz: i am also waiting 1298 submitter to test
<pitti> Morning
* Mithrandir tears evolution's head off
<Mithrandir> I ROCK
* Mithrandir jumps up and down
<Mithrandir> (on evolution's head)
<Mithrandir> I wonder whose idea it was for evolution-data-server to ship it's own, private copy of libdb.
<Mithrandir> jdub: any idea how much will break if I get seb128 to upload an evolution-data-server that does not use it's private libdb, but the shared one?
<mdz> Mithrandir: what version does it ship?
<Mithrandir> 4.1
<Mithrandir> which breaks in, well, interesting ways on amd64
<jdub> Mithrandir: very strongly recommend we don't
<jdub> one sec
<jdub> will rationalise
<jdub> just have to order dinner
<Mithrandir> jdub: do you have any other suggestion?
<jdub> ok
<jdub> sorry
<jdub> back
<jdub> Mithrandir: we can't, because evo needs the same version of libdb so you can copy around contacts
<jdub> Mithrandir: surely RH have a patch for this?
<Mithrandir> no idea yet, I've been chasing this bug from evo to e-d-s to orbit (which was a dead track), over some corba shit, a bit more around e-d-s and now finally to libdb and wondered wtf it was failing
<Mithrandir> I discovered ripping out the static version fixes the problem on amd64
<Mithrandir> we could see if updating the private libdb 4.1 to the latest version fixes the problem
<Mithrandir> it shows itself by blowing up if you use a free-thread access to the db.
<daniels> mdz: the r4xx stuff adds support for any card newer than the 9800 (last of the r3xx series, effectively)
<Mithrandir> daniels: is this amd64 support as well?
<daniels> Mithrandir: amd64 already works fine on ati
<daniels> Mithrandir: but yes, r4xx will work ok on amd64 ;)
<Mithrandir> good
<daniels> i think i've dug up some halfway sensible code for amd64 vbe
<Mithrandir> woo, that's great.
<fabbione> daniels: ubuntu20 is up in main
<daniels> fabbione: people.nny.com/~fabbione?
<fabbione> daniels: MAIN archive
<daniels> oh wow, main
<daniels> shit
<daniels> not bad, just surprising :)
<fabbione> daniels: again.. next time read my activity report for 2004-09-20
<fabbione> the "changelog" section ;)
<daniels> heh, I'd only just cleared warty-changes when I said 'oh wow, main'
<daniels> canonical-activity is a little further down the list
<fabbione> brb
<daniels> 01:13 < clee> btw, ubuntu is totally sucking.
<daniels> 01:13 < clee> I hate having everything just work.
<daniels> nice work, guys :)
<seb128> morning
<Mithrandir> hi seb.
<Mithrandir> seb128: evolution-data-server seems to not ship clean source ; libdb/dist includes config.log among other things
<seb128> hum, I've not checked
<seb128> is that a problem ?
<daniels> oh man, fglrx doesn't do xrandr? that's so much arse
<Mithrandir> seb128: it's ugly, nothing more.
<seb128> ok :)
<seb128> I'll check that
<Mithrandir> seb128: I'd really like you to apply a small patch as well -- it thinks amd64 doesn't support fast mutexes
<seb128> better to bug report upstream with the patch and wait for comments at this point of the release cycle
<seb128> where is the patch ?
<Mithrandir> in libdb/dist/aclocal/mutex.ac; #if (defined(i386) || defined(__i386__)) && defined(__GNU
<Mithrandir> C__)
<Mithrandir> should be changed to include || defined(__x86_64__)
<Mithrandir> do you know how to regenerate the configure script?  When I try to, it blows up :/
<jamesh> seb128: I think the trashdir patch for trash applet is pretty much done, btw.
<Mithrandir> bah
<seb128> jamesh: yes, I'm reading my mails, I've seen the patch but not tested yet
<seb128> Mithrandir: feel free to upload e-d-s with the patch if you want. What's the problem with the configure generation ?
<jamesh> With the patch, if I start with an empty trash, put a file in the trash on the USB key, it says I have 1 item in the trash
<jamesh> when I unplug the USB key, it says the trash is empty again
<seb128> cool
<jamesh> when plugging it in again, it sees the 1 item again
<seb128> rock !
<Mithrandir> seb128: make[4] : @db_cv_path_sh@: Command not found
<seb128> utch
<seb128> let me try
<Mithrandir> it's missing from configure.ac
<Mithrandir> I wonder how they ever built this in the first place
<Sledge__> morning
<Mithrandir> seb128: getting anywhere?
<seb128> it builds fine here after running the auto*
<Mithrandir> can you put the diff somewhere I can get at it?
<Mithrandir> so I can build and test that it works on amd64 before uploading
<seb128> the configure diff ?
<Mithrandir> how are  you running auto*
<seb128> libtoolize --force --copy && aclocal-1.6 && autoheader && automake-1.6 -acf && autoconf
<Mithrandir> erm, libdb doesn't use automake
<seb128> hum, I've run it for e-d-s in fact
<seb128> that's not good ?
<Mithrandir> I just don't see how this:
<Mithrandir> : tfheen@golem ..a-server-1.0.0/libdb/dist > grep -ir  @db_cv_path_sh@ . 
<Mithrandir> ./Makefile.in:SHELL=    @db_cv_path_sh@
<Mithrandir> ./configure:s,@db_cv_path_sh@,$db_cv_path_sh,;t t
<Mithrandir> ./config.status:s,@db_cv_path_sh@,/bin/sh,;t t
<Mithrandir> can ever work.
<Mithrandir> no, running it in the top level doesn't help
* Mithrandir scratches head
<Mithrandir> it doesn't find the files in aclocal/
<seb128> try to use aclocal-1.6 -I /usr/share/aclocal/gnome2-macros
<Mithrandir> why should libdb care about gnome2-macros?
<Mithrandir> it's now just complaining about AM_VERSION_SET
<seb128> no idea of why it should care but it works here in this way :)
<Mithrandir> when you've changed libdb/dist/aclocal/mutexes as I wrote?
<Mithrandir> mutexes.ac
<Mithrandir> ah
<Mithrandir> s_config
<Mithrandir> yay!
<Mithrandir> s///
<seb128> yes, it works fine here in the way described before with the change in libdb/dist/aclocal/mutex.ac
<Mithrandir> I've made it work now, making diff.
<Mithrandir> jdub/mdz: around?
<Mithrandir> jdub: http://raw.no/patches/evolution-data-server_1.0.0-0ubuntu2-amd64-libdb-mutex.diff ; fixes 1443 ; approved for upload?
<fabbione> jdub: wake up dude :-)
<Mithrandir> (yes, the diff is big due to autoconf being run, I'm sorry)
<Mithrandir> he's xa on jabber.
<fabbione> daniels: http://people.no-name-yet.com/~lamont/buildLogs/x/xfree86/4.3.0.dfsg.1-6ubuntu20/
<daniels> fabb	awesome :)
<fabbione> daniels: we probably have the full fix for the Xv
<fabbione> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=256052
<fabbione> check the last comment on this bug
<fabbione> there has been a big ati update on xorg.
<fabbione> daniels: should we start packaging x.org?
<fabbione> from scratch
<jdub> Mithrandir, fabbione: pong
<Mithrandir> jdub: see mail
<jdub> replied
* Mithrandir guesses "approved". :P
<jdub> deferred :)
<Mithrandir> ok, I hope mdz will approve it when he wakes up, then.
<pitti> jdub: just fixed https://bugzilla.ubuntulinux.org/show_bug.cgi?id=1589 ; approval?
<jdub> commented, approved
<daniels> fabbione: from scratch?
<daniels> fabbione: i already have packages, you bongsipper :)
<fabbione> yes from scratch
<daniels> why from scratch?
<fabbione> because:
<fabbione> a) i want to split as much as we can from the beginning with some insane stuff
<fabbione> b) i want to get rid of all the old maint scritps from debian
<fabbione> c) we have like 300K lines of patches to revisit
<jamesh> one of the gnome-panel authors can't spell "preffered" :)
<daniels> fabbione: heh
<daniels> fabbione: getting rid of the dbs crap would be good
<daniels> fabbione: sure
<fabbione> actually i am happy with dbs
<fabbione> what would you suggest instead?
<daniels> dpatch?
<daniels> i see the case for dbs, though
<fabbione> what's the difference.. dpatch is even more dangerous
<fabbione> anyway we need to talk on the phone at least before we start
<Mithrandir> dpatch is scary, since it wedges fairly easily, IME
<fabbione> Mithrandir: yep
<fabbione> and we don't want that for X ...
<fabbione> brb
<fabbione> re
<pooh_> morning all
<sivang> morning
<fabbione> daniels: are you still around?
<seb128> jdub: #1493, ok for upload ?
<thom> argh
* thom beats firefox in the nose
<thom> broken makefiles ahoy!
<thom> /home/thom/work/packages/mozilla-firefox-0.99+1.0PR/config/nsinstall: cannot make directory /usr/bin/defaults: Permission denied
<fabbione> nice :-)
<thom> what the hell is /usr/bin/defaults?
* thom boggles in terror
<fabbione> Source: x.org
<fabbione> Section: x11
<fabbione> Priority: optional
<fabbione> thom: do you want to exchange?
<pitti> thom: shall I take #552 (thunderbird security vulnerability) from you? I'm running out of major bugs
<thom> pitti: it should just be a sync request
<pitti> thom: you really want to sync in the freeze?
<thom> 1385 needs investigation :-)
<thom> pitti: and see comment 4 on 1385 :-)
<pitti> thom: ah, okay. If Matt agress to sync, fine for me
<pitti> thom: but such regressions liek 1385 are the reason why I like to backport security fixes :-/
<thom> pitti: sure
<thom> pitti: you know mozilla's approach to security fixes tho, right? :(
<pitti> thom: not really
<thom> pitti: here's a new api, here's a patch that uses the new api to fix the bug, everyone, upgrade, quick
<pitti> thom: I assumed something along that line, yes
<jdub> thom: it is very hard to write a secure api! (!!!) look at windows! (!!!)
<pitti> thom: is there any other reason to upgrade to 0.8 apart from the security fix?
<daniels> fabbione: sup?
<daniels> fabbione: oh man
<daniels> fabbione: please don't do libs
<daniels> fabbione: give me a sec, i'll upload some files you need
<daniels> fabbione: also, xorg is better, i think
<fabbione> daniels: no i just prepared an empty debian dir
<fabbione> with the minimum to unpack x.org 6.8.1
<fabbione> nothing more
<fabbione> also because i want to discuss with you a bunch of things
<daniels> fabbione: sure
<fabbione> on how to approach x.org to simplify the split later
<fabbione> i have some insane ideas
<Mithrandir> fabbione: any idea what might cause this:
<Mithrandir> X Error of failed request:  BadValue (integer parameter out of range for operation)
<Mithrandir>   Major opcode of failed request:  45 (X_OpenFont)
<Mithrandir>   Value in failed request:  0x2c00058
<Mithrandir>   Serial number of failed request:  1197
<Mithrandir>   Current serial number in output stream:  1198
<Mithrandir> ?
<Mithrandir> (xfontsel dying when selecting verdana font)
<lamont> elmo about?
* Mithrandir whacks defoma
<T-Bone> hi, anyone awake?
<thom> quite a few people are, yeah
<thom> lamont: catch him on jabber, prolly best
<T-Bone> ok ;) Roughly put, I'd like to know what it takes to become an ubuntu maintainer
<Mithrandir> looks like lying to defoma was a bad idea
<thom> T-Bone: http://www.ubuntulinux.org/community/maintainers
<jdub> hey
<jdub> so
<jdub> .debs aren't built in the order they packages are specified in control, are they?
<Mithrandir> jdub: I don't think it's defined anywhere
<T-Bone> thom: ok. Another question, to which I couldn't find an answer on google: is there a plan to port ubuntu to ia64?
<thom> T-Bone: if enough people with ia64s express interest, sure
<T-Bone> thom: well, I do express interest, and might even be interested in actively contributing to such a port
<T-Bone> i have machines, and time on my hands
<thom> certainly not for warty though :-)
<T-Bone> yeah I would have guessed that ;)
<thom> but start a thread on the devel list, see if there's interest, and go from there :-)
<T-Bone> thom: ok, i'll do that
<sivang> T-Bone : take a number :) I also want to become one ;-) what are you interested in besides ia64?
<T-Bone> sivang: well, i'm already a DD, and a (modest) kernel hacker, so my interests in the OSS and Linux fields are quite vast ;)
<lamont> T-Bone: I plan to start a local mirror with ia64 bits in it just to run the house machine...
<T-Bone> lamont: here's some data for you, dude ;)
<T-Bone> as part of one of my school's project,
<T-Bone> i'm working on ia64 linux
<lamont> T-Bone: the real need is a working warty (er, hoary) installer for ia64 - the rest flows pretty easily.
<T-Bone> part of that project is to check the existing distro
<T-Bone> the second part of the project
<T-Bone> is to eventually build a rock solid distro, suitable for enterprise-grade quality
<T-Bone> a free distro
<T-Bone> this might also get integrated to the Gelato federation
<T-Bone> therefore, i thought about porting ubuntu
<T-Bone> lamont: see my point? ;)
<lamont> T-Bone: bigtime
<T-Bone> lamont: this is also why i have _time_ ;)
<T-Bone> lamont: aside palinux time ;)
* sivang there is going to spring a nifty cool thing out of this :)
* lamont grumbles at X
* T-Bone considers copy/pasting this log to his wikipage for ubuntu maintainership subscription ;)
<lamont> fabbione: ok.  that's 10 fingers _AND_ 10 toes.  You can stop uploading new versions of X :-)
<Mithrandir> lamont: he's just trying to keep the buildds in good shape
<lamont> Mithrandir: the buildd's don't break a sweat.  My local mirror hates him. :-)
<Mithrandir> heh, ok :)
<lamont> building:   05:56:04     3.53%
<lamont> idle    :  156:56:00    93.41%
<lamont> total   :  168:00:04
<lamont> like I said... no sweat. :-)
<Mithrandir> yeah, I get those as well
<lamont> and that's because I gave back all the 'building (really probably == failed)' packages in universe yesterday... :)
<lamont> Mithrandir: yeah, you would.
<Mithrandir> just for amd64, though
<lamont> speaking of which, once I get the summary reports to show up, do you want to keep getting all the logs, or just hit the web site?
<Mithrandir> RSS feed for only the failed ones would be nice.
* Mithrandir hides a bit
<lamont> Mithrandir: what's RSS??? :-)
<T-Bone> lol
<Mithrandir> lamont: seriously, I can code up the RSS feed if you give me a hook somewhere in the chain of putting the logs somewhere
<Mithrandir> (or access to the database, or something)
<lamont> hrm... I could add -v to the rsync, and then generate HTML from that to give you a list of all the logs for a day...
<lamont> */10 * * * * rsync -a ...:buildLogs/ public_html/buildLogs/
<lamont> that could certainly get fatter...
* T-Bone wonders why there's no name on the wiki page MaintainerCandidates
<Mithrandir> it was probably added recently
* T-Bone adds himself
* thom cries at firefox
<thom> god this is sucky
* lamont points at people.no-name-yet.com/~lamont/buildLogs/byDate
<lamont> Mithrandir: ~/bin/mirrorLogs.py, btw
<lamont> patches welcome. :-)
<jdub> hey
<jdub> dh_install doesn't rename
<jdub> is there another option apart from stuff in rules?
<thom> debian/foo.install
<jdub> that's:
<jdub> file dir
<jdub> not file dir/file
<thom> thought it did both? oh well
<jdub> nah
<thom> suck
<jdub> unfort
<jdub> thanks for the firefox stuff dude
<jdub> sorry it is painful :|
<thom> is ok
<jdub> i am doing something now
<jdub> which will brighten your day
<thom> i have at least one upstream bug to file so far
<jdub> and make you cack your panties
<lamont> Kamion: you about?
<jdub> thom: i am... KILLING ESOUND :-)
<thom> rock and roll
<thom> how?
<jdub> polypaudio :-)
<jdub> protocol compat
<jdub> so all libesd apps will still work
<jdub> but... actually work
<thom> swoit
<jdub> then i will convince gnome to shift to it in 2.10
* lamont decides that #1559 is his day's activity
<lamont> back in a bit
<Kamion> lamont: yo
<jdub> yo rburton 
<rburton> hey jdub
<rburton> lamont: so i'm trying to find out if msttcorefonts was built for universe, if it failed, etc. it isn't in your build logs, so can i assume it wasn't even built?
<pitti> fabio: you guys broke my iBook
<pitti> fabbione: this morning I apt-upgraded my iBook (did not do that for about a week), and now X does not start any more; I only get a black screen, cannot switch back to consoles, etc.
<pitti> fabbione: any idea how I can debug this?
<Mithrandir> rburton: msttcorefonts is contrib
<Mithrandir> rburton: contrib is outside of universe ATM
<rburton> aah
<jdub> oh
<jdub> bong
<jdub> sorry, should've remembered that
<rburton> np
<rburton> can i expect it for warty?
<Mithrandir> rburton: you want to test 1.1.7 of it?
<rburton> yeah ok
<Mithrandir> binary i386 package or source?
<rburton> i386 will be great
<Mithrandir> it's actually an _all.deb, so :P
<rburton> good point so it is
<Mithrandir> http://raw.no/tmp/msttcorefonts_1.1.7_all.deb
<Mithrandir> 
<Mithrandir> uhm
<Mithrandir> once it's installed, can you check that fonts still work, and that fonts are now in /usr/share/fonts/truetype/msttcorefonts?
<rburton> installing...
<rburton> sure
<rburton> fonts are in right location
<Mithrandir> I _think_ I've gotten it all right, but it's always nice to have somebody else test as well
<rburton> seems to work fine, great
<Mithrandir> cool, thanks
<sladen> seb128: gpdf -is- xpdf
<seb128> sladen: http://bugzilla.gnome.org/show_bug.cgi?id=112506
<lamont> rburton: let me check - not in the web buildLogs means either built, or already marked failed/depwait/etc.
<rburton> lamont: turns out it wasn;t built as its in contrib
<Mithrandir> lamont: it's contrib in Debian
<lamont> Kamion: is there a convenient script lying around somewhere that I could use to find all the source packages that have _all.deb, but no _i386.deb, and mention same in their control file?
<lamont> rburton: ok.
<Kamion> lamont: not that I can think of, unless you count "hack it up with grep-dctrl" ...
<lamont> Kamion: that's what I was trying to skip. :-)
<lamont> s/skip/avoid/
<lamont> hrm.. I could just take everything that
<lamont> is 'building' on i386 and see if it has any arch: all in the archive.
<sladen> seb128: ``GPdf's handling of embedded fonts is almost non-existant.''  Oh that's clever, defeating 97.5% of the reason for PDF...
<lamont> Kamion: btw, I moved which machine does the i386 daily DI build...  scream if it doesn't work in the morning...
<lamont> Kamion: 29 packages to visit. Not that bad.. :-(
<fabbione> Mithrandir, pitti: driver?
<pitti> fabbione: radeon
<pitti> fabbione: I can still log in over network
<pitti> fabbione: looked at the X log, nothing I can tell from it, but maybe I can send it to you?
<fabbione> pitti: send it to daniels. he did some ati update
<pitti> fabbione: okay
<fabbione> I will revert the changes and upload ubuntu21
<jdub> thom: where's the "tell xscreensaver to blank on lid close" thing?
<jdub> nm, found it
<pitti> fabbione: you will revert the ati changes?
<pitti> fabbione: so can I just wait for ubuntu21 instead of trying to downgrade?
<fabbione> pitti: up to you
* thom laughs in the face of firefox. I WIN!
<fabbione> it will take me another 10 minutes to upload
<pitti> fabbione: if you upload today...
<fabbione> and approx 2 hours before it will be in the archive
<thom> my radeon still works with -20 :-)
<pitti> fabbione: that's fine, thanks!
<fabbione> jdub: do you agree or do we need to ask for mdz approval too?
<fabbione> thom: so does mine
<jdub> fabbione: for?
<jdub> oh
<jdub> reverting changes in a new upload?
<fabbione> yes
<jdub> i can approve of that, given the fallout ;)
<thom> Preparing to replace mozilla-firefox 0.9.3-2.2ubuntu3 (using .../mozilla-firefox_0.99+1.0PR-1_amd64.deb)
<fabbione> ati is broken
<jdub> best to get it in, see if anything else breaks
<jdub> thom: rock :)
<fabbione> jdub: do you approve or not? ;)
<jdub> fabbione: yes
<fabbione> there is no news that you CAN approve :-)
<Kamion> console-data RC bug coming up
<Kamion> (translation b0rkage, including English)
<fabbione> fabbione@trider-g7:/usr/src/xorg$ ls
<fabbione> x.org-6.8.1              x.org_6.8.1-0.1.dsc
<fabbione> x.org_6.8.1-0.1.diff.gz  x.org_6.8.1.orig.tar.gz
<fabbione> PHEAR
<fabbione> MUHA UHA UHA
<rburton> oooooh
<fabbione> rburton: just kidding.. that's only the orig.tar.gz :-)
<fabbione> there are 0 binaries ;)
<rburton> it's a start :)
<fabbione> yeah exactly
<fabbione> pitti, jdub: X uploaded
<fabbione> that's the last one if there are no other major bugs coming up
<pitti> fabbione: thanks for the info. I sent the X log to daniels, FYI
<pitti> fabbione: ah, wasn't ubuntu12 supposed the last one? :-))
<Mithrandir> fabbione: pong, huh?
<Mithrandir> fabbione: oh, what kind of drivers I'm using?
<fabbione> Mithrandir: you said something was wrong with X
<fabbione> i guess it's an ati driver
<fabbione> driver/card
<Mithrandir> fabbione: I did?  Where?
<Mithrandir> fabbione: ah, no, I found out
<fabbione> <Mithrandir> X Error of failed request:  BadValue (integer parameter out of
<Mithrandir> just me lying to defoma
<Mithrandir> which is a bad idea
<fabbione> lamont: yeah 10 fingers, 10 toues and now 1 d**k ;)
<fabbione> lamont: i will need help to count for the next release
<Mithrandir> fabbione: you can count to a lot more than 10 with just your fingers.
<Kamion> "I'd give my left penis to be normal"
<Mithrandir> fabbione: with ten fingers, you can count to 1024.
<Mithrandir> with your toes as well, you can count to a million (1024^2)
<Mithrandir> should be enough, even for X revisions
<fabbione> Mithrandir: ahah
<fabbione> Mithrandir: don't be so sure
<fabbione> anyway.. i need to write down some ideas on how to split Xorg source
<fabbione> s/ideas/insane &/
<Mithrandir> fabbione: I think lamont will kill you if you go over 1M X revisions
<fabbione> Mithrandir: it will cost me less to buy him an adsl ;)
<Mithrandir> yeah. :)
<Mithrandir> including the digging
<lamont> fabbione: ADSL not available in my area.
* lamont needs to either wait, or move ~2000 feet south
<lamont> which REALLY, REALLY, REALLY HURTS
<fabbione> lamont: well we can buy a serious wireless link with dishes and so on..
<lamont> OTOH, if the proposal to develop the land a mile west of here goes through, then they'll drop another RT close enough to hit me within 12 months, I expect.
<fabbione> lamont: I saw a bunch of them years ago
<lamont> feh
<fabbione> and they weren't too expensive
<fabbione> considering..
<Mithrandir> 2000 ft?  You can just get a drop there and then use coax to get to you, then?
<Mithrandir> if you use 3com card, it works with 600m 10base2.
<Mithrandir> cards, even
<lamont> "there" is in the middle of a field, and there are county roads in the way...
<Mithrandir> get a digger, then? :)
<lamont> however, wireless link to go .5 miles is a possibility...
<thom> right, hopefully this is the last firefox build
<thom> then i need to investigate languages
<fabbione> lamont: search on google.. there was someone that did a wlan <-> parabolic dish adapter using a can of tomato souce
<fabbione> cheap and effective
<Mithrandir> fabbione: pringles antenna
<lamont> fabbione: that gets you about 8-12 dB.  I have a 24dB dish on the roof
<lamont> and at least 1 spare in the shed.
<Mithrandir> that could work
<Mithrandir> as long as you have LoS, wlan works fairly well out-of-spec.
<Mithrandir> (and decent antennas)
<lamont> Mithrandir: big time -that's what I'm using for my wlan internet feed now.
<lamont> however, when the hilltop looses power long enough to run the UPS dry, it's bad...
<lamont> is 18 miles "out of spec"?
<Mithrandir> for 802.11b?
<lamont> yep
<Mithrandir> certainly.
<Mithrandir> :P
<lamont> 1W ERP (legal limit) on both ends.  About 5dB or less of margin.  sucks to have weather
<Mithrandir> you boost it a bit, I guess, then?
<lamont> yeah.
<Mithrandir> 1W isn't really much, though.
<lamont> the funny thing is that what really kills it is snow, not rain.
<Mithrandir> well, it tries to melt the snow.. kinda icky.
<lamont> the reflected near-power at the hilltop site de-senses the receiver, and pushes the noise floor above our margin.
<lamont> rain just attenuates the signal.
<Mithrandir> also, I'd think snowflakes are a bit bigger, so you catch them.
<lamont> nah - 1/4 wavelength == 2cm, which is still pretty huge compared to our typical snowflakes
<Mithrandir> hm, true.
<m_tthew> what sort of antennas on each end?
<Mithrandir> what's the reason, then?
<m_tthew> are you using amps?
<lamont> OTOH, the massive wall of snowflakes makes a pretty good reflector for all the 50W, 100W, and 50KW transmitters at the site.
<lamont> even with poor reflection, that's a hell of a lot of reflected power.
<lamont> my end is 100mW aironet into a 24dB dish (and yes, that's too much...  But there are cable and connector losses)
<m_tthew> parabolic grid or actual dish?
<lamont> the hilltop is 100mW into a 60dB passfilter, 1W amp, lowloss cable, and 8dB omni
<lamont> grid
<Mithrandir> lamont: why an omni at the hilltop?
<lamont> Mithrandir: the other 50 or so users of the hilltop can talk to it better that way...
<m_tthew> have you tried the hilltop with more gain and original radio power without an amp?
<Mithrandir> oh, there are other users. :)
<m_tthew> I've had lousy experiences with amps, usually just jacks up the noise floor really bad.
<lamont> m_tthew: not even close to working.
<Mithrandir> m_tthew: should help when you have a passfilter in front.
<m_tthew> yeah, and that low loss, is it LMR400?
<lamont> m_tthew: for the short runs, LMR400.  Anything over ~10 meters --> LMR600
<m_tthew> oh, you need runs that long between the radio and antenna, eh?
<rburton> can someone using ppc run gnome-audio-profiles-properties for me?
<m_tthew> crikey LMR600, 400 is hard enough to work with
<lamont> m_tthew: took us time to find some good amps.  the co-op is actually in the process of switching over to Motorola Canopy
<rburton> it will either crash, or you'll get a dialog
<lamont> radio is typically a PCI or PCMCIA card in the computer in the closet somewhere.
<m_tthew> lamont: canopy seems to work very well, particularly in those 'lots of clients' situation that tank 11b
<lamont> m_tthew: 1"5/8 hardline is much more fun to work with... :)
<m_tthew> lamont: :) heh
<lamont> m_tthew: yep.  none of this 'wait for a clear channel' niceness...  OTOH, if anyone is running w/o gps sync, everyone dies.
<m_tthew> lamont: hah, I didn't know that
<lamont> m_tthew: canopy slices time up into AP and SM slots, and the AP assigns them to SM's.  Hence you _KNOW_ that the channel is clear for your transmit time, and the air-delay means that other AP's still get clear time (since every AP on the planet transmits at the same time...)
<lamont> that is, if they all agree on what time it is.. ;)
<lamont> right. enough stalling.  time to work on getty
<m_tthew> thanks, and good luck :)
<Kamion> jdub: #1607 OK?
<jdub> Kamion: yeah, sure
<jdub> Kamion: we should probably take translations out of the freezer
<Kamion> ta. this is kind of an odd case, a missing translation of just one of the keymap names kills the whole lot
<jdub> mmm
<Kamion> it's also an odd case because English is a translation (from C) :-)
<jdub> hrm
<jdub> so
<jdub> i have a module with a bunch of dlopenable things in it
<jdub> some of which i'm putting in separate packages
<jdub> should they depend on the primary package?
<jdub> suggest it?
<jdub> they're totally fricking useless without it
<Mithrandir> then make them depend on the main package?
<jdub> that's the right thing to do?
* jdub will do it for now :)
<Mithrandir> would be reasonable, IMHO
* Kamion ponders a base-config-minimal.udeb
<Kamion> Mark wants several questions moved back to pre-reboot, and I really don't want to duplicate the code if I can help it
<Kamion> having the base-config source generate some udebs with the questions it wants to ask seems like the least bad answer
<azeem> is the goal to not have any curses-based stuff running after reboot, and directly enter X?
* thom sighs
<Kamion> azeem: apparently so, yeah
<thom> Mithrandir: dude, have you looked at translating firefox 1.0PR yet?
<Kamion> azeem: well, no questions anyway unless X goes wrong
<azeem> sure
<Kamion> it's a slightly scary redesign
<azeem> if ubuntu releases are such a non-moving thing, did you consider just extracting a tarball image of base+desktop, and do configuring on top of it?
<Kamion> azeem: see sounder@; that's really hard to maintain
<azeem> I mean, it looks like every desktop will be around 99% identical
<Kamion> considered and rejected
<azeem> yeah, ok
<Kamion> it would be an awful lot of divergent code to do that, too; we'd have to support both paths because netboot installs don't want to work that way
<azeem> right
<azeem> I guess the speed difference wouldn't be so big nowadays anyway, so the maintainabilty trumps it
<Kamion> exactly, there are other ways to speed things up
<fabbione> Kamion: which mail are you talking about?
<Kamion> fabbione: hm?
<fabbione> <Kamion> azeem: see sounder@; that's really hard to maintain
<Kamion> fabbione: thread about debootstrap with John
<fabbione> i got curious, but i couldn't understand the thread
<fabbione> ahhh
<fabbione> i tend to skip VERY looong threads
* thom machine guns the mozilla foundation
<jdub> Kamion: you'll be pleased to know that john is now harassing bruce
<Sledge__> jdub: *grin*
<Sledge__> he sent a private email to me today about Debian DVDs
<Sledge__> and I think I'm just going to ignore him for now
<Kamion> jdub: oh good; mind you I think he's capable of multidirectional harassment
* Kamion tries to write a design document for this base-config stuff
<lamont> seb128: http://people.no-name-yet.com/~lamont/buildLogs/g/gtk+2.0/2.4.10-1ubuntu1 ...
<lamont> :-(
<lamont> xargs: rm: terminated by signal 4
<lamont> dh_movefiles: command returned error code
<lamont> gotta love ppc...
<lamont> I think I'm going to make an autoreply for that...
<seb128> hum
<seb128> I've nothing to do, that's an autobuilder failure, right ?
<jdub> seb128: what's the cdbs rule after install, but before binary?
<lamont> seb128: that's a ppc kernel bug
<jdub> common-binary?
<lamont> but yeah,
<seb128> jdub: let me check
<lamont> from now on, things that say ' terminated by signal 4' will get retried. :-)
* jdub tries that
<lamont> so why does dist-upgrade ask me about kernel keymaps, framebuffer devices, and such???
<mdz> morning
<thom> mdz: so, um.
<seb128> jdub: install/package: perhaps ?
<thom> they've totally redone how language support works
<jdub> seb128: that seems to happen beforehand
<thom> in firefox
* jdub covers his eyes.
<thom> and i can't make the old language packs work at all
<jdub> jesuuuuus
<seb128> epiphany at least has translation integrated :p
* seb128 runs
* thom chuckles at seb
<thom> i wasn't saying it
<seb128> not saying .... :)
<lamont> looks like my AP didn't survive the power mess yesterday either. :-(
<thom> mdz: on the plus side, firefox works fine ;-)
<mdz> thom: well, considering our current firefox is pretty much untranslated, at least that's not a regression :-)
<thom> this is true
<thom> i guess we can just pull in the translations when they get done, and hope to hell they don't fuck them up again before 1.0
<thom> mdz: am i good to upload 1.0PR then?
<mdz> thom: yes
* lamont wonders if thom has anything to do with fireturd...
* thom blinks at lamont
* lamont takes that as a 'NO'.
<jdub> seb128: so install -> tmp
<seb128> yes
<jdub> then binary -> (package)/
<jdub> i need to futz with (package)/ before -> .deb :)
<seb128> binary-install/package:
<seb128>    rm debian/package/...
<jdub> binary-install? hrm, i'll try
<jdub> seb128: rocking!
<jdub> seb128: thanks
<jdub> seb128: you will be very happy to see what i'm working on :-)
<seb128> np
<seb128> oh ? /me waiting for the next upload :)
<jdub> lamont: so if we do random uploads, things will pop into universe?
<lamont> jdub: mcs Build-Depends mono-mcs (which is built by mcs), so it'll need to be bootstrapped.
<lamont> new would require elmo love
<lamont> but I think all the sources are there already (in universe), just back at 0.96...
<lamont> gimme a list of source packages, and it's trivial to verify that they exist.
<jdub> lamont: new source packages
<lamont> that takes elmo love
* jdub picks a flower
<lamont> but yes, they'd wind up in universe.
<jdub> actually
<jdub> i don't need a fucking flower
<lamont> and then someone would probably have to poke me to bootstrap them.
<jdub> elmo: I'M GOING TO KILL ESD UNTIL IT IS DEAD
<lamont> jdub: and non-revivifiable?
* Kamion reads a scroll of turn undead
<jdub> i'll wrap it in plastic if i have to
<lamont> [er, Steven Brust, Vlad Taltos series ] 
<lamont> jdub: destroy head, decapitate, or prevent those who care from recovering the body for at least 3 days. :-)
<lamont> s/head/brain/
<jdub> good god
<jdub> Kamion: what on earth is this installer change for?
<Kamion> jdub: -> sabdfl
<Kamion> 15:19 <sabdfl> main things i'd like for next sounder are (a) username questions moved to pre-reboot, so if all goes well with x we get no post-boot questions, and (b) keybd question reintroduced (mdz's
<Kamion>                request) with simple sane text
<Kamion> I think Mark thought it was an easier change than it actually is; the username stuff is *relatively* straightforward as it stands, but "no post-boot questions" is non-trivial if you want a properly configured timezone
<seb128> mdz: nautilus-cd-burner 2.8.3 released today, part of the release note : "Lock drive while burning when using HAL"
<Kamion> 'cos tzsetup has a number of dependencies which make it tricky to run it outside /target (and I don't believe in the idea of running debconf stuff chrooted and expecting it to talk to cdebconf correctly)
<jdub> Kamion: he said you described it as easy a few weeks back 8)
<jdub> Kamion: was talking to him about it; we're going to do an RC on the 13th, final on the 20th
<Kamion> jdub: he was only asking about the username question back then
<Kamion> I didn't know the goal was "no questions post-reboot"
<Kamion> although looking back I think I may not have been reading between the lines enough
<jdub> ahr
<jdub> yeah, that seemed to be the issue with the whole computer menu thing
<jdub> "oh, if you'd meant the goal was to pull all the icons off the desktop, and figure out a ui to deal with that..."
<thom> uh, how do i set emacs/whatever keybindings in gnome?
<lamont> how very, um, cute.
<lamont> sudo doesn't have /dev/tty1 open (lsof), but it's prompt goes there. sigh.
<thom> (trying to test #1294)
<thom> jdub/seb128: ^
<mdz> jdub: when and where was it decided to delay the release?
<mdz> seb128: nice!
<jdub> mdz: was just talking to sabdfl in other channel
<jdub> thom: used to be a dropdown in keyboard shortcuts
<jdub> thom: guess it's gconfy now
<thom> jdub: any idea where?
<jdub> thom: maybe under /desktop/gnome ?
<mdz> fabbione: so there were some problems with X?
<sladen> Kamion: there's still the PITA that the CD needs removing, else it really would be fire and forget
<Kamion> sladen: can't do much about that given that some systems suck the CD back in on reboot
<lamont> Kamion: leave a foot print at the end of install, if that's there when you get to the bootup of the install disk, ask the user if his machine is one that sucks the CD back in at reboot... ??? :-)
<sladen> Kamion: indeed.  Need a chain-loader and default-to-harddisk for that
<thom> jdub: *shrug*
<thom> jdub: can't see anything that looks reasonable
<Kamion> sladen: most people will probably want to remove the CD, though; the chainloading trick would work but would be pretty nonintuitive for most people, I think, and would require a considerable delay
<Kamion> sladen: (there's also the question of where to chainload *to*)
<sladen> Kamion: default entry on the harddisk
<lamont> W00T!!!!
<Kamion> "default entry"?
<sladen> Kamion: MBR
<Kamion> powerpc?
* lamont feels very dirty
<lamont> but util-linux is fixed.
<mdz> lamont: both the old bug and the new bug?
<lamont> yes
* lamont hugs /dev/null
<Kamion> sladen: how would a CD determine which hard disk the BIOS was going to boot first?
<lamont> the patch from samuel needs an open(/dev/null) after his close, and the old close restored.
<lamont> mdz: permission to upload?
<sladen> eg.  Windows user leave the Ubuntu CD in.  Windows boots fine.   User pops CD and selects "install" before the timeout, Ubuntu installs.   Ubuntu reboots leaving the CD in, Ubuntu second-stage boots fine.
<mdz> lamont: diff?
<Kamion> sladen: just all feels like too much complexity for a very delicate area of code that MUST always work
<sladen> Kamion: it's exactly what grub on your hard disk does
<Kamion> sladen: the current approach might not be so pretty, but it never fails
<Kamion> no it's not ...
<Kamion> this is the question of how to get to grub
<Kamion> grub has a configuration file that the installer can populate; the CD does not
<lamont> mdz: bide
<sladen> Kamion: The Disk Boot device is selected by mapping in the BIOS.  Disk access for loading the boot loaders is all managed through the BIOS and it magically gets taken care of.
<Kamion> let's revisit this for hoary, I don't want to countenance it for warty
<Kamion> we are in PREVIEW FREEZE :-)
<sladen> Kamion: (this is also the approach taken by the Windows Installer AFAICR)
<sladen> Kamion: this is a Hoary thing, don't worry!
<Kamion> dude, Windows only works properly half the time if you install it on the first disk. :-)
<Kamion> d-i works in all kinds of weirdo bizarre situations and makes mince-meat of them
<jdub> man the mailing list is insane
<sladen> Kamion: Ah, I see your point.  User might install to  hdbX and have the grub MBR placed on hdb, but still have the BIOS set to boot from MBR on hda
<Kamion> right
<sivang> Kamion : i've even had less success rate with windoze than that :)
<Kamion> they might well want it to be a secondary operating system
<Kamion> it's a pretty common scenario for people trying out Linux
<sladen> Kamion: v.unlikely, and the solution would probably be not to do the auto-reboot unless installation was in the 99.5% common case
<Kamion> *so* not unlikely
<Kamion> people do this all the time
<Kamion> especially people unlike us who don't know up-front that they're going to commit a computer to Linux
* sladen ponders when and who clears the FastBoot flag in the CMOS
<Kamion> it's also hard to work out from d-i what the case where auto-reboot will work actually is
<lamont> mdz: diff in bug#1574
<lamont> er, 1559
<lamont> damn bugziila
<mdz> lamont: oh, so the ioctl works on /dev/null, too?
<lamont> mdz: no.
<mdz> lamont: what is that fd used for?
<lamont> the ioctl just makes sure that the tty we open to do the ioctl doesn't land on fd0
<thom> seriously, if anyone has a small nuclear device so i can do the world a favour and remove the mozilla foundation from the map, please do let me know
<lamont> mdz: and then you don't wind up with tty1 showing up in ps aux output for a shell on /dev/tty2...
<jdub> hrm
<jdub> so
<jdub> i have a package
<jdub> with 'libpolyp0' in it
<jdub> and i need to break out some glib2 and glib1 packages
<jdub> so i'm thinking of libpolyp0-glib1.2
<jdub> is that ooky?
<lamont> er, the open(/dev/null) just makes sure that the tty we open to do the ioctl doesn't land on fd0
<mdz> lamont: ewww
<lamont> yeah.
<lamont> gotta just _LOVE_ tty's in the kernel;\
<T-Bone> =)
<mdz> lamont: ok, go for it
<lamont> the fall back was to just not check anymore, and declare it "too hard"
<mdz> jdub: I thought you wanted to kill glib1
<thom> so um, saving to "Desktop" doesn't work, but saving to /home/thom/Desktop does
<thom> where the app is running as me, and appears to be presenting some form of "nice" interface
<thom> OOOOK. so, when firefox says "Desktop", it means "users home directory"
* thom applauds
<jdub> mdz: well
<thom> because a consistent UI is a bad UI
<mdz> thom: did you notice if PR1 fixed that weird icon problem in the save dialog?
<thom> mdz: it appears to, yes
<jdub> mdz: i could be an utter fascist, and not even provide the glib1.2 bits
<mdz> thom: cool
<mdz> jdub: fascism R us
* jdub weighs it up
<jdub> who really is going to write a new app using glib1.2 anyway
<jdub> still
<jdub> i need a separate glib2 package
<jdub> libpolyp0-glib2.0
<jdub> ^ cock or rock?
<jdub> dbus does
<jdub> dbus-glib-1-dev / dbus-glib-1
<Kamion> mdz,jdub: #1165?
<sladen> jdub: provide glib2 and wait until/if somebody files a bug against not being able to do glib1 stuff ?
<mdz> Kamion: sorry, I thought I had already given it thumbs-up
<jdub> sladen: mmm
<Kamion> mdz: aha, ok, merging now
<mdz> Kamion: oh, I remember, I had meant to reassign it to Daniel because he was doing a discover1-data upload
<lamont> Kamion: 2.12-9 uploaded to sid
<Kamion> mdz: he's done that now, hasn't he?
<mdz> Kamion: yes
<lamont> "I am taking a penalty card"
<mdz> Kamion: I bet bugzilla gave me a list of matches or something, and I didn't notice that it hadn't gone through
<Kamion> ok, guess I'm safe to upload then
* mdz snarls an bugzilla
<mdz> yes
<lamont>    * The I-HATE-LINUX-TTY-HANDLING Release
<sladen> where's the feature request for rewriting  https://bugzilla.ubuntu.com/NNNNN  ->  show_bug.cgi?id=NNNNN  go ?
<Kamion> Enter new bug -> Bugzilla
<sladen> :)
<thom> i'm sure that'd break something utterly unrelate
<thom> it is a mozilla project, after all
<jdub> thom: it would break firefox translations
<Kamion> jdub: ... on Thursdays
<jdub> Kamion: hfsnw!
<Kamion> ?
* jdub blinks and ubuntu-users hits 55 unread
<jdub> Kamion: 'holy fucken shit no way'
<jdub> Kamion: download 'computer boy' :)
<elmo> the firefox translations are already fucked
<mdz> right
<mdz> maybe rewriting bugzilla URLs would fix them
<thom> well, i can't reproduce eugenia's firefox bug, surprisingly enough
<mdz> didn't she already admit that she installed some random extension?
<thom> mdz: not that i can see
<lamont> mdz: fwiw, I'm stalling on #1433 to see what debian decides.
<thom> ok, i need a drink after the horror of firefox
<thom> ciao
* lamont bbiab
<elmo> hmm, should /dev/loop* exist post-install or am I still stuck in some 2.4.xx world?
<Kamion> elmo: is the loop module loaded?
<elmo> yah
<elmo>  /.dev/loop* exists ... and works.. ?
<Kamion> udev. RUN AWAY
<elmo> MAKEDEV loop makes them in /.dev/ too :/
<elmo> anyway, anyone know the rpm equiv of dpkg -c ?
<elmo> short of rpm2cpio :)
<Kamion> -qlp
<Kamion> -qip for dpkg -I
<elmo> thanks
<elmo> wrong fricking ISO anyway.  hateful IBM
<schweeb> question, sort of technical... but shouldn't your default locale be set to the language selection you chose on install?  I select en_US and it uses POSIX/C... this affects a lot of regional specific default settings, like paper size and stuff
<lamont> Kamion: care if I fix a couple other annoyances with buildd chroot scripts>?
<lamont> <     ln -s mawk $TARGET/usr/bin/awk
<lamont> >     ln -sf mawk $TARGET/usr/bin/awk
<mdz> elmo: how did nvidia-kernel-source end up in restricted when it's not in a seed?
<mdz> it should be pushed out to universe
<elmo> because it was part of the nvidia stuff that was uploaded in a bunch and I assumed/was told they'd all live in restricted
<mdz> elmo: ok, please give it the boot
<mdz> we build the module with the kernel, so there's no need to try to support that mes
<mdz> mess
<elmo> ok, I suppose I really should just have anastacia know about restricted
<lamont> Kamion: care if I take the debootstrap bug from you?
<lamont> hope not... bz doesn't always ask before just committing away... :(
<lamont> mdz: mind if we upload a new debootstrap that has warty.buildd in it?
<mdz> lamont: what are those for, anyway?
<lamont> buildd chroot building
<lamont> er, creation, even
<lamont> debootstrap --variant=buildd warty chroot-warty http://....
<elmo> dooooooooooooh
<elmo> sudo needs to be Essential: yes or something similar
<lamont> and you get the lean, mean, buildd chroot...
* netjoined: irc.freenode.net -> tolkien.freenode.net
<mdz> lamont: what's different about the buildd chroot?
<lamont> well, base goes from that long list, down to >     base="apt binutils cpio cpp cpp-3.3 dpkg-dev g++ g++-3.3 gcc gcc-3.3 libc6-dev libdb4.2 libgdbm3 
<lamont> libstdc++5-3.3-dev linux-kernel-headers make patch perl perl-modules $additional"
<elmo> mdz: it's essential +build-essential
<elmo> (in theory)
<mdz> lamont: sure, why not
<mdz> elmo: essential + build-essential + lamont's goodies for poking around in the chroot? ;-)
<lamont> elmo: I do admit to adding buildd-essential and fakeroot to the required list...
<lamont> mdz: no.
<lamont> I install those _after_ I build the chroot, and not in the production chroots, in any case.
<elmo> did anyone see my comment about sudo?
<lamont> elmo: yes
<lamont> what broke with it not Essential:?
<elmo> lamont: dude, there's no root password by default
<elmo> and if you're cleaning out a machine, it's too easy to remove sudo by accident
<elmo> like, err, I just did on one of ours
<lamont> ROTFL
<lamont> any root windows around, or is it thombot-switch time?
<elmo> no, no root windows, I'm trying to use thombot-obsoleting-ilo now
<T-Bone> LOL
<lamont> ah, remote console good...
<lamont> mdz: uploading new debootstrap, then.
<mdz> lamont: ok
<mdz> elmo: too easy? pfft
<elmo> how's it not?
<mdz> elmo: we let you remove your kernel, or grub, all sorts of things that will break your system but are not essential
<mdz> if you set a root password, you should certainly be allowed to remove sudo
<mdz> there will certainly be people who want to
<mdz> perhaps sudo prerm could refuse if your root password is locked
<lamont> mdz: although sys/super/etc...
<lamont> all universe, though.
<mdz> echo "ROOT PASSWORD IS LOCKED -- THIS COULD BE BAD"; sleep 10
<elmo> mdz: I think that's a good plan
<elmo> mdz: actually it doesn't let you remove your kernel
<elmo> I did that too, and that correctly errored out
<elmo> and removing grub doesn't actually remove the bootloader
<elmo> mind if I file a bug on sudo suggesting the "ROOT PASSWORD IS LOCKED, CONTINUE TO SCREW YOURSELF?? (Y/y)" prompt in prerm?
<T-Bone> elmo: nice wording ;)
<T-Bone> and nice set of choices too (Y/y) ;)
<mdz> elmo: purging grub leaves /boot/grub behind?
<mdz> elmo: file away
<mdz> elmo: I'd prefer that it not be interactive about it, but clearly it should warn somehow
<sivang> do we have mpg123 source package?
<sivang> i can't seem to find any info of it using apt-cache, although it seems to be present. (many other programs depend on it)
<T-Bone> mpg123 is non-free
<T-Bone> apt-get install mpg123 actually gets you mpg321
<T-Bone> hmm sorry, wrong chan
<sivang> tnx
<sivang> i am doing security review, so this happens to be informative ;)
<jdub> YEAH, TAKE THAT ESOUND YOU SMEG!
<T-Bone> o_O
<sivang> jdub : is ESOUND giving you trouble ? ;-)
<T-Bone> sivang: anyway, what I said was connected to debian, it might be mostly crap wrt ubuntu :P hence my "wrong chan" mention
<jdub> sivang: no, dude
<jdub> sivang: apart from the mess i may need to clean up as i KILL IT UNTIL IT IS DEAD
* T-Bone gets scared
<sivang> jdub : anything I can help you with ? 
<sivang> ;)
<jdub> if you want to do a security review of polypaudio, that'd be great
* sivang is good at killing cockroaches
<sivang> jdub :i'll look at it, almost 1 pkg to go for 2004 universe
<Kamion> lamont: go for it, on both counts
<Kamion> mdz: how about sudo prerm refusing if it's being run within sudo?
<mdz> root has gone 184 days without being checked, check forced.
<mdz> root: ***** REBOOT LINUX *****                                                 
<mdz> root: 13861/124928 files (3.9% non-contiguous), 283383/497983 blocks
<mdz>    ...fail!
<mdz> I thought that bug was fixed
<mdz> (fsck found no errors, made no changes, and yet it screamed at me to reboot)
<mdz> (and rebooted)
<mdz> Kamion: ooh, that's an interesting one :-)
<mdz> I like it
<schweeb> jdub: you seen this: "I don't know why and I'm not yet motivated to fix it since my views on esd are mostly unprintable."
<schweeb> heh
<schweeb> - Alan Cox
<jdub> :)
<schweeb> one of the best OSS quotes ever
<jdub> we're gonna do it this time
<jdub> GNOME 2.10: DEATH OF ESOUND
<schweeb> thank god
<schweeb> esound sounds like pure shyte
<schweeb> although, alsa's dmix sounds pretty neat, but I couldn't get it working perfectly... some audio corruption
<jdub> almost impossible to configure
* jdub wonders how impossible it would be to autoconfigure
<schweeb> can't be any harder for a dev to set up than a gstreamer pipleine, heh
<schweeb> *pipeline
<schweeb> it's a lot of routing the stuff between sources, really
<schweeb> it needs a lot more clean documentation, rather than just the simple "works for me this way on this hardware" solutions I could find
<Kamion> - fix broken stupidity
<Kamion> thom in a subtle mood, I see :)
<sivang> jdub : can't find the polypaudio package. No source yet?
<jdub> sivang: only just uploaded, so NEW
<sivang> jdub : k
* sivang is updating pkg lists.
<sivang> come to think of it, it's 30mins minimun ;) if to recall what Kamion once said
<Kamion> the NEW queue is processed by hand, that's in addition to the usual archive delays
<jdub> elmo: help me CRUSH esound!
* T-Bone *loves* esound!
<lamont> sivang: in the worst case, non-NEW source can take 33 minutes to show up.  And binaries can take up to (worst case) 33 minutes from the time they are uploaded.
* T-Bone ducks
<lamont> + whatever manual handling is needed.
* lamont hands jdub T-Bone to use to beat esound to death. :-)
<T-Bone> lol
<jdub> bit messy
<seb128> jdub, mdz: here ?
<seb128> we have a problem with nautilus-cd-burner
<seb128> 2.8.3:
<seb128> Lock drive while burning when using HA
<seb128> ^ that's great
<seb128> but ...
<seb128>         * configure.in:
<seb128>         Require hal with lock primitives.
<seb128> -> 0.2.98
<seb128> (we have 0.2.92)
<lamont> Kamion: you still about?
<Mithrandir> thom: nope, not yet.
<Mithrandir> mdz: ping?
<Kamion> lamont: yep
<lamont> Kamion: is there somewhere trivial that I could grab a set of scripts that would allow me to create a ubuntu d-i cd?
<lamont> that is, how does an archive turn into a bootable cd image???
<Kamion> lamont: think "pain and suffering"
<T-Bone> eeek
<lamont> Kamion: No.....
<Kamion> lamont: you can *try* with http://cdimage.ubuntulinux.org/code/debian-cd.tar.bz2 and colin.watson@canonical.com--2004/cdimage--mainline--0
* lamont is trying to turn T-Bone loose on warty/ia64, you see....
<Kamion> lamont: you'll need germinate too
<Mithrandir> mdz: unping
<Kamion> but it's very much a self-assembly kit right now
* lamont grumbles
<mdz> Mithrandir: pong
<mdz> Mithrandir: unpong
<mdz> seb128: hmm, I remember npmccallum had reservations about newer hal
<Kamion> the cdimage tree currently contains, at top level:
<Kamion> bin  britney  debian-cd  ftp  germinate  local  log  scratch  secret  www  {arch}
<Kamion> bin is in the cdimage--mainline--0 arch archive above
<seb128> mdz: he said that's a bit late, but we are stucked
<Kamion> britney, local, secret you can ignore
<Kamion> debian-cd is in the tarball above
<Kamion> ftp is the archive
<seb128> mdz: upstream just did that in a right way ... and I've no real idea on how to do this in a different one with the old hal
<Kamion> germinate is, well, germinate
<mdz> seb128: will you test it with the new hal?
<Kamion> log, www are for publishing; scratch is temporary
<seb128> mdz: I'm not uploading the new hal for the moment, perhaps better to talk with npmccallum and pitti about this
<Kamion> lamont: when I actually get an arch archive of debian-cd, I'll put something together which stands a better chance of just working, but for now the above is about the best I can do ...
<lamont> Kamion: that's a start, to be sure.
<lamont> so with the tarball, you don't actually have to arch-get anything, yes?
<mdz> seb128: agreed, but if you would test the new nautilus-cd-burner locally with the new hal, that would be great
<mdz> npmccallum: are you here?
<Kamion> lamont: the tarball is only debian-cd
<Kamion> lamont: feel free to make arch mirrors of cdimage somewhere T-Bone can see, though; there's nothing private there
<lamont> Kamion: ah, OK
<Kamion> oh, and germinate, I guess, as long as it's only my current archive (Scott's old one has the internal wiki password in older revisions)
<seb128> mdz: ok
<Kamion> colin.watson@canonical.com--2004/germinate--mainline--0
<lamont> Kamion: was wondering about germinate's status... 
<lamont> mdz: have I mentioned how much I hate flushes?
<Kamion> in order to do ia64, you'll need to use the 'hints' facility to override the right kernels into germinate
* lamont fixes libopenhbci
<mdz> lamont: I thought we were finished with that business
* T-Bone feels like he'll have to read some docs
<lamont> mdz: it's the little turds that are annoying.
<Kamion> and you'll have to edit miscellaneous bits inside debian-cd; look for 'amd64', 'i386', and 'powerpc', ignore anything mentioning 'potato', 'woody', or 'sarge', and you'll get an idea what needs changed
<Kamion> mdz: we'd better be, we have mirrors now
<Kamion> mdz: a flush would totally shag the mirrors :)
<mdz> Kamion: we have users, too :-)
<Kamion> mdz: quite
<thom> Mithrandir: ah well
<lamont> mdz: gnucash and several others should start building in about 25 minutes
<mdz> lamont: excellent, thanks
<lamont> Kamion: _we're_ done with flushes.  _I'm_ not done with _CLEANUP_ from the last ones.
<Mithrandir> thom: I'll prod upstream
<thom> Mithrandir: it seems they changed the layout and stuff quite drasticly, was just wondering if you'd experienced it yet
<lamont> (since i386 builds arch-all, anything where one exists and not the other requires tender loving clubbing)
<Kamion> lamont: heh
<lamont> and remember, one should _never_ use vi to fix a .changes file.
<Mithrandir> thom: ew, ok.
<lamont> oops.
<thom> mdz: what did I do to make you hate me? first mozilla, now php? ;-)
<mdz> thom: nobody likes PHP :-(
<lamont> elmo: is anything gonna bitch that there are now two _i386.changes files for libopenhbci? :(
<mdz> thom: I figured you might at least have exposure, from Apache-land
<thom> mdz: nup. not complaining, mind. just commenting :-)
<thom> more so from working for a webhost before this :-)
<lamont> mdz: as long as you don't give him ocaml, he should forgive you.
<thom> _should_
<lamont> lol
<npmccallum> mdz: sorry, I was at dinner.  Whats up with hal? seb128?
<seb128> hey npmccallum 
<seb128> <seb128> we have a problem with nautilus-cd-burner
<seb128> <seb128> 2.8.3:
<seb128> <seb128> Lock drive while burning when using HA
<seb128> <seb128> ^ that's great
<seb128> <seb128> but ...
<seb128> <seb128>         * configure.in:
<seb128> <seb128>         Require hal with lock primitives.
<seb128> <seb128> -> 0.2.98
<seb128> <seb128> (we have 0.2.92)
<seb128> upstream did the lock for n-c-b in a right way and released today n-c-b 2.8.3
<npmccallum> which requires a newer hal
<npmccallum> ?
<seb128> <seb128> <seb128> -> 0.2.98
<mdz> npmccallum: also, what's the status of openoffice.org issues?
<sivang> mdz : got my mail?
<mdz> sivang: yes, thanks
<sivang> mdz : no prob. feel free to comment me about it.
<npmccallum> mdz: I'm doing those tonight, It takes a big chunk of time to do those (ooo takes forever)
<npmccallum> seb128: I have no problem with a newer hal, though it will require a newer dbus
<sivang> anyways boys, I must take a break, that nasty virus is back again.. (dizzy dizzy...) lamont you ok btw?
<seb128> npmccallum: do you see any other solution for n-c-b ?
<npmccallum> seb128: just our own locking implimentation... but that won't have nearly the ammount of test as hal will
<sivang> anyway, hope he feeling alright ;) night everybody Zzz..
<seb128> npmccallum: what do you think it's better ?
<mdz> npmccallum: make sure that it meets the deadline for sounder 9
<lamont> sivang: never quite sure...
<npmccallum> seb128: I think the right way to fix it is to do what upstream is doing
<npmccallum> seb128: there isn't any way to fix it without a fairly major change (and it is a fairly major bug)
<seb128> yeah, I agree
<npmccallum> mdz: I still need to know what to do with the ubuntu-sounds package (license issue)
#ubuntu-devel 2005-10-03
<sivang> night everyone
<bddebian> Gnight sivang 
<tseng> Kamion: thanks alot.
<dholbach> good night everybody
<mjg59> sabdfl: Hello?
<sabdfl> mjg59: just nominated you for the tech board, i hope you're still available?
<sabdfl> mjg59: errr... stunned silence?
<Keybuk> no fair
<\sh> g'night folks
<Keybuk> tradition has it that he doesn't find out until after he's been nominated and voted in
<sabdfl> ok. shhhh...
<bddebian> hehe
<mjg59> sabdfl: Sorry, busy drinking
<mjg59> sabdfl: Thanks! Was that what you wanted to ask me this morning?
<sabdfl> mjg59: yesh
<sabdfl> eggshellent
<sabdfl> we have all the infrastructure to run a vote now. could you draft up a (short - 200 words) statement of the things you find interesting about linux and free software for me?
<sabdfl> i'll incorporate that into your nomination, and send it to the wires
<mjg59> Sure - what sort of timeframe?
<sabdfl> we'll get the vote setup in LP, and run it from TB to TB, so you have a chance to come along and answer any questions from the hostile masses
<sabdfl> soonest would be next week, or two weeks later, to get started
<tseng> did we decide who votes now sabdfl ?
<sabdfl> tseng: yes, all devs, not just the -core
<tseng> hm, cool.
<sabdfl> or hot, depending :-)
<tseng> im a big proponent of community governence :P
<tseng> not that the sabdfl and the current boards havent been doing an awesome job
<sabdfl> but not punctuation or speling
<sabdfl> it seems :-p
<tseng> indeed.
<sabdfl> heh. night all
<Nafallo> gnight sabdfl :-)
<tseng> sleep well
<Nafallo> if I would buy a printer/multi-pass today, I should buy HP for stunning support in my favorite linux-distribution, right? :-)
* Keybuk remembers to turn the hob on this time
* mvo goes to bed now
<segfault> after that apt PO fixes, how do i translate it? it's not listed in rosetta
<bddebian> Kamion: Are you working through Malone?
<zyga> segfault: pull the source, rosetta is broken 
<segfault> and then just send it to mvo?
<zyga> segfault: or upload to rosetta, or both
<zyga> segfault: note that you can find the package or manually forge the url for the package and then upload the translation
* zyga still does not understand why rosetta does not display all packages
<segfault> i tried that, https://launchpad.net/distros/ubuntu/breezy/+sources/apt/+pots/apt/pt_BR/+translate
<zyga> https://launchpad.net/distros/ubuntu/breezy/+sources/apt/+translations
<zyga> nag people in #launchpad about it
<zyga> it should work
<lllmanulll> Hey guys, just wanted to say that a reporter from cnet.com asked me a few questions about developping for Ubuntu in an email : I just sent my answer, in which I'm writing a lot of very nice things :)
<segfault> zyga: doing that :)
<lllmanulll> It has been (and still is) really a pleasure to work for Ubuntu :)
<jdub> mjg59: ping
<mjg59> jdub: Hi
<bddebian> Were one of you two checking out the wv thing for beagle or was that dropped?
<jdub> mjg59: should ircomm stuff work if irattach is running?
<jdub> mjg59: and have you see ircomm stuff crash the machine?
<jdub> also, ircomm{,-tty} is not autoloaded
<jdub> and congratulations for TB nomination
<bddebian> Oh yeah, congrats mjg59 
<mjg59> jdub: I haven't seen ircomm crash, no
<mjg59> You need to modprobe ircomm-tty (or something like that)
<mjg59> Then ircomm0 should "just work"
<jdub> yeah, have done
<bob2> nsc-ircc is the x40 ir module, right?
<mjg59> bob2: Yeah
<mjg59> Depending on BIOS version, you need to do PnP setup first though
<jdub> with the bios update, i can now do fn-f7 for crt/lcd
<jdub> however, the crt output looks horrendous when displaying on both
<jdub> as if it were interlaced, and each line were moving left and right at different times
* bob2 googles
<jdub> pipka got her T42 today
<mjg59> jdub: Yeah. It's likely that in that mode it's running them off the same pipe, which isn't really spec compliant
<HrdwrBoB> mm nice, T42
<mjg59> It's *probably* an X bug of some description, but I'm not sure
<jdub> oh, hmm, XP SP2 comes with bluetooth support?!
<mjg59> Yeah
<bddebian> Is elmo the only one that can drop packages from the archive?
<jdub> plugging in a bluetooth usb thingy and having it work out of the box was... unexpected :-)
<tseng> jdub: what kind?
<jdub> belkin
<tseng> rock on
* bddebian is apparently talking to himself again
<elmo> bddebian: dude, it's a removal - chill out, it's not going to do any harm if it waits a couple of days
<bddebian> elmo: I was asking because I have a question about another one, not if you had already done them
* jdub boggles at the 'receive a file' mess
* bddebian loves getting chastised for trying to fucking help clean up Universe
<jdub> how much do we trust ext2resize?
* ogra has a MSI dongle, worked out of the box too :)
<ogra> do we ?
<jdub> or parted's resizing foo?
<ogra> gparted should wor fine
<ogra> (dont try it with cf cards though)
<Nafallo> ogra: oh? why not?
<ogra> it broke mine when we tested it at UDU
<ogra> i had to repartition...
<Nafallo> hmm, can't reproduce then :-P
<Nafallo> or wait. it did some time indeed.
<ogra> fine, so it was fixed inetween
<Nafallo> but works last time I tried :-)
<Nafallo> I could always test it... ;-)
* jdub resizes /home
<Lathiat> Rotund: sup
<jdub> e2fsck -fy /dev/hda3 -> ahem.
<Nafallo> ogra: seems working.
<ogra> great
<ogra> nice to see it evolved
<Nafallo> hmm, I could actually resize things with that program now.
<Nafallo> nice indeed :-)
<jmg> hey all
<jmg> im having an issue with lilo and devmapper in breezy please advise
<jmg> http://paste.ubuntulinux.nl/2600
<jmg> guys i have my root in lvm trying to reinstall lilo
<jmg> i get an error  http://paste.ubuntulinux.nl/2600
<jmg> guys what can i do about this [pid 23930]  ioctl(4, DM_TABLE_STATUS, 0x807d378) = -1 ENXIO (No such device or address)
<bob2> dude, seriously
<jmg> i think it is a bug in breezy udev
<magnon> jmg: This isn't a support channel, use #ubuntu for support requests or file a bug in Bugzilla to track it properly please
<bob2> I swear my laptop disk is getting slower
<carstenh> 19:02:52 < jdub> BenC, mdz: so is this "my hard drive is slower" stuff 
<carstenh>           supported by any useful evidence yet?
<carstenh> bob2: you are not allone with that
<lifeless> bob2: heh. I bonnied the hell outta breezy
<lifeless> bob2: it got faster than hoary
<bob2> hmm
<bob2> bddebian: please set a realname in launchpad
<bob2> getting mail from "bddebian" is annoying
<bddebian> bob2: Is that under Display Name?
<bob2> I dunno
<bob2> think so :)
<bddebian> Done
<bddebian> Sheesh, the things I get chastised about :-)
<bddebian> bob2: Let me know if that last one comes in as Barry deFreese! 
<bddebian> #1557 looks easy if someones interested.  I'm not. :-)
* bddebian assigns ajmitch to 1523 ;-P
<ajmitch> bddebian: ?
<bddebian> Whoops, wrong window :-)
<bddebian> ajmitch: It's audacity and you did the last change. ;-)
<lamont-away> GO GSTPLUGINS! it's YOUR BIRTHDAY
<bddebian> Uhm
<lamont-away> libs/gst-plugins0.8_0.8.11-0ubuntu4: Dep-Wait by buildd-hppa+bld-3 [optional:uncompiled] 
<lamont-away>   Dependencies: libswfdec0.3-dev
<lamont-away> libs/swfdec0.3_0.3.4-3ubuntu1: Dep-Wait by buildd-hppa+bld-3 [optional:uncompiled] 
<lamont-away>   Dependencies: libgstreamer-gconf0.8-dev
<bddebian> Heh
<lamont-away> so I guess I get to bootstrap that one while muttering cureses
<bddebian> Lucky you :-)
* lamont-away files 16507 to vent
<infinity> lamont-away : Bah, you know it'll just get assigned to me, and I'll curse your name.
<lamont-away> it was autoassigned to seb
<lamont-away> and the bug just says "break gstreamer0.8-swfdec out into it's own package, kthxbye"
<bddebian> hehe
<infinity> Ahh, if it doesn't have "FTBFS" anywhere in the bug, I won't get it, yay.
<lamont-away> clearly a post-breezy bug
<lamont-away> well, it does grumble about "circular build-depends"
<infinity> Well, we're so painfully not bootstrappable from scorched earth, that I don't know if anyone even cares anymore.
* lamont-away builds a swfdec-unencumbered gst-plugins0.8 to use to do the build
<jbailey> infinity: Were we ever?
<lamont-away> outside of compilers, I don't think we're that bad
<infinity> No, Debian never has been.
<jbailey> infinity: Debian certainly isn't.
<infinity> None of it's all that hard to work around, but you certainly can't just type "make world" and come back in a week to see what happened.
<jbailey> infinity: There's a few evil spots.
<jbailey> (starting from a cross-compiler)
<fabbione> morning
<infinity> Well, not counting compilers.
<infinity> We still have a fair number of circular build-deps.
<jbailey> Or the rest of the toolchain
<jbailey> And, say, base.
<infinity> If you get all of base, build-essential, and debhelper/debconf done manually, it gets a bit less ugly.
<infinity> But gst-plugins isn't the only higher-level package that has lamont's gripe. :)
<jbailey> I think perl was the suckiest one to build for hurd-i386 when I hadnled our last archive event.
<jbailey> You know you're in trouble when suddenly you're building krb4 so that you can get openldap... =)
<bddebian> heh
<infinity> Well, apparently arm is dumping and rebuilding all of sid for an ABI switch or some such, so maybe they'll start filing circular build-dep bugs when they see them. :)
<jbailey> Oh, are they doing the EABI now?
<jbailey> Insane.
<jbailey> They should've held off for working multiarch'
<jbailey> Given it a new arch name, and just made them parallel installs.
<infinity> Just caught it in someone's blog, don't know if it's actually happening.
<jbailey> mips and arm each have completley new ABIs
<jbailey> If mips does the N64
* lamont-away looks at the gst-plugins0.8 build time, goes to bed
<bddebian> heh
<lamont-away> infinity: armeb?
<lamont-away> which, of course, should really be called 'armbe'
<jbailey> lamont-away: EABI, mre likely.
<jbailey> lamont-away: They get things like a thread register. =)
<jbailey> And working floating point.
<lamont-away> ah, ok
<bob2> or, perhaps armpickanendianismandstickwithit
<lamont-away> anyway, bed
<jbailey> g'n lamont.
<bddebian> Gnight lamont 
<jdub> armchooseyourownendventure
* bob2 pelts tomatos at sydney
* bddebian wonders if gstreamer-cdio plugin is included in that build?
<bob2> didn't the gnome-screensaver change get reverted?
<mjg59> Yes
<bob2> nm needs love
<bddebian> Is that still not straightened out?
<jdub> nm needs a sync from j^'s repo
* jdub doesn't know what's holding that back
<bob2> it got synced last week
<jdub> oh
<jdub> probably right after i checked, too
<bob2> er, woo, yay for being unbootable
<wasabi> Is there an active initive for a nano ubuntu meta package/setup/etc for embeddedish systems?
<jdub> check out the microbuntu spec
<jdub> no work so far, though
<wasabi> k
<wasabi> I've got me a project at the office which calls for something similar, guess I'll just hack it together myself.
<bob2> surely just using emdebian would be simpler?
<wasabi> I like the dev pace of Ubuntu a bit better. :0
<jdub> initramfs makes things interesting
<wasabi> I'm just building a little nano itx fanless system to drive an office projector. People will walk in, it'll scan for their laptops in the room (bluetooth) and let them display their laptop on the projector (rdesktop/vnc/whatever)
<wasabi> It'll have a flash based HD.
<wasabi> So I want to rig something up that doesn't actually write.
<wasabi> And fits in 256mb
<infinity> Do a server install, grab deborphan, and start removing packages until it's tiny enough for you. :)
<wasabi> Yeah. THat's hte plan.
<wasabi> I think I'm going to play with / in a weird way. Sounds fun.  use a loopback device for root with a tmpfs unioned.
<wasabi> So it's writable, but nothing saves.
<infinity> Like a livecd.
<wasabi> Yeah.
<wasabi> It was awesome. I showed my boss how fast I could put this app together, it took about 30 minutes.
<wasabi> gdm, autologin, launch a shell script. Shell script uses zenity to do basically everything.
<wasabi> Super simple. ;)
<jdub> zenity is rad for this stuff
<wasabi> Yeah. It was so easy to get a useful app up and running.
<wasabi> I mean, it's not "real development", but for some projects, it's perfect.
<wasabi> I'm not totally sure how to set it up to mount / right though.
<jdub> check out casper for its bind mount dm love
<wasabi> that's a udeb, aye?
<jdub> yeah
<jdub> but you can apt-get source casper
<wasabi> ahh nice
<wasabi> I'm only doing this because from what I understand, it's not good to write flash disks a lot.
<wasabi> (and it sounds cool)
<jdub> most of them have sane wear-leveling, but better to be safe
<wasabi> hope the sleep support works right on this box I'm setting up.
<wasabi> hmm. initramfs is pretty simple
<wasabi> built in support for rw/unionfsing the root drive would be pretty rad. ;)
<wasabi> jbailey, ? :)
<bob2> interesting, 2,6,12-9 doesn't boot on my desktop anymore
<jdub> bob2: how does it fail?
<bob2> hangs at "enabling additional executable formats"
<bob2> which seems to be a coincidence, since it used to hang while enabling acpi
<Burgundavia> jdub, should g-a-i be in applications and in system--> admin?
<pitti> A lovely good morning to everybody!
<HiddenWolf> 'morning to you. :)
<lifeless> uhm
<lifeless> replacing libsane.usermap shows an empty diff - wtf is it prompting me ?
<crimsun> probably isn't ignoring trivial whitespace?
<lifeless> not sure
<lifeless> but it didn't even have a hunk marker
<lifeless> and I'd not touched that file
<crimsun> yeah, I noted that, too but just pressed 'y'
<infinity> Did the file move between packages, or something?
<ajmitch> morning JaneW 
<JaneW> hi ajmitch 
<dholbach> bon jour!
<ajmitch> morning dholbach :)
<pitti> Hey dholbach 
<dholbach> pitti: morgen martin! :)
<sivang> pitti: Morning Martin
<sivang> dholbach, others :)
<pitti> Hi sivang 
<zyga> morning :)
<sivang> pitti: I discussed some bits of the cupsd bug last night with Keybuk
<pitti> Hi zyga 
<pitti> sivang: ah, any progress?
<sivang> hey zyga 
<sivang> pitti: not really :-/ Keybuk told me that from what he discovered, there is no reasonable way to do a reload without elevating back to root
<sivang> pitti: Currently, cupsd installs sigterm instead of sighup when executed as a user
<sivang> pitti: so, changes ought to be intrusive IMHO in order to workaround that
<pitti> sivang: humm, merely redetecting printers should not require root
<pitti> sivang: user "cupsys" is in group "lp" which can happily access all USB, parallel, and serial printers
<poningru> question who handles mirrors for ubuntu apt repos?
<poningru> cause a group of students here (including me) wanted to ask our uni to add ubuntu repos as a mirror
<robitaille> poningru,  there is a mailinglist: http://lists.ubuntu.com/mailman/listinfo/ubuntu-mirrors
<sivang> pitti: so assuming I modify it to install a SIGHUP instead of SIGTERM when -HUP'd , I need to write a custom handler that just calls the printer detection code again, is that what you meant?
<poningru> ic thanks
<pitti> sivang: right
<poningru> btw my uni already handles bunch of stuff for other distros
<sivang> pitti: (first part of the sentence refers to when executed as undeprivileged user)
<poningru> ftp.cise.ufl.edu if anyone is interested
<sivang> pitti: ok, back to the drawing board :)
<pitti> sivang: yes, if you run cups as root, the current behaviour should stay
<dholbach> infinity: do you know more about the recently restarted test-rebuild (and where the old logs are)?
* dholbach cries a fair bit
<ajmitch> hi mvo 
<dholbach> morning mvo
<zyga> hello mvo
<infinity> dholbach : Old logs are where they always are.
<infinity> dholbach : http://people.ubuntu.com/~lamont/buildLogs/Test/
<dholbach> infinity: ok, i was talking about the breezy-autotest.failed.$arch  thingies
<infinity> Ahh, no luck there.  There isn't an archive of the old wanna-build states, afaik.
<dholbach> fuck
<mvo> hello everyone :)
<poningru> robitaille: question do other places mirror the repos? or is it just the install isos?
<jsgotangco> hi mvo
<doko> anybody here, who wants/can test eclipse on powerpc? (pitti ?)
<robitaille> poningru,   I have no idea.  I just knew there was a mailing list :)
<poningru> hehe thanks guess I will subscribe and ask there
* poningru wishes there was a web interface for sending mail to lists in mailman
<robitaille> poningru, https://wiki.ubuntu.com/Archive    has an email address at the end
<crb> ogra/mdz: awake?
<crb> dholbach has asked me to bug you regarding being able to edit bugs for triage in #ubuntu-desktop.
<bob2> hah
<dholbach> crb: your mail adress is: craig@dubculture.co.nz?
<crb> It is
<dholbach> crb: then your changes to the bug were accepted
<crb> yes, just not the URL field.
<dholbach> oh i see
<dholbach> hope ogra will be soon awake so he can take care of it - until then i add it, ok?
<crb> sure, no trouble
<ajmitch> crb: thought I recognised the nick
<crb> ajmitch: hi
<ajmitch> hello
<sivang> hi mvo 
* mvo waves to sivang 
<mdz> crb: http://wiki.ubuntu.com/HelpingWithBugs
<mdz> crb: have you read that?
<crb> I have 
<mdz> crb: any questions about it?
<crb> np
<crb> no
<mdz> crb: what is your bugzilla login?
<bob2> wow, you need special permission to fiddle bugs?
<ajmitch> bob2: in bugzilla, yes
<crb> craig@dubculture.co.nz
* bob2 pines for the fjords of debbugs
<mdz> crb: you have editbugs now
<mvo> ping segfault 
<crb> thanks
<dholbach> goooood morning, seb!
<ajmitch> hi seb128 
<seb128> hey dholbach ajmitch
<mvo> hey seb128 
<seb128> hey mvo pitti
<pitti> Hi seb128 
<pitti> doko: argh, another disk and mem hog? :-)
<doko> pitti: I don't know, who to ask else ...
<pitti> doko: *sigh* toss it over :-)
<doko> pitti: deb http://people.ubuntu.com/~doko/eclipse-powerpc/ ./
<doko> pitti: maybe check first without the three *-gcj packages (interpreted mode), then with the -gcj packages
<pitti> doko: what happened to openoffice.org2-l10n-{bs,lt}? they just disappeared
<mvo> seb128: is someone from the frensh i18n team working on updating the apt translation? I want to do a upload soon (to fix ubuntu 15603), would be nice if that could be included
<seb128> mvo: there was at 100% yesterday
<seb128> mvo: rosetta already get your changes from yesterday?
<seb128> I'll update the few new ones
<doko> pitti: see the changelog, disabled. I'll look at them again for the next upload
<mvo> seb128: I can't find it in rosetta :/
<pitti> doko: so shall I throw them out of language-support or keep them? l-s-{bs,lt} are uninstallable because of that
<seb128> mvo: ups, I've apt-get source it indead
<seb128> mvo: that's because you don't ship any .pot with the package ... any reason for that?
<mvo> seb128: I have po/apt-all.pot here
<doko> pitti: I'm trying to have an upload on Friday, will start a test build today in the dc
<pitti> doko: ok, then I leave it for now; thanks
<seb128> mvo: right, so that's a question for carlos (maybe pitti?)
<pitti> mvo: carlos should be able to help you with rosetta; so apt isn't imported into Rosetta at all?
<seb128> pitti: seems so, there is no translation page for it
<pitti> BenC: ping
<\sh> elmo: can u have a look on the latest free realplayer package from Real? is it ok for us to upgrade the realplayer package in multiverse?
<pitti> doko: which eclipse package shall I install? e-base?
<pitti> doko: (I never used eclipse so far)
<\sh> elmo: regarding the license ;)
<doko> pitti: eclipse-sdk
<doko> and after that: eclipse-rcp-gcj, eclipse-platform-gcj, eclipse-jdt-gcj
<zyga> seb128: hi
<zyga> seb128: I've fixed all calendar packages, sorry I could not resist
<\sh> elmo: please sync sylpheed-claws-gtk2_1.9.14-1 from unstable (universe that is) thx
<zyga> mvo: how is synaptic looking?
<seb128> zyga: k
<seb128> jdub: around?
<seb128> carlos: hi
<zyga> seb128: ping me if you want all the diffs
<carlos> seb128, hi
<seb128> carlos: do you know why rosetta has no apt po files?
<sivang> pitti: got my email?
<mvo> zyga: the backpotr the i18n patch? haven't looked yet, sorry
<jdub> seb128: yo
<seb128> jdub: hey
<zyga> mvo: if you find a moment pleas do so, I'd love to translate remaining messages 
<seb128> jdub: why does ubuntu-artwork install stuff to gnome-wallpaper-properties instead of gnome-background-properties ?
<jdub> seb128: for some reason, it was done that way in warty - from memory, it had to do with the monthly background stuff
<jdub> seb128: so symlinks were added, and now it's a bit b0rk
<seb128> jdub: what prevent the monthly background to use gnome-background-properties folder?
<carlos> seb128, 05:48:54 WARNING Error scanning tarball: The source package apt for breezy has more than one .pot file in source/build/po/domains/libapt-pkg3.9. Ignoring the tarball.
<seb128> jdub: just trying to get why it is this way before changing stuff made on purpose
<seb128> carlos: what do you need to fix that?
<seb128> carlos: thanks BTW :)
<jdub> seb128: i don't remember, but it doesn't matter -> fix it at will
<carlos> seb128, that we get only one .pot file per directory
<jdub> seb128: i'm actually doing a respin of that package tonight, so if you know how to fix it properly, please blat me a patch :)
<seb128> carlos: you have to way to force the right one?
<carlos> seb128, I can change by hand the tarball
<carlos> but next update will fail again
<seb128> jdub: zyga has been working on that, seems that he only install files to /usr/share/gnome-background-properties 
<seb128> mvo: why does apt has different .pot?
<mvo> carlos: the interessting bit is po/apt-all.pot
<jdub> that's what the current packges do
<pitti> jamesh: here?
<mvo> seb128: historical reasons, the build-system is "different" than most auto-tools using programs
<seb128> jdub: right, that's the -calendar which are wrongs :/
<jdub> seb128: the old ones, yeah
<ogra> dholbach, you pinged  ?
<ogra> morning
<dholbach> ogra: it's all sorted out, was about editbugs privileges for crb
<ogra> ah, i see, sorted
<zyga> re
<zyga> jdub: I have tested this on breezy
<zyga> jdub: new package simply installs in the proper place and conflicts + replaces the old one
<zyga> jdub: it works like a charm
<seb128> "shutdown -r now" turning the box instead of restarting it ... which pacakage is to blame for that (#16340), linux?
<fabbione> seb128: dpkg -S shutdown ?
<fabbione> seb128: you also want to check if they issued the ioctl to make the machine do a hard reboot on shutdown
<fabbione> (it's configurable)
<fabbione> seb128: hmm.. i blame mjg59 :)
<seb128> fabbione: the "dpkg -S shutdown" is to point sysvinit or a question for the submitter?
<seb128> fabbione: how do you configure that?
<fabbione> seb128: it's an ioctl via /proc
<carlos> mvo, seb128 Could you fix the 'apt' package?
<fabbione> i don't remember the details
<seb128> fabbione: k, thanks
<Kamion> that would be sysctl rather than ioctl probably?
<carlos> mvo, seb128 it's a matter of move three .pot files inside the right path
<fabbione> Kamion: yes.. sorry...
<mvo> carlos: I just looked at it, it looks like it's not easy to fix because the makefile assumes the pot files in the po dir
<carlos> mvo, but the .pot file is inside po and the .po ones inside domains/$domain?
<carlos> mvo, how is that?
<Kamion> hmm, I have a nasty feeling that this bug fix I'm currently doing is going to hide #13250 further so that it's still latent but harder to reproduce
<Kamion> argh
<zyga> is there a bugzilla bot around here?
<mvo> carlos: in the LANG_POFILE rule, it runs  "$(MSGMERGE) $(notdir $@) $(PO)/$(call GETDOMAIN,$*).pot -o $@"
<mvo> carlos: I have a look now
<carlos> mvo, ok, found the solution
<carlos> mvo, apt-all.pot has all strings and translations from the build directory, right?
<mvo> carlos: yes
<pitti> seb128: mind if I take #16070 from you?
<ogra> dholbach, send to doesnt work with a motorola razor (but i think its rather a low level prob, i can send to the laptop, but nor from it)
<ogra> s/nor/not
<carlos> mvo, could you add a rule that removes those .pot files so we only have the apt-all.pot?
<seb128> pitti: that's *mine*
<seb128> :p
<pitti> seb128: ok, ok :-)
<seb128> pitti: joking, sure take it :)
<carlos> mvo, just before the rule added by pitti to extract the .po files
<pitti> seb128: I get the same behavior, and it is annoying
<seb128> pitti: it opens nautilus on the wrong folder?
<mvo> carlos: oh, you mean in the rules file. nice idea
<dholbach> ogra: you send from your box to the phone? and not the other way around?
<seb128> pitti: is nautilus crashing or what?
<pitti> seb128: yes, it always opens ~
<carlos> mvo, yeah
<dholbach> ogra: oh sorry, now i understand
<pitti> seb128: no, it just opens ~ instead of e. g. /media/PittiUSB
<ogra> dholbach, i tried both ways... from the box to the phone doesnt work
<seb128> pitti: what I got from the description but it works fine for me, you are welcome to debug it
<mvo> carlos: trying now
<seb128> pitti: thanks :)
<pitti> seb128: I wanted to fix it anyway, and now I found a matching bug
<dholbach> ogra: but you did the pairing dance? exchanged a pin and everything and have gnome-obex-server running?
<carlos> mvo, wait
<ogra> hmm, i dont need a pin for sending to the box from the phone...
<carlos> mvo, hmm, that's not the solution
<seb128> mvo: did you speak with pitti about cdrdao?
<carlos> mvo, why are we using only one .pot file when we have three domains?
<ogra> let me grab that phone manual :)
<carlos> mvo, language packs need that we have the three languagepacks
<dholbach> ogra: :)
<carlos> the three domains no languagepacks
<carlos> mvo, we cannot just import apt-all.pot
<mvo> carlos: hrm, so it would require the three different domains in three different dirs?
<carlos> mvo, yeah
<carlos> and kill apt-all.pot
<carlos> mvo, how is that we have an apt-all.pot file??
<carlos> mvo, we have three directories already, we just need to move the .pot file inside the domains directories where the .po files are
<mvo> carlos: to make the life of the translators easier, they can work with apt-all.pot and the build-system will deal with the rest
<carlos> mvo, I suppose that's a Debian solution, right?
<carlos> mvo, because it's useless for Ubuntu
<mvo> carlos: it's the apt solution ...
<carlos> mvo, is there any easy way to fix it the way I told you ?
<lifeless> mvo: just the man
<mvo> carlos: looking at it now
<lifeless> mvo: synaptic did something weird today
<mvo> lifeless: what exactly?
<lifeless> I had it open on virtual desktop 3, it popped up a config file keep/replace question
<lifeless> but alt-tab did not show that questions window
<seb128> carlos: you should have a way to specify exceptions, ie: what pot file to pick for a package
<zyga> lifeless: I get that too
<lifeless> so I had by mistake clicked on a foreground window
<zyga> lifeless: the window does not show in the taskbar either
<lifeless> and couldn't find the question window again
<lifeless> I had to go though all my windows and minimise them :[
<mvo> lifeless: thanks. I'll fix that so that the window appears in the window list
<lifeless> mvo: np
<carlos> seb128, I know, but I don't have time to fix all those issues now so it's the only way to get updates. I can do a manual fix (I'm doing it now) but the updates will not be imported automatically
<fabbione> daniels: ping?
<daniels> pong
<fabbione> i think i found out why #16035
<`anthony> will the GCC version in breezy be updated before the final release? I'm seeing some really funky funky warnings that make no sense at all from it.
<fabbione> we don't check if the user did actually select a resolution
<`anthony> I notice it's a pre-release version.
<fabbione> we just assume he does
<ogra> dholbach, its my phone :/ it obviously has no recieving options at all :/
<fabbione> daniels: given that we answer nothing, we keep parsing the result as empty
<fabbione> daniels: so MAXRES is set to null at expr operation
<fabbione> daniels: i am burning a live to reproduce it
<daniels> yeah, probably
<dholbach> ogra: try to browse for services with sdptool - i can't believe that the phone is not capable of doing so
<daniels> i'd argue that's pathological enough to be 'user error' though
<fabbione> either the question is not asked
<fabbione> or the user didn't answer
<daniels> well, it said /modes was asked
<pitti> `anthony: we should not update it if we can avoid it
<daniels> so yeah, it could occur if they deselected all the default resolutions
<fabbione> yes, but not that it was shown
<daniels> in which case, I don't know that we should even attempt to create a configuration file
<fabbione> you see the same even if it's not prompted for real
<daniels> doesn't matter, we have defaults set
<ogra> dholbach, the manual doesnt state such a capability anywhere, but i'll try
<daniels> so if it wasn't shown, we'd get an answer back
<fabbione> daniels: i am not sure.. you reset the templates somewhere in postinst
<fabbione> does it keep the default in that case?
<dholbach> ogra: i was quite happy with the results of sdptool
<daniels> fabbione: yes
<fabbione> daniels: the sane thing is that if there is no answer from the user (he deselects everything) we should ask again
<fabbione> + db_get xserver-xorg/config/display/modes
<fabbione> + _db_cmd 'GET xserver-xorg/config/display/modes'
<fabbione> + echo 'GET xserver-xorg/config/display/modes'
<fabbione> + IFS='
<fabbione> '
<fabbione> + read -r _db_internal_line
<fabbione> + RET=
<fabbione> there is clearly nothing selected there
<fabbione> either debconf did fart badly
<fabbione> or the user is on crack
<daniels> if you go into an infinite loop, then the only way to kill it is with, well, kill
<daniels> i'd like for that not to be the case
<fabbione> daniels: we can avoid infinite loops. by asking no more than 3 times
<fabbione> after that we error badly
<fabbione> "IZ THAT WHATA WANT?"
<daniels> okay, I'll check it out
<Kamion> fabbione: it's a multiselect; selecting nothing's perfectly in-spec
<daniels> but still, that's a pathological case to be designing for
<seb128> daniels: hey. I poke you some time ago about the hoary liveCD doing 640x480 only on a "intel 82865G" based box where warty was doing 1024x768. You said it has been fixed after hoary, but colony5 still has the issue ... anything that you need to fix it?
<ogra> dholbach, nothing...
<daniels> Kamion: in-spec, yes; sensible, no
<fabbione> Kamion: yes, i know
<daniels> seb128: hmm.  desktop system, right?
<seb128> daniels: yeah
<fabbione> Kamion: i didn't complain that was out-spec. there might have still been a debconf crack
<Kamion> fabbione: I don't believe it :)
<dholbach> ogra: but bluetooth is turned on? did you turn on "show device" on your phone? you might want to investigate in this pairing thing
<fabbione> Kamion: still... it can happen :)
* Kamion tries to avoid blaming lower levels first - they're generally better-tested
<fabbione> Kamion: that's why i did expose more than one possibility
<daniels> Kamion: (seems like my policy of blaming debconf for xserver-xorg configuration bugs is contagious.)
<`anthony> pitti: Ok. I will log a bug against it, then.
<Kamion> daniels: I think it's been right a total of once so far ;)
<daniels> Kamion: one outta three ain't bad.
<Kamion> actually, is that even true? can't remember
<fabbione> well i am going to eat some food and test it
<Kamion> there's probably been one instance of mad passthrough lunacy
<daniels> Kamion: (to be fair, the weirdarse set-value-not-in-select-silently-fails bug wasn't being blamed on Debconf until I'd spent several hours unable to see the blindingly obvious problem.)
<daniels> yeah, we've had passthrough stupidity.
<ogra> dholbach, ahh, i see a list now :)
<dholbach> ogra: hsprang (known as lazyb0y nowadays) just works 15 minutes from here for the next weeks :)
<ogra> great :)
<Kamion> that said about lower levels, I'm beginning to think #13250 must be a crash in libparted or something like that
<seb128> daniels: ?
<pitti> seb128: cool, I now have a drivemount applet that actually works and on top has sensible names
<seb128> pitti: "sensible names"?
<seb128> pitti: what was the bug?
<pitti> seb128: before I had "OTi flash disk" and "OTi flash disk (2)", now I have "PittiUSB" and "PittiExt3" (the volume labels)
<seb128> ah, nice
<pitti> seb128: the bug was that dm-a prefered drives over volumes and ignored attached volumes
<pitti> seb128: therefore activation_uri was NULL and nautilus was called without parameters
<pitti> (-> thus it showed home)
<seb128> oh, k
<seb128> explain why it works with my fat32 mounted drive :p
<pitti> seb128: now I do it the other way round: if there is a volume, I do not display the matching drive
<pitti> seb128: do you get your device label as tooltip?
<daniels> seb128: oh, uhm
<seb128> pitti: cool. Do you put the patch upstream too?
<daniels> seb128: output from sudo ddcprobe?
<pitti> seb128: I'll mail it to jamesh, he can commit it himself and clean up if he wants
<pitti> seb128: that ok?
<daniels> seb128: (sorry, missed your reply)
<seb128> daniels: let me know what they need to try. That's not for one of my box
<seb128> so it'll take some time to ping/pong
<pitti> seb128: hm, it seems that I need the drive for unmounted volumes, darn
<seb128> pitti: not sure than jamesh is the only maintainer for that, usually bugzilla.gnome is better
<pitti> seb128: otherwise I can't remount; gotta work some more on it
<seb128> maybe davyd or desrt want to commit it
<pitti> seb128: ok, I'll file a bug upstream
<seb128> thanks
<jamesh> pitti: bugzilla'ing it and CC'ing me would be good
<seb128> hey jamesh
<pitti> jamesh: ah, you are here - maybe you can give me a hint about it?
<pitti> jamesh: did you read the explanation above?
<jamesh> pitti: the drive mount applet code is mostly mine (the code to launch the CD player and stuff in 2.12 isn't)
<ajmitch> hi kobold 
<kobold> ajmitch: hi!
<ajmitch> kobold: quick question, is it worth keeping zope-ldap around?
<seb128> jamesh: do you have an idea of why launchpad_integration_add_ui () gives these "assertion `gtk_accel_group_from_accel_closure (accel_closure) != NULL'"
<seb128> ?
<pitti> jamesh: we must not throw away volumes of attached drives since it's volumes that we open, not drives
<pitti> jamesh: OTOH we need the drives for remounting unmounted volumes
<kobold> ajmitch: I don't know if someone is using it, sorry.
<jamesh> seb128: no
<kobold> I've never used it.
<pitti> jamesh: so we need both, but should not display drives if there is a matching volume
<ajmitch> kobold: hm, looks like it's deprecated upstream (quite dead), but someone is using it in ubuntu
<ajmitch> chmj: you have an updated package that has been sent to you?
<kobold> if someone is using it, then just leave it around.
<jamesh> pitti: the code doesn't throw away volumes attached to drives -- it just handles drives and unassociated volumes separately
<ajmitch> kobold: yeah, it's got a bug in breezy that is needing fixed :)
<pitti> jamesh: it does - look in add_volume(): if there is a matching drive, you do not add the volume
<kobold> ajmitch: which bug? could you please give me an URL?
<jamesh> pitti: that's because we've already added the drive though, right?
<ajmitch> https://launchpad.net/distros/ubuntu/+sources/zope-ldap/+bug/2359
<daniels> seb128: okay ... just sudo ddcprobe would be cool
<pitti> jamesh: but that's necessary since a drive does not have an activation_uri and no proper label
<daniels> seb128: as well as Xorg.0.log
<mvo> carlos: is it enough to have one pot per dir and no other pots around? or will apt have to do more than that?
<seb128> daniels: k, I'll ask and ping you again
<pitti> jamesh: see bug #16070
<jamesh> pitti: the mounted volume associated with the drive has an activation uri though
<pitti> jamesh: right, that's why my current patch throws away the drive if there is a volume
<jamesh> pitti: that doesn't make sense.
<pitti> jamesh: that works fine for mounted volumes; they open nicely in nautilus and have a good name
<pitti> jamesh: but now I don't get drives when I unmount the volumes
<daniels> seb128: cool, thanks
<pitti> jamesh: do you think you have some minutes to look into this
<pitti> ?
<kobold> ajmitch: you are wrong, you can handle multiple products in a source package.
<ajmitch> kobold: there are a few other zope bugs on malone that can probably get closed after I confirm they're fixed :)
<jamesh> pitti: sure.
<ajmitch> kobold: right, the way I was using dh_installzope caused it to say that it couldn't
<pitti> jamesh: <pitti> seb128: before I had "OTi flash disk" and "OTi flash disk (2)", now I have "PittiUSB" and "PittiExt3" (the volume labels)
<pitti> jamesh: that's another reason to use volumes and not drives
<jamesh> pitti: it's possible that it got broken in 2.12
<kobold> ajmitch: see zope-cps in debian experimental, for example.
<kobold> I wouldn't remove zope-ldap just because it have multiple products in a source package.. :-)
<pitti> jamesh: from gdb'ing, it does not seem to be broken - drives conceptually should not have a volume label nor an activation URI, right?
<ajmitch> kobold: no, I only saw that it was a little stale upstream :)
<jamesh> pitti: the idea is that a drive represents a physical device, while a volume represents a partition on the device
<pitti> jamesh: right, and we want to open a partition, we can't open a drive
<jamesh> pitti: so for instance, you don't eject volumes; you eject drives
<mvo> pitti: does pkgstriptranslations extracts the pot file too? 
<pitti> mvo: yes
<jamesh> pitti: and when you eject the drive, all the volumes associated with the drive go
<pitti> jamesh: well, eject will always unmount all volumes on a drive
<pitti> jamesh: right
<pitti> jamesh: eject takes care of that
<fabbione> daniels: yes.. i can confirm that without selecting anything we fail
* fabbione fixes
<mvo> pitti: will it just look for pot files in the build-tree and use them? or will I need to trigger it in some way?
<pitti> mvo: it grabs all pot files it can find in the source directory
<mvo> pitti: ok, thanks
<carlos> mvo, just move the .pot files with the .po files for that domain
<carlos> and that's enough
<ajmitch> kobold: the other 2 zope bugs I haven't checked, want the urls to have a quick glance?
<jamesh> pitti: so the idea was to have one button for the drive, rather than one button for the volume
<kobold> ajmitch: yes, thanks.
<ajmitch> https://launchpad.net/distros/ubuntu/+sources/zope2.7/+bug/590
<ajmitch> https://launchpad.net/distros/ubuntu/+sources/zope2.7/+bug/653
<jamesh> pitti: I didn't get round to implementing multiple "open volume" menu items, because the gnome-vfs backend didn't seem to ever associate multiple volumes with a drive
<ajmitch> 653 looks to be long since fixed
<pitti> jamesh: but my usb stick has two partitions, so I need two buttons anyway
<pitti> jamesh: right, I currently get one drive and one volume per partition, and an additional drive for /dev/sda
<pitti> jamesh: that is a bit weird, since /dev/sda{1,2} shouldn't technically be drives
<pitti> jamesh: so in the end drivemount applet only maintains three drives 
<jamesh> pitti: I haven't looked at how it works with the HAL backend, but for the older fstab/mtab watcher backend, it went something like this:
<jamesh> each user mountable entry in /etc/fstab gets a GnomeVFSDrive
<jamesh> each entry in /etc/mtab gets a GnomeVFSVolume, associating the volume with a drive if the mount points match
<jamesh> tha HAL backend should be able to do better, but I don't know if it actually does.
<pitti> jamesh: the current behaviour is quite consistent to that AFAICS
<kobold> ajmitch: I have no clues about 590 ...
<ajmitch> kobold: I haven't been able to reproduce it on breezy, and it was filed back in may
<jamesh> pitti: yeah.  last I looked, it was using fstab for GnomeVFSDrives, and using HAL to look up mounted volumes
<kobold> ajmitch: how could I subscribe myself to zope* bugs?
<ajmitch> kobold: currently I don't think you can subscribe to packages like that
<kobold> ajmitch: neither single packages?
<ajmitch> probably another wishlist bug to file for malone
<kobold> ajmitch: 653 has been fixed...
<pitti> jamesh: in fact, the computer:/// place does it absolutely right
<ajmitch> kobold: I'll close #653, perhaps ask in #launchpad about the subscribing
<jamesh> pitti: that's the code I based the drivemount code on, actually.
<kobold> ajmitch: do you receive the bugs by email or what?
<jamesh> computer:// uses the GnomeVFSVolumeMonitor API too
<ajmitch> kobold: yes, but I receive all the bugs assigned to MOTU
<ajmitch> kobold: perhaps we could have a zope team on launchpad to assign bugs to
<kobold> ajmitch: I think we definitely need it.
* kobold doesn't want to receive all the MOTU's bugs.
<ajmitch> it's a lot
<ajmitch> because it includes all the bug comments, status changes etc
<kobold> could you do something or ask about "Zope team" on launchpad? it would be great to see it happens.
<ajmitch> sure, it will only take a couple of minutes to setup
<kobold> ajmitch: thanks!
<zyga> hey
<zyga> will someone take a triviall fix for epiphany
<zyga> the download manager displays 'progress bar label|%d%%' at the progress bar
<zyga> (which is obviously broken)
<zyga> someone forgot to pass it thru GUI gettext stripper function
<zyga> anyone?
<pitti> zyga: do you have a patch?
<zyga> pitti: I will in a moment, building now
<jamesh> pitti: how's this look? http://pastebin.com/376659
<ajmitch> kobold: https://launchpad.net/people/zope
<zyga> pitti: BTW: someone should rename epiphany to epiphany-game and make epiphany a dummy package 
<pitti> jamesh: that should solve the activation_uri bug
<zyga> s/ny/my/
<pitti> jamesh: it still leaves the label bug, but that's not too important
<Kamion> kobold: anyone can create a team in launchpad, btw; getting it to be the default assignee is a different matter ;)
<ajmitch> Kamion: we'll just manually assign for now - the numbers of unassigned bugs are manageable
<Kamion> sure
<kobold> ajmitch: could you please approve me? O:-)
<Kamion> I did a pass over installer bugs misfiled in Malone last night, for much the same purpose
<ajmitch> dholbach does fairly regular assignments of bugs now
<mvo> carlos: I prepared something to make apt rosetta friendly, could you have a look before I upload? I don't want to upload twice because of some wrong assumption/error in my changes
<ajmitch> kobold: you're an admin of the team now
<kobold> ajmitch: thanks ...
<jdub> http://jehaisleprintemps.net/detail.php?id=1172&lang=fr
<jdub> seb128: ^^
<mvo> carlos:http://people.ubuntu.com/~mvo/apt/rosetta/ 
<seb128> jdub: cool :)
* jdub is looking at referer logs ;)
<kobold> ajmitch: how could we set zope team as maintainer of zope packages? is this possible?
<ajmitch> kobold: not yet, as the packages aren't setup as launchpad packages yet, afaict
<kobold> I have to admit that launchpad really rocks.. and I look forward to see it completed.
<ogra> ajmitch, isnt zope in main ? 
<kobold> ogra: zope2.8 and zope3 are in main.
<ogra> ah, thats why you cant use launchpad then :)
<ajmitch> ogra: a number of products are in universe still :)
<ogra> fun...
<ogra> bugtracker mix :)
<ajmitch> kobold: used zope3 much for development?
<ajmitch> ogra: hopefully not for too much longer :)
<ogra> i suspect sabdfl will call for launchpad for main at UBZ
<ajmitch> yep
<ogra> (he did that at UDU too ;) )
<ogra> but stepped back ... :)
<ajmitch> except after UDU, malone got some good hammering from us :)
<ogra> yup
<ajmitch> and is now getting closer to usable for main
<fabbione> daniels: i am testing the fix right now.. do you have any other changes pending?
<daniels> fabbione: no, tbh I'm still catching up on -70 and some bug mail
<fabbione> daniels: i can mail you the diff for -70
<fabbione> i kept it locally
<daniels> ah, it's okay thanks
<fabbione> i am keeping a lock on -71
<fabbione> if i get the fix right i am going to upload it
<jdub> wow, fridge is in google already
<ajmitch> jdub: and the forums, apparantly
<fabbione> daniels: http://people.ubuntu.com/~fabbione/debian-from-69-to-70.diff
<daniels> -71 is all yours
<daniels> i'll catch up with -72 later
<fabbione> ok
<zyga> pitti: that's a nastier bug than I expected but I'm on it - I just need to fetch devhelp for gtk to know how to fix it
<zyga> pitti: the message comes from the default gtk progress cell renderer
<Kamion> Mithrandir: wanna join the ubuntu-installer team in launchpad? I was thinking of getting some friendly lp admin to set it as default assignee for a bunch of stuff
<Kamion> ("no" is a valid answer, though ;))
<zyga> any gtk guru could help tell me what does Q_ do and how does it differs from _?
<zyga> const char *Q_(const char *);
<ajmitch> kobold: do you think there's time to get a number of the zope products in breezy back in sync with debian?
<Mithrandir> Kamion: how do I do that?
<Mithrandir> Kamion: I'm utterly unable to locate any "team list" or something like that.
<Kamion> (https://launchpad.net/people has a team list)
<zyga> pitti: it looks fixed
* Mithrandir sells his souls to Kamion
<Kamion> heh
<Kamion> you have more than one? spares?
<pitti> zyga: nice, thanks! seb128 will love you
<sivang> that sould be registered as a GUI usability bug
<klepas> would you guys be able to answer me a quick question?
<zyga> pitti: should I send him the patch?
<sivang> klepas: is it a development question?
<klepas> no one in #ubuntu seems to know the answer.
<klepas> Sadly not.
<JaneW> BreezyGoals owners - please check your goals, most of these have not been updated for some time (even though they are complete).  Please add a note detailing current state of goal, and if any further work is required.
<klepas> It's to do with UIDs
<pitti> zyga: maybe easiest would be to open a bug and attach the patch to it, then whoever grabs it first will upload it
<klepas> and editing them in the cli
<pitti> klepas: I answer in #ubuntu
<fabbione> daniels: AHAHA i was right!
<klepas> :)
<fabbione> daniels: he didn't select any resolution
<Mithrandir> Kamion: yeah, that too.  Haven't you read the latest harry potter?
<Kamion> Mithrandir: yes :)
<JaneW> please also update the status (hopefully to Completed)
<JaneW> https://wiki.ubuntu.com/BreezyGoals
<JaneW> If any part are deferred, please let me know so I can add these details to the deferred goals table
<zyga> pitti: good idea
* zyga fixed first bug in a really big package - yay :>
<sivang> zyga: which bug# ?
<jbailey> wasabi: IIRC, mdz was playing with unionfs and initramfs and was having some major kernel issues, dunno the final solution.
<zyga> sivang: none, I didn't bothered to look - I just fixed it
<fabbione> unionfs is teh OOPS
<zyga> sivang: epiphany-browser does not update the label in download manager progress bar
<segfault> morning.
<sivang> zyga: heh yeah, seb128 *loves* epiphany :)
<zyga> seb128: ping ;-)
<doko> seb128: does fontconfig/gnome make font substitutions on it's own, if it doesn't find an appropriate font? I.e. Bitstream Vera Serif isn't available as oblique font in the font selection panel, but applications like abiword allow me to print it as italic ...
<fabbione> jbailey: Kamion is building another sparc CD.. this one should go all the way to Ubuntu desktop
<pitti> jamesh: ok, I apply your patch now, thanks!
<fabbione> jbailey: if you can check on the fly the stuff i did ask, i can still try to fix X autodetection
<pitti> jamesh: we'll leave the label problem to Dapper then?
<jbailey> fabbione: 'kay.  Do you know when it'll be ready?  I still have the sparc box wired up.
<jamesh> pitti: I guess so.  Do you have any other ideas for the applet?
<fabbione> jbailey: pretty soon i guess
<pitti> jamesh: hm, it works fine for me
<pitti> jamesh: otherwise
<sivang> pitti: patches for lpi by any chance?
<pitti> sivang: for an applet that hardly makes sense, or does it?
<pitti> sivang: or wait, it does have a menu
<sivang> pitti: I meant for the patches jamesh sent you, were they for lpi ?
<sivang> pitti: if so, which applet
<pitti> sivang: no, they fix the nautilus opening for a volume
<pitti> sivang: drivemount-applet
<\sh> daniels: ping
<\sh> daniels: do u know any issues with keyboard mappings after upgrading from warty -> hoary -> breezy?
<pitti> seb128: bah, that libgphoto patch is really ugly...
<ogra_> \sh, whats broken ? 
<ogra_> i have no AltGr (Meta) since some days, but suspected a HW error...
<\sh> ogra_: no...on franks sony the same
<ogra_> oh
<ogra_> yipppie... i dont need to buy a new keyboard...
<\sh> strange that I have it still...so I think some xkb b0rkage
<ogra_> \sh, all other keys wirk right ? 
<\sh> but no error to see in the logfiles
<ogra_> *work
<\sh> ogra_: yes..even altgr is giving xkb events...but altgr+q or e or bla is not working
<pitti> jdub: still here?
<ogra_> yup and its very hard to ping you for me :)
<ogra_> no backslash
<pitti> seb128: should we change the CD player app of gnome-volume-manager from totem to sound-juicer now?
<\sh> ogra_: and didn't change with the last xorg upload
<pitti> seb128: jdub told me that this was the way to go, but I'm not sure wheter that counts as UI/documentation freeze break
<zyga> seb128: http://bugzilla.ubuntu.com/show_bug.cgi?id=16536
<zyga> :-)
<\sh> ogra_: highlite should work as well on sh only ;)
<ogra_> sh, yes ?
<seb128> pitti: it's gnome-cd, not totem atm, right?
<pitti> seb128: no, ATM it's totem
<seb128> zyga: what's funny about this one? :p
<pitti> seb128: jdub asked me to do that since gnome-cd is obsolete
<seb128> pitti: oh, here it uses gnome-cd, probably a previous user config
<pitti> seb128: totem is ugly for audio CDs, s-j is better, so I'd like to fix that
<ogra_> \sh, btw, i think its rather a kernel prob, no altgr in console mode...
<seb128> pitti: gnome-cd is no obsolete yet, probably for 2.14. Anyway I've not issue with totem or sound-juicer, pick whatever you prefer :)
<seb128> pitti: let's use sj so
<pitti> seb128: but I guess I should contact the doc guys; do you have a contact?
<dholbach> is 9GB the minimum size of an installation? a user sent me this: http://ubuntu.gplan.info/9GB-minimum.JPG
<\sh> ogra_: argl
<zyga> seb128: I've just fixed it
<zyga> seb128: it's trivial - you can apply it
<seb128> pitti: ask on their chan or to jbailey maybe
<\sh> ogra_: u know the bugzilla entry? ,-)
<ogra_> sh, nope
<seb128> zyga: I would say "it has no information about what the issue is and it works fine for me"
<ogra_> as i said, i suspected my hardware
<\sh> ogra_: crap
<zyga> seb128: hmm :/
<zyga> seb128: I'll attach a screenshot
<seb128> zyga: the download manager has a "%" to the bar
<ogra_> dholbach, that screen is absolutely correct...
<seb128> ie:
<seb128> %10     filename
<seb128> ... ko of ... ko
<zyga> seb128: then there is something strange
<dholbach> ogra_: hm?
<seb128> zyga: maybe your translator didn't respect the Comment|msg 
<Kamion> dholbach: no
<ogra_> dholbach, i guess he needs to play with his bios settings
<zyga> seb128: no - I see the default message from gtk2
<seb128> zyga: but since your bug has no information about the locale, version used, etc
<zyga> I'm attaching the screenshot
<Kamion> dholbach: that's the minimum possible size for *that partition*, not for an installation
<seb128> zyga: yeah, maybe your translator have messed the GTK translation
<\sh> elmo: please sync gcfilms_5.3-3 from debian unstable (universe that is) thx
<ogra_> dholbach, has nothing to do with required space
<zyga> seb128: no - that's the deafault untranslated message
<seb128> put a screenshot
<\sh> ogra_: I'll file one..but on which package?
<dholbach> ogra_: that's what i thought
<ogra_> \sh, hmm, kernel ? 
<\sh> ogra_: kernel?
<ogra_> (package linux)
<zyga> seb128: attached
<seb128> zyga: and another remark: don't change bugs to NEW yourself
<seb128> there is no point to have UNCONFIRMED if the submitters change them to NEW themself
<zyga> seb128: sorry I thought this is an obvious bug
<seb128> #. do not translate the part before the |
<seb128> msgid "progress bar label|%d %"
<seb128> msgstr "progress bar label|%d %"
<seb128> 
<Kamion> dholbach: for example, if the partition already has 9GB of data in it, you can't resize it to be smaller that that
<seb128> from the gtk pl.po file
<seb128> zyga: translator messed the GTK translation as I said before
<dholbach> Kamion: thank you
<zyga> seb128: what do you see when you download a file?
<seb128> zyga: %nn
<zyga> seb128: it's strange that I see the default label and you see something proper
<Kamion> dholbach: (that's the dialog you get when you attempt to resize a partition, not the one you get when you create a new one - there's no minimum size mentioned in the latter)
<seb128> zyga: the fr.po has not the "progress bar label|"
<seb128> zyga: read what I just copied on the chan
<seb128> zyga: "#. do not translate the part before the |"
<dholbach> Kamion: super, thanks - i'm just talking to him
<seb128> zyga: and pl.po has "progress bar label|%d %"
<zyga> ok
<\sh> ogra_: http://bugzilla.ubuntu.com/show_bug.cgi?id=16539
<seb128> zyga: they screw by putting "progress bar label|" with the translation
<seb128> so you get that on your bar
<zyga> seb128: I get it now
<\sh> ogra_: please confirm ;)
<mvo> pitti: I was looking at the main-inclusion problems for cdrdao. I noticed that when applying the O_EXCL patch cdrdao disable my eject button (without the patch that works fine). did you noticed a similar issue with cdrecord?
<zyga> darn I didn't fix a bug then ... you've fixed it
<seb128> lol
<zyga> seb128: the source uses Q_ which maps to gettext_strip_helpers or something similar
<zyga> seb128: I thought that prevents us from seeing stuff before "|"
<doko> seb128: does fontconfig/gnome make font substitutions on it's own, if it doesn't find an appropriate font? I.e. Bitstream Vera Serif isn't available as oblique font in the font selection panel, but applications like abiword allow me to print it as italic ...
<seb128> zyga: as the translator comment say, don't translate the part before |
<seb128> zyga: it's here to give a context, ie: allow to 2 same strings to have different translations
<zyga> seb128: yes I know 
<zyga> seb128: I've got to get going now - I'll look at the po file when I get back
<zyga> thanks
<seb128> np
<seb128> thank you for working on bugs :)
<seb128> doko: not that I know of, but jamesh probably knows better about this
<Riddell> seb128: can you move some more files to gstreamer-gtk? libstdautodetect, libgsttextoverlay and libgsttimeoverlay
<Riddell> or I can move them
<seb128> Riddell: let me ping the Debian maintainer first, we don't want to create any divergeance
<seb128> what is the issue with those?
<Riddell> gconf brings in gtk
<seb128> $ ldd /usr/lib/gstreamer-0.8/libgsttimeoverlay.so | grep gconf
<seb128> $
<Riddell> textoverlays bring in pango
<seb128> oh, k
<Riddell> which brings in cairo
<seb128> you need cairo anyway
<seb128> there is a cairo plugin
<seb128> can these changes wait after 5.10?
<Riddell> ah, move gstcairo as well then
<seb128> creating new package break the Depends
<seb128> ie: we will have to review all the package that may need to put a Depends on -gtk due to the moves
<Riddell> well -gtk already exists so that has to be done anyway
<seb128> excepted that pixbuf is not really useful
<seb128> but if we start moving a bunch of other stuff that's an another matter
<seb128> ie: the overlay stuff are useful
<Riddell> there arn't many rdepends on gstreamer0.8-misc
<seb128> right, but that's still some work
<seb128> lemme me ping the Debian maintainer first
<seb128> maybe he'll want to do a -gconf
<seb128> and a -pango
<pitti> mvo: no, that worked fine
<pitti> mvo: that's odd, why should that have any effect on the eject button? I don't see the connection
<mvo> pitti: yes, it's odd. but I see this effect  here in the "cdrdao copy" case with the O_EXCL patch
<mvo> (and not without it)
<pitti> mvo: the effect is that eject does not work *after* cdrdao is finished?
<mvo> pitti: "cdrdao copy" first reads the source, then ask for a medium swap. eject (on the cdrom) will not work with the patch anymore (but does without)
<pitti> mvo: weeeird - does it really close the device properly?
* mvo checks that now
<pitti> mvo: and why it doesn't call eject in the first place?
<mvo> pitti: no idea :)
* Kamion attempts to come up with deliberately broken FAT filesystems
<pitti> mvo: it would be nice, then the user does not have to do it manually
<Treenaks> Kamion: from linux, or do you have a windows machine to create them with? :)
<Treenaks> Kamion: I know a few interesting ways to break FAT fs's from Windows :)
<pitti> Treenaks: hexedit?
<Treenaks> pitti: well, that too
<Treenaks> pitti: but (write 100 small files; delete 25-50 and 75-100; then write one big file (which will be fragmented)
<Treenaks> pitti: then delete all files and turn off the PC while it's still writing :)
<Treenaks> pitti: voila, broken FAT
<pitti> lol
<Kamion> Treenaks: 'echo A | dd of=<device> bs=1 seek=510' does the job nicely
<Kamion> parted ain't gonna open that
<Treenaks> Kamion: :)
<seb128> carlos: why does rosetta list evolution-2.2 for evolution?
<Kamion> oh, except then it doesn't even recognise it as fat32. whoops.
<Treenaks> Kamion: try "bitrot" (Wichert made a tool for that once)
<Kamion> too awkward, I only have the installer here so far. I'll mangle the info sector instead.
<Kamion> (and no, I can't do a full install because that would perturb the test too much ...)
<fabbione> daniels: http://people.ubuntu.com/~fabbione/debian-from-70-to-71.diff <-
<fabbione> daniels: i am finished for today on X
<fabbione> Kamion: if you plan to make new CD's can you please be sure to include X -71 ?
<spayne> mdz: ping
<Kamion> fabbione: I'm not doing any special releases today
<Kamion> I need to hide in a box and fix bugs
<fabbione> Kamion: kthx :)
<mvo> pitti: what else needs to be done for cdrdao beside debian #272646 and malone #1528?
<dholbach> i'm out for lunch
<dholbach> see you
<lamont-away> elmo: you might try anastasia w/hppa sometime in a couple hours and see what it looks like.   /me will be offline, but it has the potential to be fairly clean
<lamont-away> (totem is building shortly, and will free up more of the ubuntu-desktop blockers)
<eruin> I hope this is the right spot... In what cases would /proc/acpi/thermal_zone/ be empty for a laptop?
<seb128> Mithrandir: do you keep tracking this users-admin/amd64 issue?
<doko> seb128: where are the default fonts for gnome configured?
<Mithrandir> seb128: I'm banging my head against it just now.
<Mithrandir> seb128: it just doesn't make sense, the stack state is corrupted _somewhere_
<seb128> doko: gconf /desktop/gnome/interface/font_name
<seb128> Mithrandir: yeah, nasty bug ... let me know if you figure something
<seb128> doko: /desktop/gnome/interface/monospace_font_name and /desktop/gnome/interface/document_font_name too
<Mithrandir> seb128: so far I've come to "glibc is buggy and stomps on memory which it shouldn't", but that's not this bug.
<seb128> probably not :)
<doko> seb128: yes, but these are alias names
<seb128> doko: fc-match <font>
<seb128> doko: what are you trying to figure?
<pitti> mvo: no "else"; if the two things in the inclusion report are fixed and the package generally works, that's fine
<doko> seb128: which font (from which package) is actually used as the default font for Serif/Sans/...
<sladen> doko: vera I think now
<mvo> pitti: thanks, just uploaded the new version with the fixes
<mvo> pitti: should I note that in the wiki page?
<pitti> mvo: would be nice, yes
<ogra_> doko, do you read -devel ?
<seb128> doko: 
<seb128> $ fc-match Serif
<seb128> VeraSe.ttf: "Bitstream Vera Serif" "Roman"
<seb128> $ dpkg -S VeraSe.ttf
<seb128> ttf-bitstream-vera
<ogra_> doko, the matching for Helvetica Verdana etc is broken
<ogra_> (at least for display fonts, not for print fonts though)
<doko> seb128: I want to make the DejaVu fonts the default, these are Bitstream fonts, but with Oblique Serif fonts available, and more eastern european characters
<daniels> xprint is the way of the future
<seb128> doko: I guess you have to change /etc/fonts/fonts.conf
<ogra_> daniels, that doesnt use fontconfig ?
<daniels> seb128: fonts.local, surely
<daniels> ogra_: HEAVY HEAVY SARCASM
<daniels> seb128: or local.conf, maybe
<ogra_> err, oh, sorry :)
<seb128> daniels: ups, correct
<doko> ogra_: ???
<ogra_> why the heck does evo crash for me twice a day ....GRRR
<doko> daniels: heh, I'll wait until you did modularize the fonts, i.e. glyphs per package ... ;-P
<tseng> doko: bitstream-vera-sans-mono-latin-a
<ogra_> doko, see the thread about firefix default fonts... fontconfig has a strage fontmapping for some fonts
<doko> ogra_: hmm, when does get fonts.conf updated?
<doko> $ ls -l /etc/fonts/fonts.conf
<doko> -rw-r--r--  1 root root 12727 May  4 16:13 /etc/fonts/fonts.conf
<ogra_> i think in postinst of fontconfig and probably in postinst of every new font you install afterwards
<doko> ogra_: no, install ttf-dejava, and nothing happens ...
<jbailey> Riddell: ping?
<bddebian> Good morning
<sivang> Good morning bddebian 
<bddebian> Heya sivang
<Kamion> 01:07 < bddebian> Kamion: Are you working through Malone?
<Kamion> bddebian: I was just doing a pass over it looking for misfiled installer bugs
<Kamion> and a few other ones I noticed and care about
<bddebian> Kamion: NP, I just had one open and it closed right in the middle of me checking it.. ;-)
<Kamion> which?
<bddebian> I don't remember, the number, it was some dumb one :-)
<Kamion> oh, #990 probably
<Riddell> jbailey: hi
<Kamion> annoyingly, operating on universe bugs causes Malone to send a mail to a moderated mailman list which then says "your mail has been held for moderation" or some similar noise
<Kamion> the list should be configured to let through mail from Malone without that message
<Treenaks> Kamion: they changed the MAIL FROM:<> stuff (which now breaks RFC 2821), that's what's causing breakage ( afaik )
<bddebian> Riddell!!
<bddebian> Kamion: Aye, that was pissing me off last night :-)
<bddebian> Riddell: Do we not have kdebindings?
<Riddell> bddebian: we do
<pitti> daniels: do you have any idea how an userspace program could test whether its $DISPLAY is currently "active", i. e. the current console?
<seb128> bddebian: could you stop breaking the string freeze by changing desktop files? That breaks every single translation for the strings you change
<pitti> elmo, Znarl: can I please have the blender build-deps in concordia/breezy?
<Znarl> pitti : Can you create a RT request?
<bddebian> String freeze?
<Kamion> bddebian: https://wiki.ubuntu.com/BreezyReleaseSchedule
<pitti> Znarl: we really need RT requests for that?
<pitti> Znarl: ok, I'll do that
<Znarl> pitti : It's helpful for us to keep track of changes.
<pitti> Znarl: sent
<Znarl> Thanks.
<bddebian> seb128: Oh, sorry, I didn't know about that one.  Is that Universe too?
<seb128> bddebian: dunno if there is a freeze but you just broken translations and desktop files are not a part of language packs, so you screw everything != english for 5.10 by doing this
<bddebian> :-(
<seb128> no big deal, but consider that before changing string :)
<seb128> HIG stuff can wait for after 5.10
<tseng> bddebian: dude yes please
<tseng> bddebian: i was not thrilled by the string change either.
<bddebian> tseng: ??
<tseng> bddebian: (blam?)
<bddebian> tseng: You mean a string change there too?
<tseng> bddebian: you changed the .desktop file
<bddebian> Yes
<tseng> did you change all the translations too?
<bddebian> I wanted to but I don't know all the charactersets
<seb128> tseng: he probably just didn't not he was breaking them
<seb128> s/not/note/
<tseng> seb128: i know, he meant to fix a "bug"
<seb128> let's just stop changing strings for 5.10 now
<seb128> so everybody is happy :)
<tseng> yes :)
<bddebian> seb128 / tseng: Would that include adding new .desktop files?
<tseng> bddebian: no
<tseng> not imo
<seb128> bddebian: nop, you don't break translations for non-translated stuff
<tseng> changing the strings in all my desktop files also creates more delta to debian for something i dont agree with in the first place
<seb128> though I'm not sure of that's uglier to not have the menu entry or to have an english one :)
<lifeless> oh
<lifeless> I just remembered 
<lifeless> has anyone noticed that hibernate has the same hot key as 'help' in the logout dialog ?
<bddebian> Ugh
* bddebian should just quit trying
<tseng> just not changing strings would be fine :P
<bddebian> tseng: I seem to fuck up something or other no matter what I try to "fix"
<bddebian> Not to mention getting bitched at for trying to clean up the archive
<\sh> bddebian: hey...this is life ;) I'm getting bitched as well at my company here when I fix something ;-) 
<Kamion> elmo: any chance that you could make cron.sync keep around the minimal and standard files for each project/suite/arch triplet? it would make ~cjwatson/jessica easier to drive if it could pick out those files for each arch
<elmo> root=/dev/mapper/Ubuntu-root
<elmo> ^-- who's responsible for us requiring that in grub config?
<seb128> bddebian: don't get it wrong, your efforts are appreciated! I'm just pointing the translation issue because it may be non obvious. Keep the good work :)
<sivang> bddebian: don't quit trying! You only know if seb128 appriciates you enough, is when he critisises something you do, trust me ;-p
<Kamion> elmo: at what stage does it fail if you use some other syntax?
<elmo> Kamion: some other syntax?
<pitti> Znarl: thanks
<mvo> Kamion: what usplash version is on the current daily i386 install?
<Kamion> elmo: I assumed you were talking about requiring /dev/mapper/Ubuntu-root as opposed to some other syntax for LVM devices, like /dev/Ubuntu/root
<Kamion> mvo: see the .list file next to the .iso
<elmo> Kamion: well, no, my problem is that root= line is hardcoded into the grub config, as kopt= variable
<elmo> Kamion: so when you switch ti a non-stock kernel, you get screwed by it
<sivang> Kamion: what is Jessica's role in life?
<Kamion> er, it's only hardcoded that way if you install on LVM
<elmo> which is a regression, compared to hoary and earlier
<Kamion> unless something extremely weird has happened
<Kamion> sivang: # Synchronise package priorities with germinate output
<Mithrandir> seb128: I see some silent stack breakage, but it's more or less impossible to valgrind due to too much noise from libc and glib/gtk. :-/
<mvo> Kamion: thanks
<elmo> Kamion: oh - it's an LVM thing, sorry I thought it was generic
<elmo> Kamion: is that required to boot off LVM?
<Kamion> elmo: well, you need *some* root= parameter AFAIK. What were you using before?
<elmo> Kamion: this is a new breezy 'server' install; I've never run a custom kernel on it before :)
<Kamion> ah, you haven't done LVM-root on hoary?
<elmo> certainly without LVM, we normally don't have a root at all, I'd forgotten this one had been LVMed
<elmo> nope
<Kamion> ok, I guess either you need to put the LVM modules in your initramfs or compile them in monolithically, then; I've never done LVM-root with a non-stock kernel
* mvo wonders why dselect is still a dependency of ubuntu-standard
<Kamion> because I was in the discussion that established what to move to standard ;)
<ogra_> heh
<mvo> Kamion: heh :) 
<seb128> Mithrandir: not cool :/
<ogra_> Kamion, you are soo nostalgic sometimes :)
<Kamion> mvo: oh, and at the time, dpkg still pre-depended on dselect
<Kamion> ogra_: screw nostalgia, I use it and can't stand the alternatives
<Kamion> we can probably move it further out in dapper, though
<dredg> elmo: can i request a sync of mlmmj from debian please? it fixes some basic things that are broken in the current package
* Mithrandir blinks at the suggestion that elmo runs rootless servers.
<jbailey> Mithrandir: P'haps he's just waiting for one of us to root them for him?
* jbailey hides.
<elmo> dredg: done
<dredg> elmo: cheers
<Kamion> Packages to change from priority important to optional
<Kamion> ------------------------------------------------------
<Kamion> cramfsprogs
<Kamion> dash
<Kamion> initrd-tools
<Kamion> d'oh, I probably should've done that a while back ...
<ogra_> does that matter for universe packages ?
<elmo> Kamion: done, but I guess you already know
<Kamion> elmo: BTW did you ever get round to looking at my alicia patch to make it actually work?
<elmo> ogra_: yes, it matters
<ogra_> oh
<Kamion> elmo: done which?
<elmo> copies of minimal + standard
<Kamion> ogra_: cramfsprogs and dash are not in universe, even though initrd-tools is
<Kamion> ogra_: so they were being needlessly installed on netboot installs
<Kamion> elmo: oh, right, cool, thanks
<ogra_> double oh...
* ogra_ finds it very intresting that there is not one complaint on -users that the unoff. backports are gone...
<ogra_> seems they were not *this* important for the users
<pitti> ogra_: not that the official backports of firefox were much saner :-) (SCNR)
<magnon> seems that most of the users are bleeding edge ;)
<ogra_> pitti, lol
<ogra_> pitti, but there you can blame Mez directly....
<pitti> well, it was just bad luck...
<magnon> pitti: btw, my powerbook has strange bugs. sound doesn't work, event devices are gone... checked with another powerbook, same modules loaded and all seems to be the same
<ogra_> pitti, nope
<pitti> magnon: sounds like the udev bug we recently had...
<magnon> so, pbbuttonsd doesn't have anything to count with, so when it's on my screen goes off every 10 mins :P
<magnon> yeah, I haven't updated in a little while
<Kamion> elmo: excellent, I have 'jessica -a amd64' etc. working now
<ogra_> pitti, i opposed making him MOTU before he wouldnt be able to make empty packages, remember ?exactly for this purpose
<pitti> magnon: please upgrade to the latest Breezy and try again
<magnon> in the process atm :)
<Kamion> elmo: is there anything I should do with the "Packages to change from priority source to optional" list? I'm guessing that any binary packages with priority source are a mistake
<magnon> oh great, xserver updates :P
<elmo> yeah
<elmo> they should just be made optional
<magnon> pitti: will just upgrading udev be sufficient to test?
<elmo> kamion: and no, sorry I haven't had a look at alicia, feel free to apply the patch on jackass, if it's blocking you
<Kamion> elmo: certainly not blocking, I just have a local copy of the script with the patch
<pitti> magnon: well, you need to reboot afterwards, but udev is the only package that caused that, yes
<magnon> of course
<pitti> magnon: without rebooting you can just try "sudo udevstart"
<pitti> magnon: (even with the old package)
<Kamion> was more in case it was useful for making microchanges to stuff like udeb priorities in Debian
* Diziet finishes wrestling with CUPS and Firefox.  Printing is very complicated nowadays.
<Kamion> although, hmm, I guess those must work if alicia works for .debs in Debian
<magnon> pitti: gorgeous, that trigged the pbbuttonsd bug ;)
<pitti> magnon: 100% CPU? 
<magnon> yup
<pitti> magnon: did you upgrade pbbuttonsd as well? to 0.7.1?
<magnon> I believe I did and then told you it didn't help
<magnon> the newest Debian package works though
<elmo> Kamion: our override situation is much more messy/complex than debian's
<Kamion> jbailey: were you going to fix binutils-static to have its own doc directory and stop depending on binutils, or shall I do that?
<Kamion> elmo: yeah, I couldn't quite work out why there seemed to be two of everything
<Kamion> (which was why alicia hated life)
<jbailey> Kamion: I can.  Sorry, forgot about it.  doing
<Kamion> jbailey: cool, thanks
<Tm_T> what's wrong with xorg, in X any kb key just changes resolution
<Tm_T> known problem?
<magnon> pitti: I'll test more later. have to go
<Kamion> jbailey: (that'll be 6MB less in a base install)
<pitti> magnon: then ours will work as well, I mergd recently
<magnon> good
<mvo> Kamion: usplash on the current daily isn't run in stage2. is that known?
<pitti> carlos: I looked at blender for a while; it uses a highly nonstandard gettext system, hard to create a POT file
<pitti> carlos: and the PO files do not even have a header
<Kamion> mvo: broken due to the recently-introduced alternatives bug that jbailey fixed today, I imagine
<pitti> carlos: well, at least some of them don't
<mvo> Kamion: thanks
<jbailey> Kamion: Was that my "Hey, .so files don't go in /usr/share" thinko? =)
<Kamion> jbailey: yeah
<Kamion> I imagine that'll have caused usplash not to display anything ...
<jbailey> Yes, quite probably.
<Kamion> I note, incidentally, that Edubuntu installs are going to show the Ubuntu usplash image on the first reboot and the Edubuntu usplash image on the second and subsequent reboots
<jbailey> IT would've been a dangling symlink, and usplash would bail on the missing fail.
<Kamion> since edubuntu-artwork depends on too much graphical stuff to install it in the first stage
<Kamion> jbailey: BTW, surely /usr/anything isn't a great place for the usplash image
<Kamion> I'd've thought /lib/usplash/...
<carlos> pitti, hmm, I will take a look
<jbailey> Kamion: It just gets stuffed into the initrd.  I couldn't see the point of cluttering up the root filesystem with something that we only load before that point anyway.
<pitti> carlos: I can probably generate a POT file with *all* strings, but that would be way too much
<Kamion> jbailey: oh, I see, good point
<carlos> with all strings?
<pitti> carlos: I look in their CVS and on their webpage to find out how they generate their POTs
<Kamion> sorry, forgot it was initramfs'd now
<Riddell> Kamion: isn't it just edubuntu-artwork-usplash that's needed?  and that shouldn't depend on much
<pitti> carlos: they don't use a wrapper method like _(), at least not consistently
<carlos> but I suppose they have a script that extracts the strings, right?
<Kamion> Riddell: oh, I hadn't realised it was a separate package now; that makes sense
<tepsipakki> kamion: is there any way to tell partman to use fixed partition sizes in a recipe?
<mvo> Kamion: I was wondering if my usplash change (0.1-11) fixed the installer console-font switching also (in stage2). so I guess I need to re-test that tomorrow
<Kamion> tepsipakki: use equal minimal/maximal sizes, and probably equal priority to both?
<Kamion> so '104857600 104857600 104857600' for a fixed 100MB partition
<tepsipakki> kamion: thanks, I'll try. I haven't tried this for a while
<Kamion> tepsipakki: that's what kickseed does if you ask for a fixed size, anyway
<wasabi_> Is it just me or is the evo exchange backend totally broken in breezy?
<pitti> carlos: ugly, I mail the blender guys
<jbailey> wasabi_: I've had some failure and some success reports.
<jbailey> wasabi_: What problem are you having?
<wasabi_> Well, the configuration tab doesn't list any useful config options
<wasabi_> Just Username.
<wasabi_> No where can I even insert the name of the server to use.
<carlos> pitti, ok, thanks. Please, keep me inside the loop
<jbailey> Eh?
<jbailey> I'll look at that in an hour or so.
<tepsipakki> whoa, the usplash-logo made it in the netboot-image, nice ;)
<Kamion> oh, yeah, did that last week
<wasabi_> jbailey, so what did you think about my unionfs idea?
<wasabi_> To just build it in.
<jbailey> wasabi_: mdz was working on something like that earlier and getting kernel crashes.
<wasabi_> Aww. =(
<jbailey> I didn't follow it in detail, so I don't know.
<Mithrandir> seb128: I'm banging my head against some valgrind failures which doesn't make any kind of sense, so I'm going home to see if that helps.
<segfault> does edubuntu's client kernel has usplash?
<ogra_> segfault, jbailey told me its in since today (untested yet)
<ogra_> s/ts/the opportunity
<seb128> Mithrandir: k
<segfault> nice
<tepsipakki> kamion: does not work. I used "512 512 512" for root, and I get 466MB
<Kamion> tepsipakki: it's possible it's not exact depending on priorities of other partitions; you'll have to read the recipe documentation
<Kamion> segfault: usplash is in the initramfs, not the kernel, fyi
<tepsipakki> is it available online somewhere?
<tepsipakki> or do I need to make a cvs-pull first?
<sladen> tepsipakki: is that with the 10% of disk-space reserved for root.   466 * 1.1 is exactly 512
<tepsipakki> sladen: root doesn't use percentages, swap does
<tepsipakki> ..hmm, you _really_ can shoot yourself in the foot with priorities ("No root file system is defined")
<sladen> tepsipakki: root as in the 10% of diskspace that is reserved for the root *user*.  (eg. if you do df -h)
<tepsipakki> ;)
<Kamion> tepsipakki: http://svn.debian.org/wsvn/d-i/trunk/installer/doc/devel/partman-auto-recipe.txt?op=file&rev=0&sc=0
<tepsipakki> oh... f*ck
<tepsipakki> is 10% the default?
<bddebian> Anyone have any thoughts on morgueing ghc-cvs??
<Kamion> I thought the default was 5%
<tepsipakki> I've seen that too
<tepsipakki> kamion: thanks for the link
<ogra_> the default is 5%
<Kamion> it's tunable in d-i though
<ogra_> except sladen secretly tweaked that ;)
<Kamion> but indeed, the default in partman is 5% too
<Kamion> at least for ext2/ext3, haven't checked others
<Yagisa1> G'day - doing a test install of breezy in vmware - and running into a partitioning error http://eyagi.bpa.nu/~jamie/breezy-no-lvm-on-raid.png
<Kamion> Yagisa1: I can't get to that site from here; traceroute stops at syd-pow-ibo-are-5-ge-0-1.tpgi.com.au
<StR> Hi all!
<bddebian> Hello StR
<StR> why did you choose to use php5 in breezy?
<StR> it's not a god idea...
<StR> there is no pear package for php5
<tepsipakki> guys, it was df lying to me all along. cfdisk shows that the sizes are correct, and the small differences are due to partman rounding to the cylinder size, so all is well ;)
<dholbach> sto: what about php-pear?
<Kamion> fabbione: ok, I think I've come up with a way to get correct deb-src lines for ports, although it's pretty ugly
<dholbach> StR: php-pear
<dholbach> sto: sorry
<Kamion> tepsipakki: cool
<elmo> Kamion: blink?
<jbailey> StR: Why is it not a good idea?  Isn't it the recommended version by upstream now?
<elmo> the correct deb-src line for ports is a.u.c surely?
<jbailey> Kamion: \o/
<Kamion> elmo: quite so
<jbailey> elmo: Right, but it was just manging the ports.u.c =)
<Kamion> elmo: but base-config didn't know that
<StR> jbailey: because there is no php5-pear  package
<dholbach> StR: php-pear is it
<StR> dholbach: really? it works for php5?
<Kamion> elmo: (and until about five minutes ago, base-config didn't support differing binary/source sites at all)
<dholbach> StR: http://packages.ubuntu.com/breezy/web/php-pear
<Kamion> StR: it's built from the php5 source, so I kind of imagine so
<dholbach> StR: you should have a better look before you claim there was none :)
<StR> i will try it.. thanks
<dholbach> super
<elmo> Kamion: can you think of anything beyond BLK_DEV_DM that I'd need to compile in to have LVM-root working?
<pitti> jordi: good news - see #15541 :-)
<sivang> elmo: fixing #15017 ?
<Kamion> elmo: I think that should be enough
<elmo> sivang: no
<mvo> pitti: mind if I upload alsa-utils to fix set-default-soundcard (#16087)? the problem is that system utils should use #!/usr/bin/python2.4 explicitily 
<jbailey> I have this urge to apply a serious amount of debhelper to binutils
<unu> janimo: hello
<Kamion> Ryan Troy just /msged me to say that he's set up spam filtering on the forums, which should help with ubuntu-devel@ noise
<mdz> morning
<Nafallo> Kamion: great news.
<Nafallo> morning mdz :-)
<mvo> morning mdz 
<ogra_> morning md
<ogra_> z
<ogra_> Kamion, you mean ubuntu-users ? 
<ogra_> (he wanted to shut down the -devel gw)
<bddebian> Heya mdz
<Kamion> ogra_: no, I mean -devel; he wanted to re-enable the -devel gateway once spam filtering was sorted out (which I'm not sure I agree with, but hey)
<Kamion> I want to do other things rather than getting into all that, if possible
<ogra_> heh...
<ogra_> at least its a small improvement
<ogra_> (but not the promised change :/)
<Kamion> feel free to talk with him about it
<Nafallo> ogra_: I agree with you fwiw.
<ogra_> Kamion, i'll do, if i tamed xscreensaver ;)
<pitti> mvo: (sorry, was away for a bit) of course, if it is necessary, go ahead
<mvo> pitti: `anthony suggested it and he should know :)
<Kamion> mvo: what's the rationale for using python2.4 explicitly? just curious
<mvo> Kamion: he said that importend system software should use it explicitly to make sure it always works. he has a bunch of other python2.4 version installed in /usr/local and this /usr/bin/env thing broke update-manager for him (and some other tools)
<pitti> mvo: but s-d-s should work fine with 2.1, and we don't support other versions
<mvo> pitti: it's more about /usr/bin/python vs. /usr/bin/env python I think
<dilinger> Kamion: when you have a sec, i've got some ssh auth change questions on #d-d
<mvo> pitti: but yeah, s-d-s is so simple that it really shouldn't matter ...
<jordi> pitti: #15541 doesn't exist?
<pitti> mvo: well, I'd be fine with /usr/bin/python
<pitti> jordi: erm, it does
<pitti> mvo: right, #!/usr/bin/python should be good enough
<pitti> mvo: an explicit version is too ugly IMHO
<mvo> pitti: yes, I think so
<mvo> pitti: *agreed*
<elmo> Kamion: /dev/mapper/ foo is like, a static device right?
<elmo> (and what's with the ini-caps?)
<pitti> elmo: not sure what you mean, but encrypted USB sticks use it, too
<elmo> pitti: I'm trying to boot a root-LVM system, and it's dieing with a custom kernel, even tho I've got DM enabled, trying to work out why
<pitti> elmo: ah, yes, a /dev/mapper/foo is a normal block device
<pitti> elmo: (I thought you mean that it is not dynamic, like with removable devices), sorry for disturbing
<jordi> pitti: malone?
<jordi> pitti: oh, ok.
<pitti> jordi: no, bz https://bugzilla.ubuntu.com/show_bug.cgi?id=15541
<pitti> jordi: belocs locales are on their way :-)
<pitti> jordi: while I have you here: we don't have any Asturian translations in our packages, so with which data am I supposed to create a language pack?
<elmo> 1/go Znarl 
<mdz> pitti: which packages in main depend on libsdl?
<mdz> elmo: are you using mkinitramfs with your custom kernel?
<jordi> pitti: excellent :)
<elmo> mdz: no, it's monolithic
<mdz> elmo: you need the userspace activation
<jordi> pitti: I guess there are none yet.
<jordi> Hopefully they'll do something in the next months.
<ogra_> mdz, tuxpaint uses sdl-ttf
<mdz> device-mapper just manages the block device; you need the userland tool to actually look at your disks to scan for volumes and set up the tables
<elmo> mdz: this is failing in mounting the root FS?
<mdz> elmo: yep
<elmo> how can userland stuff be relevant before it's even mounted the root FS?
<mdz> elmo: "/dev/mapper/blah" is meangless to the kernel
<pitti> mdz: quite a bunch: http://www.rafb.net/paste/results/wkHwdu80.html
<ogra_> mdz, the other tux* tools use libsdl-image
<pitti> mdz: oops, that was too much, sorry
<mdz> elmo: you need to run the userland initialization to set up a volume in the kernel before it can be mounted, whether it's root or not
<mdz> ogra_: tuxpaint isn't in main
<elmo> mdz: sorry I'm horriibly confused, are you telling me, the way our LVM root works is by running userland tools in the ramdisk or something?
<elmo> and is that the only way to do LVM-on-root?
<mdz> elmo: I am telling you that that is the *only* way that lvm2 has *ever* worked
<ogra_> mdz, waiting on anastacia since some weeks
<ogra_> mdz, *type and *math are
<mdz> elmo: initrd/initramfs is required
<elmo> #$T^#$^!!S%T
<Keybuk> elmo: dude, embrace early userspace, it is your friend
<mdz> ogra_: it did not even appear in anastacia until about a week ago
<Keybuk> initrd sucked, initramfs is sweet
<elmo> Keybuk: only by stockholm syndrome
<bddebian> Heya \sh
<jdub> embrace distribution kernels, they are also your friend :-)
<mdz> ogra_: and it is not listed at the top of the wiki page yet
<\sh> re bddebian 
<ogra_> mdz, * tuxpaint: MainInclusionReportTuxpaint (Edubuntu, cannot be promoted until sdl-image1.2 is in main)
<pitti> mdz: http://www.rafb.net/paste/results/KcCkGi55.html
<mdz> elmo: you are making it hard; if you just install the packaged kernel it should boot out of the box with lvm on root
<ogra_> mdz, sdl-image1.2 is approved and listed under promoted
<ogra_> GAH
<ogra_> blind me
<ogra_> sorry
<elmo> mdz: yeah yeah
<mdz> ogra_: yes, and tuxpaint is under "needs work"
<mdz> things get promoted when they reach the top of the page
<ogra_> mdz, from tuxpaints review page: MartinPitt: approved; sdl-ttf2.0 looks fine, too.
<ogra_> i didnt make an extra report ... do you need one ? 
<ogra_> and i have no idea why -stamps is where it is, its approved too
<mdz> ogra_: I don't promote packages which are marked as needing work.  when a package _and_ all of its dependencies are in anastacia and ready to promote, they should all be moved to the top section
<Kamion> the person looking for inclusion needs to take responsibility for moving it up the page when problems are resolved; archive admins aren't generally going to go out looking for stuff
<ogra_> mdz, ok, moving it... do you need a separate report for sdl-ttf2.0 to fullfil the formals ? or is the mentioning from pitti in the tuxpaint approval enough
<mdz> Riddell: so python-qt and python-kde3 were in main before, you say? why were they demoted?
<mdz> ogra_: there is a page for a report, but it is empty and not linked to the queue: https://wiki.ubuntu.com/MainInclusionReportLibSdlTtf
<mdz> it says the package is already in main, which it is not
<Riddell> mdz: they used to be a build-dep for hpij
<mdz> Riddell: python-qt3 was in main for hoary
<mdz> Riddell: python-kde3 I don't think was in main
<ogra_> hmm, very weird...
<Riddell> mdz: qscintilla wasn't either I think
<Riddell> I'll write main reports for them
<ogra_> mdz, i'm pretty sure it was at aug 15th
<mdz> libcdio uses dpkg-awk for this: ./debian/rules:LIBCDEV=$(shell dpkg-awk 'Provides:libc-dev' -- Package | sed -ne 's/^Package:[[:space:] ] *//p' | head -1) | libc-dev
<mdz> is that really worth bringing dpkg-awk into main?
<mdz> it seems unlikely to be actively maintained
<mdz> Depends: libcdio3 (= ${Source-Version}), ${libcdev}
<sivang> mdz: is that a common way to do variable substitution ?
<mdz> sivang: is what?
<mdz> using dpkg-gencontrol? yes
<elmo> or he could just do libc6-dev | libc-dev like everyone else
<sivang> mdz: no, the dpkg-awk thing you just mentioned
<sivang> re: libcdio
<Kamion> sivang: no, it's not
<mdz> no, it's pretty awful actually
<Kamion> the modern tool would be something from grep-dctrl, but that's still nasty and "don't do it"
<sivang> so why do people do stuff like that? :)
<elmo> because they're unique and special snowflakes
* bddebian has no comment
<sivang> elmo: LOL^2
<bddebian> elmo: Have a thought about morgueing ghc-cvs?
<hughsie> desrt: you get my email on hal development list, or shall I cc you directly?
<mdz> pitti: I'm a bit wary of the libsdl alsa change
<mdz> pitti: it has a huge reverse dependency chain
<pitti> mdz: I know your feeling, me too; it's just that -oss does not work at all in Gnome
<pitti> mdz: it's not hard to install OTOH, so at least we should promote -alsa to main
<mdz> pitti: shouldn't we have used -esd?
<mdz> pitti: yes, agreed
<mdz> pitti: go ahead and seed it to supported
<pitti> mdz: for games, low latency is probably better
<pitti> mdz: so I'd seed both -esd and -alsa
<mdz> pitti: yes
<pitti> mdz: so we keep the default to -oss?
<mdz> pitti: in fact, there's probably no reason not to seed -all
<mdz> they're all built from the same source in main so all the deps are probably there already
<pitti> mdz: ok, then I seed all of the variants (-all, -alsa, -arts, -esd, -nas)
<Riddell> Kamion: if I have a kubuntu-artwork-usplash package what needs done for it to get used?
<mdz> pitti: -all depends on the rest
<pitti> ah, ok
<pitti> mdz: seeded
<ogra_> mdz, i really dont get the sdl-ttf stuff but i happen to remember that i talked with pitti about it and we both were surprised it was in main already... i cant find anything in the rdepends that could have pulled it to main before...
<pitti> mdz: so we postpone the default switch to dapper
<mdz> ogra_: if it somehow ended up in main without anything pulling it in, then it would have immediately shown up as to be demoted in anastacia
<ogra_> hmm
<ogra_> do you have logs from anastacia ? i feel a bit silly...
<mdz> no
<mdz> ogra_: it's irrelevant, really
<mdz> it isn't in main and it has no review
<ogra_> sigh..
<bddebian> ogra_: See, elmo ignores me ;-P
<mdz> bddebian: I don't think that's a fair characterization after waiting 8 minutes for a reply
<bddebian> notice the ;-P :-)
<mjg59> bddebian: It is an accusation that you seem to make an awful lot...
<sladen> bddebian: elmo is in the UK.  Like every other british person here, he finished 1:15 hours ago...  You'll have to wait until 08:59 tomorrow.
<fabbione> Kamion: ah ok.. but again, don't get too crazy if it gets too hugly
<mdz> pitti: is aspell-es source obsolete?
<pitti> mdz: it's a bit difficult; aspell-es is built from both the espa-nol and aspell-es source, but espa-nol has a newer version 
<pitti> mdz: so I guess the source package is obsolete, yes
<bddebian> mjg59: No usually I accuse myself of bugging him too much :-)
<mdz> pitti: if it's truly obsolete, we should remove it entirely to avoid the possibility of it superseding the espa-nol binary in the future
<pitti> mdz: I don't know for sure TBH, I'll mail the Debian maintainer
<zyga> hello
<bddebian> Heya zyga
<pitti> mdz: I tell you when I got an answer
<mdz> pitti: thanks
<zyga> I'm falling apart
<zyga> four projects ... :/
<zyga> how are you guys/girls?
<mvo> hey zyga, I'm preparing a uplaod with your i18n patches 
<zyga> mvo: super, I'll check it :-)
<mvo> zyga: it was only the missing "_("translations")", right? and the pl.po file?
<zyga> mvo: well I'd also add _("extra")
<zyga> anything that can appear as section in synaptic
<mvo> zyga: where does extra come from?
<zyga> mvo: once you upgrade I'll install every possible package (non-conflicting) from the repo and check if anything else shows up
<zyga> mvo: I'm not sure really 
<zyga> mvo: no sorry!
<zyga> mvo: restricted
<zyga> but I guess extra did show up too...
<mvo> zyga: it's only usefull if the translators have a idea what the section means :) I need to put some comment in at least
<zyga> mvo: yes, put the commets, look at other stuff in the same file
<zyga> mvo: every section is explicitly labeled as such
<Kamion> Riddell: I haven't worked out the exact details yet, but just let me know and I'll sort it out somehow
<mvo> zyga: I'll add "restricted", but I don't know what to do with "extra", I can't think of a usefull comment for it
<Kamion> Riddell: in fact, yes, it's trivial, just a cdimage seed change
<zyga> mvo: 'Extra' is okay
<zyga> mvo: remember - it's about the translator
<zyga> Ekstra
<zyga> Dodatkowe
<zyga> or whatever
<zyga> I'm sure you could show your ideas
<Riddell> Kamion: kubuntu-artwork-usplash has been uploaded
<Kamion> Riddell: debian-cd adjusted accordingly, for both Kubuntu and Edubuntu (which has edubuntu-artwork-usplash)
<janimo> is the default ubuntu artwork part of the usplash package?
<janimo> and edubuntu and kubuntu provide it separately?
<Riddell> janimo: yes
<Riddell> Kamion: great, thanks
<janimo> and installing one of those gets the default art changed?
<janimo> or is it a CDonly thing?udeb
<Kamion> janimo: no, separate package
<Riddell> janimo: you need to run update-initramfs -u
<Kamion> {kubuntu,eduubuntu}-artwork-usplash
<janimo> ok thanks guys
<Riddell> janimo: update-initramfs -u -t if it's your first run
* janimo is interested in xubuntu-artwork-usplash
<Kamion> Riddell: remember to seed kubuntu-artwork-usplash
<Kamion> ogra_: remember to seed edubuntu-artwork-usplash
<Kamion> (if you haven't already)
<Riddell> Kamion: in the desktop seed?
<zyga> yay, xorg upgrade
<zyga> I really like the new separated xorg package
<ogra_> yup
<Kamion> Riddell: ship
<zyga> insead of downloading one big blob
<Riddell> Kamion: ok
<zyga> we can download multiple small blobs that all depend on each other
<zyga> yay
<Kamion> well, desktop would work too
<Kamion> that would cause the kubuntu-desktop metapackage to depend on kubuntu-artwork-usplash too
<Kamion> which may or may not be appropriate; up to you
<Kamion> usplash is in desktop, so I guess desktop would be best, actually
<Riddell> Kamion: well usplash is in desktop
<Kamion> yeah
<Riddell> ok
<Diziet> Firefox makes me wish for makecache, which is like ccache except impossible.
<zyga> Diziet: why is it impossible?
<zyga> Diziet: if you dont dump everything you built and it has no dependency on changed stuff ... it should work?
<Diziet> Make can invoke things (and look at files) that the wrapper can't know about without ptraceing make, which would make it far too slow.
<Diziet> Maybe an LD_PRELOAD could do it faster.  But then to tell whether the cache was still relevant you'd have to stat all of those things again.
<zyga> Diziet: maybe getting rid of such stuff from the makefiles could hel
<zyga> help
<Diziet> Good idea.  Please send your patches to the Firefox build system upstream :-).
<desrt> hughsie; cc me, please
<zyga> Diziet: oh okay - as soon as I get cold fusion working, okay?
<Kamion> please design my teleporter first; I want a cron job interface to it so that I can be transported to the pub without having to think about it
<ogra_> Kamion, no beer at home ? 
<mdz> Mithrandir: ping
<zyga> Kamion: well once I do that I'll beem you directly to your teleporter pad - untill then just stand still and wait
<Kamion> not quite as much variety
<\sh> Kamion: hmmm...nice idea...we should BoF it ,-)
<Mithrandir> mdz: pong
<Mithrandir> mdz: or, semi-pong, I'm making pancakes so high-latency.
<ogra_> \sh, hey, the we even could meet all in Kamion's pub 
<ogra_> *then
<\sh> ogra_: did u ever play with wpa_supplicant?
<ogra_> nope
<ogra_> all i can think after nearly 60h worktime in 3 days is screensaver, screensaver, screensaver ....
<ogra_> and this darn unlock button still doesnt work...
<Nafallo> Mithrandir: ooooh. I know what I want next time we visit ;-).
<\sh> ogra_: lets swap the work...u deal with EIT tables and I will rewrite screensaver from scratch ;)
<ogra_> \sh, haha, you should hav offered that last friday, now i have only the unlock button left... i hope i can upload the new lock patch tonight
<\sh> ogra_: I think u don't want to deal with broken java stuff on windows 
<drac> Breezys 2.6.12 kernel, and X.org. Matrox card. LIBGL_DEBUG=verbose glxinfo. "MGA DRI driver expected DDX version 1-1.2.x but got version 1.1.1"
<drac> So.. no 3D anymore. :P
<ogra_> \sh, during this screenaver change there were times i wished i had to :p
<Keybuk> waaaah
<drac> I hope that won't be final version of Mesa.. or kernel in breezy :(
<Keybuk> did someone just hit "ASSIGN ALL BUGS TO KEYBUK" ? :p
<Mithrandir> mdz: oh well, dinner, I'll repong in a little while.
<ogra_> hmm, great idea, now you bring that up...
<mdz> jbailey: bugzilla is saying "Excluding:  jbailey@ubuntu.com " for your bugs
<mdz> Mithrandir: bug 15571 needs some love; what's highest on your todo list right now?
<Nafallo> drac: file a bug :-)
<Mithrandir> mdz: dinner. :-)
<mdz> Mithrandir: your Ubuntu todo list
<jbailey> mdz: Yes.  I use the queries to get the bugs instead of getting them by email.
<Mithrandir> mdz: I could look at that, sure
<Mithrandir> mdz: I've been banging my head against the g-s-t generates invalid passwords on amd64 the whole day.
<mdz> Mithrandir: I'll be around late into my night, let's talk about it in your morning
<Mithrandir> mdz: ok, sure.
<mjg59> Hrm.
* mjg59 ponders the "Display enable skew" field
<mdz> jbailey: then you need to read every bug to see what has changed
<mdz> jbailey: sometimes I add a comment to a bug asking about its status, and I don't hear back from you
<mdz> likewise, you'd need to check every bug to see if a user added new information
<mdz> this seems awfully inefficient
<jbailey> mdz: In this case I probably missed it because I thought it was more after-deadline m-o-m noise.
<jbailey> mdz: I found that I was missing emails in my mailbox because of the volume.  Instead I sort by the last-touched date in the lists and can see what's changed.
<jbailey> I can add it back for now.  I'm just trying to figure a way of managing malone, rt, bugzilla and the other email in some reasonable way.
<mdz> whatever works for you, so long as you're  notified when a bug is updated
<Nafallo> NonLanguagePackTranslationDeadline tomorrow. what's not langpacks? :-)
<mdz> Nafallo: the installer
<Nafallo> mdz: nothing else?
<mdz> oo.o and firefox perhaps
<Riddell> mdz: main inclusion reports done
<Nafallo> oki. thanx.
<janimo> seb128, any thoughts on the lpi sans libgnome bug?
<Kamion> Nafallo: .desktop files
<Nafallo> Kamion: are those in Rosetta to?
<Nafallo> Kamion: btw, pkgconf-* is the installer, right?
<Kamion> Nafallo: Rosetta> no idea
<Kamion> Nafallo: no, that's debian/po/ directories, i.e. debconf templates
<Nafallo> but that's what the installer uses? I've already translated some of those the other night...
<Kamion> the installer uses debconf a lot, yes, but by no means all debconf use is by the installer
<Nafallo> hmm, oki :-)
<Kamion> I forget whether other debconf templates are included in language packs, but I kind of doubt it
<Nafallo> then all pkgconf-* should be high priority for us :-P
<Kamion> it's a bit of a tradeoff; pkgconf-* files outside of the installer aren't displayed to users as much as some normal translations elsewhere
<Kamion> so kind of up to you ...
<mdz> jbailey: what is the intent of all this new usplash/initrramfs complexity?
<mdz> jbailey: we're awfully close to release for this sort of thing
<Nafallo> the normal translations are in langpacks, that will give us another week ;-)
<Kamion> looked like making usplash run earlier, to me
* Diziet gives hirself a crash course in JavaScript.
<mdz> Riddell: thanks, have pitti review them and move them to the top section
<jbailey> mdz: It lets the splash image be skinned easily.
<jbailey> mdz: The change is just that it gets the file from a dlopen rather than having it built in.
<bddebian> mdz: In all honesty, how should we determine if a package should be morgued or not??
<jbailey> So it's quite minor.
<Kamion> (ah)
<drac> Nafallo: Where do I file bugs against Ubuntu.. ?
<jbailey> bddebian: If it doesn't move when you stick a fork in it...
<mdz> jbailey: it also adds an alternative
<bddebian> jbailey: :-)
<mdz> jbailey: which has already spawned bug #16514
<jbailey> mdz: Yeah, fixed by the -13 upload this morning.
<jbailey> I made a thinko between /usr/lib and /usr/share
<mdz> jbailey: it's easy to make mistakes when introducing this type of change, which is why we need to avoid it this late in the game
<mdz> we should only be fixing high-impact bugs and low-risk bugs
<Nafallo> drac: bugzilla.ubuntu.com for main
<jbailey> mdz: 'k.  The only other major one I have that I'm still testing is debconf'ing the glibc questions and some locale updates.  I think it's major enough since the old upgrade-applet doesn't automatically pop up the terminal window for questions.
<mdz> jbailey: yes, the glibc questions need to be addressed, but I think debconf is not the best approach at this stage.  We should use a sane default and suppress the question
<mdz> debconf introduces a lot of variables
<dholbach> could somebody give me another opinion on lintian-overriding non-dev-pkg-with-shlib-symlink with the reasoning "that lib is not used anywhere, won't split out"?
<jbailey> dholbach: I tend to prefer to keep lintian warnings as a reminder in the future in case something *does* grow a dependancy on it.
<bddebian> Shoot, I didn't realize scribus was a main package :-(
<dholbach> because i tend to be a bit anal about the out splitting, i find myself in front of the new fashion to lintian-override it
<jbailey> mdz: We already force restart them in $DEBIAN_FRONTEND == noninteractive mode, it would be easy enough to just make this the case always.
<dholbach> (but i got a good thrashing from fabbione, maybe that's why i have an eye on it :-))
<mdz> jbailey: that sounds reasonable to me
<jbailey> mdz: Do you think it's worth doing a notification applet notification to say that  NSS has been updated and rebooting isn't a horrible idea?
<jbailey> (Not in those words)
<mdz> jbailey: yes, I do; I was thinking about that during my last hoary->breezy upgrade
<dholbach> thank you, jbailey 
<Keybuk> jbailey: to be honest, any libc update (even a minor one) really should be followed by a reboot
<Keybuk> otherwise you have two copies of it mapped into memory
<Keybuk> but *shrug* I've never convinced most unix people that reboots aren't bad, and uptime chasing is silly
<bddebian> heh
<jbailey> Keybuk: It's not a problem in classic unix and mainframe circles.
<jbailey> Keybuk: Almost all high-end services I've ever seen has a weekly reboot for sanity.
<Kamion> I find them more a hassle than bad, personally; I lose state
<mitsuhiko> hi guys
<jbailey> Kamion: A surprising number of my apps preserve state when I save the session, it's kinda frightening.
<mitsuhiko> can someone explain me "Solution #2" on this page: https://wiki.ubuntu.com/UnsignedGpgKey ?
<bddebian> mitsuhiko: What is to explain?
<zyga> mitsuhiko: it's longish, takes more money, it's silly
<zyga> mitsuhiko: wait for a trip to some foreign country and sign away
<mitsuhiko> zyga: hm
<mitsuhiko> zyga: ok. i'll sleep about it :)
<ogra_> zyga, why does it need to be in a foreign country ? 
<zyga> ogra_: if you cannot do #1 it's probably because there is no-one near you
<zyga> (probably)
<ogra_> zyga, so i have to go to another country instead of another city ? 
<zyga> ogra_: if you cannot do #1 its probably because it's not convenitent 
<zyga> ogra_: ;-)
<zyga> okay okay it's not strict but I'd say that the only reason to use #1 if the nearest person is really really far away
<Kamion> the only reason to use #2, I guess you mean
<zyga> ah
<zyga> yes :)
<ogra_> i still dont get why that needs to involve foreign contries... :)
<Kamion> it's just an example ok
<ogra_> ok...
<Kamion> you're being too precise :)
<ogra_> mitsuhiko, didnt you live in dortmund ? 
<mitsuhiko> ogra_: ney, hermagor ^^
<mitsuhiko> ogra_: somewhere in the south of austria
<ogra_> oh, ok
<zyga> ogra_: because the country boundary is usually far more difficult to cross than city boundary
<ogra_> zyga, i simply cant imagine there are n austrians with a signed gpg key :) but lets drp this conversation here 
<ogra_> s/n/no
<zyga> ogra_: I did not apply this to any explicit country context
<seb128> janimo: not worked on it yet
<lamont>  * Unmounting local filesystems...                                              umount: tmpfs busy - remounted read-only
<lamont> umount: /dev/hda4 busy - remounted read-only
<lamont> feh
<lamont> pitti: ping
<lamont> seb128: you around?>
<dholbach> <- dog walk
<seb128> lamont: pong
<lamont> seb128: trying to rationalize which source packages gtk-smooth-engine should be building/delivering and which ones need to be removed/epoch'ed/whatever to make things sane again....
<seb128> lamont: gtk2-engines could probably build it
<WaterSevenUb> mvo, you can still upload .desktop after non language pack freeze?
<lamont> seb128: the heart of the issue is that hppa has gtk-engines-smooth_0.6.0.1-1_hppa.deb in the arvhive, but no one else does...
<bddebian> WaterSevenUb: Apparently not advised ;-)
<seb128> lamont: gtk2-engines was probably building it for some time
<lamont> seb128: so either the source (gtk-engines-smooth) should be removed or made buildable.
<lamont> ia64/sparc have gtk2-engines-smooth, but hppa doesn't... hrm
<WaterSevenUb> bbdebian, ok.. so I still have time until tomorrow to bother mvo :-)
<WaterSevenUb> mvo, if you manage some time, upload them ;)
<lamont> and yet hppa has uploaded a finished gtk2-engines...
* lamont goes to look at breezy-at
<mvo> WaterSevenUb: erm, right :)
<WaterSevenUb> mvo, thx for language-selector change too :)
<lamont> seb128: breezy-autotest shows that (today), the gtk2-engines source in breezy does _NOT_ deliver gtk2-engines-smooth, while it did previously...
<WaterSevenUb> mvo, now that uses iso-codes how is thing updated in rosetta?
<lamont> so a no-change upload of gtk2-engines will break gnome.  kthxbye
<seb128> lamont: yeah, we probably did and Debian didn't so when we synced
<seb128> lamont: how will it break GNOME? gnome doesn't really care about this package :)
<lamont> well, break might be a strong word.
<seb128> lamont: anyway will fix it
<lamont> since hppa has the gtk-engines-smooth version, adding hppa to the scripts pulls that source into main, while the other architectures are happy with the (no longer built the same) gtk2-engines
<seb128> oh, the package is a main one
<lamont> seb128: if gtk-engines-smooth should go away completely, please request that.  Otherwise, it needs to have a higher version number.
<seb128> gotcha
<lamont> Rejected: gtk2-engines-smooth_0.6.0.1-1_ia64.deb: old version (1:2.6.2-0ubuntu2) in breezy >= new version (0.6.0.1-1) targeted at breezy.
<lamont> from breezy-at
<seb128> no it doesn't, it still builds the gtk1 variant
<elmo> actually that's from the main archive
<lamont> elmo: ah, ok
<lamont> anyway, thanks seb128
<seb128> np
<pitti> Hi lamont
<lamont> pitti: lobbed a bug at you
<lamont> 16562
<lamont> (all of the archive is still using the old 7.4 pgtcl.  thought you'd like to know...)
<pitti> lamont: well, actually there was no libpgtcl at all in breezy
<pitti> lamont: right, I'll add an epoch
<lamont> pitti: thanks
<pitti> lamont: could you please have a look at #10119?
<lamont> pitti: the answer to your question is 'poorly'
<lamont> I've hardcoded vfat on a number of them, because it picks fat when left to itself...
<lamont> I guess I could go look at the detection code and figure it out
<Kamion> pitti: last I checked, mount used libblkid or whatever it is to try to do the guesswork
<Kamion> which grobbles about inside the filesystem with various heuristics
<lamont> sounds right
<Kamion> but ICBW, and mount might have its own heuristics too
* Kamion goes off to do other things for the evening; night all
<ogra_> Kamion, enjoy
<pitti> night Kamion 
* pitti returns to $)$=&* postgresql
<ivoks> pitti: :)
<ivoks> so -alsa will not be default... :/
<pitti> ah, btw, does anyone happen to have an ia64 box with a sid or breezy dchroot?
<ivoks> pitti: ravel?
<pitti> ivoks: I discussed this with mdz, too close to the release; but at least the other drivers will be in main
<ogra_> ivoks, ravel is amd64
<ivoks> ah...
* ivoks blind
<pitti> I need a sparc, ia64, or fast mips box
<pitti> postmaster SIGBUSes on these platforms
<fabbione> pitti: ??
<ogra_> my mips only has irix on it :(
<fabbione> pitti: what do you need on sparc?
<Nafallo> Kamion: I hope you crawl Rosetta last thing tomorrow evening ;-).
<pitti> fabbione: I need a relatively fast machine with about 500 MB for debugging postgresql 
<pitti> fabbione: I need the psql build deps, gdb, strace
<pitti> fabbione: Florian Weimer gave me access to a mips, but it is missing gdb, and he's not available ATM
<pitti> fabbione: s/Weimer/Lohoff/
<fabbione> i can give you sparc..
<fabbione> it's not THAT fast.. but there is space
<pitti> fabbione: oh, do you happen to have a breezy build log?
<fabbione> sure
<fabbione> i think so at least
<pitti> fabbione: it automatically runs the test suite, and I'm interested in the results
<fabbione> http://bld-3.mmjgroup.com/buildLogs/p/postgresql/7.4.7-2ubuntu2.1/
<fabbione> pitti: that one should fit your need
<fabbione> one dir up for other versions
<henriquemaia> Hello, I'm having a problem with my amarok on my Breezy. 
<pitti> fabbione: oh, that's hoary
<henriquemaia> When I start it, I get:
<pitti> fabbione: with hoary and gcc-3.3 it works, I need breezy or sid
<henriquemaia> Starting amarokapp..
<henriquemaia> amaroK: [Loader]  Don't run gdb, valgrind, etc. against this binary! Use amarokapp.
<henriquemaia> amaroK: [Loader]  amarokapp probably crashed!
<fabbione> pitti: what version is in sid?
<fabbione> sorry breezy..
<henriquemaia> Anyone knows what's this?
<fabbione> henriquemaia: -> #kubuntu
<pitti> fabbione: any recent, preferably 8.0.3-12 or later
<pitti> fabbione: that URL also has postgresql-8.0 logs
<henriquemaia> I'm using gnome, but thanks.
<pitti> fabbione: it's HPPA, it fails there as well
<fabbione> pitti: meh i don't have these logs. but it did build...
<fabbione> pitti: send me your ssh key
<pitti> fabbione: yes, I currently do not let a failed test suite fail the build
<pitti> fabbione: http://www.piware.de/mpitt-ssh.pub
<fabbione> pitti: via email please?
<fabbione> (at least signed)
<pitti> fabbione: alright
<Keybuk> user "firefoxinnovator" logs in as "chiefinnovator"
<\sh> at last...working from bed
<Keybuk> (#16510)
<Keybuk> cute
<fabbione> pitti: working on it.. right a few secs..
<pitti> fabbione: last time I debugged postgresql on a loaded m68k buildd machine  - THAT was fun :-)
<fabbione> pitti: i could give you that too :)
<pitti> fabbione: no thanks :-) it's working on m68k now
<pitti> these slow machines are a PITA
<ogra_> mdz, depmod -aQ ?? wht is -Q ?
<ogra_> *what
<elmo> dholbach: why are you uploading pwmanager for the THIRD time in a row?
<bddebian> Heh, now dholbach gets his! ;-)
<segfault> mvo: sorry, i forgot the attachment :/
<segfault> will send asap.
<ogra_> ARGH
<ogra_> the 10th evolution crash today... and no time to debug grmpf
<mvo> segfault: ok
<\sh> ogra_: crash or just "not responding"
<fabbione> mdz, Kamion: ping?
<ogra_> \sh, it locks up, but the window stays...
<segfault> that's why thunderbird is better.
<\sh> ogra_: so no backtrace window..yeah the same here
<Keybuk> elmo: bah, that's barely 200 millidhanielstones
<ogra_> but i dont have time to care for that, if i dont manage to finish xscreensaver until tomorrow i can forget about edubuntu... i'm running out of time
<elmo> Keybuk: the same package for the third time after two previous (identical) REJECTs
<Keybuk> elmo: indeed
<bddebian> millidhanielstones? :-)
<Keybuk> bddebian: the Dhanielstone is the benchmark for the number of uploads per day
<bddebian> Ahh heh
<Keybuk> 1 Dhanielstone is 1 upload of X.org in 1 day
<bddebian> Oh fuck, I did it again
<lamont> Keybuk: is the comparison compile-time or disk-space based?
<Keybuk> lamont: like all good benchmarks, it doesn't specify that
<lamont> LOL
* lamont iterates on kernel config
<lamont> s
<fabbione> Keybuk: ahhaha
<lamont> nsDeviceContextSpecG.cpp:1215:2: error: #error !
<lamont> make[5] : *** [nsDeviceContextSpecG.o]  Error 1
<lamont> feh.
<lamont> that's not very nice at all
<sivang> lamont: what's the sound of "feh" ?
<lamont> it sounds like, um. feh.
<lamont> :-)
<fabbione> lamont: yeah.. firefoxtrot
<lamont> standard english 'F' followed by the 'e' from 'met'
<lamont> fabbione: yep
<fabbione> yeah i just saw it here
<lamont> hppa 88.54% 5509 of 6222
<lamont> sparc 82.99% 5196 of 6261
<frank23> I know this is not a support channel, but can anyone modprobe ath_pci in 2.6.12-9?
<mdke> frank23, i haven't got my acx111 card working in breezy yet
<fabbione> lamont: as i told you.. my 82.99% can install ubuntu-desktop.. can you? ;)
<frank23> mdke: I'm just trying to figure out if it's my problem or breezy's problem
<fabbione> frank23: check bugzilla for linux-restricted-modules
<fabbione> there are bugs open on madwifi
<frank23> fabbione: ok
<lamont>   ubuntu-desktop: Depends: x-window-system-core but it is not going to be installed
<lamont> '
<lamont> fabbione: so it's close
<fabbione> lamont: can you tell me in details why it's not installable?
<fabbione> lamont: i can perhaps fix it easily
<lamont> interestingly, apt-get install ubuntu-desktop x-window-system-core says it's happy
<fabbione> no no
<lamont> The following packages will be REMOVED:
<lamont>   libesd0*
<fabbione> it's happy because it's pulling in xserver-xorg-dbg
<fabbione> xserver-xorg is not installable for some reasons
<mdke> frank23, i have a bug open on acx_pci too
<fabbione> (same that i was experiencing on sparc)
<lamont> xserver-xorg-input-* has no installation candidate
<fabbione> MEH
<sivang> fabbione: and how does MEH sounds ? :)
<fabbione> lamont: that's going to be fun
<fabbione> sivang: M like in MYMUMMAOWNSYOU
<fabbione> E as in FEH
<fabbione> lamont: none of the drivers has been marked as hppa available...
<fabbione> lamont: that's not easy..
<fabbione> lamont: or at least fun
<lamont> fabbione: what do I need to do to fix it, I wonder?
<sivang> fabbione: okok, sorry if I bugged you :)
<fabbione> sivang: i wasn't kidding ;)
<fabbione> lamont: give love to debian/control and debian/scripts/vars.hppa
<fabbione> lamont: the point is out of the 23283928 drivers..
<fabbione> which ones do actually build and are used on hppa?
<fabbione> that's something you either know or we need to figure looking at the build log
<fabbione> or do a lot of interesting reading in Xmakefiles
<lamont> fabbione: well, the fact that it depends on all of them, but builds none of them, is well, annoying
<fabbione> yes
<mdz> fabbione: yes?
<fabbione> the problem is that: it builds everything.. we don't know what.. so pkgs are not generated
* lamont -> gone for a couple hours
<fabbione> lamont: + debian/scripts/vars.hppa will define the real Depends line
<lamont> fabbione: ah, ok.
<fabbione> mdz: hi
<lamont> so is it just a matter of seeing what it built?
<fabbione> mdz: i would like permission to upload discover1 with sparc only fixes. For other arches is just a rebuild
<fabbione> lamont: exactly
<fabbione> lamont: and associate it to the right package
<mdz> fabbione: ok
<fabbione> lamont: + adjust the final xserver-xorg Depends:
<fabbione> mdz: http://people.ubuntu.com/~fabbione/sparc.diff <- diff
<lamont> fabbione: OK.  I'll save the complete build tree, and see what we get
<fabbione> if you want to check
<fabbione> lamont: ok
<lamont> but right now, must run away for a bit.
<fabbione> mdz: the first chuck is inside an ifdef, but it's not obvious
<fabbione> mdz: the rest is...
<fabbione> lamont: sure
<fabbione> later
<mdz> fabbione: I see, thanks
<fabbione> mdz: thanks to you
<mvo> carlos: I did the apt upload now, I hope everything is fine and it can be imported into rosetta now :)
<LaschW> Is there any online documentation of OEM mode installation of breezy available?
<Burgundavia> LaschW, not currently
<Burgundavia> LaschW, it is planned to have some written
<LaschW> Burgundavia: So is there any CVS access to have a closer look?
<Burgundavia> LaschW, at the code for oem config? no idea, ask Kamion 
<LaschW> Kamion: Is there any CVS access to have a closer look at OEM mode install related programms?`
<doko> pitti: are the belocs-locales going to main, or do they stay in universe?
<janimo> is elmo's address james@c.c?
<carlos> mvo, thank you
<bddebian> janimo: Might work but I know james.troup@u.c works
<pitti> doko: for breezy we'll keep them in universe, but I'd like to switch to it in dapper
<janimo> bbdebian, thanks
<bddebian> np
<Keybuk> hmm, two things
<Keybuk> first, usplash didn't even appear that reboot
<Keybuk> jbailey: did you just break it? :p
<Keybuk> and secondly, I'm afraid I get 35 MB/sec from my laptop drive whatever I have running :-/
<slomo> elmo: did you read my mosml mail? (and the ffmpeg one weeks ago? ;) )
<Keybuk> mdz: 14330, 10517, 8873 (/dev/rawXXX not world-writable)  are you happy to leave those NOTABUG ... if people really want the entire world being able to write directly to any firewire device they should change the permissions/rules themselves
<doko> pitti: ok, then I'll leave the extra languages disabled for OOo2
<mdz> Keybuk: if the dv device exists so that applications can get access to firewire video devices, they should use that interface
<Keybuk> yeah, that's what I figure
<mdz> if it doesn't do what they need, it's buggy
<Keybuk> it's like an app writing to /proc/bus/usb not /dev/video0
<Keybuk> actually, it's worse, because at least /proc/bus/usb is device-discreet <g>
<bddebian> Anyone see an issue with bringing in the gutenprint stuff from Debian?  It replaces the ijsgimpprint stuff (package rename)
<Keybuk> are there such things as firewire hubs?
<bddebian> Not that I have seen
<sladen> Keybuk: http://www.charismac.com/Products/firedino/
<mjg59> Nnngh.
<Keybuk> sladen: cute.
<bddebian> Oh brother :-)
<HiddenWolf> damn, redhat is going to be big... :P
<jbailey> Keybuk: Shouldn't have, I've seen a bunch of success reports today and tested on 4 archs.
<HiddenWolf> they're supposed to put 16 million copies of redhat on the 100 dollar MIT-pc. For starters.
<mjg59>  I hate vga16fb so much
<mdz> HiddenWolf: they have a hypothetical deal to bundle redhat with a hypothetical product ;-)
<HiddenWolf> mdz, It's a hell of a big roll-out, if they'd get the deal
<HiddenWolf> mdz, just saw some concept sketches, it seems to be still moving forward.
<mdz> and the product actually goes to market...and ships that many units...
<HiddenWolf> Even if they realise 10% of their goals, that's still 1.5 million units in the first year. ;)
<sladen> mjg59: get people to put their answers on a wiki page;  then you won't flood the mailing list like last time :)
<mjg59> Riddell: Hello?
<Riddell> mjg59: hello
<mjg59> Riddell: Unless something is done to klaptopwhatever soon, power management is going to suck on kubuntu
<Riddell> mjg59: what needs done?
<mjg59> Riddell: It needs to call the correct scripts rather than just triggering a suspend itself
<Riddell> mjg59: what are the correct scripts?
<mjg59> Riddell: For suspend, it should call /etc/acpi/sleep.sh. For hibernate, it should call /etc/acpi/hibernate.sh
<HiddenWolf> mdz, and will you fix malone #1 already? ;)
<Riddell> mjg59: ok.  what's the gnome program that handles that?
<mdz> mjg59: I thought it was supposed to call pmi
<mdz> HiddenWolf: working on it
<mjg59> Riddell: There isn't - acpid gets the event
<mjg59> mdz: Yeah, that's probably true
<sladen> mjg59: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=140848 re: incorrect modelines in vga16fb
<mjg59> Riddell: scratch what I said - use pmi instead
<mjg59> pmi action sleep and pmi action hibernate
<mjg59> You may want to use the force parameter
#ubuntu-devel 2005-10-04
<mjg59> sladen: Hrm. Interesting. It's also happening on CRTs, though.
<Riddell> mjg59: acpid gets which event?
<mjg59> Riddell: The sleep key event
<Riddell> mjg59: I have acpid running here, how is kubuntu different?
<mjg59> Except in a small number of cases, where the sleep key generates a keycode that's caught by a daemon that calls a command that signals gdm
<mjg59> Riddell: Because there's also klaptopthingy that provides functionality to trigger stuff under various circumstances
<mjg59> People seem to use it and then wonder why stuff doesn't work
<mjg59> It doesn't generate the correct lockfiles, so when the user presses the power button to resume it shuts the machine down
<mjg59> sladen: We already have the values in that patch
<Riddell> mjg59: but sleeps keys and the like work just the same?
<mjg59> Riddell: I'd guess so. I know approximately nothing about KDE.
<sladen> mjg59: There's various issues, the first being LFP scalers, the second is that I suspect alot of the minimal 'VGA' BIOSes/hardware just aren't designed to do anything except standard 640x400, the third that 640x480/2 is >128kB and if it's not mapped, that shows up as wrap-around (which is why it would be preferable to use 640x400x4 or 320x400x8)
<Riddell> mjg59: ok, thanks for the info, I'll have a go at klaptopdaemon
<Riddell> mjg59: what's the command for cpu throtteling?
<mjg59> Riddell: ? Powernowd handles that automatically
<Riddell> klaptopdaemon has 
<Riddell> klaptopdaemon has an option for doing it explicitly
<mjg59> Riddell: Strip it
<Riddell> ok
<mjg59> We don't have any means of doing that
<sladen> Riddell: the equivalent functionality (in the CPU applet) is disabled
<Riddell> which package is pcm in?
<sladen> Riddell: pcm?  or pmi?
<mjg59> pmi?
<mjg59> powermanagement-interface
<pitti> mdz: just got an answer about espa-nol vs. aspell-es; the former should be used, the latter is obsolete
<Riddell> oh aye.  I'm too sleepy
<pitti> mdz: that means we should remove aspell-es from breezy completely
<pitti> elmo: can you please remove the aspell-es package? it is obsoleted by espa-nol
<pitti> elmo: i. e. both source packages build the binary aspell-es, but espa-nol is newer
<pitti> ok, good night everybody! cu tomorrow
<Riddell> lllmanulll: I just got some questions from a CNET reporter too
* mvo goes to bed now
<lllmanulll> Riddell, Ah, right :)
<lllmanulll> Well that's good news, seems like they want to talk about Ubuntu :)
<seb128> hey lllmanulll
<lllmanulll> hey seb128 :)
<dholbach> good night everybody
<Riddell> I wonder how he picks his interviewees
<lllmanulll> Oh, by the way, I'd like to rise a small problem
<mdz> will the Gnome Massager give me a massage?
<lllmanulll> Ah, nevermind, I'll file a bug :)
<dholbach> who's the gnome massager?
<lllmanulll> haha
<lllmanulll> A guy just sent a mail talking about a "Gnome Messager"
<Riddell> dholbach: Maria Blackmore does a mean workout
<dholbach> oh nice :)
<dholbach> Riddell: maria blackmore...?
<dholbach> it seems too late for me :)
<ogra_> mdz, the kernel module for the HW is still missing :)
<mdz> lllmanulll: and then in the body of the message he wrote "Gnome Massager"
<mdz> which sounded like even more fun
<lllmanulll> Ah, right :)
<ogra_> oh, it seems bsd already is prepared :)
<lllmanulll> But that's a great idea all the same :)
<lllmanulll> If GNOME can actually give massages, I'm sure it'll get far over KDE :-p
<ogra_> but there shouldnt be a separate app... it should just get included into workrave /me thinks
* Riddell starts work on a Massage KPart, ready for integration throughout KDE
<mdz> heh, someone is going around actually trying to run GNOME applications on an alpha and filing grave bugs in debbugs when they don't work right
<ogra_> with ubuntu ? o_O
<elmo> ogra_: "debbugs"
<ogra_> err, yes... i dont get enough sleep...
<mdz> ogra_: they are imported into bugzilla, of course; debzilla doesn't have enough AI to filter them
<ogra_> heh
<jdahlin> mdz: shouldn't 16568 block 12301 instead of duping it?
<mxpxpod> jbailey: ping?
<jbailey> mxpxpod: Lagging though as I'm wrestling with Exchange so I'm mostly at another computer.
<mxpxpod> jbailey: how do I redo my initramfs again (bootsplash and initramfs just updated)
<jbailey> mxpxpod: dpkg-reconfigure linux-image-$(uname -r)
<ogra_> mxpxpod, dpkg-reconfigure linux-image-`uname -r`
<mxpxpod> thanks :)
<ogra_> bah, 1 char less and still slower
<jbailey> ogra_: Considering I have a cup full of tofu icecream in one hand, you should be ashamed.  You have the timezone working against you though ;)
<ogra_> lol
<mdz> jdahlin: er, yes, thanks
<jdahlin> mdz: np, it just confused me a little
<HrdwrBoB> does anyone know the default HP iLO username/passworD?
<sladen> HrdwrBoB: is there a luggage tag on the bag with the details on?
<HrdwrBoB> sladen: I just got the user guide for it apparenty you have to set it up in the BIOS .. I'll read some more :)
<elmo> mdz: are you mid anastacia?
<mdz> elmo: no
<elmo> oh, well you left some python-qt stuff uninstallable
<elmo> and with 2.3 versions in main
<mdz> python2.3 is in main for breezy
<mdz> I haven't really bothered sorting out the modules
<elmo> uhm - ok is there any point in keeping 2.3 python modules in main?
<elmo> I've been demoting them out of hand
<mdz> my understanding is that people need to use python2.3 for zope?
<mdz> and so they might want some modules too
<mdz> the qt3 thing was an oversight; I thought it didn't have any deps waiting
<doko> elmo, mdz: python2.3 is needed for zope2.x. upstream doesn't do security audits with python2.4 and zope2.x, probably they won't do it for the 2.x release cycle anymore
<lamont> mdz: any objections to me lsb-base-ing ipsec-tools (racoon, setkey)
<lamont> ?>
<mdz> lamont: not if it's an easy one
<lamont> it's pretty trivial
* lamont just re-noticed that it wasn't lsb-ified
<bob2> I wonder why my desktop always has the fan on now
<bob2> even when doing nothing
<Keybuk> quiet tonight
<ajmitch> hopefully because people are working hard
<Keybuk> mdz: why "obsolete after the release" ?
<mjg59> mdz: Around?
<lamont> mdz: adding all the xorg-{driver,input} packages for hppa - any objections?
<lamont> literally just changing debian/control Architecture: lines, and hppa manifest
<seth_k> hmm, daniels, re: that xkbcomp command, after I paste in those lines to xkbcomp it just sits and acts like it wants more input. How do I terminate the input?
<daniels> seth_k: hit ctrl-d
<seth_k> thanks
<seth_k> posting output in the bug now
<daniels> ta
* Keybuk does something his Computer Science teacher always hated him for
<Keybuk> mmm... anonymous enums
<lamont> anonymity is a good thing
<lamont> daniels: you planning a -72 upload?
<bddebian> Yeah, then how come we have to sign packages? ;-)
<Keybuk> he used to whinge at me to use #define instead for defining numerical constants
<daniels> lamont: hppa's broken, eh?
<lamont> well, xserver-xorg is uninstallable is all
<daniels> lamont: bug reports in diff form are appreciated ;)
<lamont> daniels: yeah, testing my change now
<lamont> daniels: so far, it's just Arch lines for all the packages that correspond to _drv.o files, plus the manifest file changes... anything else I should be looking at?
<daniels> seth_k: sudo dpkg -i --force-confmiss /var/cache/apt/archives/xkeyboard-config_0.6-2_all.deb
<lamont> Keybuk: well if you declare them "const foo=2' that's one thing... adding random variables is more scary...
<daniels> lamont: that should e it
<lamont> daniels: woot
<daniels> lamont: no, wait
<daniels> lamont: debian/scripts/vars.hppa also, IIRC
<seth_k> daniels, dpkg - warning: downgrading xkeyboard-config from 0.6-3 to 0.6-2.
<seth_k> daniels, and then I get a TON of Configuration file xxxxxxxxxx does not exist on system, installing new config file as you request
<seth_k> daniels, restart X now?
<lamont> daniels: does vars.hppa get used before install stage?  taht is, can I just fix the file mid-build, or do I need to kill the testbuild?
<daniels> seth_k: yeah
<Keybuk> lamont: he used to prefer
<Keybuk> #define FOO_LEN 1
<Keybuk> #define BAR_LEN 4
<Keybuk> I prefer
<Keybuk> enum { FOO_LEN=1, BAR_LEN=4 };
<daniels> seth_k: and all should be good.  that's an error that only triggers when upgrading through a small set of versions of xlibs.
<daniels> lamont: unfortunately, it gets sourced first thing
<lamont> sigh
<seth_k> daniels, safe to upgrade back to 0.6-3 ?
<lamont> does XSERVER_XORG_SPECIAL_DEPENDS need all the -input-* pkgs, or just the -driver* packages?
<seth_k> daniels, it gave me a downgrade warning
<lamont> ah, all the -input- packages are there.  that would explain it
<lamont> daniels: build time is ~1 hour or so... will advise
<lamont> daniels: and when do you plan to upload?
<daniels> seth_k: yeah, that's fine
<daniels> lamont: just -driver; -input- is already taken care of, iirc
<daniels> lamont: preferably today
<seth_k> thanks for your help daniels, I'll mark the bug as invalid
<daniels> seth_k: no worries, ta
<lamont> daniels: if all goes well, I'll have a diff for you in about an hour
<Amaranth> #15636 needs a sync from pyxdg cvs to fix it
<lamont> 642 lines of diff -u
<jdahlin> daniels?
<daniels> jdahlin: mmm?
<jdahlin> daniels: I noticed while upgrading to breezy today that some xorg package is doing something like: find / *_drv*
<daniels> it shouldn't be, but apparently it does sometimes
<jdahlin> I couldn't upgrade, it was a box with nfsroot and many many files in some nfs mounts
<daniels> ouch
<daniels> okay, I'll check it out, think the fix should be fairly easy
<mdz> mjg59: yep
<infinity> Oh, look, it's an mdz.
<mdz> s/an/THE/
<jdahlin> daniels: should I file a bug?
<mdz> infinity: were you able to find out what was going on with 10080, or are we hoping against hope that the new version fixes it?
<daniels> jdahlin: it's okay, already sorted locally
<infinity> mdz : Due to the fact that I once, in a previous life, cared about VGA on a deeper level than I now do, mjg59 has asked me to petition for a kernel freeze exception to drop vga16fb's default res from 640x480 to 640x400 (which, if I remember naything from the bad old assembly/demo days, should resolve a lot of the "wraparound usplash/installer" issues people are having)
<mdz> infinity: sounds awfully risky
<mdz> we'd also need to resize the artwork, no?
<infinity> mdz : Well, the original submitter of that bug was incredibly unhelpful (as you've noted), but other bug submitters have been more forthcoming about their problems, and the pre-up thing should indeed fix it.
<infinity> mdz : He has a patch ready, and the artwork can be resized post-haste (in fact, lots of the artwork was alreayd done in both sizes, apparently)
<infinity> mdz : The problem is that 640x480 was an extension to the original VGA specs, and doesn't really work everywhere, and overflows fixed buffers allocated for VGA on lots of really old and really new cards (more of the ones in the middle seem to get it right)
<mdz> infinity: but it's the only mode we've tested for the past month :-/
<infinity> mdz : We'd also lose 5 lines out of the installer (going from 80x30 back to 80x25) unless we used a smaller font, but that's probably not worth caring about.
<mdz> and usplash testing is hard to get because people need to regenerate their initrds manually at the right time
<infinity> mdz : Yeah, and if I hadn't heard mdz complaining about problems with it this morning, I wouldn't have spoken up at all.  I didn't realise the issues were as widespread as they seem to be.
<mdz> actually we have more than a month of 640x480 testing, since the installer's been using it for ages
<mdz> I think we ought to wait until dapper
<infinity> There shouldn't be a computer on earth for which 640x400 would be a regression, but it should help a lot of broken ones.
<infinity> But yes, it can wait, if you're really nervous about it.
<mdz> by using 640x480, we're staying in the same mess we've been in since warty
* daniels notes that the installer is broken on a few laptops.
<mdz> with 640x400 we risk a new and unknown mess
<mdz> daniels: yeah, with known, documented workarounds
<mdz> and on the rest of the world's computers, it works splendidly
<infinity> Yeah, the documented workaround of using test-only or vesafb should work fine (one or the other) for most people.
<infinity> s/test/text/
<mdz> I like the idea; I just think we're too close to release to make the change now
<infinity> Yeah, you're likely right.  I wish I'd noticed earlier (would have been "nice" if I had broken hardware here, I would have immediately leapt on it..)
<infinity> Oh well.
<wasabi> mdz, i've heard you were doing some work to get unionfs support in the standard initramfs but ran into some kernel crashes (source: jbailey)
<wasabi> Have a resource to fill me in with?
<infinity> 320x200 and 640x400 are the only two modes I know of that work pretty much on all PC hardware within the last 15 years.
<mdz> wasabi: not exactly; here's the story
<mdz> wasabi: we patched in unionfs early in breezy, with the aim of using it for ltsp and the live cd
<infinity> (Well, and some strange pixel-doubling modes, like 320x100, 160x200, and other oddities)
<mdz> wasabi: it proved itself to be unusably buggy for ltsp, and so we never even enabled it for the live cd (Mithrandir made the patch but it's unreleased)
<wasabi> Ahh.
<mdz> wasabi: since it wasn't being used for anything and was not behaving very supportably, the kernel team preferred to remove it
<wasabi> I was looking into attaching it to my initramfs so that I can specify unionfs on the kernel command line to have root rw without saving.
<wasabi> Would make it more convientent for installing on embedded stuff for me.
<infinity> mdz : Anyhow, the wraparound isn't going to blow up anyone's hardware or anything, just look ugly, so I guess if we document it, and make the change as early as possible for dapper to get testing, that'll have to do.
<mdz> infinity: i think that's the best plan
<mdz> wasabi: the code for that is already in the ltsp package
<mdz> wasabi: you just need to provide the module
<infinity> mdz : As for 10080, did you get the CC on my followup to 10334?
<mdz> infinity: I did
<mdz> have you read the diff?
<infinity> Yeah, it's sane.
<mdz> I've never had to set up pppoe, thankfully, so I don't know what to expect from it
<mdz> can you mail me the debdiff?
<infinity> It's also been in Sarge for ages with pretty good results, if the BTS is to be believed.
<wasabi> Also, I was wondering about some sort of loop-back file support for /
<wasabi> For instance:
<wasabi> root=/dev/embedded/flash:/rootfs.img
<wasabi> See where I'm coming from?
<infinity> mdz : Yeah, I'll do the merge manually, and mail you the 1.6ubuntu2->1.8ubuntu1 debdiff.
<infinity> mdz : I assume you don't mind pulling in the minor translation fixes from 1.7 and 1.8?
<mdz> wasabi: with the initramfs script in ltsp, you just switch it on and say "throw a tmpfs on top of my root before starting up userland"
<Keybuk> *giggles* at gcov
<mdz> infinity: don't mind that
<Keybuk> oh dear, I appear to have not tested --help
<wasabi> Basically, that last example, mounts root as a loopback fs.
<wasabi> Makes managing a flash-based system easier. You distribute a root file, which is put on the flash device, vs actually having a real partition (lots of scattered writes)
<desrt> daniel does stir
<desrt> daniels; any way i can get more useful information for you on bug 16122?
<daniels> desrt: dunno, sorry; i don't do l-r-m anymore
<daniels> (nor do I have any idea about that particular bug)
<desrt> ah right.  fglrx is a kernel thing, not x
<desrt> kthx.
<lamont> daniels: sigh... ~50% of the way through the log file
<Keybuk> bloody hell, this is what I call an odd release cycle:
<Keybuk> 1.0.0  2005-09-29
<Keybuk> 0.1.0  2004-10-31
<lamont> Keybuk: clearly a busy year
<lamont> or a major re-scoping
<Keybuk> neither, just zero bugs all year
<Keybuk> I must've been on bloody good form when I wrote it
<lamont> heh - hct?
<Keybuk> nah, grepmap
<bob2> hah
<bob2> and now it's almost obsolete
<Keybuk> indeed
<Keybuk> still, it'll be used for breezy so figured I may as well make life easier for people
<Keybuk> reduced it's strictness about map file format a little
<jdub> mdz: http://lwn.net/Articles/153187/ <- interesting from the POV of solaris contracts on linux (and SMF) :-)
<Keybuk> jdub: the kernel guys are going to run out of letters to put in front of "notify" soon
<jdub> Keybuk: that's okay, there's always notifyfs to bring it all together in the linux style :-)
<Keybuk> hmm
<Keybuk> who broke metacity btw?
<Keybuk> when I Tab through windows, it only ever-so-briefly flashes the window border rather than keeping it on the screen all the time
<mdz> jdub: oh, is that what SMF does?
<jdub> mdz: well, SMF depends on solaris contracts, which you could compare with pnotify
* jdub couldn't find much in the way of documentation about contracts other than contracts.c and the library manpages
<lamont> daniels: building xc-xserver-xorg-dbg
<daniels> Keybuk: is the window area filled with black?
<daniels> Keybuk: if so, fix your xorg.conf
<Keybuk> daniels: no, not that I can see, why?
<Keybuk> it just draws the border then draws straight back over the top of it again
<Keybuk> fix how, ooi?
<daniels> *shrug*, wfm
<daniels> add your modules section back so you have SHAPE
<Keybuk> I don't have shape in there ...
<Keybuk> where did that go?
<daniels> no-one ever has, or probably will
<daniels> hint: Load "extmod"
<Keybuk> extmod is in there
<infinity> desrt : ping.
<daniels> right.  but that's only relevant to the window-area-is-painted-solid-black problem.
<Keybuk> Section "Module" has GLcore, i2c, bitmap, ddc, dri, extmod, freetype, glx, int10, type1, vbe
<desrt> infinity; pongtastic!
<daniels> right
<Keybuk> daniels: when you alt-tab do you get a permanent black border around the window ?
<daniels> Keybuk: yes
<Keybuk> and are you up to date today?
<infinity> desrt : Is that on an intel AGP chipset?
<Keybuk> any other ideas what it could be?
<desrt> yes
<Keybuk> I've only noticed it in the last few days, so it's a recent breakage
<desrt> 0000:00:01.0 PCI bridge: Intel Corp. 82865G/PE/P PCI to AGP Controller (rev 02) (prog-if 00 [Normal decode] )
<infinity> desrt : Can you try 'Option "UseInternalAGPGART" "no"' (or "yes", I'm not sure which way is which) in your conf?
<desrt> i have it set to no
<Keybuk> jdub: hmm, but unotify is the netlink event socket for the sysfs file system already <g>
<desrt> i've tried both... they give different errors :)
<Keybuk> (as apposed to using dnotify on sysfs)
<daniels> Keybuk: yes
<desrt> power is acting up a bit here (bit storm)
<desrt> so if i disappear that's why
<infinity> desrt : Ahh, joy.  Can I get the errors from both in the bug log?
<Keybuk> daniels: spill the beans :p
<infinity> desrt : Clearly marked, so I know which is which? :)
<daniels> Keybuk: ask the metacity maintainer
<Keybuk> already filed a but
<Keybuk> though it hasn't been changed since August
<Keybuk> oh, no, wait, new version a few weeks ago
* Keybuk looks when he installed that
<Keybuk> 2005-09-07 13:38:16 status installed metacity 1:2.12.0-0ubuntu1
<Keybuk> hmm, no, I've definitely noticed the change _since_ then
<Keybuk> it basically looks like something's redrawing the window
<desrt> infinity; done
<mdz> infinity: ok, pppoeconf++
<infinity> Uploaded.
<desrt> infinity; do you have any more questions/stuff to try?
<desrt> if not, i'm gonna hit the proverbial sack
<infinity> desrt : I'm looking at it in the background, but not dedicating too many cycles to it, so go have a happy nap. :)
<desrt> awesome.  cheerio :)
<infinity> desrt : Erm, wait.
<infinity> desrt : Which kernel is this on :)
<desrt> 686-smp
<infinity> I had a feeling it would be SMP.
<infinity> Out of curiosity, can you see if it goes away with -686?
<desrt> arf
<desrt> sure
<infinity> (obviously not a solution, just curious..)
<desrt> downlaod eta 4m
<infinity> mtrr on SMP kernels is slightly different than on UP kernels, and it's possible something's not accounting for that.
<desrt> it's not real SMP
<desrt> just HT
<desrt> so if push came to shove i'd probably suck it up
<desrt> i think i'm going to buy a new PC circa january anyway
<desrt> k.  reboot.  brb.
<Keybuk> gnargh
<Keybuk> s/unstable/breezy/ la la la
<desrt> infinity; absolutely no impact
<desrt> infinity; still getting the same mtrr errors in the dmesg and direct rendering disabled
<infinity> \o/
<infinity> Oh well.
<infinity> Thanks anyhow. :)
<desrt> night.
<fabbione> morning
<Keybuk> morning
<lamont> daniels: ping
<daniels> lamont: diff?
<lamont> well, wondering what happened to my changes to control...
<lamont> do you regenerate it or some such silliness?
<daniels> ... no
<lamont> hrm..
<lamont> Package: xserver-xorg-driver-ati
<lamont> Architecture: alpha amd64 arm hppa i386 ia64 hurd-i386 m68k powerpc sparc
<lamont> and yet we didn't build that
<lamont> or rather, never installed it
<lamont> I added the driver/input files to MANIFEST.hppa.in, but they didn't get installed, so it hates me
<lamont> daniels: for where I'm at: http://people.ubuntu.com/~lamont/xorg.diff
<infinity> Is it actually building the drivers?
<lamont> infinity: I got the list by saying 'find . -name '*_drv.o' and adding the arch to debian/control, and the destination files to MANIFEST.hppa.in
<jdub> mdz: cliff got in touch
<daniels> lamont: so xserver-xorg-driver-ati*.deb is empty?
<mdz> jdub: what's the status?
<lamont> daniels: given that we never get around to building the .debs....
<infinity> The MANIFEST check fails?
<lamont> because the manifest check fails
<daniels> so MANIFEST.hppa.new doesn't have ati_drv.o?
<jdub> mdz: going back and forth on the splash atm, but background is sorted
<lamont> the string 'xorg-driver-ati' does not appear in the output
<bob2> does hppa even have pci?
<mdz> jdub: on track to upload tomorrow?
<lamont> daniels: I preadded it to hppa.in
<lamont> and it's not in .new, so we fail
<jdub> mdz: very much so (have plan b artwork as well, just in case)
<daniels> lamont: so make install isn't carrying it over, if it's built at all
<lamont> ./build-tree/xc/programs/Xserver/hw/xfree86/drivers/ati/ati_drv.o
<lamont> daniels: I GOT THE LIST BY FINDING ALL OF THE _DRV.O FILES THAT WERE BUILT
<daniels> lamont: ... okay ...
<lamont> and that's correct, install isn't installing it
<lamont> and I freely admit to having NFC why
<infinity> Did hppa have an ati driver in the xorg packages in the old world order?
<infinity> (obviously it was built, but was it ever installed?)
<daniels> i have no idea why it would occur
<fabbione> lamont, infinity: you could compare xorg -10 with what's now
<fabbione> in -10 the MANIFEST files were ok and updated
<daniels> that'd be getting ObjectModuleTarget with InstallObjectModule
<daniels> and hppa is totally SEP for me
* infinity notes that xserver-xorg/hppa in Debian/sid contains exactly 0 drivers.
<fabbione> daniels: on the good side sparc works.. except the keyboard layouts :(
<daniels> fabbione: what's wrong with them?
<daniels> lamont: oh yeah, welcome to the world of no loadable servers
<fabbione> daniels: i can't say exactly.. i know jbailey did play with it yesterday.. X even manage to autoconfigure :)
<fabbione> daniels: at least with an ATI card
<fabbione> but it's like you press A and comes out something else
<daniels> fabbione: and you know your discover1 changes were completely pointless, right?
<daniels>       # must be Discover 1.x
<daniels>       DISCOVERED_VIDEO=$(discover --disable-all --enable=pci \
<daniels>                                   --format="%V %M\t%S\t%D\n" video 2>/dev/null)
<infinity> lamont : There are nodriver modules in xserver-xorg in Debian/hppa/sid, perhaps that's just the correct thing? :)
<fabbione> daniels: without my changes discover1 can't see the SBUS -> PCI bridge
<daniels> correct for hppa, yes, as no-one's bothered to write an elfloader bit for it
<lamont> infinity: well, having the xserver-xorg package not installable is what I was trying to fix.
<fabbione> daniels: so it can't detect PCI video cards
<fabbione> daniels: they have been tested dude 
<infinity> lamont : So, the answe may just be to not have it depend on any drivers for hppa.  That would make it match sid's package, for functionality.
<fabbione> daniels: the issue was above PCI.. and we still need SBUS to detect esp and some lan cards
<daniels> ah, okay
<daniels> lamont: well, it'll probably be broken for a while
<fabbione> daniels: + the code we had was segfault-o-rama :P
<daniels> that does sound like discover, yes
<lamont> daniels: atm, I really don't care if the xserver loads... I just want ubuntu-desktop installable, and xserver-xorg's deps are the only thing in the way
<daniels> lamont: basically, you need to find a way to not build -input- on hppa, and to have -core provide -input-* and -driver-*
<lamont> hrm... OK. but not tonight
* lamont -> home.
<infinity> mdz : ping.
<ivoks> 'morning
<jsgotangco> morning ivoks, sabdfl
<Mithrandir> hi mdz
<sabdfl> allo allo
<ivoks> rene :)
<Mithrandir> hi sabdfl
<ajmitch> hello sabdfl 
<fabbione> daniels: when do you plan the next X upload?
<fabbione> daniels: did you also get the diffs from people.u.c/~fabbione ?
<fabbione> (i did publish both 70-to-71 and 71-to-72)
<daniels> you mean 69-to-70 and 70-to-71
<fabbione> oui..
<fabbione> daniels: i might have the fix for the keyboard layout stuff pretty soon
<fabbione> that's why i was asking when you plan to upload X
<daniels> sometime about now
<fabbione> ok
<fabbione> no .. it won't be THAT soon
<daniels> okay
<jdub> http://static.flickr.com/29/46304339_cb5ec248e9_o.gif <- X
<fabbione> just go ahead.. if they will show up, i will do a porter upload
<fabbione> jdub: hahaha
<daniels> fabbione: gnnrg
<fabbione> gnnrg????
<daniels> fabbione: i'd really prefer if you just gave me the diff, unless you need it in the archive YESTERDAY GODDAMNIT
<daniels> it makes my life about a bajillion times easier
<daniels> jdub: x is love
<fabbione> daniels: i needed them in the archive yesterday
* jdub doesn't debate that "love == angry cat with machine gun"
<daniels> fabbione: ... sparc is release-critical?
<fabbione> daniels: no, but the other 3 fixes are
<jdub> that image c/o a dude in jordan who digs ubuntu :)
<tepsipakki> jdub: I didn't quite get your post regarding dependency init.. do you mean that Sun SMF is a better bet than initng etc?
<daniels> fabbione: which other three fixes?
<jdub> tepsipakki: absolutely
<tepsipakki> jdub: me too
<fabbione> daniels: the 3 bug fixes.. they were all Major or >
<fabbione> daniels: + yesterday you said yourself that it was ok for you that i did the uploads, because you had nothing in the queue
<daniels> actually, that's not quite what I said
<fabbione> daniels: i did ask to you if you had pending changes and you said no.. -71 is your
<fabbione> daniels: can i fix xfonts-core? or do you have any objection with it?
<daniels> fabbione: i said -71 is yours, yeah
<daniels> and that I'd catch up with -72 today, which I've done
<daniels> what else are you doing to xfonts-core?
<fabbione> daniels: the fix i did yesterday (missing simlink) is not enough
<fabbione> see the last comment on 15611
<fabbione> we need to change /usr/X11R6/lib/X11/fonts/* from dirs to symlinks
<fabbione> hey JanC 
<fabbione> meh
<fabbione> JaneW
<Mithrandir> mdz: pongpong?
<daniels> fabbione: no, that will break universe font packages
<daniels> fabbione: right now, the failure mode is that you don't get fonts from some packages when you upgrade
<daniels> fabbione: i'd really, really, rather not complicate that by another transition
<fabbione> daniels: the problem is that right now it doesn't work for main either
<fabbione> because xorg.conf is not always regerated (and can't be) with the new paths
<fabbione> regenerated
<fabbione> a solution would be to symlink the contents of /usr/share/X11/fonts/100dpi/* in /usr/X11R6/lib/X11/fonts/100dpi
<fabbione> or something like that
<fabbione> that would maintain the dirs s they are
<fabbione> and make both happy
<daniels> if people make a config file with xorgcfg or whatever, they're on their own anyway
<daniels> noting that we don't even ship that tool anymore
<daniels> it works for all configurations we've ever generated from dexconf
<fabbione> daniels: it's enough that the config doesn't match the md5sum by just adding a whitespace
<fabbione> echo "" >> /etc/X11/xorg.conf
<fabbione> and bam
<dholbach> good morning
<daniels> fabbione: so?
<dhonn> theres a bug in gnome search where I cant right click and choose a program to open a file
<daniels> fabbione: if you take an XF86Config-4 from warty and drop it into a breezy system, it will work
<daniels> fabbione: this is without dexconf doing rewriting tricks
<daniels> fabbione: the only place you get /usr/X11R6/lib/X11/fonts from is external configuration tools
<daniels> i think the costs here outweigh the benefits by far
<pitti> Good morning
<dholbach> pitti: how was the moving?
<mpool> hi
<zyga> hello folks
<fabbione> daniels: if i take a xorg.conf or XF86 with just an extra empty line (no need of external config tools) X will fail to start
<mpool> hi, i'm seeing the ipv6 dns slowdown too
<pitti> hi zyga 
<fabbione> daniels: not making this fix will kill all users that have a modified config
<mpool> i understand what's happening and how to work around it for myself
<mpool> but i think the default will be pretty bad for many users
<zyga> can we modify ATI's fglrx stuff anyway?
<fabbione> mpool: hoary or breezy?
<dholbach> hi carstenh 
<carstenh> hi dholbach 
<zyga> I wanted to use fglrx_config recently and it works semi-okay but spits out a config file for XFree86 not for x.org
<mpool> fabbione: breezy
<mpool> it wasn't this bad in hoary
<fabbione> mpool: that's really weird..
<daniels> fabbione: dude
<mpool> my default nameserver just ignores AAAA requests
<daniels> fabbione: take an XF86Config-4 from warty
<mpool> so there's a long timeout before breezy's resolver backs off to A requests
<daniels> fabbione: drop it into breezy
<hunger> zyga: Jut copy the section for the graphics card into your existing xorg.conf.
<fabbione> because breezy glibc don't resolv ipv6 as first
<daniels> fabbione: and it will work
<daniels> fabbione: it doesn't matter if you modify it or not, things will just work
<mpool> fabbione: ok, i thought so
<mpool> fabbione: this happens even if i disable the ipv6 kernel module
<daniels> fabbione: this is because I already added symlinks in /usr/lib/X11, which we used in warty and hoary
<mpool> it's pretty yucky
<mpool> i'm concerned that people who have nameservers that don't handle ipv6
<daniels> fabbione: the only tools which generate anything referring to /usr/X11R6/lib/X11 are external tools like xorgcfg, which we cannot and do not support
<mpool> which is probably fairly common
<mpool> will just think hoary is really slow
<zyga> hunger: yes I know but this could be easily fixed
<daniels> fabbione: so, just to be clear -- if you sit on warty or hoary and modify your config file by exactly one character, and nothing in it gets changed -- things will still work
<fabbione> daniels: whatever.. i reassinged the bug to you.. handle it as you prefer
<hunger> Is there a way to add custom lines to sections of xorg.conf via dexconf?
<mpool> fabbione: what do you think? is there anything we can do?
* hunger needs DisplaySize set.
<fabbione> mpool: with breezy glibc ipv4 is always resolved before ipv6, but if the apps request ipv6 first, than you might encounter that problem
<fabbione> mpool: the general thing is ok
<fabbione> so it depends from what apps is giving you problem
<mpool> what do you mean by "the general thing is OK"?
<sivang> morning all
<fabbione> if the DNS you are using is not RFC compliant, fix the dns :)
<fabbione> we do the right the thing
<fabbione> we are RFC and posix compliant
<fabbione> if an application specifically asks for ipv6.. well it has the rights to do so
<mpool> ok
<mpool> maybe more apps are built with ipv6 turned on?
<mpool> i see that if i just call gethostbyname it does only the ipv4 request
<mpool> which is good
<fabbione> there is no need to tell the apps to enable/disable ipv6
<mpool> so
<fabbione> it's enough they use gethostbyname2 instead of gethostbyname
<mpool> i note your smiley, but many people are not able to fix their dnses very easily
<fabbione> yes, but neither we are going to be non-{rfc,posix} compliant
<fabbione> the timeout is a perfectly allowed condition
<fabbione> normal i would say
<mpool> i thought the previous behaviour was that if there were no ipv6 routes/addresses, it wouldn't do the lookups
<mpool> that seems like a reasonable heuristic
<mpool> isn't it?
<fabbione> nope..
<fabbione> you are still allowed to perform dns queries
<fabbione> the algo is complex.. but in few words it does all the queries to figure out the matching source -> dst ip
<fabbione> the fact that ipv6 is not loaded or configured will be checked at a later stage
<fabbione> and this is ok, because the apps might be doing looks up to enable ipv6..
<fabbione> you cannot know that in advance
<mpool> right
<mpool> it's a reasonable approach
<mpool> however
<mpool> there doesn't seem to be any way for people with broken DNS servers to turn off ipv6 queries 
<fabbione> you can't
<fabbione> a dns query is nothing more than translating strings into strings
<fabbione> and the point is that you can do ipv6 queries on an ipv4 network
<fabbione> and viceversa
<mpool> sure
<mpool> i understand why the default is compliant
<mpool> but i think this will bite a number of users
<mpool> don't you agree?
<fabbione> note that breezy is much better than hoary...
<fabbione> even if i agree on the general annoyance of a timeout, i won't agree with solutions that will disable ipv6
<fabbione> not even configurable ;)
<mpool> ok
<mpool> so what do you think should happen to people with servers like this?
<fabbione> ISP's need to become compliant to RFC's :)
<mpool> mm
<fabbione> mpool: after the first lookup, the resolver learns
<fabbione> so it's only at the first contact the problem
<fabbione> after that it gets faster
<mpool> fabbione: no, it doesn't
<fabbione> it shoul
<fabbione> +d
<mpool> when i first installed Breezy, I had a ~6s delay on every tcp connection
<mpool> it makes a pretty bad first impression i have to say
<mpool> and not everyone will be able to figure out what's going on
<fabbione> mpool: what apps are you using to time this things?
<mpool> apt?
<mpool> every apt-get request pauses for ~6s
<mpool> ssh
<mpool> telnet
<ivoks> ?
<fabbione> ssh no
<fabbione> i don't believe it
<fabbione> because it uses gethostname
<fabbione> and not gethostbyname2
<mpool> firefox has an option to turn off ipv6 dns, because it's broken for a signficant fraction of users
<mpool> what i would like to see is a similar system-wide setting
<fabbione> that's how i figured the difference between hoary and breezy resolver
<mpool> i don't think we can ignore the fact that many users do have DNS servers that don't handle ipv6
<mpool> i hear RH and Fedora have a setting like this
<fabbione> apt uses gethostbyname too
<fabbione> so it defaults to ipv4
<mpool> fabbione: anyhow, resolv.conf(5) implies that AAAA records are only consulted if 'options inet6' is set
<fabbione> telnet yes.. it does ipv6 first
<mpool> but it seems to be always on
<fabbione> it's not
<fabbione> i am sure
<mpool> if it worked as the manpage says, or if we had, say, 'options noinet6' 
<mpool> then that would be OK with me
<fabbione> because all my networks are ipv6 compliant
<fabbione> and i still keep going on ipv4 with ssh & co.
<fabbione> that means that ipv6 is not used as first
<fabbione> firefox and mozilla are the only 2 apps that are hutterly broken in that way
<fabbione> and it has been known for ages
<fabbione> because they implement their own variant of the resolver
<maswan> mpool: what kind of brokeness do you have?
<maswan> I mean, I have no v6 connectivity at all, and I have no problems.
<ivoks> me too
<fabbione> maswan: the issue shows up when the DNS you are using is broken and can't resolv ipv6 at all
<mpool> maswan: as i said above, apps like apt or ssh pause for ~6s when opening a connection
<mpool> whcih is pretty broken
<mpool> maswan: i suspect you have no ipv6 but you do have a DNS server that responds to AAAA
<fabbione> mpool: can you try to use dns.fabbione.net for a test?
<maswan> fabbione: which in practice means what? a bind4 from the late 80ies?
<fabbione> mpool: and see if it works better?
<mpool> maswan: yeah, or maybe a windows based server or something
<fabbione> maswan: or probably other implementations
<mpool> or also many embedded routers
<mpool> for myself, i can just fix it by using a local server or something
<maswan> mpool: Oh, right, embedded routers. Or firewalls.
<maswan> firewalls == teh suck.
<fabbione> mpool: if that doesn't work.. than there is something hutterly broken on your network...
<mpool> the problem is all the other people who will install breezy and say "wow it's really slow"
<mpool> on forums and lists you can find lots of people who previously tried to work around this by disabling the ipv6 module
<mpool> but for good reasons as fabbione says that's no long enough
<maswan> fabbione: I have a wireless nat box thingie, and if the firewall in that is turned on, it mangles dns packets. badly.
<fabbione> the kernel module has nothing to do with bind/resolver
<fabbione> maswan: yeah.. so do i here
<fabbione> maswan: but that doesn't mean it's breezy's fault
<mpool> fabbione: it used to
<fabbione> mpool: never..
<fabbione> the module in the kernel provides the protocol
<mpool> i think previous resolvers tried to see if the ipv6 protocol was available before doign the lookup
<fabbione> it did never interact with the resolver
<mpool> which i agree is broken, but at least it gave people a way to control it
<fabbione> than it's a glibc thing
<fabbione> resolver = glibc
<maswan> fabbione: Of course not, problem is that you need to work around the bug. :/
<fabbione> maswan: yes.. i know..
<fabbione> i have to do the same here for a few more things..
<mpool> so
<fabbione> mpool: can you do the test i did ask you?
<mpool> i think there should be a workaround for people with broken servers
<mpool> agree/disagree?
<mpool> oh, yes
<mpool> going straight to dns.fabbione.net works fine
<mpool> it's just my router that's broken
<fabbione> see.. the point is.. we can't workaround all possible brokness on the internet
<Treenaks> the workaround is fixing the servers, imho
<fabbione> Treenaks: exactly
<ivoks> that's bugfix, not workaround :)
<Treenaks> either reply to all AAAA requests with an error/nxdomain/whatever... or reply normally.. don't drop the request :)
<mpool> i'm not asking you to work around all possible brokenness, just this one case which can be fairly easily worked around
<mpool> Treenaks: ok, well, you go and upgrade every dns server in the world
<mpool> in the meantime
<fabbione> ivoks: there is no real workaround.. other than patching the resolver and make it an extra thing to carry around
<mpool> for people on such networks, breezy is unusable
<fabbione> mpool: so was hoary and warty
<mpool> hang on, back in a bit
<fabbione> even worst in hoary and warty
<fabbione> i need to go to the doctor
<fabbione> bbl
<fabbione> mpool: i need to go the doc
<fabbione> i will be glad to keep talking about it later
<ivoks> fabbione: i hope you're ok
<mpool> OK
<mpool> yeah i hope you're ok too
<fabbione> remember that the easiest workaround is to install a local bind
<fabbione> i am fine
<fabbione> it's only a check
<fabbione> :)
<mpool> ok, let's talk later
<ivoks> fabbione: i hope not The Check :)
<fabbione> ivoks: in the worst case they will tell me that i will die soon..
<fabbione> so i mean.. what's the big deal :P
<maswan> actually, that's a fairly good suggestion, assuming a caching-only bind isn't hairy to install (it wasn't at all last time, so...)
* fabbione &
<ivoks> fabbione: i'm sure that won't be the case...
<torkel> maswan: install networkmanager and you will get bind9 for free :-)
<ivoks> :)
<dholbach> good morning mvo
<mvo> hey dho
<mvo> good morning dholbach 
<infinity> maswan : The default install of bind is cacheing only, so yeah, it's pretty simple.
<infinity> I think it might even offer to munge your resolv.conf in postinst to put 127.0.0.1 at the top, but not sure.
<infinity> bind8 used to.  Don't recall what bind9 does.
<mpool> 2
<infinity> 3
<lifeless> 4
<bob2> 5
<Treenaks> 6
<Mithrandir> 7
<lifeless> 7
<Mithrandir> tsktsk, lifeless blew it
<Kamion> fabbione: er, openssh doesn't use gethostbyname, except in like two unimportant places; it uses getaddrinfo nearly everywhere
<mpool> hi Kamion
<mpool> i see you replied to one of these requests previously
<Kamion> mpool: hmm, which?
<mpool> asking for a way to disable ipv6 dns queries
* sladen reads the 640x400 scrollback
<mpool> in hoary, it was possible to do this by disabling the ipv6 module
<Kamion> did I reply to such a request specifically in the context of openssh, or somewhere else? sorry, brain like a ... thing with holes in
<infinity> sieve
<bob2> php?
<mpool> no, more generally
<mpool> mm
<mpool> let's wait for fabbione
<mpool> or you can read the scrollback if you have it and want to
<Kamion> I glanced through the scrollback on arriving, yes, but I honestly don't remember having replied to a request like this before
<Kamion> although I might've commented on a glibc bug, not sure ...
<mpool> sorry, i can't find the link
<mpool> it's not important
<Kamion> ok
<zyga> mvo: hey
<zyga> mvo: I'll send you pl.po for synaptic later today
<pitti> Hi carlos 
<carlos> pitti, hi
<mvo> zyga: a updated one? your current one went in with the upload yesterday
* mvo waves to carlos
<zyga> hmmm
<zyga> mvo: it's missing some stuff 
<zyga> mvo: I dont remeber if I translated that in rosetta
<zyga> mvo: I did: make -C po update-po
<zyga> and it gave me about 60 untranslated stuff
<mvo> zyga: can you upload the result po into rosetta?
<mvo> today is NonLanguagePackTransationsDeadline
<zyga> mvo: ?
<zyga> mvo: sure
<zyga> mvo: what's that?
<mvo> zyga: no translation updates outside of rosetta 
<zyga> ah
<zyga> okay
<mvo> zyga: still CC me, because I think today it's still possible and I will put the update into my svn repo
<zyga> okay
<mvo> thanks
<HiddenWolf> pitti, ping
<Kamion> crimsun: please revert your keychain change; it was a bug in ssh-askpass-gnome which has been fixed
<crimsun> Kamion, will do.
<Kamion> crimsun: (although if it was reported in Ubuntu more recently than 8th September or so, I'd like to know ...)
<mvo> pitti: around?
<pitti> HiddenWolf, mvo: pong
<fabbione> re
<fabbione> Kamion: yes sorry.. i mean getaddrinfo
<fabbione> but that's changed too in glibc to be posix compliant
<mvo> pitti: there seems to be a issue with nautilus-cd-burner and gnome-volume-manager ... if I insert a cdrw (with stuff on it) and trying to write a iso on it, I get "insert a rewritable or blank cd". but there is one (mounted by g-v-m) already. the question keeps poping up unless I manually umount the cd
<pitti> mvo: oh, that's odd - n-c-b is supposed to unmount the drive first...
<seb128> and is supposed to ask if you want to clear it then
<pitti> bah, why does Mandrake do such an exceptionally good job of hiding their SRPMs?
<mvo> pitti: I tested it with writing a iso (daily)
<mvo> seb128: yes, it asks after I unmounted it manually
<seb128> pitti: you need a patch from them?
<pitti> mvo: I always use n-c-b, never had a problem with it...
<pitti> seb128: yes
<seb128> pitti: http://cvs.mandriva.com/cgi-bin/cvsweb.cgi/SPECS/
<pitti> seb128: that does not have security update patches
<pitti> seb128: but thanks, it's interesting
<seb128> pitti: ah, so good luck :)
<crimsun> Kamion: reverting it works fine, tested from console and from within GNOME. Thanks!
<seb128> you're welcome
<mvo> pitti: hm, if I'm the only one with this problem then it may be my system hating me or something :)
<seb128> mvo: does hal list the CD as rewritable?
<mvo> seb128: I guess so, after I "umount /media/cdrom" it works fine
<seb128> oh, interesting
<pitti> seb128: so the problem is that n-c-b does not unmount the CD, or it doesn't recognize it as rewritable?
<seb128> pitti: does not umount it
<seb128> mvo: try settings gconf /apps/nautilus-cd-burner/debug
<seb128> gnome-session-remove nautilus
<seb128> nautilus
<HiddenWolf> pitti, hotplug is yours, right?
<jdub> http://mail.gnome.org/archives/networkmanager-list/2005-September/msg00055.html
<jdub> ^ interesting for n-m fans
<seb128> then you have the verbose of what happen ... dunno if it has something about that
<seb128> hey jdub
<mvo> seb128: thanks
<pitti> HiddenWolf: depends; Keybuk and me usually touch it
<HiddenWolf> pitti, my hotplug is taking ages to taking ages to complete since about 2 days. How do I go about creating a decent bugreport about that?
<HiddenWolf> pitti, as in taking long enough to drop out of usplash.
<ivoks> hello
<fabbione> mpool: still around?
<ivoks> problems with i386 dbuild
<Kamion> crimsun: ok great, thanks
<ivoks> i386 build daemon can't authenticate packages for install and fails to build source cause of that...
<fabbione> ivoks: what buildd is that?
<fabbione> there is the name on top of the build log
<ivoks> vernadsky
<pitti> HiddenWolf: you can boot in the single user mode, where you can see which module takes so long
<fabbione> infinity: ^^
<fabbione> ivoks: thanks
<ivoks> fabbione: np
<pitti> HiddenWolf: please do that, look where it hangs, then you can just write that into the bug report
<HiddenWolf> pitti, I will. brb
<fabbione> pitti: i think the sparc did finish the build a long time ago :)
<pitti> fabbione: it did, I know
<pitti> fabbione: I debugged a bit, and then I crashed to bed
<fabbione> cool
<mpool> fabbione: hi
<fabbione> mpool: yo..
<pitti> fabbione: when initdb calls postgres, postgres SIGBUSes, but if I call postgres myself in gdb, it doesn't
<mpool> fabbione: i fixed my problem by running bind on another machine here
<mpool> which is fine for me
<mpool> however i think some users will experience this bug
<pitti> fabbione: and if I have initdb call postgres through a gdb wrapper, it does not crash either
<pitti> fabbione: so I guess I'll wait for Florian to update his mips box for debugging
<mpool> i think it's pretty clear from reports in previous releases that there are broken servers which are not easily fixed
<fabbione> pitti: you should consider trying only strace
<mpool> therefore i would like very much if there's a workaround
<fabbione> mpool: yes, but running bind locally is light 
<fabbione> given that it will only do cache
<mpool> OK
<fabbione> + you get a real DNS server implementation
<mpool> well, if it's easy to install that and have resolvconf point to it,t hat would be ok
<mpool> might need a faq entry
<fabbione> imho it's a much better solution than mangling the resolver
<fabbione> see this setup:
<fabbione> box connected to crappy ISP
<fabbione> ipv6 tunnel to whatever free ipv6 isp
<fabbione> box dns points to crappy isp
<fabbione> you can't use ipv6 at all because it doesn't resolve
<fabbione> you install local bind
<fabbione> you win over your crappy ISP
<fabbione> and you can use ipv6
<fabbione> for real
<HiddenWolf> pitti, usb, device descriptor/8 - error 110 bunch of errors while my *many* ports are checked.
<pitti> HiddenWolf: then please attach the dmesg log, too
<mloskot> hi
<mpool> fabbione: ok, sounds good
<mloskot> Q: I've reported a bug on Bugzilla related to alexandria from Univers, but as I was told on #launchpad, I should report it to the Malone. So, should I report the bug again, to Malone, or leave it as is on Bugzilla?
<fabbione> there are other advanteges too..
<fabbione> mloskot: move it to malone please
<fabbione> mpool: such as you have full control of the cache.. like to kill negative poisoning :)
<fabbione> mpool: without having to wait for your ISP cache to die
<fabbione> but that goes down to my insane paranoia
<infinity> ivoks : It's been fixed.
<mloskot> fabbione: but it will stay on Bugzilla too, or how to remove it from bugzilla?
<mloskot> fabbione: https://bugzilla.ubuntu.com/show_bug.cgi?id=16602
<fabbione> mloskot: just close it..
<mloskot> ok
<fabbione> i can close it for you if yuo want
<mloskot> ok, do it please.
<fabbione> done
<mloskot> thanks
<fabbione> np
<mloskot> As I see, there is no selection for release i.e. Breezy and amd64 on Malone, right?
<mvo> Kamion: still no usplash on i386-daily-install?
<fabbione> dunno really.. i didn't look into malone details yet
<mloskot> ok
<HiddenWolf> pitti, Attachment #4197  to Bug #16603 Created
<HiddenWolf> pitti, chances are it chokes on my printer.
<mloskot> Can I use structured or re-structured text (Zope/Plone gadgets) in Malone report bug form?
<Kamion> mvo: ok, will have a look later today if nobody beats me to it; though if you're there, I'd appreciate it if you'd investigate
* fabbione takes a lock on edubuntu-artwork
<pitti> HiddenWolf: use lsusb to find out what usb 2-5 is
<HiddenWolf> pitti, not listed, should be printer then.
<pitti> HiddenWolf: did you switch it off after boot?
<HiddenWolf> pitti, no. It won't even power on for some reason. I've swithed some cables tho, had some pc trouble earlier.
<HiddenWolf> pitti, let me reboot.
<JaneW> mdke: ping
<mvo> Kamion: I'll have a look now
<HiddenWolf> pitti, seems my hardware is troubled.
<HiddenWolf> pitti, there was a loose usb cable, when I plug it in any port, my pc won't go past POST.
<HiddenWolf> All usb-hardware works fine tho.
<Treenaks> HiddenWolf: that was a country-wide ADSL outage.. not your fault (probably)
<HiddenWolf> Treenaks, what?
<Treenaks> HiddenWolf: seriously though, my laptop won't go POST if I plug in my multi-card-reader-thingy
<Treenaks> HiddenWolf: it could be something like that
<HiddenWolf> Treenaks, guess it is, seems to be the multi-cardreader in my monitor.
<Treenaks> HiddenWolf: Try turning off "USB Legacy" in the bios
<HiddenWolf> Treenaks, thanks, I'll try that later.
* mvo reboots
<fabbione> there
<fabbione> edubuntu-artwork fixed
<ogra> fabbione, ??
<pitti> fabbione: will we see naked Fabios as wallpaper now?
<ogra> hey, but not for the children
<fabbione> ogra: http://people.ubuntu.com/~lamont/buildLogs/e/edubuntu-artwork/0.1.0-7/ <-
<ogra> you'd scare them away :p
<fabbione> pitti: ahah
<ogra> fabbione, bah, that was jbailey
<fabbione> ogra: i didn't point the finger to anybody
<fabbione> i just took a lock on the package and released
<ajmitch> ogra: do you have time to check an edubuntu-specific malone bug?
<ogra> ajmitch, there are no edubuntu malone bugs ;) all of edubuntu is in main :p
<ogra> ajmitch, tell me :)
<ajmitch> ogra: well it was misreported against the wrong package anyway :)
<ajmitch> https://launchpad.net/distros/ubuntu/+sources/scsi-idle/+bug/2315
<ogra> thats not edubuntu specific at all
<ajmitch> no, but he said it worked on a plain breezy box
<ajmitch> which is strange :)
<ogra> and i asked elkner several times to please repot bugs in bugzilla
<ogra> thaere is nothing edubuntu specific that could cause it
<ajmitch> I'll reject the bug then
<ajmitch> I know
<ogra> yup
<ogra> make a note that it should go to bugzilla
<ogra> *sigh* 
<ogra> i even offered him he could mail his bugs to me so i can put them in bugzilla
<mvo> mjg59: around? 
<Kamion> infinity: just a thought about that vga16fb 640x400 thing from last night; perhaps it would be possible to add a kernel option (disabled by default) that runs vga16fb in 640x400? That way, we could get people to test it with not quite so much risk.
<mvo> Kamion: usplash works now, I had to regenerate the initrd so that it included the new usplash-artwork.so
<Kamion> mvo: oh, you mean you were upgrading?
<mvo> Kamion: no, it was a fresh install, but the cd included 0.1-12. no idea why
<Kamion> mvo: you rsynced the image too early this morning
<Kamion> 21 8 * * *      for-project ubuntu cron.daily
<Kamion> London time, and takes maybe an hour or so to build
<Kamion> or a bit less, but anyway
<Kamion> today's image definitely has usplash 0.1-14
<mvo> Kamion: ok, thanks
<mvo> Kamion: can we make termwarp usplash aware? so that it quits usplash and runs console-screen.sh if usplash is runing (to properly init the fonts)? 
<Kamion> mvo: lib/menu/intro quits usplash already; it could run console-screen.sh too
<Kamion> although maybe termwrap would've been a better place for that, but I'd rather not move it now - maybe in dapper
<Kamion> mvo: what do I do, just '/etc/init.d/console-screen.sh'? how do I know if usplash was running, as well as installed?
<mvo> Kamion: I'll send you a draft patch, ok? 
<Kamion> mvo: sure, great
<toresbe> hey guys
<toresbe> A problem with launchpad, is this the place to raise that?
<daniels> #launchpad, isn't it?
<toresbe> I probably should've guessed that ;)
<toresbe> thanks :)
<Nafallo> Kamion: when are you going to extract the last finished translations? :-) tomorrow morning?
<Kamion> Nafallo: no idea
<Kamion> whenever it winds up being convenient, I guess
<Nafallo> hehe, we want to know the explicit deadline... ;-)
<Nafallo> if we get this night we would be happy :-P
<Nafallo> I would work to atleast 3 UTC ;-)
<Diziet> Oh, bugger, I'm a total idiot.
* backports-r-us getting increasingly ticked at school internet filters...
<Diziet> I uploaded from the wrong tree and it had random #error's strewn through it.
<Kamion> Nafallo: sure, you can have this night no problem
<infinity> Diziet : Already been fixed.
<Diziet> Oh, has it ?
<infinity> Yes.
<Mithrandir> jbailey: shouldn't 14239 be closed?
<Diziet> That's nice.  My mirror is obviously out of date.
<infinity> Also made an executive decision about versioning, as a guy who occasionally does security uploads, and changed the c/r to (<< ${Source-Version}).... Sure, it's not technically true, but it serves the same purpose, makes life a lot less painful, and the only drawback is that it forces the packages to be in version lockstep.
<infinity> Which isn't really a big deal.
<Diziet> inf: Errr.
<Nafallo> Kamion: thanks :-)
<fabbione> Diziet: you can keep close #16460
<Diziet> So I'm told.
<Diziet> Gah, apologies for incompetence.
<Kamion> Nafallo: (it's not like extracting translations from Rosetta is a quick, painless, or automatable process)
<infinity> Diziet : Since we have a pretty loose concept of package ownership here, it pays to subscribe to breezy-changes (or subscribe to an rss feed of it, or peruse the archives occasionally) to see if people have uploaded things you care about. :)
<Nafallo> hihi :-)
<Nafallo> anyone else scroll stopped working with the new xorg?
<daniels> nothing changed there
<daniels> so I'd be looking at the kernel
<Nafallo> daniels: the kernel haven't changed since this morning.
<Nafallo> baah! coward! ;-)
<Lathiat> haha
<Nafallo> hmm
<Nafallo> what does Option "HorizScrollDelta" "0" do? :-P
<tepsipakki> is it intentional that /etc/nanorc has "set mouse" that breaks middle-button paste?
<Nafallo> tepsipakki: THANKS! :-)
<tepsipakki> nafallo: you hit the same?-)
* Nafallo gets bugs fixed just by being here ;-)
<Nafallo> tepsipakki: irritated me for the last couple of months atleast ;-)
<tepsipakki> yeah, me too, but not enough to actually do something about it.. the version in sarge apparently does not have this feature
<tepsipakki> oh it does, but not on by default
<Kamion> elmo: please sync nano from unstable (tepsipakki's bug above, plus line count bug that I think might be one that's been annoying me for ages on amd64)
<Nafallo> hihi
<Kamion> last version just missed UVF, but looks safe
* Nafallo rm nano* :-P
<ogra> Nafallo, uuuh... how unclean...
<ogra> use dpkg :)
<tseng> dpkg --purge
<Nafallo> ogra: ehm... rm nano* after apt-get source ;-)
<ogra> heh
<tepsipakki> =)
<tepsipakki> hrr, adduser fails if nscd is running.. but, maybe thats why nscd is crap and supported ;)
<tepsipakki> UNsupported..
<maswan> is there something like nscd that is supported?
<maswan> (cache name/group lookups)
<tseng> something like that will be supported in dapper for edubuntu
<tepsipakki> heh, no
<tseng> see ogra 
<maswan> tseng: ah, neat. then we might not have to live with nscd for that much longer.
<tseng> hm im thinking network auth
<tseng> not nessecarily "group/name lookups"
<sivang> does anybody know if we have anything that can fix zip files in main/universe?
<infinity> 'fix'?
<ogra> we have zipfiles in main/universe ?
<Lathiat>  assume he means he has a corrupt .zip and wants soemthign to try recover it
<ogra> i think there are only debs
<maswan> tseng: well, that's the lookups I'm doing that needs nscd here
<ogra> ah
<ogra> :)
<infinity> sivang : Not sure if it does the same thing as the oldskool pkzipfix (was that what you were looking for?), but 'zip' has a '-F' switch.
<infinity> sivang : Which can be doubled-up (-FF) for really broken archives.
<Nafallo> hmm, where is Keybuk? :-)
<Nafallo> or is it common practice for grepmap to segfault a lot? ;-)
<Kamion> Keybuk works notoriously strange hours; I'm sure he'll be along eventually; file a bug in the meantime
<Nafallo> just made sure the bug was new first :-)
<Nafallo> couldn't find anything in /var/log/syslog.*, so it has to be new :-P
<sivang> infinity: THANK YOU
<jbailey> Mithrandir: Yup, thanks
<Nafallo> hmm, synaptics seems to be Keybuks fault :-P
<mjg59> mvo: Hello?
<segfault> morning.
<sivang> yo mjg59 
<zyga> hello seb128 
<zyga> ah
<zyga> hello segfault 
<zyga> darn tab, why doesn't it work like in the shell?
<seb128> zyga: xchat?
<mvo> mjg59: thanks, alreday solved (some usplash stuff)
<seb128> zyga: /set completion_amount 0
<mjg59> mvo: Ah, ok
<zyga> seb128: mmm :-)
<zyga> thanks
<mvo> mjg59: the recent changes make it now run on vt1? it used to be vt8? but the changelog indicates that's jbailey change
<backports-r-us> seb128: does GAIM have completion of some sort?
<pitti> Diziet: shall I look into the firefox backporting issues (the three things that backports-r-us mentioned that need to be changed)?
<jdub> elmo: ping
<backports-r-us> sweet, firefox progress :)
<seb128> backports-r-us: what sort of completion? gaim for IRC? 
<mjg59> mvo: You'd have to ask jbailey
<ogra> seb128, i guess he means logout completion :p
<HiddenWolf> pitti, ping
<segfault> when will the next language pack be generated?
<pitti> Hi HiddenWolf 
<pitti> segfault: ask carlos :-)
<carlos> pitti, I ping you this morning, did you see my private msg?
<Diziet> pitti: Sure.  I'm afraid I don't have any useful opinions about it but do keep me posted.
<pitti> carlos: I did, I answered you :-)
<HiddenWolf> pitti, hi
<pitti> Diziet: me neither, I'd just apply the changes and test them
<carlos> pitti, are you identified?
<carlos> pitti, I didn't get any answer...
<pitti> carlos: yes
<pitti> carlos: got my ping?
<carlos> pitti, freenode says you are not identified
<pitti> hm?
<pitti> carlos: now I am, sorry
<carlos> and no, I didn't get your ping
<carlos> pitti, no problem ;-)
<segfault> carlos: any idea?
<carlos> segfault, we should have one at the end of this week
<carlos> pitti, right?
<pitti> carlos: depends on the next tarball, but I hope so :-)
<segfault> and it'll include all the purple and blue modified strings?
<HiddenWolf> pitti, seems that bug I reported earlier has something to do with usb legacy support.
<seb128> carlos, pitti: how long does it take from a package upload to a rosetta pot update?
<carlos> segfault, yes
<carlos> seb128, usually, the worst case is 8-9 hours
<segfault> nice
<carlos> seb128, atm the queue is a bit busy so could take one or two days
<seb128> carlos: I've uploaded a new control-center yesterday, can you look what happened with it?
<carlos> seb128, sure
<seb128> carlos: it was not shipping the pot before, this upload is supposed to fix that
<carlos> seb128, so that explains it... cool, thanks!
<seb128> what explains it?
<seb128> https://launchpad.net/distros/ubuntu/breezy/+sources/control-center/+pots/control-center-2.0/ should be updated right?
<pitti> HiddenWolf: yep, I read that; can you please followup on the bug?
<carlos> seb128, it explains that control-center is completely outdated...
<HiddenWolf> pitti, excuse me, hadn't checked mail
<carlos> seb128, yeah
<HiddenWolf> pitti, it's solved if i turn off legacy support, any idea what can cause it?
<seb128> carlos: just let me know if it's queued or if there is an issue :)
<pitti> HiddenWolf: I guess your BIOS tries to find an USB keyboard and somehow is buggy
<HiddenWolf> pitti, ok
<carlos> seb128, sure
<carlos> seb128, it's queued to be imported
<HiddenWolf> pitti, probably not worth fixing then?
<seb128> carlos: thanks
<pitti> HiddenWolf: no idea, if your BIOS hangs, then not :) if the kernel hangs, the report shuold stay open
<HiddenWolf> hotplug hangs'
<pitti> Hi jdthood 
<jdthood> pitti: I just noticed that #5813 hasn't been fixed in Breezy and easily could be with a little patch.
<pitti> jdthood: oh, that patch looks easy enough, thanks for pointing out
<nomed> just a question ..
<bddebian> Hello
<nomed> why when i generate kernel-headers using make-kpkg the scripts dir is not included?
<Diziet> Why when people report firefox bugs do they always use bugzilla or forums pages as their test cases ?  So far I haven't had one where it WFM but not for them just because the page had changed, but it's only a matter of time.
<pitti> elmo: can you please sync alsa-driver? it's just a small build fix
<elmo> pitti: ok to override ubuntu changes?
<pitti> elmo: yes
<pitti> elmo: (there are no actual changes)
<elmo> pitti: pls say so, so I don't have to ask
<elmo> done
<pitti> elmo: yep, next time; thanks
<pitti> jdthood: patch applied, thanks!
<jdthood> pitti: Yer fast, dude.
* mvo grumbles about dpkg 'dependtry <= 4' assert
<bddebian> Can someone please clarify for me?  Can I add new .desktop files or not?
<Riddell> bddebian: why would you want to?
<Diziet> Anyone here know anything about defoma ?  16599 shows a missing font file.
<bddebian> Riddell: To close Malone bugs
<Riddell> bddebian: any example?
<bddebian> Malone 2690
<Rotund> What is the proper procedure to go about requesting a package gets updated to a newer version before Breezy is released?
<Rotund> is it a bug report?
<Mithrandir> Rotund: if it's in main: you're probably too late, if it's in universe, ask on #ubuntu-motu
<bddebian> Rotund: A main or universe package?
<Rotund> libtheora.  I'm assuming main
<mvo> Riddell: if you haven't uploaded kdm already, please hold on a bit. I have a second version of the console-screen patch
<bddebian> Rotund: Yep, it's main so you probably won't see it.
<Rotund> darn.  they've fixed the memory leaks and bitrate management issues
<Rotund> That's kind of major in my mind
<Mithrandir> Rotund: is it a clean and nice patch?
<Rotund> I don't know.
<Rotund> alpha4 was 14 Dec 2005 and alpha5 was 20 Aug 2005
<Rotund> I have to assume there were major changes
<Rotund> Well.  they call it a "incremental update"
<janimo> Rotund, the changes summarized on their site suggests there aren't so many
<Rotund> The site suggests that, but 8 months between releases would make me think that's unlikely
<Kamion> depends on how active the project is.
<Kamion> anyway, only way to actually check is to look at the changelog or the source diff
<Riddell> bddebian: I don't see what's wrong with adding that, having an untranslated .desktop file is better than none at all in my opinion
<Rotund> I'd hope theora (the great hope for a good open source no patent video codec) is fairly active
<Riddell> bddebian: but don't take my word for it
<jdthood> I have been looking at bugs filed at bugs.freedesktop.org for the radeon driver.  I find that some of the issues reported there are also mentioned in the xserver-xorg changelog, sometimes as fixed.  Are patches being sent upstream?
<bddebian> seb128: Do you have an opinion on that?
<highvoltage> elmo: i want to arrange a mirror for ubuntu & edubuntu at a local isp. how much space would it take up? and which paths should ideally be mirrored?
<highvoltage> elmo: if you're not arround, please mail me back: jonathan@tsf.org.za
<Rotund> The changes in theora alpha5 are mostly comments
<Rotund> 1 added feature and a little renaming
<jdub> elmo: ping
<bddebian> Anyone know much/anything about erlang?
<Rotund> another question about packages.  What if there's a newer version of the package in Debian (same maintainer) than in Universe?
<Rotund> (Ross Burton and Meld)
<elmo> jdub: ?
<jdub> Rotund: we stop syncing at UpstreamVersionFreeze - that's quite normal
<jdub> hey elmo 
<ogra> Rotund, main packages need a real good reason to et upgraded in this state of the release cycle, added features dont fall in this category...
<ogra> Rotund, but inuverse upgrades are possible as long as it is proven that a upgrade doesnt affect any other packages or introduces new bugs
<sivang> Rotund: mainly bugfixes
<ogra> Rotund, so if it doesnt introduce new breakage, meld seems like a good candidate
<Rotund> Well, I see the libtheora as bugfixes.  The meld is a much larger change (going version 1.0) but there's no interlinking
<ogra> Rotund, for universe stuff #ubuntu-motu is the right place
<Rotund> ogra: and what should I say?
<ogra> Rotund, which crasher or dataloss bugs does the theors upgrade fix ? 
<ogra> *theora
<Rotund> bad encoding/decoding and memory leaks.
<Kamion> ogra: don't confuse him by talking about universe - libtheora is in main
<ogra> Kamion, he asked about meld
<Rotund> Kamion: meld is in universe
<Kamion> oh, but meld, ok
<Kamion> fair enough, sorry
<Rotund> I've found 2 packages =)
<ogra> Rotund, go to -motu and ask for a update there, the MOTUs will care for it
<Rotund> libtheora I expected to see a new version when it was released in August and didn't notice it hadn;t gotten upgraded until now
<ogra> for theora ... that needs proof that it really fixes stuff...
<Diziet> IWBNI people who wrote shell runes had some idea about how.
<Diziet> It Would Be Nice If.
<ogra> Diziet, btw, you would be my hero if you could fix the "the cert window pops up on the wrong (even minimized) ff win"
<sivang> lol
* Diziet winces.
<sivang> mine too :)
<ogra> dunno a bug # though... but its quite annoying and thim never managed to fix it
<ogra> thom even
<sivang> I guess we should use epiphany , as seb128 says :)
<Diziet> I haven't looked at it at all.  It gives me the impression of being very nontrivial.
<Rotund> Hmmm.  libtheora on Debian hasn't been updated at all (even in unstable)
<Rotund> That's interesting as there wasn't many changes
<Diziet> Is it upstream ?  It's the kind of thing you would think would be in upstream's bugzilla.
<ogra> i think its a question of missing metacity/wnck integration
<Diziet> Has _no-one_ noticed that if you have two printers of the same type, you can't print to the second one in firefox ?  (Because the second one ends up with a space in its name.)
<ogra> i guess the lack of two printers prevents most people of notcing :)
<Rotund> ogra: so for theora, the change list from Xiph isn't good enough.
<Diziet> But making lots of different printers (all of which don't actually go anywhere) is the only sane way to test printing.
<sivang> Diziet: firefox specific? not CUPS thing?
<Diziet> sivang: It's a bug in the default print command.
<ogra> Rotund, if its not in debian yet its unlikely anyway that we can easily upgrade...
<Diziet> Of course ffox doesn't bother putting up a dialogue saying `your print command died', let alone capture the stderr and show it to you.
<Rotund> I guess I don't really care as I'm thinking of grabbing a CVS version of theora anyways.
<Diziet> So if you run ffox from the panel, you print and nothing comes out and you wonder why.
<Rotund> thanks a lot
<ogra> elmo, could you sync meld from sid please ? i dont think there were ubuntu changes
<Rotund> ogra: meld is only changed in unstable... not sid
<Diziet> cert window bug> I agree it's a bug that really ought to be fixed.  But it feels like one with a big patch.
<Rotund> oh wait.  That is sid =)
<ogra> err, sid != unstable O_O ? did i miss something ?
<Rotund> sorry.  I think they'd say "okay now we bump sid to testing and make a new release name for unstable"
<ogra> Diziet, i think its only a bt fiddling with wnck/metacity... to find out which win is requesting the popup and let it appear there
<ogra> s/bt/bit
<ogra> but might be time consuming...
<ogra> probably to late for tha
<ogra> t
<Kamion> Rotund: no, not true; Debian releases testing as stable and then makes a new codename for testing
<Rotund> I was thinking sarge as well. not sid.  double oopsy
<Rotund> Kamion: yeah.  I forgot that notation.
<Kamion> sid is (nowadays) a permanent codename for unstable
<Rotund> anyways.  Thanks a lot and off to work
<Diziet> ogra: You think it's a metacity bug ?  I'm not very familiar with post-1995 wm protocols :-).
<dholbach> bbl
<ogra> Diziet, i think its missing integration ... i bet epiphany does it right
<Diziet> `Missing integration'?  Sounds like someone has invented a scheme that means every app has to know about every wm ...
<Diziet> Wahey !  10293 happens to me too, all by itself.
<Diziet> I mean, with my actual printer when I just try to print something.
<Diziet> Strange that it only happens sometimes.
<ogra> Diziet, metacity uses timestamps for windows since hoary, it prevents windows from stealing the focus.... i think there we would have to look...
<ogra> (stealing the focus and popping up in fron of the other wins ...)
<Amaranth> seb128: http://bugzilla.ubuntu.com/show_bug.cgi?id=15636 is fixed in pyxdg cvs
<Amaranth> /whois seb128 
<Amaranth> err
<Amaranth> oops
<Diziet> ogra: Oh, this is that launch timestamp thing that I remember seeing somewhere.
<ogra> yup
<janimo> is powermanagement-interface available on all platforms?
<ogra> iirc the prob appeared with this change
<Diziet> If you think you know roughly where to look etc. I'd be happy to consider a patch if it's _really small_ and I can see that it's correct.
<pitti> elmo: please sync py2play (ubuntu override ok) and phpmyadmin from Debian (security updates)
<ogra> Diziet, i really think its time consuming to find the right place
<ogra> lets keep it for dapper, but look into it early
<Diziet> Right.  More so for me - I'd have to start to understand it all first.
<Diziet> Sure.
<ogra> i'll happily help :)
<pitti> elmo: oh, and gopher and imp3, too, please (all universe)
<Diziet> ogra: Thanks, I'll probably take you up on that.
<ogra> :)
* pitti snickers - elmo is vulnerable - CAN-2005-2230 :-)
<elmo> pitti: done
<pitti> elmo: thanks
<ogra> elmo, did you get my request for meld above ? 
<Diziet> Anyone see my request for help with defoma and fonts ?
<Diziet> 16599
<Diziet> ogra: If you know something about metacity, do you have an opinion about the correctness of the patch http://bugzilla.gnome.org/attachment.cgi?id=51679&action=view which is supposedly for our 15995 ?
<ogra> Diziet, looks good to me... but a quich look from seb128 wouldnt do any harm i think ;)
<ogra> hes far deeper in metacity...
<Diziet> I'm not wholly convinced, in particular because it seems to count UTF-8 chars rather than bytes (which is probably what the X server is complaining about when it sends the error that makes metacity die), and there's no justification for the number 512.
<Diziet> I mean the X server probably counts bytes.
<Diziet> Also, I'm not sure if it's in the right place - that it catches all bugs of this form.
<Diziet> It seems unlikely that there would be just the one, but of course ICBW.
<Diziet> seb128: ping
<ogra> nope, it wont catch all bugs of this form... 
<Diziet> OTOH we might be better off fixing this one which can be exploited by web pages.  Others probably can't.
<ogra> ask Riddell if konqueror in KDE can see the site without crash :)
<Riddell> which site?
<seb128> Diziet: pong
<ogra> if he can, X shouldnt matter
<ogra> Riddell, 15995
<Diziet> seb: See scrool re 15995.
<hunger> Is wiki.ubuntu.com down?
<seb128> Diziet: it can't hurt, I would use it
<hunger> No, works with another browser:-( Sorry for the noise.
<Mithrandir> ogra: well, it doesn't crash with openbox.
<Diziet> riddell: Use my test case, not the original site, and save yourself the unpleasant experience :-).
<ogra> Mithrandir, thast what i expected
<ogra> :)
<Diziet> seb: Um, but I would like to fix the bug properly and so forth.
<ogra> Diziet, see Mithrandir 
<Diziet> If you don't know, that's fine, I'll investigate myself.
<ogra> so X shouldnt matter here
<ogra> its a WM thing
<seb128> Diziet: is there any reason to put a limit to the title length?
<Diziet> The way it fails is that metacity sends some X request that's too large and the X server says `no way' and then metacity's X error handler kills it.
<Riddell> Diziet: no crash in konqueror
<Mithrandir> openbox limits the title to ~4k, though
<Diziet> Clearly a title that's too long to display is pointless and ought to be truncated.
<Diziet> Display anywhere, I mean.
<seb128> Diziet: the patch seems fine to me
<Diziet> Where did this `512' come from ?
<Riddell> Diziet: no crash in konqueror when using metacity either
<Diziet> Riddell: konqueror probably (sensibly) truncates the title itself.  I don't think, though, that it's a _bug_ in ffox that it doesn't.
<Diziet> Is that the only place where the title is set ?  I grepped for \btitle\b and got other stuff which I don't currently understand but seems like it might have similar problems.
<Diziet> Are there other strings analagous to the title which metacity also mishandles ?
<Diziet> These are the kind of questions I'm looking for answers to.
* ogra curses xscreensaver (and jwz while i'm at it)
<seb128> comment on the gnome bug
<seb128> they will probably reply
<Diziet> Just `the patch is fine' isn't so reassuring :-).  I can see that the patch doesn't make it worse ...
<mjg59> Kamion: New installs mount my other Linux partitions by default, but don't mount my Windows partition  by default. Deliberate?
<seb128> Diziet: I'm not upstream for that and doesn't know the code for it, better to comment on bugzilla.org for a GNOME guys :)
<Diziet> seb: :-).  OK.
<Diziet> If they're good about replies, I'll do that before I get stuck in myself.
<Kamion> mjg59: #16233, I imagine
<Kamion> mjg59: but send me /var/log/partman if you could
<Kamion> or /var/log/installer/partman if you've finished the install
<mjg59> Ok
<mjg59> It didn't involve autopartitioning, BTW
<Kamion> hmm
<mjg59> I just selected some existing partitions and formatted them
<Kamion> it's supposed to preselect your Windows partition to be mounted on /media/hda<n> or whatever
<mjg59> Yeah
<pitti> carlos: ok, I have created a reasonably useful blender.pot now :-)
<carlos> pitti, wow, how?
<bddebian> elmo: Should we morgue manderlbot since neither we nor Debian have source for libxmerl-erlang which manderlbot depends on?
<pitti> carlos: some blender guy sent me 64 KB python code that grabs the strings and builds a pot
<pitti> carlos: it contains some strings that shouldn't be translated, but that's good enough
<bddebian> seb128: Did you happen to see my question about new untranslated .desktop files?
<ogra> elmo, ta for meld...
<carlos> pitti, ok
<pitti> doko: ping
<elvirolo> hi all
<bddebian> Hello elvirolo
<elvirolo> is the relaese of breezy gonna be delayed ? because it still has serious bugs
<bddebian> infinity or lamont-away: Can you please clear the dep-wait for ghc-cvs?
<elvirolo> like this one : http://bugzilla.ubuntu.com/show_bug.cgi?id=16066
<Yagisan> elvirolo: thats a normal bug - if you want serious try to install hoary on linux software raid with /usr as 0 or 5- and see if it starts
<elvirolo> I understand
<Yagisan> elvirolo: I'm sure it will get fixed at some stage though
<elvirolo> but still it definitely needs to be fixed ...
<elvirolo> but breezy will be released soonush
<elvirolo> soonish*
<doko> pitti: pong. while you are here, mind checking OOo1 on you iBook? *duck*
<pitti> doko: is the "sys" module really included in python-minimal? dpkg -L does not reveal it
<pitti> doko: why ooo1?
<doko> pitti: it's a builtin module
<pitti> doko: ah, thanks
<lamont-away> bddebian: doing it now, with a vengence
<torkel> elvirolo: follow the hint in comment #3 (setting the loglevel to debug) and attatch a log to the report and someone will probably take a look at it
<doko> pitti: OOo1 does have more translations than OOo2, does even run on machines like iBooks ...
<elvirolo> torkel: thank you, i shall
<bddebian> lamont-away: With a vengence? :-)
<bob2> what is the selling point of 2.0 over 1.0?
<tseng> bob2: i think the gnome integration is actually part of 2.0
<tseng> bob2: and not a massive fork/patch
<elvirolo> torkel: in fact, comment #3 was mine :-D
<Mithrandir> bob2: slower, fatter and makes even more people cry.
<doko> bob2: writing OpenDocument format, better MS compatibility (although there are some regressions)
<bob2> haha
<bob2> tseng: I always thought OO 1 didn't link against enough libs ;)
<lamont-away> bddebian: I um, cleared 'em all
<bddebian> lamont-away: Ahh :-)
<tseng> bob2: http://www.equalmusic.com/photos/coheed3.jpg in other news, you could double for the singer of coheed and cambria, i think
<bddebian> lamont-away: How far behind is: http://people.ubuntu.com/~lamont/buildLogs/Lists/breezy.all.i386 ?
<lamont-away> That file gets created and pushed to that URL every 20 minutes
<seb128> bddebian: nop, say it again ?
<janimo> mjg59, is pmi susp/hib supposed to work in console mode too?
<bddebian> lamont-away: OK, thx
<bddebian> seb128: Should I not add new untranslated .desktop files either?
<pitti> doko: FWIW, neither OOO1 nor 2 are particularly nice on a 256 MB iBook, they are both slow as hell
<pitti> doko: ok, where are the debs?
<seb128> bddebian: I've no opinion on that, that doesn't make a regression ... but I'm not sure if we prefer to lack some entries or to have some english ones 
<seb128> maybe you could mail the mailing list about that?
<janimo> ogra ping
<ogra> janimo, pong
<janimo> ogra mailing list admin questions again got 2 minutes?
<ogra> sure
<lamont-away> pitti: you should try them on a 128MB system.. :-)
<lamont-away> my wife needs more memory...
<pitti> lamont-away: no thanks, /me uses LaTeX and gnumeric :-) (my gf, too)
<PzyCrow> Since upgrading to Breezy each try to start X with the nvidia driver results in a system lockup. Is this a known problem? I couldn't find anything in bugzilla.
<pitti> elmo: loop-aes-utils sync, please
<bddebian> seb128: OK
<doko> pitti: in the archive (1.1.5)
<pitti> doko: ah, that one; ok
<pitti> doko: is it utterly urgent? or is tomorrow ok?
<doko> pitti: end of week/weekend would be nice
<pitti> doko: yep, ok
<pitti> BenC, mvo: btw, has there been any solution to the kernel upgrade notification?
<mvo> pitti: it should be a matter of adding the needed key to the notification file. but I don't want to upload a kernel with just that change in :)
<mjg59> janimo: If you're lucky
<pitti> mvo: so there is such a key now?
<pitti> mvo: jbailey wants to add a reboot notice to glibc; I guess it is high time to factorize those
<jdub> elmo: ping
<mvo> pitti: there has been the idea around to have a "reboot" notification that can just be touched if a pkg needs rebooting
<mvo> pitti: I find this idea nice and appealing
<janimo> mjg59, also why is vbestate not saved on prepare (commented in the script) on resume it prints out errors
<mjg59> janimo: Because doing that breaks things
<mjg59> It's saved on boot isntead
<pitti> mvo: yes, but we need to make it a bit more flexible, maybe the user is interested in the reason
<pitti> mvo: otherwise just touching user.d/reboot is easy
<janimo> mjg59, which script saves it?
<janimo> also is pmi platform indep, can I depend on it in a package?
<janimo> I am rying to get susp/hib into xfce-session
<mjg59> janimo: /etc/init.d/vbesave
<jbailey> pitti: Ah, you're already talking about it. =)
<mjg59> Yes, pmi should be platform independent
<infinity> pitti : The kind of people those notes are targetted at don't care about reasons, they care about "some updates you installed require a reboot, please do so"
* jbailey reads the scrollback
<pitti> infinity: well, true
<infinity> pitti : People who want reasons have changelogs, can watch the packages installing, etc, etc.
<janimo> is pmi an ubuntu only thing for now? Can I send patched sources calling pmi upstream?
<infinity> pitti : We're not really targetting people who should have to know or care what glibc is in the first place.
<pitti> mvo: ok, so what about having u-d just ship a well translated generic reboot notification?
<jbailey> mvo: My thought was to have a notification in /usr/share/doc of some sort.
<jbailey> Nice, generic and translated.
<pitti> mvo: then hal, dbus, kernel, etc. just create a symlink to it
<jbailey> Then just ln -sf it when you need it
<jbailey> On reboot rm the created symlink.
<infinity> Looks like many people have all reached the same page at the same time.
<infinity> Always good. :)
<jbailey> infinity: Watch it page fault now.  WE'LL ALL BE SWAPPED OUT!  OH NO!!
<jbailey> err.
<jbailey> dont mind me. =)
<elmo> jdub: ?
<elmo> pitti: done
<pitti> thanks
<infinity> jbailey : Nerd jokes don't suit you.
<bddebian> heh
<jbailey> infinity: What would you rather I tell, dear?
<infinity> jbailey : Try something vaguely sexually suggestive and oddly creepy instead.
<jbailey> Oh, you mean go back to my usual.
<bddebian> hahaha
<jbailey> infinity: It's a bit harder without jblack sitting beside me, but I can try. =)
<mvo> pitti: yes, that sounds good to me
<pitti> mvo: it would really help to fix this nasty "4 notifications in a row" mess, so I hope mdz ack's this for Breezy :-)
<janimo> mjg59, ah I did not have vbestate becauseI forgot to uncommend ACPI_SLEEP.Will uncommented remain the default for breezy?
<jbailey> pitti: My favourite is getting the notices after I reboot. =)
<infinity> pitti, mvo : Well, the fact that it's "very translateable" will score brownie points for approval, I'm sure.  And if you get the string written and frozen in the next day or two, we may even have 15 or 20 languages by release. :)
<mvo> pitti: I'll attack it right after coming back from playing hockey
<pitti> mvo: I love you :-)
<bddebian> hmm
<pitti> infinity: and it's not even intrusive
* mvo beams
<lamont-away> elmo: please take a gander at anastasia w/hppa and see how it looks...
* infinity tries the bed thing again.
<lamont-away> getting at least palo and libgcc2 into main would mean we could build CD's and actually test things and such
<pitti> infinity: sleep well
<LaschW> Kamion: Is there any CVS access to have a closer look at OEM mode install related programms?`
<mdz> pitti: ?
<pitti> Morning mdz
<bddebian> Hello mdz
<pitti> mdz: the idea was to unify the current plethora of "please reboot" update notifications of hal, dbus, kernel, and glibc to one common and well translated generic reboot notification
<pitti> mdz: u-n would ship this in /usr/share somewhere, packages could just drop a symlink into user.d/ and u-n's init script coudl properly clean up the symlink
<pitti> mdz: so user see one nice message instead of 4 untranslated one
<mdz> pitti: that would definitely be an improvement
<pitti> mdz: what do you think?
<mdz> pitti: but what changes are involved?
<pitti> mdz: u-n needs to ship that file, and we need to update hal, dbus, kernel, and glibc to set a symlink instead of creating their own notifications
<mdz> I think it should be abstracted in u-n
<pitti> mdz: (well, glibc does not yet do it, jbailey is just about to add the notification, that's why we discussed about it in the first place)
<pitti> mdz: a small u-n script that sets the symlink is even nicer, right
<pitti> mdz: maybe /usr/share/u-n/flag-reboot, or whatever
<mdz> so packages would do if ...exists...; then notify-reboot-required; fi
<mdz> right
<pitti> sounds good
<mdz> rather than worrying about symlink issues
<pitti> mdz: I think that is unintrusive enough to be breezyable, and it would improve user experience a lot
<mdz> that's fine with me if it goes in this week
<mdz> next week we start rolling RC candidates
<pitti> mdz:<mvo> pitti: I'll attack it right after coming back from playing hockey
<pitti> mdz: changing hal and dbus is a piece of cake, kernel probably too
<pitti> mdz: technically, this would be subject to NonLanguagePackTranslationDeadline, though :-)
<mdz> pitti: well, if we create these common templates in u-n, we can include them in u-n's po file
<mdz> pitti: and export to rosetta and langpacks
<mdz> which would be great
<pitti> right
<mdz> Diziet: any resolution on the firefox font situation?
<pitti> we can't just translate them automatically since the files don't use gettext
<ogra> grrrr 5th evo crash today
<Nafallo> ogra: sounds fun :-)
<pitti> ogra: "mutt sucks less" (SCNR)
<pitti> ogra: seriously, any useful backtrace?
<ogra> pitti, ENOTIME
<Mithrandir> pitti: mutt sucks differently, you mean?
<pitti> ogra: my last evo crash produced a nice bt, which was fixed quickly
<pitti> Mithrandir: definitively much less for me at least
<ogra> pitti, it just locks up... after about 3-4h usage
<pitti> Mithrandir: although I agree that it is a matter of taste
<ogra> no crash or backtrace
<pitti> ogra: strace?
<jbailey> strace on evo for two hours would be too painful to use.
<pitti> jbailey: why for two hours?
<pitti> jbailey: just attach strace to it when it hangs
<ogra> pitti, i'm running 2 pbuilder simultaneously compiling xscreensaver, i have no ressources for 4h evo stracing
<pitti> ogra: ^
<pitti> ogra: no need to
<jbailey> pitti: Yeaeh, true.
<pitti> ogra: also, if evo hangs, just gdb-attach on it and bt it
<pitti> ogra: if you have -dbg installed, you should get a good result
<Mithrandir> ogra: you should have more than one computer. :-)
<ogra> pitti, will do, next time it crashes
<pitti> ogra: "gdb /usr/bin/evolution $(pidof evolution)" -> you get the idea
<ogra> sure
<pitti> ogra: and "strace -p $(pidof evolution)"
<ogra> i wonder if its mdz's fault, it happened 3 out of 7 times when i answered mails from him :P
<pitti> ogra: shhh - that's still s3kr3t
<Mithrandir> too much hot mdz&ogra action?
* Mithrandir hides.
* ogra sees nearly a pattern there :)
<Nafallo> lol
<pitti> ogra: check the source for strcmp(s, "mdz") || sleep(10000000)
<Diziet> mdz: Hi.  Fonts, yes:
<Nafallo> lol
<ogra> *g*
<Diziet> The discussion on the mailing list seems rather inconclusive.
<Diziet> I can change the default from serif to sans (indeed I've just uploaded that).
<ogra> Diziet, i find the debian bug very clear
<Nafallo> elmo: did you miss Kamions syncrequest for nano earlier? :-)
<doko> elmo: please install lib64z1-dev on davis/breezy, the concordia stuff can wait, but this one would be very nice to have
<Diziet> ogra: You mean you agree with Keith Packard's message of the 3rd of April ?
<Diziet> It certainly seems unclear to me at the moment that the right fix is some change in firefox to request a different font.
<ogra> Diziet, i agree with robot101's fix of th wrong mapping for helvetica, tahoma, verdana
<ogra> #its fonconfigs mapping of the MS fonts
* Robot101 waves
* ogra waves back
<Diziet> Hello.
<elmo> doko: done
<elmo> Nafallo: yes
<Diziet> Um, where is that fix ?
<Diziet> Are you referring to those two URL's in Romain Francoise's message in the Debian BTS ?
<ogra> yup, to Robot101's blg
<ogra> blog
<Diziet> 403
<doko> elmo: thanks
<ogra> there is a new url attached to the mail
<ogra> sorry, me evo just freaked out..
<Diziet> What mail ?
<Nafallo> 13:36:44 Kamion  elmo: please sync nano from unstable (tepsipakki's bug above, plus line count bug that I think might be one that's been annoying me for ages on amd64)
<elmo> Kamion: done
<ogra> Diziet, http://www.robot101.net/2005/03/16/fontconfig-fun/
<ogra> from "Ming Hua" 
<Diziet> Oh, wow, actual running prose :-).
<Diziet> Right, that's a nice summary of the problem.
<Treenaks> You don't have permission to access /files/fonts.conf on this server.
<Diziet> _However_ it doesn't answer my question about metric equivalence.
* Treenaks pokes Rotund 
<Treenaks> uh
<Treenaks> Robot101: 
<Robot101> oh, sorry
<Robot101> hmm
<Robot101> thats interesting
<ogra> Diziet, dont touch the sizes... some webdesigners rely on that ... you'll produce a lot of anger among them :)
<Robot101> er, it works for me
<Treenaks> ogra: those web designers should be taken out, shot, shot again, cut to pieces, and dumped in a fast-flowing river
<Diziet> ogra: We had that conversation on ubuntu-devel.  See 
<ogra> Treenaks, its the majority
<Diziet> <1127978611.7321.46.camel@localhost.localdomain> from James Livingston <jrl@ids.org.au>
<Treenaks> ogra: time to organise a party then ;)
<ogra> Diziet, see mpt's comment there
<Diziet> mpt> Don't have that one yet I think.
<ogra> its from tuesday (18:39 german time)
<Diziet> In any case, let us suppose for the moment that we accept the idea that the metrics _must_ be right even for web fonts.
<Diziet> What's that in UTC ?  Message-ID ?
<slomo> Diziet: german is UTC+0200
<ogra> Message-Id: <a375865ad4f49036d755b25015008af7@canonical.com>
<Diziet> ogra: Um, eh ?
<ogra> ?
<Diziet> Anyway, back to what I was saying:
<Diziet> So if you think that the metrics have to be right, then surely you must conclude that we have to leave the situation as it is.  Since in hoary the metrics were wrong - we used a font with the wrong metrics - and in breezy the situation is more correct.
<Diziet> Whereas in fact everyone's complaint seems to be the reverse.
<ogra> Diziet, in any case you should discuss it with mtp, why else has canonical a UI specialist who cares exactly for that
<ogra> *mpt
<mdz> Diziet: my understanding from the discussion is that the defalut fonts, as in hoary, are Vera, but some users are getting a different font from fontconfig for some reason
<mdz> Diziet: that's the bit we need to address
<Diziet> Yes.
<ogra> yup
<Diziet> It's a shame no-one is answering my point about metrics.
<Amaranth> mdz: fontconfig 2.3 change from what has been said
<Diziet> We can't just change fontconfig to hand out fonts with the wrong metrics more often, because that will break typesetting applications.
<Amaranth> mdz: the metrics are now correct and good for printing but look like ass on the screen for a website
<mdz> Amaranth: I'm talking about the fact that some users are getting an entirely different font, as returned by fc-match
<ogra> Diziet, we shouldnt step away to far from upstream with the metrics...
<Amaranth> mdz: you mean the ones getting nimbus?
<mdz> Diziet: if nothing else we should revert to the Hoary behaviour; the change of fonts in firefox is a regression
<mdz> Amaranth: yes
<ogra> Diziet, if i design a page for mozilla, i expect it to look the same in all mozillas (at least on the same OS)
* Diziet is writing an email.  This IRC discussion is totally at cross purposes.
<Diziet> mdz: AIUI it's not just a regression - it fixes some broken cases for printing.
<janimo> elmo, please sync xfce4-notes-plugin, discard our changes, thanks
<mdz> Diziet: the screen is more important
<elmo> janimo: please read my email
<mdz> firefox is a front line app
<mdz> does anyone remember that bug about unicode_start only being run for the first console?
<janimo> elmo, did not get it was wondering why you synced the tow others
<ogra> Diziet, i would follow the blog entry but with the djvu fonts instead of the standard vera fonts, looks like the conclusion for me if i take all answers
<mdz> it's been duped as 16607 but I can't find the original bug
<Diziet> I'd like to try to find a proper fix before we jump back to hoary.  But if that bug is better than this bug sure.
<ogra> Diziet, we dont jump back to hoary
<elmo> janimo: sigh.  it's in my email.  xfce4-notes-plugin is newer in breezy than in sid.  I can't sync it.
<ogra> Diziet, there were no djvu fonts in hoary...
<pitti> mdz: that bug is still present, btw
<janimo> epoch?ok thanks
<mdz> pitti: what' sthe bug#?
<pitti> no idea, /me looks
<elmo> janimo: no, don't epoch it
<Diziet> We could jump back to hoary by nixing fontconfig to hand out `wrong' but better-looking fonts.
<janimo> elmo, of course I am not, I was wonderind if we already had epoch. but I'll look. thanks
<ogra> GRRRR
<Amaranth> Diziet: or change the firefox preferences to use certain fonts instead of 'serif' and 'sans-serif'
<ogra> why is xscrensavers status mapping scattered all over the code... 
<ogra> Amaranth, thats not good as default...
<pitti> mdz: can't find it either, maybe it was never filed...
<Amaranth> ogra: no, it but it does fix both problems, just in a hacky way
<Diziet> amaranth: You think that's right ?  I'm going to suggest it in the discussion.
<ogra> Amaranth, thats merely evil
<Diziet> Will it help when the website asks for a particular font ?  Because that seems to be the case in question.
<ogra> nope
<ogra> the fontconfigmapping will still bring you Nimbus
<Amaranth> Diziet: I don't think it's right, I think it is just less wrong than breaking either printing or screen reading in fontconfig
<Amaranth> ogra: if you specify a windows font that you don't have installed, yeah
<Amaranth> which most websites do....even mine
<ogra> Amaranth, we have no windows fontrs in ubuntu
<Amaranth> i know
<Diziet> AIUI, the problem is when a site asks for a Windows font.
<Diziet> fontconfig recognises the font name and realises that only Nimbus fits the metrics.
<Amaranth> i was just showing my change of heart on irc so it wouldn't sound like i'm saying two things at once :)
<Diziet> So it uses Nimbus.
<ogra> so this must get fixed... its an odd experience if half the sites look blurry by default, even if they print fine
<Diziet> Am I right ?
<Amaranth> Diziet: yep
<ogra> Diziet, not really...
<Diziet> Where am I wrong ?
<Amaranth> The only real solution I can think of is to make fontconfig understand the difference between screen and print.
<ogra> Diziet, it recognizes that keithp selected Nimbus as the right font...
<Diziet> keithp ?
* lamont-away wonders why his laptop says 'system halted' at the bottom of the screen, but he still can talk to it remotely in a random xterm
<Amaranth> but that's why he selected it
<ogra> fontconfig doesnt compare metrics, it follows the local..conf file
<ogra> Diziet, upstream
<Amaranth> keithp == keith packard, super X hacker ;)
<Diziet> upstream> Oh, right.
<Diziet> Yes, yes, but the _reason_ that font is listed there is because it has the right metrics.
<ogra> thats the real bug imho... it *should* cmpare metrics instead of pulling them from a font file and it should know if its for print or screen... but it doesnt now...
<Amaranth> wasn't him getting kicked out of the xfree86 team the final straw that made people fork? (offtopic)
<Diziet> What ?  Why would it know print or screen ?  It just gets the requested name, right ?
<pitti> Lathiat: indeed, I'm on a security rampage today :-)
<ogra> Diziet, only for priting which is not as important in a browser as screen
<Amaranth> ogra: Yeah, like I said the real solution is to make fontconfig understand the difference between print and screen. That's not happening before breezy releases though.
<ogra> Diziet, yes, but it *should* know what for the font is needed...
<Diziet> ogra: *should*> Right.
<ogra> as long as we have different fonts for print/screen
<Diziet> Can we just stick to the facts rather than the shoulds for a moment ?
<ogra> as long as it doesnt, concentrate in screen, not on print
<Amaranth> Diziet: The facts are we either break printing or break screen reading in ways that will have people bitching.
<Diziet> Do we in fact have different fonts ?  I thought the same font files were used for both ?
<Diziet> ama: That's not a fact, that's a conclusion.
<ogra> type1 vs ttf :)
<Diziet> Stop trying to pursuade me and inform me, dammit !
<ogra> type1 -> wondeful for printing, they look far better than ttf...
<dilinger> wow
<ogra> ttf -> best for screen ... 
<dilinger> apt just shit itself quite spectacularly
<Diziet> So when ffox invokes fontconfig, does fontconfig know it's for the screen ?
<ogra> nope
<Amaranth> No.
<Diziet> Note of course that ffox wants fonts for printing too and then it still wants `nice' rather than `right metrics', unlike most other cases of printing.
<ogra> thats place for future improvement 
<Diziet> So if you're sayign that type1 is for printing and ttf is for screen, how does fontconfig know which to pick ?
<ogra> the main purpose for a browser is screen reading...
<Diziet> I mean, how do you get it to pick a type1 for printing ?
<ogra> it doesnt, thats the point
<Diziet> I'm going to ignore all comments of the form `it is more important that'.
<jdub> um
<ogra> and currently it picks a type1 for screen
<jdub> there's really no qualitative difference between type1 and ttf for printing
<Diziet> So is it really the case that you should never pick a type1 for the screen ?
<jdub> no
<ogra> jdub, scale a ttf to 400pt ;)
<ogra> and then print it :)
<jdub> ogra: looks fine, no technical reason why it shouldn't
<Diziet> jdub: Are you disagreeing with:
<Diziet> <ogra> type1 -> wondeful for printing, they look far better than ttf...
<jdub> Diziet: it is less optimal to choose type1 for screen because they don't provide as much hinting as ttfs
<Diziet> <ogra> ttf -> best for screen ... 
<Diziet> jdub: Ah.
<Diziet> So you would normally prefer a ttf ?
<jdub> this is not wildly relevant to choosing a font for firefox
<jdub> of course
<jdub> one of the bitstream vera family
<ogra> Diziet, so wipe my first sentence then ... i remember times where you shouldnt have used ttf for print
<Diziet> Couldn't we have ffox invoke fc with a special flag, eg  --use-font-maps-from=/usr/share/other/directory/with/different/mappings   ?
<ogra> Diziet, yeah, in dapper :)
<Diziet> Well, is it that hard ?
<jdub> Diziet: erk, why?
<Diziet> So that ffox can get different answers to gs.
<Mithrandir> ogra: ttf has always been ok to print, at least since it was introduced in Mac OS 7 in 1991.
<Diziet> Or whatever else uses fc.
<ogra> jdub, Diziet wnats perfect metrics for printing
<jdub> diziet can't always get what he wants :-)
<Diziet> If you use a font with significantly different metrics with a page description language you end up with seriously damaged output.
<Diziet> The question is, can I this time ?
<ogra> Mithrandir, so bring a ps document with embedded ttf fonts to a print shop... 
<jdub> right, so we should not configure fontconfig to match fonts with wildly different metrics
<Mithrandir> ogra: print shops usually prefer PDFs, not PS nowadays. :-)
<jdub> and, really, you should be choosing specific fonts when you require this anyway
<Diziet> Was the previous situation with substituting Vera for the M$ fonts OK ?
<ogra> Mithrandir, i'm out of print business since nearly 10 years *shrug*
<ogra> Diziet, yes
<Diziet> jdub: Yes, but we're about to configure it so that even when the document requests specific fonts we give it different ones, aren't we ?
<jdub> Diziet: why would we do that?
<ogra> imho you only need 2 fonts in a browser, serif and sans...
<Diziet> The problem case is web pages which specify a specific font.
<ogra> err 3 ... monospace indeed
<Diziet> You'd prefer to nobble it so that ffox only used the defaults ?
<jdub> Diziet: why is that a problem case? they get what they ask for
<Mithrandir> mdz: re the gnome slowdown; I'm unable to reproduce that on any machine I have available.  The only one which matches the other machines somewhat dies in the middle of the bonnie run, but I was too tired&bored at the end of the day to debug why.
<Diziet> Web designers are idiots.
<Diziet> Many sites request specific M$ fonts because that's what was on the idiot's system.
<Diziet> And they look crap as a result.
<jdub> and we have fonts that are like those
<Diziet> (This is not my experience, only my understanding.)#
<Diziet> We have (a) fonts that would look good if we substituted them and (b) fonts that have the same metrics but not (a)&(b) together.
<Diziet> Now in a web browser we want (a) and for printing we want (b).
<jdub> ij
<jdub> ok
<jdub> this is solving a non-problem
<jdub> let's avoid the damage by ignoring whoever suggested this
<Diziet> People seem to think it's important that web pages look pretty in our browser.
<jdub> they do
<jdub> if they think web pages rely on precise font metrics, they're wrong
<jdub> so
<Diziet> Not these ones with the broken font specifications, which are (apparently) fairly common.
<Diziet> Yes, yes, the web pages _don't_ rely on precise metrics.
<Diziet> They just specify the M$ font.
<jdub> and that's fine
<Diziet> If you use another font they render fine.
<jdub> the browser says "oh, don't have that font, we'll fall back to serif or sans"
<jdub> or, more likely, the page specifies a fall back
<Diziet> But, the font that breezy's fontconfig picks when you ask for the M$ one, looks crap.
<jdub> either way
<jdub> it doesn't matter
<jdub> if fontconfig's matching list includes crap looking fonts, remove the matchings that refer to crap looking fonts
<jdub> better still, remove the fonts
<Diziet> Those fonts look OK when printed.
<Diziet> And when a document to be printed asks for the M$ font, we have to give them that font because otherwise the metrics will be wrong and it can look very bad (text overwriting itself, etc.)
<Amaranth> Diziet: I'm one of those 'idiots' who ask for MS fonts on his website.
<Diziet> (By document to be printed I mean something in a page description language as opposed to a reformattable document.)
<jdub> specifics would be nice
<Amaranth> Diziet: Because falling back to sans-serif has always come out ok.
<Diziet> ama: But you specify an alternative, right ?
<Diziet> Does your site look bad in breezy's ffox ?
<jdub> if 'verdana' matches to 'bitstream vera serif' then yes, that's silly
<Amaranth> font-family: Trebuchet MS, Arial, Helvetica, sans-serif;
<Diziet> And, URL please :-).  A nice example would help.
<Amaranth> Diziet: I dunno, bad superblock on my breezy HD.
<jdub> Diziet: dude, specifics
<Diziet> OK, tell me the URL, I'll look for myself.
<Amaranth> damn netware messages keep popping up and breaking my concentration
<Diziet> And *sympathy*
<Amaranth> Diziet: http://www.realistanew.com
<Diziet> Netware ??
<Amaranth> i'm at school
<ivoks> Amaranth: ugly fonts :/
<Amaranth> ivoks: I blame fontconfig. ;)
<ivoks> Amaranth: ah...
<ivoks> that's trebuchet
<Diziet> OK, so that comes out in Nimbus.
<Diziet> Which is what we don't like.
<Diziet> And this is not Amaranth's fault, it's our system's.
<ivoks> Diziet: true
<Amaranth> it should be falling back to bitstream vera sans or whatever :)
<ivoks> Amaranth: anyway, trebuchet is ugly :)
<Amaranth> it looks great here on windows xp
<ogra> Diziet, i'm not sure... it might be Amaranth's fault anyway ;) 
<Amaranth> trebuchet is a little off, but i wanted to try something different
<Diziet> If I go into the firefox preferences and ask for Bitstream Vera for serif, I see Bitstream Vera.
<Diziet> Which I hadn't expected.
<Diziet> So obviously I still don't understand what's going on.
<Diziet> Ticking `always use my fonts' works too :-).
<mdz> Mithrandir: are there any patterns in the hardware configurations of those experiencing it?
<Amaranth> Why wouldn't you expect it to give you bitstream vera if you ask for it?
<Amaranth> it only falls back on matching and coming up with nimbus if the requested font isn't available
<Mithrandir> mdz: a lot of those people seem to have ICH6 IDE bridges.
<Mithrandir> mdz: I might have access to such a system, but as I said, it was really unstable today.
<mdz> Mithrandir: are they the same chipsets which have this "led always on" bug?
<Diziet> amaranth: I guess I don't know how the firefox font preference works.
<Amaranth> Diziet: it just asks fontconfig for a font
<Diziet> I had imagined that ffox would take the list from the website's css and replace sans-serif with the string you specify in the preferences.
<Amaranth> if the font exists it gets exactly what it asked for
<Diziet> And would then pass that list to fontconfig.
<Diziet> So given that I don't have `always use my fonts' I would have expected my setting to come last.
<Amaranth> hmm
<Amaranth> perhaps it knows to use your font if it doesn't get exactly what it asked for with the other options
<Diziet> So given it finds Nimbus with the sans preference set to sans, why wouldn't it find it with the sans preference set to Bitstream Vera ?
<Mithrandir> mdz: it seems to all be intel-based systems at least, but I can't reproduce on my only stable intel system (my x40)
<Diziet> IBWNI someone here had some idea what was actually going on.  I certainly don't.
<jdub> because you're then saying sans-serif == bitstream vera sans, not "go match!"
<Diziet> `no match', you mean.
<Diziet> But if you say fc-match sans-serif you get a match, don't you ?
<jdub> no, i mean "so go and make a match!"
<jdub> only because it's an alias
<ivoks> khm...
<mdz> Diziet: what we want is for firefox to use bitstream vera, as it did for hoary
<ivoks> maybe i'm wrong
<ogra> Diziet, fc-match Helvetica
<ivoks> but doesn't it say Helvetica first?
<ogra> Diziet, fc-match Verdana
<ivoks> and... fonts.conf says...
<Diziet> root@samual4:~ # fc-match Helvetica 'Bitstream Vera Sans'
<Diziet> n019003l.pfb: "Nimbus Sans L" "Regular"
<ivoks> alias helvetica Nimbus
<ivoks> line 150
<ivoks> fonts.conf
<Amaranth> delete that ;)
<ogra> Diziet, Bitstream is ignored in your line above
<Diziet> Because it's an absolute match.
<Diziet> I mean, Helvetica is.
<Diziet> So what I don't understand is why I get Bitstream Vera by changing the ffox preferences.
<Diziet> On Amaranth's site.
<Amaranth> *boggle*
<Diziet> If that works everywhere perhaps we should just change the ffox prefs.
<Amaranth> and the gnome prefs, and the kde prefs, etc
<jdub> what's your match for 'trebuchet ms'
<jdub> ?
<jdub> (mine is trebuchet, having the ms fonts installed already)
<Diziet> root@samual4:~ # fc-match 'trebuchet ms'
<Diziet> Vera.ttf: "Bitstream Vera Sans" "Roman"
<Amaranth> so you should have been getting bitstream vera sans anyway
<ivoks> argh..
<ivoks> ok
<ivoks> i have a fix
<ivoks> fc-match Helvetica
<ivoks> Vera.ttf: "Bitstream Vera Sans" "Roman"
<ivoks> just kill those Adobe lines in fonts.conf
<jdub> if we never want nimbus, just kill it from the mathces
<jdub> regardless of printing
<Diziet> But we do want it for printing, I think.
<jdub> alternatively, check out red hat's fonts.conf
<Diziet> Now _that_'s a good idea.  Copy DR.  Joy.
<jdub> no, 'check out'
<jdub> it *always* helps to survey what others are doing
<Diziet> I think we should try to understand.
<ivoks> so, problem isn't in #150 in fonts.conf?
<jdub> that may be assisted by looking at alternatives
<Diziet> OMG we are going round in circles.
<jdub> red hat have a solid history of doing the right thing regarding fonts
<ogra> Diziet, just wipe Nimbus as jdub says
<Diziet> And WTF is with the XML config file anyway ?!
<Diziet> I'm losing it, can you tell !
<ogra> which XML file ? 
<jdub> fonts.conf
<ogra> ah
<ivoks> why don't we alias times to serif?
<ivoks> helvetica to sans and courier to mono?
<ogra> exactly
* Diziet posts to ubuntu-devel.  Please read the discussion and contribute there if you have something to say :-).  Thanks.
<Diziet> Ah, good, my ffox 18 has built.
<Nafallo> is there a list of what packages the installation uses? Rosetta has packages for Debians, Ubuntus and boths installations it seems :-P.
<Nafallo> lot of templates with the same strings floating around...
<bddebian> Damn, ghc-cvs still hasn't shown up
<runeh> Where do I request package updates? Need the newest libipoddevice and such for my nano to work in Banshee.
<Nafallo> runeh: #ubuntu-mono, slomo.
<runeh> Thanks.
<slomo> runeh: i'll do them soon, don't worry ;)
<runeh> Ah. Thanks. :)
<Nafallo> hihi
<Nafallo> hilight deluxe :-P
<runeh> Been trying to build them myself, but had no luck. :P
<slomo> i just wait for a new banshee release which should be released soon and then do all 3 packages at once
<runeh> Yeah. They said monday.
<zyga> libipoddevice?
<zyga> geez open source has a lib for everything
<zyga> libyourmotherinlaw....
<Nafallo> zyga: ;-)
<slomo> runeh: it's not worth the worries... ;) when nothing happens until saturday i'll upload a cvs snapshot of banshee with the newest release of the 2 libs...
<slomo> runeh: the cvs fixes many really ugly bugs
<runeh> zyga: For an easy, higher level way to access her?
<Nafallo> hmm. would be nifty. apt-get remove --purge libyourmotherinlaw :-P
<zyga> runeh: yeah, there's a remote access method that's far safer
<zyga> you can send her encapsulated messages 
<runeh> slomo: Yeah. And I figured it's nicer to have dpkg handle the libraries installed, than me pushing modified versions in here and there.
<runeh> Looking forward to next week then. :)
<ivoks> Diziet: change, not delete ;)
<runeh> Don't like having to use a friends computer to transfer music to my player. :P
<mjg59> jbailey: Hang on. So we unconditionally attempt to load vesafb?
<mjg59> jbailey: That would explain why all the other framebuffer modules are already loaded when we try to start usplash
<slomo> runeh: ;)
<jbailey> mjg59: Yup, because the kernel package asks us to.
<jbailey> Although usplash I think runs before that.
<mjg59> jbailey: So how on earth are we trying to load modules that are already loaded?
<mjg59> Or does usplash do something funny like add vga16fb's depends to the autoload list?
<jbailey> mjg59: What bug number are you looking at, so I can follow along? =)
<mjg59> #15317
<HiddenWolf> pitti, around?
<Kamion> you know if LaschW actually stayed around for more than five minutes I might be able to answer his question
<jbailey> Anyone here got the insmod: error inserting
<jbailey> '/lib/modules/2.6.12-8-386/kernel/drivers/video/console/bitblit.ko': -1 File Exists
<jbailey> errors at startup?
<Nafallo> jbailey: yes
<jbailey> Nafallo: Are you free to do a test that involved rebooting?
<Nafallo> s/8-386/9-amd64-k8/
<bddebian> Gawd I hate C++
* bddebian hides from jbailey
<jbailey> Nafallo: Right. =)
<Nafallo> jbailey: not at the moment, I'm making Kamion happy ;-).
<zyga> jbailey: me
<jbailey> Nafallo: I would never interfere with Kamion's happiness. =)
<zyga> jbailey: strange, noticed it yesterday
<Nafallo> jbailey: I could check if 9-686 is though :-P
<Nafallo> hihi
<zyga> jbailey: 9-k7
<jbailey> bddebian: You keep hacking on *bad* C++.  People who think that casts and CPP macros are good.
<Kamion> next time LaschW shows up, somebody point him at 'apt-get source oem-config localechooser kbd-chooser' please
<bddebian> jbailey: Aye.  I'm back looking at xgsmlib :-(
<pitti> Hi HIdd
<pitti> oh, neat timing
<Nafallo> jbailey: 9-686 availible :-)
<Keybuk> mdz: want to see something even funnier?
<Keybuk> with Caps Lock _on_, go onto the console and type "abcdef" with the shift key held down
<Nafallo> Keybuk: you have a bug from me :-)
<Keybuk> you'll get abcCEf
<Keybuk> uh, abCdEf
<zyga> Keybuk: that's an old story ;-)
<zyga> Keybuk: depending on the locale
<Keybuk> zyga: it's still being told today
<zyga> Keybuk: I'll get aBcDeF
<Keybuk> bet that means your locale has a fancy accented character for 'a' ?
<Nafallo> jbailey: did you get my msgs? :-)
<Keybuk> ie. you have , ,  or anything like that on your keyboard
<zyga> Keybuk: 
<zyga> Keybuk: (you didn't think of that - did you ;-)
<Keybuk> didn't even know that one existed
<zyga> :D
<Nafallo> :-)
<Keybuk> looks like Salvador Dali's 'a' key
<Keybuk> Nafallo: oh?
<Nafallo> Keybuk: grepmap segfaults here. 16133 IIRC
<zyga> if you are *so* interested I can show you the capital version...
<Keybuk> Nafallo: oh, good, can I have your modules.inputmap
<Keybuk> (grepmap has never worked on amd64, just nobody noticed)
<Nafallo> sure, I'll attach it :-)
<Keybuk> the inputmap array size is different on amd64 to i386, and so far we've just been lucky there was nothing important after it in memory
<jbailey> Nafallo: I did sorry, suddenly had 3 popups at once. 
<Keybuk> zyga: nah, it just fits the pattern of the bug, that's all
<Keybuk> any key with anything more than just the basic latin lower and upper case variants gets inverted
<Keybuk> (c and e are usually also  and  in most euro locales)
<jbailey> Keybuk: Eh.  Don't you use UTF-8? =)
* zyga woneders how to get euro stuff when both c and e are already allocated for locale stuff
<Keybuk> jbailey: yes, afaik
<jbailey> Huh, I got a cents sign from you and then some noise for the second character.
<Keybuk> unless x-chat in breezy has turned it off by default
<mjg59> jbailey: That was utf-8
<jbailey> Huh, weird.
<spayne> who where is on the CC?
<spayne> Community Council i mean
<ogra> spayne, elmo, Kamion, mako 
<spayne> mako: ping
<Nafallo> Keybuk: well, I'm here for your debugging needs ;-).
<Keybuk> Nafallo: -> /msg
<spayne> elmo: ping
<spayne> Kamion: ping
<pitti> seb128: can I somehow switch to the Gnome keyboard settings? I believe I currently use X', so the keyboard applet etc. don't work
<\sh> zyga: meta+3 i think
<pitti> mdz: good news about langpacks - it seems that we'll get new packs tomorrow
<pitti> mdz: having fresh packages tomorrow for testing, and another set of fresh packages right before the release - is that fine?
<pitti> HiddenWolf: pong
<zyga> does anything use ~/.local ?
<zyga> apart from autopackage?
<HiddenWolf> pitti, all the ports in my cardreader suddenly show up in the gtk filechooser window. Even when there is nothing in them.
<mdz> pitti: depends on how they go tomorrow ;-)
<mdz> pitti: get them in as soon as humanly possible
<HiddenWolf> pitti, not in places or on the desktop. is that seb128's, or something for you?
<pitti> mdz: carlos just tested today's tarball, and it just has three obsolete translation domains
<seb128> pitti: /desktop/gnome/peripherals/keyboard/kbd/overrideSettings maybe?
<zyga> or... does anyone here use/ever-used autopackage
<pitti> mdz: so in theory I could even use it, but tomorrow we should get all
<Keybuk> zyga: freedesktop-ish stuff uses it too
<zyga> Keybuk: hmm
<Keybuk> ~/.local/share/applications is where custom .desktop files go, for example
<zyga> Keybuk: mine was heavily polluted 
<zyga> with autopackage
<Keybuk> yes, well, autopackage
<Keybuk> aka. "please fuck my system with a chainsaw, no, pleeeease"
<zyga> vim: relocation error: /lib/tls/i686/cmov/librt.so.1: symbol __pthread_clock_settime, version GLIBC_PRIVATE not defined in fil e libpthread.so.0 with link time reference
<mdz> pitti: we need some time to catch the errors we haven't seen yet
<mdz> pitti:  through user exposure
<mdz> pitti: which domains are they
<pitti> mdz: right
<ogra> mdz, that ltsp patch you sent is for the debian package... while i agree that the exporting should be done in the build-client script, i dont agree with the implementation as well as with the rest ...
<pitti> mdz: btw, we always review the full diff, so it shouldn't get too bad
<mdz> pitti: which domains are obsolete?
<mdz> pitti: you review the full diff including all of the changed translations in every language?
<pitti> mdz: gdm, control-center and evolution
<carlos> mdz, gdm, evolution and control-center
<mdz> pitti: oh, those are important ones ;-)
<pitti> mdz: well, I can't review every single bit of 22 MB :-)
<mdz> ogra: I forwarded it to you because you are working on the same problem
<ogra> mdz, not really...
<pitti> mdz: but when you look a it, you get a fairly good idea about the differences
<mdz> pitti: but there are many updated translations from rosetta, right?
<ogra> mdz, i need to generate the dhcp.conf on the fly... these probs are already solved for ue
<pitti> mdz: yes, some
<mdz> pitti: that is what I mean, we need time to QA the translation changes
<ogra> s/ue/us
<pitti> mdz: right, exactly my feelign, that's why I want fresh packs ASAP, and not just before release
<ogra> mdz, but moving the exports to the script is indeed the better way
<janimo> seb128 if there's a way of reminding you of the lpi/libgnome patch without being annoying let me know :)
<seb128> janimo: I just have something like 700 bugs to my bugzilla list so you have to be patient
<janimo> seb128, ok it is just holding up xubuntu-desktop a bit, but ok if it is done before release I am fine.thanks
<seb128> you can't get xubuntu-desktop grabbing libgnome for the moment?
<janimo> seb128, I could I guess but that may mean the actual testers will be fewer if they have memory footprint issues
<janimo> I'll do that if it takes a while till you get to the fix though
<janimo> I just worry not to delay it too much so it becomes too risky for breezy
<seb128> janimo: I'll have a look on the patch tomorrow
<janimo> sbe128, merci
<zyga> jbailey: fixed
<jbailey> zyga: \\o/
<jbailey> I'll wait for the confirmation from Nafallo too then and then close the bug.
<seb128> janimo: de rien
<spayne> pitti: ping
<pitti> spayne: pong
<janimo> which is the program that gets SUSPEND/REBOOT etc commands from gnome-session and calls pmi in turn?
<mjg59> janimo: gnome-settings-daemon
<ogra> mjg59, ? 
<mjg59> ogra: Hello?
<ogra> isnt that gdm anymore ? 
<mjg59> Oh, sorry, I see 
<mjg59> janimo: Yeah, ogra is right. It's gdm that actually calls pmi
<janimo> ok thanks 
<janimo> I actually manage to call pmi from xfce-session but on resume X is killed and I am dropped into console
<janimo> so I have to see what does gnome do besides calling pmi
<janimo> does gdm run as root?
<ogra> janimo, yup
<janimo> so no sudo right
<ogra> yup
<janimo> hmm that is one difference
<janimo> thanks ogra
<ogra> do you have a login manager wrapped in your xubuntu package ? 
<janimo> ogra, not yet
<janimo> haven't decided if we'll use one or not
<zyga> Keybuk: how to re-set the keyboard after kbd_mode -k
<janimo> 'we' is exagerrated, so far noone comments on xubuntu ;)
<janimo> it may be time to announce to users and ask for opinions
<zyga> janimo: DD will need a 'select desktop' post-install package that shows screenshots and installs [xg] ?ubuntu-desktop
<jdub> seb128: ping
<seb128> jdub: pong
<jdub> seb128: did you get to chat to vuntz about the menu logo stuff?
<janimo> zyga, DD?
<janimo> debian developers?
<seb128> jdub: yeah, didn't you read what I put to the query before going to bed yesterday?
<zyga> Dapper
<janimo> aha
<janimo> you think they'll fit on the same CD?
<zyga> janimo: - no
<janimo> although xubu  is mostly a subset of ubu
<zyga> janimo: but for network enabled users this could be neet
<janimo> sure
<zyga> janimo: broadband enabled users ;-)
<janimo> so I am out ;)
<jdub> seb128: hmm
<jdub> seb128: aha!
<jdub> seb128: unfortunately, that still requires us to create a new icon theme, unless we can hack it with stock icons
* jdub tries that now
<seb128> jdub: why?
<seb128> jdub: just ship it to the hicolor folder
<jdub> directly in ubuntu-artwork?
<jdub> i guess that works
<ogra> jdub, ubuntu-artwork needs a autotools update ... i (actually jbailey) fell into this with edubuntu-artwork
<jdub> seb128: turns out there's already a gconf hack for this
<jdub> ogra: hrm, i don't ship a native pacakge
<jcohen85> jbailey: did you ever get a chance to write a new initramfs-tools package?
<jbailey> jcohen85: No, but I'd be curious if you see the same pauses now.
<ogra> jdub, but its generated with automake1.7 or something similar old...
<jbailey> jcohen85: The splash screen starts sooner now.
<seb128> jdub: where?
<jbailey> jcohen85: It also seems that udevstart might wind up pausing on non-responding devices, but I'm not sure of that yet.
<jdub> seb128: /apps/panel/default_setup/objects/menu_bar
<jcohen85> jbailey: ok, i'll try again and tell you what happens
<jbailey> jcohen85: Thanks!
<jdub> ogra: this doesn't seem to have a negative impact on the resulting package, however
<ogra> jdub, thats true....
<jdub> seb128: can't seem to get any of those keys to work
<seb128> jdub: seems to be a leftover of some old key
<ogra> even i dont understand the whole makefiel fuss in there
<jdub> ogra: it's just a relatively standard gnome style autofoo module
<ogra> yes, but cp or dh_install would suffice :)
<jdub> seb128: did you ship the distributor-logo patch?
<jdub> ogra: not for intltooling
<ogra> ah, true
<jdub> seb128: which section should it be in?
<ogra> thats the missing bit then :)
<seb128> jdub: not yet, these gconf key seem to be still used by the panel in fact
<seb128> except they don't apply to current config
<seb128> just if you create a new panel
<jdub> what about the setting under /apps/panel/objects ?
* jdub couldn't get it to work
<jdub> hrm, though i didn't restart the panel
<jdub> nup, not even if i do that
<jdub> seb128: ok, if you can push the distributor-logo patch, let me know which section it is, and i'll respin u-a
<ogra> jdub, do you have a icon ? i'd have a bumped slightly glowing version here if you need one....
<seb128> jdub: 48x48/apps ?
<ogra> s/bumped/punched
<tseng> jdub: is there more art coming?
<tseng> jdub: im getting anxious
<Nafallo> hmm
<jdub> ogra: ah, worth having a try with that too - send over when you have a minute - thanks :)
<jdub> tseng: u-a upload a few minutes ago
<Nafallo> jdub: please detect that I use WS and set the background accordingly? ;-)
<jdub> Nafallo: heh, i wish :-)
<jdub> ha ha
<jdub> gar, after all that, i uploaded the wrong one
<Nafallo> lol
<jdub> didn't include the circle update
<Nafallo> circle update? gdm?
<jdub> yeah
<ogra> grmpf.... and my next evo crash...
<tseng> circle-of-elmo?
<ogra> #6 today ...
<tseng> jdub: 
<tseng>      - removed browser homepage
<tseng> i love you
<Nafallo> I almost hope for a replacement of the gnome foot in the left corner ;-)
* mjg59 gets usplash working on vesafb
<jdub> Nafallo: that's coming in the next upload
<Nafallo> yay
<jdub> bug seb about required panel changes ;-)
<Nafallo> seb128: ^ :-)
<ogra> seb128, my evo is crashy... i just wanted to gdb backtrace it and recognized about 40 running e-d-s processes... is this a new behavior ? or rather a bug ?
<seb128> Nafallo: let's wait for artwork changes so I can test before uploading
<Nafallo> seb128: oki :-)
<seb128> ogra: bug ... but don't you get a bug-buddy dialog?
<ogra> nope
<ogra> it just hardlocks
<seb128> gdb evolution
<seb128> (gdb) handle SIG33 pass nostop noprint
<ogra> actually the e-d-s processes might be from other crashes ...
<seb128> (gdb) run
<seb128> ...
<seb128> wiat for a hang
<seb128> <ctrl-C>
<seb128> thread apply all bt
<seb128> evolution --force-shutdown 
<seb128> to cleanup
<ogra> seb128, ok... it an take some hours... happens all 4-5h 
<Amaranth> hopefully tonight i'll be able to make my pre-colony 4 breezy install work again so i can work on smeg :)
<ogra> wow, what a luck ... now it hang immediately :) this hasnt happened before...
<Nafallo> ogra: lol. you have a funny way to define luck ;-).
<ogra> Nafallo, nope i'm short of time to donate to such things... but it seems it pulled down gdb whit it... very weird...
<Nafallo> "YES! My package hangs! Now I can go eat marshmallows for the rest of my life."
<Nafallo> ogra: hehe, joy :-)
<Nafallo> ogra: I would go for the marshmallows if I were you :-).
<ogra> seb128, (gdb) thread apply all bt
<ogra> Cannot find new threads: generic error :/
<seb128> urg
<seb128> gdb bog ?
<ogra> hmm, but also evo boog
<ogra> since it hangs again no
<ogra> w
<seb128> anybody knows about this gdb msg?
<ogra> oh
<ogra> gdb is stopped and evo still runs 
<ogra> now i have a crash dialog
<ogra> hrm... but bug buddy hangs too...
<ogra> damn
<dholbach> wait a bit
<dholbach> i guess bug-buddy is working a bit
<ogra> it hard locked and my cpu runs full speed...
<ogra> oh, youre right
<dholbach> it's working
<ogra> but veeeerrryyy slllooooowwww
<ogra> jdub, dont tell me you wiped the homepage from the artwork
<ogra> edubuntu-rtwork relies on that
<jdub> ogra: ha ha ha
<jdub> oh dear
<jdub> why's that?
<ogra> shit
<jbailey> Is that the FF homepage?
<ogra> because mozilla has this hardcoded as a home location...
<jbailey> Is it moving to -docs now?
<jdub> jbailey: i thought that change had already been made?
<ogra> i didnt want to fiddle with firefox
<jdub> the intent was to use the html-generated about page from ubuntu-docs
<mdke> yep
<jdub> though ideally we'd have something slightly more useful
<ogra> gah, my system burns... its at 80 degree and bug buddy still only moves the load bar 1mm a minute
<jdong> ogra: that's not good for your computer.... :)
<ogra> haha
<jbailey> jdub: I don't think so, but tell me what you need and I'll make it happen pdq.
<jdong> ogra: unless it's an athlon tbird
<ogra> its an amd64 lappie
<jdub> jbailey: just to make sure there's an html version of the about ubuntu page shipped in... something :-)
<ogra> it survives until 89 degree 
<Nafallo> ogra: !targa? :-)
<jbailey> mdke: Do you know if we have a suitable doc for that already, or should I drag up the old one from artwork?
<ogra> Nafallo, aspire 1520
<jdub> ogra: one fix to ff will sort it out, don't worry
<jdong> ogra: my athlon64 desktop burns at 70-ish
<Nafallo> ah, acer.
<Nafallo> seems you should have gone to lidl instead ;-)
* ogra gives up on evo and bug buddy... else i'll get blisters on my right knee
<dholbach> wow, i'm on berlinblogs.com and didn't know :)
<jbailey> dholbach: They're stalking you ;)
<ogra> hmm, probably i should install the 200 waiting updates ... might please evo :)
<mdke> jbailey, aboutubuntu is the doc dude
<mvo> dholbach: you are famous already?
<Nafallo> ogra: OMFG :-P
<dholbach> mvo: haha, not really
<mdke> jbailey, put it in /usr/share/doc/ubuntu-docs/HTML i guess?
<jdong> ogra: MOTU preventing you from doing other stuff? ;)
<jbailey> mdke: Lovely. =)
<ogra> jdong, i'm not only MOTU 
<mdke> jbailey, do you think there is any way of localising the firefox homepage? e.g. HTML/en/ HTML/fr and getting them to appear in the right language?
<jdub> jbailey: then i think you can pass the firefox fix to Diziet 
<jdub> :-)
<jdub> mdke: no
<mdke> there are loads of translations for about-ubuntu
* jdong walks away in shame, with 170 updates awaiting, too
<mdke> jdub, i bet someone is clever enough to do that
<ogra> jdub, but thast really odd, now i have to change ff defaults for custom distros... thats odd, who decided that ? 
<mdke> it makes sense ogra, ubuntu-artwork doesn't maintain that page
<ogra> i dont want to fiddle with app defaults
<ogra> mdke, but hacking ff is no option... so i can forget about about-edubuntu 
<ogra> it was perfectly right in the -artwork package ....
<mdke> ogra, maybe you can give the file the same name, and ship it in edubuntu-docs
<Nafallo> ogra: no. -docs makes sense...
<mdke> that way you don't need to play with ff
<ogra> Nafallo, its a branding thing, not a doc thing imho
<mdke> oh well
<ogra> and -artwork are the branding packages
<jbailey> In the end, so is docs, really.
<mdke> ogra, the doc is maintained b the doc team
<Nafallo> ogra: yea, but rather have the -docs conflict and put the page in /usr/share/homepage.html or something ;-)
<jbailey> I'm not clear on the separation aside from who's producing it.
<mdke> not much point having to syncronise the two packages
<jdub> ogra: you would've had to change the url in the old scheme too
<ogra> Nafallo, i can only put the page where ff looks ... 
<ogra> jdub, nope
<mdke> ogra, then agree with jbailey the right place to put the page
<jdub> the old url included ubuntu-artork
<Nafallo> ogra: well, we have to make ff look at things where it's sensible then...
<ogra> jdub, i linked it in postinst and removed the link in postrm... edubuntu-artwork depends on ubuntu-artwork since it reuses most of the ubuntu stuff from there
<mdke> ogra, do something similar?
<ogra> so it was perfectly right there without much fiddling... now i have to have two packages for a derivative branding
<jbailey> You'd want to fiddle with -docs anyway
<ogra> mdke, i'll do that anyway since i need -docs for edubuntu... but that way we force everyone to have *two* branding packages for his derivative, thats not nice
<mdke> do we?
<ogra> sure
<mdke> well the package is maintained in our repository
<jbailey> The whole fact that the file is in a path that contains the word ubuntu breaks the sabdfl's want to make it possible to remove the word 'ubuntu' from the system, I think.
<mdke> do with it what you like
<sladen> ogra: could you move human etc into a base-branding and then keep the really specific stuff in a separate package (and then perhaps override that)
<mdke> jbailey, iirc mark gave his approval to putting the page in ubuntu-docs
<ogra> sladen, yes, that would probably be best...
<ogra> but having such chamges now that my packages were in order and i didnt plan time to change them before release is quite hard to manage...
<ogra> but well...
<mdke> ogra, perhaps it is best if you guys discuss it all together on the mailing list or something
<ogra> it would have been nice to know about it before...
<mdke> it is not too late to sort it out either way
<mdke> ogra, yeah, you said that
<ogra> mdke, for me it is... i just lost a week of edubuntu development to the screensaver
<ogra> and i dont even know here to get the time to finish edubuntu ... now surprise surprise i have to touch packages that i thought were finished
<ogra> it just breaks my schedule..
<mdke> ogra, perhaps just write an email to the list and let the people who decide these things sort it out
<ogra> mdke, how ? i will make the change to my package... but the communication here is not well it seems, its ot the first time i ran into such a trap.. i'll put a BOF on the BOF list to have it better in dapper...
<ogra> s/ot/not
<lamont> I wonder if I should worry that xscreensaver-data (or some such) failed to configure correctly during a dist-upgrade to breezy
<ogra> mdke, the decision apprently was made already...
<mdke> ogra, it is very trivial to un-decide and re-decide, afaics
<mdke> since the file just needs to be built and inserted into one or the other package
<mdz> mdke: there are translations for About Ubuntu? they aren't in the package.
<mdke> mdz, not yet
<ogra> mdke, its a questin if i sleep an hour less and change my package or if 5 people discuss it again and lose 1h plus 2 people have to work on 2 packages...
<mdke> mdz, jbailey is on it :)
<mdz> mdke: are you saying translations exist but are not packaged yet?
<mdke> mdz, yes
<seb128> mvo, pitti: about cdrdao, is it promoted?
<mdz> because that page is going to change
<mdke> mdz, oh dear
<ogra> mdke, i will just accept it now... but i'm not happy that i didnt know about it
<pitti> seb128: the issues are resolved, so it can be promoted
<mdke> mdz, what do you mean?
<mdz> mdke: I mean it's needed to be replaced for a long time and we are finally getting to it
<seb128> pitti: can I upload a ncb Depending on it ?
<mdke> mdz, i was copied into a discussion about this today I think...
<seb128> hum, that would be wrong
<seb128> should we list if for desktop ?
<mdke> mdz, it didn't seem like it was going to be changed
<mdke> mdz, mark already rewrote it completely once
<pitti> seb128: Suggests: sounds more appropriate, and seeding it to supported
<mdke>  [22:16:13]  < mdke> mdz, jbailey is on it :)
<mdke> argh
<dholbach> good night
<ogra> lamont, error ?
<seb128> pitti: not desktop?
<pitti> seb128: or do you want it in desktop? CD space is expensive...
<mdke> mdz, translations are at: t:
<pitti> night dand 
<mdke> https://launchpad.net/distros/ubuntu/breezy/+sources/ubuntu-docs/+pots/aboutubuntu
<seb128> pitti: I would like to get "duplicate CD" working out of the box
<mdz> mdke: there's already someone working on it.  I didn't consider it a big deal to replace it late because I could see that there were no translations
<mdke> mdz, there are like 20 languages
<pitti> seb128: fine by me, but Kamion/mdz should approve, too
<lamont> *** libsane.usermap (Y/I/N/O/D/Z) [default=N]  ? 
<lamont> we know about taht one?
<seb128> pitti: universe or supported doesn't make a real difference, people have to install it
<seb128> pitti: sure
<lamont> empty-> 453 lines
<pitti> lamont: I tested upgrades from hoary, I didn't get that
<mdke> mdz, janew said today in her email that they had decided not to employ a company to work on the page
<ogra> lamont, what was the xscreensaver-data error ? 
<lamont> I may have universe crappage as well
<pitti> lamont: empty??? how did you get that?
<lamont> ogra: the xscreensaver-data error was, um, scrolled off the screen
<Keybuk> jdub: no new HumanCircle yet?
<ogra> lamont, ok
<mdz> mdke: who are 'they'?  please forward me this email, I should have been in the loop
<Keybuk> pitti: btw, did libsane.usermap magically start working with the grepmap update?
<mdke> mdz, i haven't got my computer on me, i left it at the office, but JaneW will fill you in I'm sure, otherwise I can forward tomorrow sometime
<mdz> mdke: she hasn't
<mdke> mdz, jdub was in cc though
<pitti> Keybuk: no idea, in the last bug report the culprit was the missing libusbscanner script
<Keybuk> ahh
* ogra takes a short break...
<mdke> mdz, i'm sure if you mail her she will forward it quicker than I can
<mdz> mdke: JaneW is gone for the day and I am leaving town tomorrow
<mdz> and this is something that I asked to be done
<mdz> so I need to know if something has gone wrong
<mdke> mdz, ah ok, listen
<mdke> mdz, when I replied, I copied in ubuntu-doc@lists
<lamont> ogra: my bad
<mdke> mdz, you won't see all of her email, but the general gist is there
<mdke> mdz, http://news.gmane.org/gmane.linux.ubuntu.doc/cutoff=3255
<lamont> Unpacking replacement xscreensaver-data ...
<lamont> dpkg: error processing /var/cache/apt/archives/xscreensaver-data_4.21-4ubuntu14_i386.deb (--unpack):
<lamont>  trying to overwrite `/usr/share/man/man1/xscreensaver-getimage.1.gz', which is also in package xscreensaver
<lamont> dpkg-deb: subprocess paste killed by signal (Broken pipe)
* lamont has more scrollback than he thought
<mdke> mdz, hope that helps
<lamont> ogra: amusingly, dpkg --configure -a and the problem did not reoccur
<mdke> mdz, (the thread is "About UBuntu to be beautified")
<mdz> mdke: that message is about KReleaseNotes...do you remember the subjcet line?
<mdz> ok
<lamont> hrm.
<lamont> another dist-upgrade, wants to install a new xscreensaver-data
<lamont> ogra: so missing Replaces?
<mdke> mdz, in a later email (not on the list) I made the point about there being loads of translations
<mdz> mdke: ok, jane was confused
<mdke> right...
<mjg59> mdz: Most of the usplash stuff should be sorted
<ogra> lamont, which version of xscreensaver was there before, do you know that ? 
<lamont> Preparing to replace xscreensaver-data 4.21-4ubuntu12 (using .../xscreensaver-data_4.21-4ubuntu14_i386.deb) ...
<ogra> lamont, there is a replaces, but it might contain the wrong version
<ogra> lamont, thanks will fix that
<lamont> ogra: thanks
<ogra> :)
<mdke> mdz, anyhow you saw the url with the translations?
<mdz> mjg59: which stuff?  I think outstanding were progress bar border, insmod errors, console font issues
<mjg59> mdz: Progres bar border, insmod errors should be fixed since the move to init-top rather than init-premount
<mdz> mdke: I see it, and it's a shame that they were never used
<mdke> mdz, jbailey is working on putting them into the package
<mdke> mdz, they are quite recent
<mjg59> mdz: The previous issue would have been that vesafb was being loaded first, failing and then we were trying to reload the same modules
<mjg59> mdz: Also, it now works with vesafb
<mdz> mdke: jbailey should now that the deadline was today
<mdz> mjg59: yay
<mdke> mdz, i didn't know that :/
<mdz> s/now/know/
<mdz> mdke: it's been on https://wiki.ubuntu.com/BreezyReleaseSchedule since May
<mdke> mdz, yes, but I am just a volunteer
<mdke> mdz, anyhow, i understood that translations could be updated
<mdke> as with the language-packs
<mdz> mdke: I don't follow from BreezyReleaseSchedule -> volunteer
<mdz> the schedule applies to the entirety of Ubuntu, not individuals
<mdke> mdz, yeah, i wasn't suggesting it didn't apply, just that i wasn't aware of this deadline
<mdke> mdz, perhaps the best thing would be to hurry jeff along?
<mdke> or leave the translations out, or update them. Whatever you decide
<mcella> is there a way to hide usplash progress verbose output?
<mdz> mdke: jbailey is gone for the day according to his schedule
<mdke> mdz, ok, your call on what you want to do.
<jbailey> mdke: I'm still here.
<jbailey> Sorry was dealing with puking cat.
<mdke> ouch
<pitti> Robot101: here?
<mdke> jbailey, mdz says that today was the deadline for translations
<Nafallo> jbailey: hope you didn't mean me ;-)
<jbailey> Nafallo: LOL
<Nafallo> jbailey: msg btw :-)
<mdz> mdke: after we prepared the schedule for breezy, I thought I remembered sending you the URL personally, even, to verify that it met your needs (since it was in part based on your input)
<mdz> mdke: non-language-pack translations, yes
<mdke> mdz, yep you did
<mdke> mdz, but I have not been keeping up with it, because I am working quite hard at the moment and haven't been able to do much docs work
<mdz> pitti: did we succeed in getting oo.o or firefox into langpacks?
<mdz> pitti: we need to create a list of what qualifies for NonLanguagePackTranslationDeadline
<pitti> mdz: oo.o yes, with ffox there were too many troubles
<pitti> mdz: I had a long discussion with carlos about ffox, it's not breezyable
<Nafallo> oh
<mdz> pitti: ok, so installer, firefox, HTML documents, desktop files...
<Nafallo> OO.o in langpacks :-P
<Nafallo> damn
<jbailey> mdz, mjg59: Nafallo and zyga have both confirmed the errors are gone with the current initrafs/usplash
<mdz> pitti: anything else worth mentioning specifically?
<mjg59> Ok. I'll go back to concentrating on suspend/resume, then
<pitti> mdz: maybe upgrade notes and debconf templates
<Nafallo> ehm, HTML Documents is ubuntudocs?
<mdke> mdz, ok i'm going to bed, jbailey knows where the translations are if you decide you want them in
<mdz> pitti: upgrade notes, as in notification-daemon
<mdz> mdke: ok, good night
<pitti> mdz: yes
<Nafallo> jdub: can we have the circle to please? the splash and wallpaper rocks after half a year ;-).
<mdke> mdz, same, sorry for any trouble
<pitti> mdz: although they are pretty uncritical
<mdz> pitti: created https://wiki.ubuntu.com/NonLanguagePackTranslationDeadline
<jbailey> mdz: Is it too late now?  I thought we had the 29th to do this.
<ogra> <Kamion> next time LaschW shows up, somebody point him at 'apt-get source oem-config localechooser kbd-chooser' please
<mvo> I have some pending desktop files here, but I'm sort of hesitating to upload e.g. a new xsane because of a single i18n update in the desktop file...what is the opionion in this?
<seb128> mvo: I usually do quite a bunch of upload for this reason
<LaschW> ogra: Nice hint, but already downloaded :-)
<ogra> ok :)
<seb128> mvo: but ping me before, I've a list of uploads for a 100% french menu :p
<mvo> seb128: can we coordinate that tomorrow then :) ?
<LaschW> ogra: I see it as a nono criteria for OEM's not to have a propper documentation for OEM mode install...
<seb128> mvo: sure
<mvo> seb128: thanks
<seb128> np
* mvo reboots now to test the "only one reboot notification feature"
<ogra> LaschW, not my area, i only forwarded Kamions request :)
<LaschW> ogra: Are there any people here in Germany who work on an OEM-Install documentation?
<mdz> mjg59: any suggestions on the console font issue?
<ogra> LaschW, glaub ich nich ;) 
<mjg59> mdz: We can't change the console font while in graphics mode. We can either fix the kernel so we can (not practical now), do it in text mode (either before usplash or after usplash) or not set the console font at all
<LaschW> ogra: Hhhm, up to now I know about 3 companies who asked about input on breezy OEM-Install...
<mdz> mjg59: what we do now is do it after usplash, in gdm, immediately before X starts
<mjg59> Yes
<mjg59> Which means flicking to a text console briefly
<mdz> this seems to cause a noticeable vt switch, though, which would be nice to avoid if possible
<mjg59> I can't see any way around that
<mjg59> Though it's possible we might be able to get it to switch to a blank console
<ogra> LaschW, i havent wokred in ths area at all... but i'm sure Kamion does a documentaion an the translation team will translate it... but there is no specific german documentation writer afaik
<mvo> mdz, mjg59: I'll try that again tomorrow, I was experimenting with various ways to avoid the flickering today (without much sucess :/)
<MK> anyone: is there a way of "upgrading" to Colony5 from the preview release by using apt/synaptic, or do I have to re-install fully? (in relation to: http://bugzilla.ubuntu.com/show_bug.cgi?id=16244#c6) - if I run apt-get update + apt-get dist-upgrade .. will this do the trick?
<LaschW> ogra: We had a guy here in Friesland who has been known as some kind of Mr. Linux. But he says he will not give Linux suport anymore due he has been tricked very badly by some OpenSource sectarians who offered him a deceitful job offer...
<mjg59> mvo: Calling the usplash init script is almost certainly the wrong thing to do
<mjg59> mvo: Try just chvting to an unused console
<mjg59> There'll be flicker, but there won't be any text
<ogra> LaschW, thats bad :/
<mjg59> mvo: You shouldn't need to wait for usplash to exit. Just do the chvt and it'll release the lock when it's shut down
<mvo> mjg59: thanks, will do this
<jbailey> mvo: Ooo.  The -15 usplash actually quits properly for me now when I break in the initramfs.  Thanks!
<LaschW> ogra: In his position I should have done so likewise. They know about his situation (Hartz-IV) and misused his enthusiasm until he was forced to accept a job as a toilet man. :-((
<ajmitch> morning all
<ogra> bah
<mvo> mjg59: a chvt 2 ; console-screen before gdm starts currently does not set the fonts properly. I'm too tired for looking further now. will check tomorrow
* mvo reboots again
#ubuntu-devel 2005-10-05
<shaya> has something changed in breezy recently?
<shaya> its insanely faster
<jbailey> shaya: We added extra gerbles in prep for RC next week...
<shaya> I'm serious
<ajmitch> so is jbailey, I'm sure :)
<shaya> it's so much snappier
<shaya> could the libgnomevfs upgrade have done that?
<seb128> no
<shaya> I doubt gdm update did it
<seb128> maybe you have changed your box? :)
<shaya> nah
<shaya> just did a big update for the day
<shaya> ctrl-alt-backspaced
<shaya> and logged back in
<shaya> new splash screen was barely seen
<ogra> so it was xorg apparently
<shaya> as it flew so fast
<shaya> perhaps
<shaya> weird
<shaya> anyways, off I go
<mvo> pitti: single-reboot-notification stuff is prototypish ready. I'll take care for the rest tomorrow
<seb128> Nafallo: around?
<Lathiat> mjg59: work with vesafb = rock
<Keybuk> oh gods, not another special virtual filesystem
<Keybuk> securityfs?!
<Keybuk> but we only just killed usbfs :'(
* Keybuk waits for snotify
<jcohen85> jbailey, well, it attempted to start the splashscreen after only 2-3 seconds but it failed. it went to the gnome brown screen at 34 seconds and gnome was completely started up with all menus by 59 seconds
<Nafallo> seb128: pong :-)
<Lathiat> Keybuk: haha
<Lathiat> Keybuk: wtf is that for
<Lathiat> devfs, debugfs, sysfs, procfs, securityfs, what next? )
<seb128> Nafallo: why did you revert the xchat-systray changes?
<jbailey> jcohen85: Lagging, I'm on the phone.
<Nafallo> seb128: the bugreporter and patch contributer asked me to since it hanged xchat-gnome per default.
<seb128> Nafallo: oh, k
<jcohen85> where did boot-admin go? after the latest update in breezy, it disappeared
<mdz> who broke metacity again?
<mdz> hmm, behaving now
<jcohen85> um, gnome-system-tools removed boot-admin again...damn't
<mdz> jcohen85: it was disabled due to bugs which won't be resolved in time for se
<seb128> jcohen85: it's broken, it has been dropped
<mdz> s/se/release/
<jcohen85> every time my kernel is updated, the windows xp grub option is deleted
<jcohen85> boot-admin atleast allowed me to recreate it easily
<mdz> jcohen85: that's because of boot-admin
<jcohen85> *easily
<mdz> it created the problem in the first place
<jcohen85> jcohen85, how do i stop it from happening?
<mdz> restore the backup of menu.lst that you made before modifying it
<mdz> if you need specific instructions, please use the support channel
<jcohen85> ok
<jcohen85> heh, well the only response i got was, " i got the perfect answer!!! dont use windows ;-)"
<jcohen85> since the last update i'm not seeing the splash screen anymore. Anyone else seeing this issue?
<jcohen85> jbailey, i restarted again. it tries to load the splash screen after 2-3 seconds so the startup is signifigantly faster than before- only a few seconds slower than hoary now
<jbailey> jcohen85: Still on phone, but can you please do "update-alternatives  --display usplash-artwork.so | grep status"
<jbailey> or not..
<michele> I don't see the splash screen either
<michele> I just get a black screen until X starts
<michele> usplash-artwork.so - status is auto.
<jbailey> michele: All black, like no text at all?
<michele> yes
<michele> and the console stays black also if I switch back from X
<jbailey> mjg59: ^^ any guesses?
<mjg59> None
<michele> this is an old breezy install upgraded (it started with colony 2 I think, before usplash got in)
<Keybuk> well, there's some good news
<Keybuk>  15: inputmap finds module                        FAILED (inputmap.at:12)
<Keybuk> etc. for all the inputmap modules
<Keybuk> so make check doesn't even pass on amd64
<ogra> hmmm
<ogra> could that cause keyboard problems ? 
<mjg59> keyboard is built in statically
<ogra> i just thought about 16539
<Keybuk> only if you're on amd64
<ogra> (would be nice to have a pipe and at sign again :) )
<Keybuk> this is 64-bit specific
<Nafallo> ogra: I don't have my synaptics atm ;-)
<ogra> yup, i am on amd64
<ogra> and it doesnt occur on my x86 desktop
<Nafallo> mjg59: usb-keyboards to?
<Keybuk> does "modprobe <something>" fix the problem?
<mjg59> Nafallo: They're under USB, not input
<ogra> Keybuk, what wouls <something> be ? 
<Keybuk> no idea
<ogra> *would
<Nafallo> mjg59: ah, nice catch :-)
<ogra> heh
<Keybuk> I'm not aware of any input keyboard module
<ogra> me neither, since keyboard is built in statically
<Nafallo> ogra: cat /var/log/syslog | grep segfault
<Nafallo> :-)
<ogra> Nafallo, i cant :p
<Nafallo> then you know ;-)
<ogra> no pipe sign :)
<Nafallo> hmm
<Nafallo> copy-paste then! :-P
* ogra copys and pastes
<ogra> no segfault 
<Nafallo> baah
<ogra> its very unlikely that the kernel sends segfaults to syslog ;)
<Nafallo> I'm the only one with the bug ;-(
<Nafallo> grepmap does for me ;-)
<Keybuk> heh
<Keybuk> I'm surprised it ever worked for you, tbh
<Keybuk> even the hoary version segfaults for me on amd64 when I poke it with obscene information
<Nafallo> baah
<Nafallo> must have been a change in the last version AFAIK
<Keybuk> nah
<Keybuk> the other version is just slightly more prone to segfaulting as a result
<Nafallo> well, the reboot after that install triggered it... ;-)
<Keybuk> because I put an extra sanity check into it
<Nafallo> hmm
<Keybuk> the basic problem is that sizeof (unsigned int) is the same as on i386
<Nafallo> bad sanitycheck then... ;-)
<Keybuk> but the array needs to be twice as big on amd64
<Keybuk> I don't have a clue *WHY* it needs to be twice as big yet
<Nafallo> 32*2=64 :-P
<Keybuk> yes, but why do amd64's input devices need twice as many flags as i386? :p
<Nafallo> hmm
<Nafallo> could it be a kernel bug or something?
<Nafallo> or wait... I haven't upgraded that one :-P
<Nafallo> MUST be grepmaps fault ;-)
<Keybuk> I think it's a "the input subsystem was written by monkeys" bug
<Nafallo> hehehe
<Keybuk> basically on amd64 these need to be unsigned hung int rather than unsigned int
<Keybuk> and the array needs to be the same size
<Keybuk> (number of elements wise)
<Keybuk> which means I then can't use scanf() anymore :'(
* Keybuk is gonna mull over lunch
<Keybuk> looks like depmod has two different bits of code entirely, one for i386 and the other for amd64 *sigh*
* mjr notes that scanf() is mostly evil anyway
<Nafallo> joy! :-)
<Keybuk> mjr: not especially, it's better than most people's roll-their-own line parsers
<Keybuk> if you just want a number from a string, it's the right thing (tm)
<mjr> now that's sscanf(), a completely different story :)
<Keybuk> that's what I mean :p
<Keybuk> ahh, no, I understand now
<Keybuk> the table has to be the same size in memory
<Keybuk> the 32-bit one is made up of an array of 4-byte unsigned ints
<Keybuk> the 64-bit one is made up of an array of 8-byte unsigned hung ints
<Keybuk> the 64-bit one has half the number of elements
<Keybuk> right
<lamont> Keybuk: strtol() is your friend for ripping a number from a string...
<lamont> Keybuk: sure they're not 'long' s?
<lamont> ah, nm on the longs thing
<Keybuk> no, definitely unsigned int on i386 and unsigned long long on amd64
<lamont> uh, unsigned long long has a good chance of being 128 bits on amd64...
* lamont doublechecks
<Keybuk> no, just 64
<Keybuk> right, time to add some autofoolery to check the platform
<lamont> well, I guess that's good.
<lamont> but it's really unsigned long, no?  (long is 64-bits there...)
<Keybuk> is it?
<Keybuk> is that true for all 64-bit platforms?
<lamont> I know that amd64 and ia64 are both LP64.  I expect that ppc64 is too
<lamont> that is, longs and pointers are 64-bit.
<lamont> int is some random size between 16 and 64 bits
<Keybuk> I think I might just do what depmod does and use long long
<lamont> although 64-bit int's would make you ILP64, which they toyed with for ia64 at one point.
<jbailey> lamont: I think GNU Systems are guaranteed to have at least a 32bit int 
<lamont> jbailey: that is, int === 32-bit,  or int >= 32bit?
<jbailey> >=
<lamont> Keybuk: you could just use uint64_t...
<lamont> Keybuk: which needs #include <sys/types.h>, iirc
* lamont wonders if there's another xorg upload already planned, or if he can "just do" a minor one that fixes hppa RC bugs.
<lamont> hrm... "hppa RC bugs"  that's kinda amusing
<Nafallo> lamont: oh?
<ogra> Keybuk, http://gcc.fyxm.net/summit/2003/Porting%20to%2064%20bit.pdf
<ogra> ;)
<lamont> mdz: thoughts on http://people.ubuntu.com/~lamont/xorg.diff - fixes hppa, with minimal change/risk to everyone else
<ogra> there are the mappings for variables for 32 vs 64 bit arches :)
<lamont> ogra: and sys/types.h gives you the sized types you need - what do you care what the underlying name is...
<ogra> true
<lamont> but Keybuk has a thing for auto*, you see...
<mjg59> Now, that is *really* odd
<lamont> mjg59: ??
<mjg59> If I start irattach after a suspend/resume cycle, this laptop freezes
<ogra> but i found the doc quite helpful anyway for the Cxx transition :)
<lamont> ogra: yes
<lamont> mjg59: score!
<Nafallo> mjg59: nice :-)
<mdz> lamont: why is it that all these SCC fixes are coming in at the 11th hour?
<lamont> mdz: because after midnight would be too late?
<lamont> truthfully, work has had me hammered on a couple of assigned tasks that I finally got a bit of freedom from this week
<lamont> based purely on the deadline
<lamont> the xorg patch makes ubuntu-desktop installable on hppa
<mdz> lamont: it's just that fabbione is doing the same thing with sparc :-P
<lamont> I don't know anything about sparc.
<ajmitch> lamont: are you able to kick a rebuild for scummvm on powerpc? bugreports indicate the problem behind it failing was fixed
<lamont> ajmitch: universe?
<ajmitch> yeah
<mdz> lamont: did you do a full test build on non-hppa?
<ajmitch> gs was segfaulting last time it tried to build
<lamont> mdz: built on i386
<lamont> I suppose I should do amd64 and ppc for a full 'yes', though.
<mdz> lamont: with all the same binaries produced as in -72?
<mdz> one arch should be enough
<lamont> mdz: given xorg's manifest, I expect that's a yes.
<lamont> the scripts/vars is a cut/paste from debian/control in -72
<lamont> but I'll go do a slew of interdiffs before I consider making it -73 and uploading.
<mdz> lamont: I mean all the same .debs, since that's what you changed
<lamont> mdz: actually, all I changed was the dependencies of xserver-xorg
<mdz> lamont: if you verify that it's a no-op for one other arch, I'm fine with it, though I'd prefer at least one generic bugfix (there's a long list to choose from)
<lamont> since hppa doesn't deliver xserver-xorg-input-*
<mdz> oh, so you did.  the changelog should say that then ;-)
<lamont> mdz: I'll review the OB-bug fix list
<lamont>   * xserver-xorg Dependencies on xserver-xorg-input-* need to be optionally 
<lamont>     removed for some architectures.  (Specifically, hppa has never delivered 
<lamont>     them, and that made xserver-xorg uninstallable.)
<lamont> mdz: looking at the major bugs, I'm not really comfortable with the risk level of having me try to fix them...
<lamont> I'll stare at it some, but in the end, I'll try to piggy back my upload onto one of daniels's, or just upload it before bedtime tonight
<mdz> lamont: send it to daniels I guess; he's supposed to make an upload today anyway
<lamont> right
<Nafallo> hehe
<Nafallo> one xorg a day... ;-)
<Nafallo> ...keeps the bandwidth away :-P
<Nafallo> but then again. it's by far more better than OO.o2 :-P
<Nafallo> should we split that for dapper? ;-)
<lamont> Nafallo: esp since the oo.o* uploads tend to be new upstream releases
<lamont> Nafallo: is it split upstream?  I thought it was monolithic
<Nafallo> lamont: I wouldn't know :-). I just saw xorg's impact on my bandwidth ;-).
<lamont> Nafallo: dapper xorg will be much nicer
<lamont> since it'll be split up upstream, instead of in the .diff.gz
<Nafallo> :-)
<Nafallo> 7.0 I guess?
<lamont> right
<lamont> well, 6.8.99
<Nafallo> hehe, when did 6.0 came out? :-)
<elmo> lamont: did you report the smooth engines thing?
<lamont> I don't remember if I filed a bug on it, but ISTR I did... seb was going to upload something.
<elmo> anyone feel up for a trivial merge to fix an RC bug?  if so, please deal with dict-gcide - there's a corresponding bug in bugzilla
<lamont> elmo: ok.
<lamont> on another note, if someone wants to try to duplicate 16519 from stock hoary, I'd appreciate it
* jdong runs in opposite direction before it's blamed on backports :)
<lamont> sadly, it looks like 16609 is a dup, which would make it kinda reproduced.
<Lathiat> bugzilla or malone?
<jdong> Lathiat: bugzilla
<jdong> lamont: I've seen similar errors in the past before... usually successions of dist-upgrades and -f installs will fix it
* lamont chuckles.
<lamont> elmo: please sync dict-gcide_0.48-4.1.  kthxbye
<lamont> elmo: the ubuntu change is subsumed by debian - but let me double check that
<elmo> lamont: ubuntu changes ok to override? 
<elmo> k
<Nafallo> lamont: I just reached the same conclusion :-)
<Nafallo> fwiw :-)
<lamont> elmo: from the change log, -4.1 has the fix we have, and the fix we need.
<lamont> but the build should be quick
<lamont> elmo: go for sync
<elmo> lamont: thanks
<lamont> np
<jdong> grr, just had nautilus-cd-burner segfault on me
<blueyed> I've just dist-upgraded to breezy but still cannot set dma on my sata hdd. It still says "HDIO_SET_DMA failed: Inappropriate ioctl for device". This is a nForce4 chipset mobo.
<jdong> blueyed: (1) wrong channel (2) hdparm is for setting IDE parameters
<jdong> blueyed: SATA DMA is enabled through BIOS (though theoretically it shouldn't be off period)
<blueyed> Thanks, jdong.
<jdong> blueyed: in the future, ask in #ubuntu.. there's just as many breezy fanatics in there. This is really for developers working on Breezy or stuff of that nature
<jdong> (not to play moderator outside my domain...)
<ogra> jdong, but you are right :)
<ogra> mdz, you said you'll be out of town ? how log ? 
<ogra> *long
<mdz> ogra: I mailed allhands
<mdz> ogra: and updated StaffCalendar
<mdz> ogra: (through Sunday)
<ogra> oki
* lamont doesn't get allhands
<lamont> mdz/elmo: I was wondering how anastasia output with hppa is looking, and if it can come into the fold....
<lamont> mdz: and I'd like to do an ubuntu-meta upload sometime this weekend to finish fleshing out hppa/sparc packages... with a discussion with Kamion planned if it changes anything in the other architectures
<lamont> thoughts?
<mdz> ubuntu-meta is no problem
<mdz> I don't know how anastacia looks; I'm not sure that elmo germinates for hppa currently
<lamont> hppa is not currently generated
<lamont> which makes it un-debootstrappable (libgcc2) and no CD's (palo)
<lamont> http://buildd.mmjgroup.com/hppa-hacks is the collection of universe packages that will move into main if hppa is germinated
<lamont> (the others are build-deps)
<lamont> hppa64 cross-compiler, and expect-tcl8.3
<lamont> the latter works around a really annoyingly difficult to reproduce/find kernel bug where sometimes expect (and others, to be sure) fail to correctly wake up on child death...
<lamont> _why_ tcl8.4 hits it and tcl8.3 doesn't is, well, part of the mystery
<Keybuk> lamont: the problem is that I need the code to be different on i386 to amd64
<Keybuk> on i386 it has to be an array of 8 unsigned ints
<Keybuk> and amd64 an array of 4 unsigned long longs
<lamont> Keybuk: ew
<Keybuk> otherwise I would just do this the easy way
<Keybuk> yes, you can tell this code is dealing with the kernel
<Keybuk> "we could do it the same way for each architecture, but we won't"
<lamont> "...that would be cheating"
<Keybuk> they're not that bad though
<Keybuk> I mean, it's not as if the kernel has a different entry point table for each architecture, is it?
<lamont> mdz: 16526 may want a new adduser, or may be NOTWARTY - I'll dig through it some tonight
<Keybuk> meh, that still segfaults *sigh*
<ogra> night all
<lamont> g'night ogra
* lamont tries to remember what he was going to ask pitti
<Keybuk> yes, this string is so sadistic, even gdb fears it:
<Keybuk> parse_array (
<Keybuk>     str=0x7fbffffdf3 "402000000:3802078f840d001:f2ffffdfffefffff:", 'f' <repeats 15 times>, "e", array=0x7fbffff960, array_len=8) at util.c:136
<bddebian> heh
<Keybuk> maybe it's not this code at all
<Keybuk> this code is very bounds-safe
<Keybuk> it's probably been busted all this time, but the worst it would've done is give people joysticks a little too often
<Keybuk> so it's good that I've fixed it, but it's something else
<Keybuk> lamont: don't suppose you know what gcc's type promotion is on amd64?
<lamont> Keybuk: I don't, but I bet both doko and jbailey do
<Keybuk> I bet they're both asleep
<Keybuk> the only other thing I can see in this code which is "unusual" is that I use ...
<Keybuk> so maybe it's promoting the type differently on amd64 to i386
<lamont> Keybuk: I haven't heard anything from jbailey in oh, say about 11 minutes
<lamont> Setting up gstreamer0.8-jpeg (0.8.11-0ubuntu4) ...
<lamont> Fontconfig error: Cannot load default config file
<lamont> seb128: ^^^ what's up with that?
<lamont> Setting up linux-image-2.6.12-9-itanium-smp (2.6.12-9.18) ...
<lamont> FATAL: Could not load /lib/modules/2.6.10/modules.dep: No such file or directory
<lamont> WTH??
<lamont> ah, doh.
<lamont> the _machine_ is running 2.6.10
<Keybuk> whoah
<Keybuk> so it's definitely promotion-related
<Keybuk> I just got 545460846593 from va_arg not 1
<lamont> make it a union.
<Keybuk> ahh, I bet I know what it is
<Keybuk> size_t's going to be 64-bit, isn't it
<Keybuk> and enum is 32-bit
<lamont> yepo
<Keybuk> aha!
<Keybuk> yes, that fixed it
<bob2> Keybuk: what are you doing, anyway?
<bob2> the hct kernel api?
<Keybuk> so it wasn't the bogus kernel structure after all, it was different type promotion combined with va_args
<Keybuk> but along the way, I've fixed the kernel structure so it'll actually dtrt on amd64 <g>
<Keybuk> bob2: amd64 hardware detection stuff
<bob2> ah
<Keybuk> right
<Keybuk> let's check I didn't break i386 in the process
<Keybuk> nope, is all good
<lifeless> Keybuk: thats a familiar bug
<lifeless> Keybuk: tla hit that, oh every time tom changed stuff that uses varags
<Keybuk> yeah, it was pretty much the second thing I looked for
<Keybuk> hmm
<Keybuk> what's a good group to put mice permission in?
<desrt> elmo; ping :)
<jbailey> plugdev?
<jbailey> That way potentially someone could add some sort of additional hid and let it get used on the fly/
<Keybuk> jbailey: that's for removable disks only, isn't it?
<Keybuk> it seems like we stick everything in plugdev, and I wonder whether that's wise
<lamont> desrt: I'm gonna go out on a limb and bet that he's not awake at 03:47
<Keybuk> jbailey: also could you comment on #14669 for me
<Keybuk> it looked like you were expecting that result and wondered if you could shine some light on it
<jbailey> Keybuk: The kernel doesn't provide us any notification of when it's done scanning the USB bus, so we do a sleep 2 right now.
<jbailey> For a USB Harddrive, it needs to be more like sleep 10, it seems.
<jbailey> I've asked various kernel folks, and haven't found an answer on how to know when it's safe to proceed.
<lamont> jbailey: because why would you ever care to know when udev is done... you just need to be told that it's starting...
<lamont> yeah, that'll work
<lamont> </bitter-mode>
<jbailey> It's not even udev.  I want to know when the bus scan is done.
<lamont> ah, ok
<jbailey> udev can sit on it and rotate for all I care.  At least with it I can trust that it will handle things as soon as possible or block until it's time.
<bddebian> hehe
<jbailey> (And cause various race conditions, but that's an aside)
<jbailey> SOrry, did I just date myself? =)
<lamont> jbailey: that aside is the source of my <bitter-mode> reaction.
<lamont> sit-n-spin... ISTR that's trying to make a comeback
<bddebian> My kids have one
<jbailey> As is Air Supply, apparently.
<jbailey> At my last job, a coworker went to see them in concert.
<jbailey> It's my childhood, all over again.
<lamont> welcome to the 70's
<bddebian> Air Supply?  No freakin' way :-)
<lamont> but _STILL_ no clackers
<jbailey> Ooo, that would take us back to when Kenny Rogers sang *good* country music. =)
<bddebian> heh
<Arrogance> Reuben James?
<Arrogance> Reuben Jane
<Arrogance> sorry
* lamont boggles
<lamont> http://cgi.ebay.com/KLIK-KLAK-CLACKERS-BNIP_W0QQitemZ6002743746QQcategoryZ30QQssPageNameZWDVWQQrdZ1QQcmdZViewItem
<lamont> Keybuk: find me a couple pair of those and I'll buy you a pint or 3
<lamont> something tells me they're harder to find in the US...
<Keybuk> lamont: wtf are they?
<lamont> Keybuk: THE KILLER toy of my childhood
<lamont> two glass balls on the end of a string... and you smash them back and forht
<bob2> crap
<lamont> hrm.. I can get them in the US from one site for a mere 35 USD
<bob2> "short read" kernel errors always mean physical disk fuckage, right?
<lamont> s/glass/heavy acrylic/
<lamont> Keybuk: I'll look around and see what I can get them for here - I might be able to beat ebay
<jbailey> Almost like the land-the-ball-in-the-cup game that I was also never able to do. =)
<jbailey> But I'm the kid who destroyed like 3 of the plastic tee's in T-ball in elementary school.
<jbailey> Noone was allowed a pinch hitter but me. =)
<lamont> from a random forum: "They were called clackers, if memory serves. The memory isn't too good, though, ever since I fractured my skull playing with the stupid thing.
<lamont> "
<jbailey> Turned out my problem that I was scared of the ball exploding or something, so I closed my eyes everytime I swung the bat.
<lamont> *FOR ADULTS ONLY. These were taken off the market because of injuries they caused to kids. Please: for collectible use only. .or adults! 
<bddebian> hehe
<bddebian> Like Jarts
<desrt> lamont; a reasonable assumption :)
* lamont -> home.  g'night all
<bddebian> Gnight lamont 
<LaschW> Is there a Chance to find a maintainer for Eiciel to get Eiciel into Breezy? Eiciel is a posix ACL editor for Gnome. IMO well done and fits seamless into Nautilus.
<bob2> #ubuntu-motu
<LaschW> Eiciel only needs a rebuild on breezy. There are Debian Sarge deb's which are linked against an c102 deb from sid.
<LaschW> bob2: #ubuntu-motu is the place to ask for?
<bob2> yes
<LaschW> bob2: Thank you. 
<lamont> LaschW: so it has circular build-deps or something?
<lamont> LaschW: or is it that it entered debian post-UVF?
<ajmitch> entered debian only a couple of weeks ago, from what I can see
<lamont> that'd do it
<lamont> anyway, home
<fabbione> morning
<Keybuk> gnargh.  another source package, another "guess the rule to unpack the tarball and apply the patches" game
<bddebian> heh
<bddebian> Heya fabbione 
<fabbione> ya
<jbailey> Keybuk: Yeah, you should beat on the dpkg maintainer to get wig&pen going... ;)
<Keybuk> meh, this caps lock bug is silly
<Keybuk> there's a whole discussion to get the patch right which ends in an upload
<Keybuk> and I can't find the patch in that upload
<Keybuk> <g>
<fabbione> hey Keybuk .. any news on that little apps we were talking about?
<Keybuk> which?
<fabbione> mdz: was it a good ride?
<fabbione> Keybuk: F1
<Keybuk> ah yes, not yet
<mdz> fabbione: so far the fix/workaround seems to be successful
<Keybuk> still got another week before the race
<mdz> I can now use my sound device without irqpoll
<fabbione> Keybuk: ehhee
<fabbione> mdz: cool
<Keybuk> have I ever mentioned how much I love apps that don't even compile if you enable debugging?
<fabbione> Keybuk: ahaha
<fabbione> that's because they don't need debugging 
<fabbione> mdz: do you think 16661 is worth fixing?
<fabbione> imho it can wait dapper..
<Keybuk> oh dear, this only seems to work because the broken code is usually optimised out
<Keybuk> or something
* Keybuk gets scared
<mjg59> mdz: acpi-support is in good shape now - pretty much everything that was on my todo list is done
<mdz> mjg59: hurrah
<mdz> mjg59: given that we need to tighten down on the kernel now, are there any patches we should try to squeeze in on that side?
<mdz> fabbione: not for breezy, no
<mjg59> mdz: I've hit one kernel problem, but I haven't figured out /what/ and we can work around it, so it can be ignored
<mjg59> mdz: The only other thing is that it's possible that the sata IDE passthrough patch is broken
<mjg59> I don't seem to be able to get hdparm to do anything useful to SATA devices
<mjg59> (noticed this while going through acpi-support bugs)
<mdz> mjg59: 16646 perhaps?   sounds safe enough; i've run into that once or twice myself
<mjg59> Oh, that's a userspace issue
<mjg59> We can extend the timeout before loading the module and then drop it back to normal
<mjg59> mdz: Have you got access to a SATA system?
<mdz> mjg59: not personally, no
<mjg59> Hm.
<mdz> my test machines are all ATA and my desktop SCSI+ATA
<mjg59> Mixed is fine
<mjg59> Oh, sorry, SCSI+ATA
<infinity> mjg59 : Is this is "HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate ioctl for device" thing you're talking about?
<mjg59> infinity: Yeah
<mjg59> Hmm. Actually, maybe we don't have that patch at all. I was under the impression we did.
<mjg59> Shit.
<fabbione> mjg59, jbailey, jdub: 16663
<fabbione> this must get fixed yesterday
<mjg59> The usplash thing should be fixed
<jbailey> Wow, looking that ticket up managed to kill ephy.
<infinity> mjg59 : Is it possible to ask the IDE drivers to shut up about re-probing ports?  (or lower the severity of that printk?)
<mjg59> infinity: Oh, probably, yes
<infinity> mjg59 : Ever since we got ahci loading, my laptop now prints 4 lines of annoying junk before boot.
<mjg59> Ah, so that's what it's from
<infinity> (Because I then go on and load ata_piix afterward, I assume)
<mjg59> What's the precise error?
<infinity> [4294672.575000]  ide0: I/O resource 0x1F0-0x1F7 not free.
<infinity> [4294672.575000]  ide0: ports already in use, skipping probe
<infinity> [4294672.575000]  ide1: I/O resource 0x170-0x177 not free.
<infinity> [4294672.575000]  ide1: ports already in use, skipping probe
<mjg59> infinity: Yeah, just knock up a patch to drop the KERN_ERR in ide-probe.c to KERN_INFO
<infinity> Actually, not sure if it's ahci's fault, the timing in dmesg doesn't make it right for that... But the date when I statred seeing the errors seems to coincide.
<mdz> Keybuk: did you track down or file a bug about that metacity thing?
<mdz> I can't see which window is selected when alt-tabbing at all
<infinity> mjg59 : Does ACPI retrigger an ide bus scan?
<mjg59> infinity: Not as far as I know
<infinity> mjg59 : In dmesg, I get this order: ahci fails to load, ata_piix loads successfully, ACPI bus registered, then the ide I/O probe errors.
<mjg59> infinity: Hrm. Weird.
<infinity> Oh, I can't read.
<mjg59> infinity: Oh - it'll probably be ide-generic loading
<infinity> That's "ACPI: bus type ide registered", from ide-generic, yeahp.
<mjg59> mdz: Ok. We're missing the ata-passthru patch
<mjg59> Which I thought we had, but, hrmph.
<infinity> Yeah, that settles it, then.  If we want to unconditionally attempt ide-generic, we need to lower the severity of that.
<mjg59> infinity: It's a two line patch. I'm already in bed, so I'm not doing it :)
<infinity> Yeah, I'll do it later today and pass it to BenC.
<infinity> I'll put your name on it. ;)
<mjg59> Heh
<fabbione> infinity: just push it here.. i can commit to baz
<infinity> (Cause, you've got more street cred, yo)
<mjg59> mdz: So we don't have hdparm support for SATA disks, which means we can't spin them down
<mjg59> Whether this matters or not, well.
<mdz> mjg59: the complementary question would be how risky the patch is
<mjg59> mdz: It's in common use, but it's a 21K diff
<mdz> I'm not sure we can risk it
<mjg59> But that's almost entirely adding new ioctls, so it's code that won't be run unless hdparm is run on the device
<mdz> can someone mail me a copy?
<mjg59> http://www.kernel.org/pub/linux/kernel/people/jgarzik/libata/old/2.6.12-git4-passthru1.patch.bz2
* sladen was wondering why the disk in this machine hadn't been spinning down.
<mdz> mjg59: not entirely horrifying
* sladen hadn't registered it as a bug...
<mjg59> Alternatively, it may be possible to hack something up with sdparm
<mjg59> But I really don't know about that
<mdz> mjg59: this isn't a regression from hoary, is it?
<mjg59> Nope
<fabbione> mdz: nope.. no regression
<mdz> ok, I prefer to leave it alone then
<mjg59> Ok
<mjg59> I'll see what I can do with sdparm
<Amaranth> yay, i got my breezy system working again
<Amaranth> just had to know the math to find a backup superblock
<Amaranth> too bad i've got this crappy windows only dialup
<Keybuk> anyone know what the KDGKBMODE ioctl is supposed to do?
<Keybuk> no, ignore me, I'm on crack ... helps if I put the printf after the ioctl <g>
<Amaranth> this is probably more of an #ubuntu question but does anyone know if there is any support for conexant winmodems in the ubuntu kernel?
<Keybuk> right, so I fixed the caps lock bug
<Keybuk> but I don't really understand why
<Keybuk> heh
<fabbione> Amaranth: there is a bug open for them.. but i don't think they were included in breezy
<Amaranth> wtf, the linuxant drivers for them aren't Free?
<fabbione> that wouldn't surprise me either
<Keybuk> right, so, err, does anyone have an exotic keyboard ?
<Keybuk> I want to see whether I've fucked everything up, or made an inspired guess
<fabbione> Keybuk: exotic to what level?
<Keybuk> fabbione: non-latin keys on it
<fabbione> nope.. dk-latin1 here
<mjg59> Amaranth: No,  because they're not under a license that allows us to distribute them
<mjg59> They're not Free, and they're not free
<Amaranth> yes, i see that now, that sucks
<bob2> am I imagining things, or is it impossible to unlock the screen on the live cd?
<Keybuk> bob2: "ubuntu"
<lifeless> its undocumented
<Keybuk> iirc
<lifeless> not impossible
<lifeless> Keybuk: be nice if the screensaver told us that;0
<bob2> lifeless: well, I can't seem to change to a vt, either
<bob2> hm, not possible if you didn't set a password, afaict
<Keybuk> oh, now, that's quite entertaining
<Keybuk> with caps lock on, even the number keys get capitalised
* Keybuk wonders whether he broke that, or just discovered it was already broken
<Keybuk> no, I broke that
<Keybuk> oops
<infinity> fabbione : You have dpatch mail.
<fabbione> infinity: gotcha
<Keybuk> I did fix the _original_ bug though :p
<Keybuk> ok, no, that makes no sense
<Keybuk> according to this, I didn't actually change anything
<fabbione> infinity: can i just queue it at the end of 00list ?
<infinity> fabbione : I assume so, I hate dpatch, so I have no idea what it did.
<infinity> fabbione : Let me add it to 00list and test-apply it.
<fabbione> infinity: it's ok.. i am doint it locally
<Amaranth> err, is  gnome-app-install 0+20050927 a native package?
<infinity> Seems to go fine if I put it in 00list after all the other drivers-ide patches (to keep things tidy)
<Keybuk> ahh, I understand what I did
<Keybuk> I turned every random character into "can take capslock"
<Keybuk> meh
<ajmitch> hm
<ajmitch> it's interesting coming across bugs in malone that have been in main since january or so
<fabbione> infinity: committed
<lifeless> Keybuk: haha
<Keybuk> meh, I need the dumpkeys off someone european
<lifeless> ask ddaa
<ajmitch> what's the main upload policy at the moment?
<lifeless> hes european dvorak
<Keybuk> is he awake?
<infinity> ajmitch : Itty bitty bugfixes for obvious bugs are probably still okay without approval, anything bigger should probably go through mdz/Kamion for a quick once-over.
<ajmitch> infinity: this is fairly minor fix to a postinst for xbel-utils
<infinity> ajmitch : That would fit category 1 then. :)
<ajmitch> I'll see if I'm in the keyring yet then.. :)
<infinity> ajmitch : The more hideous/obvious the bug, and the more simple the fix, the more likely that it's explicitely approved.
* ajmitch will find out in a few minutes if he needs someone to sponsor the upload still
* infinity heads out for some errands and shopping.
<infinity> If you guys need me, queue it up in mail or /msg, I'll be back in an hour or two.
<ajmitch> if someone could check & upload what is in http://ajmitch.dyndns.win.co.nz/debuild/ubuntu/tmp/uploads/ it would be appreciated :)
<ajmitch> bbiab
<fabbione> daniels: people.u.c/~lamont/xorg.diff <-
<daniels> fabbione: yes, I saw his email
<daniels> was that all?
<fabbione> daniels: from him yes..
<fabbione> i am trying to fix 14973
<daniels> fabbione: it'll be the matrox driver rounding down in one place when it does its default mode, but then not rounding down in mode validation
<fabbione> daniels: i am checking the DCC code of the mga driver, but i get the feeling that it doesn't recognize that a certain resolution set is not valid
<fabbione> because the mode is validated later 
<fabbione> the (WW) comes from libdcc
<fabbione> and i2c
<fabbione> not from the mga driver
<daniels> radeon is about the only driver with its own mode validation
<daniels> the rest comes from common/xf86Modes.c and friends
* mjg59 adds whitelisting of known good laptops
<lamont-away> drwxr-xr-x  132 hpojlp lp     8192 2005-09-29 23:52 /
<lamont-away> I wonder if that's still the case on a fresh breezy install with hpoj
<lamont-away> or was it hpijs
<fabbione> daniels: the problem looks like that the mga driver is using 2 different polling methods on the monitor
<fabbione> daniels: the first one is the normal ConfiguredMonitor = vbeDoEDID(pVbe, NULL);
<fabbione> that seems to return proper values
<fabbione> but later it does a MGAdoDCC
<fabbione> using libddc and i2c
<fabbione> where "somehow" fails
<lamont-away> fabbione: I was thinking we'd see if the breezy version of adduser had the shadow bug or not, before we closed that...
* lamont-away sleeps
<daniels> fabbione: well, first it tries through the VBIOS, then through I2C.  sounds about normal.
<fabbione> lamont-away: we do enable shadow by default.. also mdz closed similar bugs already
<lamont-away> yeah, np
<fabbione>     /*
<fabbione>      * xf86ValidateModes will check that the mode HTotal and VTotal values
<fabbione>      * don't exceed the chipset's limit if pScrn->maxHValue and
<fabbione>      * pScrn->maxVValue are set.  Since our MGAValidMode() already takes
<fabbione>      * care of this, we don't worry about setting them here.
<fabbione>      */
<HWolf> Who is responsible for the ubuntu-artwork?
<fabbione> ^^^this smells so badly
<daniels> fabbione: so check out the difference between sync validations in MGAValidMode and xf86ValidateModes (common/xf86Modes.c)
<robitaille> HWolf,  that would be jdub
<HWolf> jdub, you've got a bug on your hands. new artwork is blocky and ugly. :P
<dholbach> good morning
<HWolf> jdub, and it installed the 4:3 version by default on my 16:10 widescreen.
<jdub> that's unavoidable
<jdub> but a respin to soften up the noise was always pretty likely
<HWolf> jdub, I had the widescreen version installed, so have it replaced by the new widescreen version should be possible.
<HWolf> *having
<HWolf> Anyhow, got to run, math workshop.
<jdub> if you had selected the ws version, this one would simply replace it
<HWolf> it didn't, apperantly
* HWolf runs
<dholbach> does anybody use a kvm switch (two boxes - one monitor/mouse/keyboard)?
<fabbione> daniels: you are right, the mga driver doesn't make anything fancy by itself, but it uses the all the standard xf86modes.c even to prune the invalid resolutions.. so i wonder if it is actually a bug in xf86modes.c
<jdub> W: GPG error: http://katia breezy Release: The following signatures were invalid: BADSIG 40976EAF437D05B5 Ubuntu Archive Automatic Signing Key <ftpmaster@ubuntu.com>
<jdub> whee!
<Amaranth> ook, that's not good
<fabbione> AHHHHHHHHHH
* Keybuk beats his head against the kernel
<Keybuk> I think the isapnp subsystem must've been written by the same great people that gave us the input subsystem
<Keybuk> for each module you can get the vendor and device id of each device it supports
<Keybuk> it's just a shame that there's no way to get the vendor or device id of any connected device
<Keybuk> "if I told you what the vendor/device pair were, you could use this file to find the module you need to load"
<mjg59> Keybuk: There's PNPdump
<mjg59> And for pnpbios devices, they're exposed in /sys/bus/pnp/devices
<mjg59> Oh, wow
<mjg59> There's actually an almost moderate number of devices with entries in modules.isapnpmap now
<Keybuk> mjg59: they're exposed, but not their vendor/device ids :p
<Keybuk> the kernel only gives us it's strange PNPid string in the /id file
<tepsipakki> why is ACPI_SLEEP not yet enabled in acpi-support?
<mjg59> tepsipakki: Because there are many machines that it doesn't work on
<tepsipakki> mjg59: ok, fair enough
<mjg59> And giving people a "Crash my computer" button is not a good way of making friends
<tepsipakki> mjg59: is there a way to make it enabled for known good machines?
<mjg59> Keybuk: I have vague memories of there being a mapping from the strings to the pnp IDs
<mjg59> tepsipakki: Yes. See ubuntu-devel
<tepsipakki> oh my.. quite recent =)
<Keybuk> mjg59: yeah, there's stuff in modalias
<Keybuk> but really not much
<Keybuk> 9 entries in modules.alias
<Keybuk> compared to 226 in modules.isapnpmap
<tepsipakki> mjg59: my stinkpad T23 works fine, I'll send you mail soon
<mjg59> Keybuk: No, I mean ISTR that there's a mechanical transformation between the two
<Keybuk> mjg59: wouldn't that be rather lossy?  the full vendor/device/function set for a pnp device can be quite long ... the ids are just PNPxxxx 
<Keybuk> *shrug*
<mjg59> Keybuk: The Vendor ID (EISA Product ID) is defined by the Plug and Play ISA specification as the combined two-byte, three-character compressed ASCII EISA ID, and the two-byte, model-specific number (32 bits total)
<mjg59> If it's PNPxxxx then it's just a class ID, and you don't need to worry about it
<mjg59> Well, not in the same way - there's a strict mapping of PNPxxxx to hardware classes. They're all serial ports or parallel ports or motherboards or something.
<Treenaks> Keybuk: you're looking at the crystalsound mess?
<Keybuk> mjg59: I still have to worry about them, because I need to be able to load modules for them
<Keybuk> the theory is that the kernel is supposed to provide a "modalias" file under sysfs which maps to modules.alias
<Keybuk> cause it knows perfectly well what modules go with what :p
<jdub> mjg59: i so want to sit down with you and figure out why my laptop, docked, works completely differently wrt special keys and so on
<mjg59> Keybuk: But you don't need to worry about the IDs in the same way. There's a very small static table for dealing with them.
<Keybuk> mjg59: but there isn't that table, is kinda my point
<mjg59> Keybuk: But it's very easy to write
<mjg59> jdub: Nngh. I wish I knew.
<mjg59> Keybuk: Sound cards and stuff won't have PNPxxxx ids
<Treenaks> mjg59: some do
<Treenaks> mjg59: oh wait, not PNPxxx
<mjg59> tepsipakki: Works fine with ACPI, or does it use APM?
* Treenaks goes stand in the corner
<tepsipakki> mjg59: both, I've been using ACPI for a year now
<mjg59> tepsipakki: Cool
<tepsipakki> mjg59: but the hotkeys don't trigger it now.. used to work though, somehow the sleep.sh isn't run?
<tepsipakki> logs show that the hotkey is pressed
<Keybuk> mjg59: you mean things like PNPB003 (Sound Blaster 16) are figmets of someone's imagination? :p
<mjg59> tepsipakki: Erm. Odd.
<pitti> Good  morning
<mjg59> Keybuk: Bah. They're supposed to be.
<tepsipakki> similar to 16555
<Keybuk> see, the way this is _supposed_ to work is that every device, for every subsystem under /sys/bus has a "modalias" file
<Keybuk> that file contains a string that looks a bit like
<jdub> "Ubuntu" is an ancient African word, meaning "I can't configure Slackware".
<Keybuk> pci:v00001002d00004337sv00000E11sd0000005Abc03sc00i00
<Keybuk> which is some magic that we don't have to care about
<Keybuk> modules have a table of device information they support, which depmod can parse and turn into wildcard-matches for those magic strings which it puts in /lib/$uname/modules.alias
<mjg59> Yes, but you don't have that
<Keybuk> right, but we're supposed to have that :p
<mjg59> So you're going to have to do it manually
<mjg59> Which is, thankfully, possible with pnp
<Keybuk> the problem is that there's nowhere to do it manually anymore
<Keybuk> it seems the effort would be better spent fixing the kernel to actually produce a modalias for isapnp devices
<mjg59> tepsipakki: Bah. Older Thinkpads seem weird.
<tepsipakki> mjg59: some update broke it recently
<Keybuk> given depmod has gone to all that trouble to make the wildcard matches for it
<mjg59> Keybuk: isapnp_parse_id is the transformation from vendor string to letters
<fabbione> dholbach: i use a KVM here
<mjg59> In drivers/pnp/isapnp/core.c
<dholbach> fabbione: does it happen to kill the mouse when you switch a couple of times?
<Keybuk> mjg59: but we don't want those ones anymore, we want the ones that match things like:
<fabbione> no
<dholbach> fabbione: under windows it didnt move any more, under linux it felt as i had specified the wrong mouse protocol
<dholbach> FUCK
<Keybuk> alias pnp:cOPT0924dOPT0000dOPT0002* snd_opti92x_cs4231
<dholbach> then i'll send that stupid thing back
<Keybuk> (from modules.alias)
<fabbione> dholbach: buy a good KVM :)
<fabbione> you won't regret the expense
<dholbach> fabbione: this d-link thing doesnt seem to be remotely a good one
* dholbach opens the window, chucks it out
<mjg59> Keybuk: But how are you going to generate that without knowing that transformation?
<Keybuk> mjg59: the kernel generates those
<mjg59> Except it doesn't
<Keybuk> right, my point is that it should
<mjg59> Right
<Keybuk> because most of the code is clearly there already, because it's generating them for modules, just not devices
<mjg59> But we're in kernel freeze
<Keybuk> yeah, I'm talking dapper
<mjg59> Ok
<Keybuk> for breezy I just stick my fingers in my ears and go "la la la isapnp la la la"
<pitti> Hi Goonie 
<Goonie> hi pitti
<pitti> Goonie: I'm eagerly awaiting the workaround test :-)
<mjg59> So there's no way of doing a slightly more awkward hotplug for the pnp case?
<Goonie> pitti: I tested it half an hour ago... see the bugzilla entry...
<Keybuk> mjg59: we already have /etc/modprobe.d/isapnp which is a list of known pnp ids to module names
<Keybuk> it's quite small
<mjg59> (Since it's blindingly easy to get from the information that the kernel provides to a vendor and device string, and you have a table between those and modules)
<pitti> Goonie: ah, cool, thanks
<mjg59> Keybuk: Uhm. Yes. It's missing huge amounts of stuff.
<Keybuk> if you know any way to massively populate that, I'm all ears
<fabbione> dholbach: i have a DANBIT SW-KEYMON8A
<fabbione> dholbach: but it's an expensive one
<mjg59> Keybuk: Take modules.isapnpmap and mechanically transform it
<dholbach> fabbione: i will watch out for it
<mjg59> The algorithm required is in the code I pointed you at
* dholbach does the silly DANBIT mantra
<Keybuk> mjg59: what do we do with the function bits?
<mjg59> Keybuk: Ignore them?
<mjg59> The drivers will set those up themselves
<Keybuk> those seem to be the active bits?
<Keybuk> unless I'm misinterpreting this file
<mjg59> The string is built from cardvendor and carddevice
<mjg59> That's enough to give you the module you want
<mjg59> Hrm. I believe, anyway. Let me check that again.
<mjg59> Oh, right, I see what you mean
* mjg59 wonders about the cs4232 stuff
<Keybuk> I think those "function" bits are actually the device ids, you see
<mjg59> Yeah
<Keybuk> or maybe they're all pairs of vendor/device
* mjg59 goes to find the isapnp spec again
<mjg59> I'm sure I had a copy somewhere
<dholbach> thank you fabbione 
<pitti> infinity: ah, tbird 1.0.7 is out
<fabbione> dholbach: no problem
<infinity> pitti : Cool, I shall start getting all the uploads ready, then.
<infinity> pitti : I assume we need to audit the diff for warty/hoary?
<pitti> infinity: yes, the diff shouldn't be too big; it looked sane for moz/ffox
<pitti> infinity: and it should be audited for breezy, too :-)
<Keybuk> mjg59: yeah, they are all pairs
<Keybuk> not really sure the significance of having more than one vendor/device pair though
<mjg59> Keybuk: There's something very odd about how they're generated
<mjg59> .id seems to end up as the cardvendor/cardid unless there are any .devs, in which case it's on the left and the devices fill up the right hand column
<mjg59> Keybuk: So I'd guess (to be on the safe side) just transform them all
<Keybuk> there's two forms, if cardvendor/carddevice are 0xffff then the real id is on the right hand side
<Keybuk> (that's for stuff from pnp_table)
<mjg59> Yeah
<Keybuk> for stuff from pnp_card_table there's just lots of pairs
<mjg59> Ok. It's because cardvendor/cardid defines a specific *card*, and the other IDs define functions on that card
<mjg59> If there's only one function, the cardvendor/cardid define that uniquely
<Keybuk> ok, so parse them all?
<Keybuk> in which case we get http://people.ubuntu.com/~scott/isapnp.auto
<mjg59> Yeah, that looks reasonable
<Keybuk> alias pnp:dtBA03b0 sb ... looks a bit odd ?
<mjg59> CTL is certainly Creative Labs
<mjg59> Hmm. Some of those are wrong, yeah
<mjg59> The first three have to be alphabetical
<Keybuk> I've seen the @@ things before in modules.alias
<Keybuk> alias pnp:ctBA03b0dPNPb003* sb
<Keybuk> that's in modules.alias too
<Keybuk> alias pnp:cALS0007d@@@0001d@X@0001d@H@0001* sb
<Keybuk> and that
<Keybuk> *shrug*
<mjg59> Keybuk: Yeah, they do seem right. How weird.
<Keybuk> probably deliberately busticated
<mjg59> They're declared that way in the code
<mjg59> But:
<mjg59> We ought to prefer snd-foo over sb and cs4232
<Keybuk> right, sb is blacklisted anyway
<Keybuk> are all these modules capable of auto-detecting options and stuff?
<mjg59> If they're declaring PNP IDs, then they ought to be doing so
<Keybuk> Treenaks: about?
<daniels> yo sebarino
<Treenaks> Keybuk: ?
<mjg59> Keybuk: What's weird is that the ne driver has PNP IDs in it, but doesn't get them generated into the alias list
<Keybuk> Treenaks: you have one of those crazy soundcards, right?
<Treenaks> Keybuk: yes
<Keybuk> Treenaks: want to try dropping that isapnp.auto into /etc/modprobe.d and seeing whether good things happen?
<Treenaks> Keybuk: and a weird irda adapter too
<mjg59> irda is more awkward
<Keybuk> you can probably just rmmod the sound card and sudo /etc/hotplug/isapnp.rc start
<mjg59> Most of the drivers aren't PNP aware
<mjg59> I should tidy that up some time
<Treenaks> Keybuk: I don't have it here atm, I'll get it from my parents this afternoon
<Keybuk> ah ok
<Keybuk> mjg59: there's a lot of duplicates in that file ... a few things declare love for CSC0010 for example
<mjg59> Keybuk: That's probably a joystick port or something...
<Keybuk> heh
<mjg59> Oh, no, it's a control port
<Keybuk> so having one will mean you get three different sound-card drivers loaded?
<mjg59> Keybuk: I think that probably means that we should just be using the left hand column unless it's 0xffff, in which case it should be the right-hand column
<Keybuk> yeah
<Keybuk> that's what I'm thinking
<Keybuk> so that means Treenaks will get cs4232 because of his CSC0000 id
<Keybuk> which is blacklisted
<Keybuk> because the snd-cs4232 doesn't declare that
<mjg59> snd-cs4236?
<Keybuk> or cs* in fact
<mjg59> Hm. There's something very odd about all this.
<Keybuk> yup
<Keybuk> that CSC0000 snd-cs4236 line came from the end of the line
<Keybuk> alias pnp:dCSC0225 snd-cs4236  is the resulting "front"
<Keybuk> this all seems a mess <g>
<Treenaks> the card needs snd-cs4231
<Treenaks> (see #4787)
<Keybuk> Treenaks: that driver doesn't declare *any* ids
<Keybuk> unless that's also known as snd-opti92x-cs4231
<Treenaks> Keybuk: I'll try them all :)
<Keybuk> but that only declares support for OPTxxxx not CSCxxxx
<mjg59> CSC0000 seems to be WSS
<Keybuk> what's IBM0071 ?
<Keybuk> hmm, modem of some kind apparently
<mjg59> IBM specific thing
<Keybuk> IBM0071  IBM Thinkpad infrared port
<Keybuk> heh
<mjg59> It ought to have a PNP0511 with it as well
<Keybuk> no, has a PNP0510 though
* infinity only just noticde the other day that his TP has an IR port...
<mjg59> Close enough
<infinity> It's well-hidden.
<Treenaks> SMCf010 is irda as well
<Treenaks> (for your irda list, mjg59)
<mjg59> Treenaks: Got that one
<Treenaks> mjg59: ok
<mjg59> NSCfoo is, too
<Treenaks> whoa, TPM chips are isapnp too
<mjg59> And WACblah is (unsurprisingly) a Wacom tablet
<Treenaks> mjg59: wacom tablets? on their own proprietary interface card I hope?
<mjg59> On tablet PCs
<Treenaks> ah
<mjg59> So generally a serial UART in an odd bit of io space
<Treenaks> hardware is scary
<Treenaks> hm.. if I can find some ancient ISA system.. I could test ATI Mach32 8)
<Keybuk> ok, so the "slimmed down" version of this file isn't really much use
<Keybuk> there's a few things in here, but mostly its oss drivers
* dholbach <- dogwalk
<Treenaks> Keybuk: I have a TCM5051 also
<infinity> mjg59 : Oh, do you already have a full list of working T43 IDs for your auto-enabling of sleep?
<infinity> mjg59 : Mine's a 2687DVU, I'd assume all 2687s should work fine.
<infinity> (I could be dead wrong, but who knows..)
<mjg59> infinity: Yup, got that one
<Treenaks> mjg59: got my Asus one too?
<mjg59> Treenaks: Yup
<Treenaks> mjg59: then it works completely, out of the box.. except for irda and winmodem :)
<mjg59> Treenaks: irda-utils doesn't work?
<Treenaks> mjg59: I can get it to work, but I have to whack it
<Treenaks> mjg59: and "have to whack it" != out-of-the-box
<mjg59> Treenaks: With the latest irda-utils?
<Treenaks> ("serial" overrides the nsc irda device)
<mjg59> Oh, is it one of those irritating things where the nsc driver loads but doesn't actually work?
<Treenaks> mjg59: hm, no irda-utils installed
<Treenaks> mjg59: is that normal?
<mjg59> Nope
<mjg59> Well, yes
<mjg59> In that it's not part of ship or desktop
<Treenaks> ah ok
<Treenaks> installing now
<mjg59> But if you want IR to actually do anything, you need it
<Treenaks> mjg59: the module doesn't get loaded by default
<Treenaks> mjg59: maybe now I've installed irda-utils it will be
<Treenaks> trying
<mjg59> You'll need to run /etc/init.d/irda-setup start and then /etc/init.d/irda-utils start
<Treenaks> mjg59: ok, so a reboot should do it :)
<Treenaks> (I just finished booting :))
<Treenaks> ok module loaded
<mjg59> Heh
<mjg59> Rock
<mjg59> Right. Bit of sleep now, I think
<Treenaks> mjg59: "nsc-ircc: unable to allocate dma=-1"
<mjg59> Bloody nsc driver
* pitti is finally under 100 bugs again (99) - yay
<Treenaks> mjg59: good luck with sleep :) try not to dream of nsc drivers ;)
<pitti> mjg59: btw, do you think we can sneak you into the nvidia programming lab for one day to fix suspend with their drivers? :-)
<Keybuk> pitti: introducing mjg59 to people we dislike is a bad idea
<Keybuk> you may find that there's nobody left alive in the nvidia programming lab if we send him
<Treenaks> Keybuk: so you're volunteering?
<Keybuk> he's a bit of a last-resort weapon for things like that
<pitti> Keybuk: I know that Linux is about choice - but choosing between broken suspend and broken video playback is not too easy :-)
<Keybuk> pitti: buy a TV and watch your porn on that? :p
<pitti> Keybuk: bah, no room for another box :-)
<Keybuk> add another room? :p
<infinity> Is anyone still seeing "Window List", "Show Desktop", and "Workspace Switcher" quit on login with (nearly) every session login?
* infinity assumes this must be a broken session from breezy->breezy upgrading, but hasn't a clue what.
<pitti> btw, daniels, is a bug "Xv is broken with the nv driver on GeForce 5200" worth filing? or would you ignore it anyway?
<robitaille> infinity,  I see it maybe once every 10 logins...
<infinity> I used to see it that infrequently, now it's pretty much every login.
<pitti> infinity: this never happened to me...
<robitaille> I also started sseing it from time to time on my Hoary desktop in last few weeks
<Keybuk> hmm, BUG!  DCC SEND -> X-Chat crash
<infinity> robitaille : Oh, really?... Hrm.  That's even more curious.
<infinity> robitaille : Anything change on the hoary desktop, other than security updates?
<infinity> seb128 : Is there a sane and reasonable way to trace/debug these "(panel applet) has quit unexpectedly" on login bugs?
<pitti> robitaille: 3v1l backports maybe? :-)
<robitaille> infinity,  no.  it's a pretty stable desktop, only security updates.  no backports
<pitti> robitaille: before anyone accuses me, I didn't break it :-)
<infinity> pitti broke it!
<robitaille> but it's a warty PR --> warty -- hoary dist-upgrade  so it could be messy
<seb128> infinity: you don't get a bug-buddy dialog to send a bug upstream with a backtrace?
<infinity> robitaille : Is it those same 3 panel applets, or just "some random applet crashing"?
<seb128> infinity: if not, not really ...
<zyga> morning hacker
<zyga> s/$/s/
<infinity> seb128 : No, I just get "Don't reload" "Reload"... And reload always works fine.
<robitaille> but it started doing it semi-recently; maybe in the last 2-3 weeks.     And I believe  it's always these 3 applets
<janimo> daniels, should installing x-window-system-core from a server install end up having the same xorg.conf as it would have with default install?
<janimo> or is it missing discover1 magic
<infinity> seb128 : But I've seen a few people complain about it, I'm not alone, so I'd classify it as reasonably important to hunt down.
<pitti> infinity: I didn't upload panel security updates - that would be hopeless :-)
<pitti> Hey zyga 
<janimo> it asked about resolution but had to do a dpkg-reconfigure to one of the x metapackages to ask about all parameters, otherwise it used the vesa driver
<zyga> how do you feel on the verge of release? :)
<seb128> infinity: some Debian guys have the same issue, but without a backtrace ..
<daniels> janimo: if you don't have discover1 or xresprobe, you'll get a different config, yeah
<daniels> pitti: well, as of two days ago, nv is actually maintained
<daniels> pitti: so I'll file it in the BZ upstream
<pitti> daniels: it works somehow, but the picture gets totally disturbed as soon as I zoom the video window to more than 2x, or fullscreen
<daniels> pitti: so scaling is totally broken
<pitti> daniels: well, scaling up until 1.9x works even
<pitti> daniels: (maybe it's not exactly 2x, just an estimation)
<daniels> ah
<zyga> hmm what are you talking about?
<zyga> scaling video?
<daniels> pitti: what specific resolution?
<pitti> zyga: Xv on the nv driver
<daniels> zyga: with the nv driver, yes
<pitti> daniels: my screen is 1280x1024
<daniels> pitti: of the video, sorry
<pitti> daniels: hm, that happens with any video
<dooglus> hi.  is it possible to find the source for old versions of packages?
<zyga> I don't know if this is related but totem cannot scale even basic .mpg's on fglrx driver
<dooglus> the most recent libgtk2.0-0 broke something in metacity - how can I find source diffs?
<zyga> (mplayer scales them fine though)
<daniels> zyga: it's probably falling back to the x11 sink instead of xv, because xv isn't enabled by default
<pitti> daniels: I can switch to nv (I'm on nvidia now) and try some, if you need
<daniels> pitti: as much specific information as I could get would be great
<daniels> pitti: you can use xwininfo to find window dimensions to try to work out exactly where it breaks
<pitti> daniels: ah, ok, I'll do that
<daniels> so does anyone here have working DRI on a Radeon?
<pitti> daniels: where is the upstream bz?
<pitti> daniels: on my ppc, 3D acceleration works OOTB
<pitti> daniels: Radeon 9200
<pitti> daniels: tuxracer works great at least
<infinity> daniels : fglrx, or radeon?
<infinity> (or either?)
<daniels> radeon
<zyga> daniels: I'm talking about totem, just to be sure - right
<Treenaks> daniels: I have working DRI on 2 radeons, but one with a broken resolution
<daniels> zyga: right
<daniels> pitti: bugs.fd.o
<Treenaks> daniels: using fglrx
<zyga> daniels: where does totem/gstreamer keep its config?
<dooglus> is there a CVS repository with the package sources in it?
<zyga> I've checked gconf 
<daniels> pitti: could you please test whether DRI worked with -driver-ati 6.8.2-71, and whether -72 broke it?
<daniels> dooglus: no, the morgue is broken
<infinity> Treenaks : With the open source driver, he meant (I just clarified that a few lines up)
<pitti> daniels: yes, as soon as I have my main internet back (ISDN at the moment)
<dooglus> daniels: is there an archive of old package versions?
<pitti> daniels: I have a slightly older xorg on my iBook
<infinity> dooglus : No.
<Treenaks> infinity: meh, my radeons are too new for that :(
<infinity> dooglus : But you might try pinging the last guy who uploaded it, and see if he has the previous source.
<dooglus> so - how do I find out what changed between 2 package versions?
<pitti> dooglus: there is the morgue.ubuntu.com
<pitti> dooglus: but it's hard to find stuff there
<infinity> pitti : The morgue has ben dead for eons.
<daniels> dooglus: that's at morgue.ubuntu.com, but currently broken
<daniels> pitti: okay, thanks
<infinity> s/ben/been/
<pitti> infinity: oh, IC
<zyga> daniels: I've got radeon 9000 if that helps
<dooglus> ew.  shame!
<daniels> zyga: if you could do what I asked pitti, that'd be great, thanks
<Mithrandir> ogra: the text "someone else" seems to extend outside the button?
<zyga> daniels: I'll be back in one hour - I'll check it out then
<infinity> mjg59 : BTW, the usplash alternatives bug isn't really fixed.  My alternative had been shoved into manual mode by a previously-broken package, I had to --auto it to unbreak it.
<daniels> zyga: thanks
<infinity> mjg59 : Once I did, though, got to see it working on vesafb.  yay.
<dooglus> ooh.  last guy to upload was seb128...  seb, do you have diffs for libgtk2.0-0 from 2.8.3 to 2.8.4?
<pitti> dooglus: oh, diffs between upstream versions? you can certainly use cvs diff -r -r to get them from the gnome cvs
<seb128> dooglus: download both upstream tarball and diff -ur between both?
<infinity> dooglus : What's the actual bug you're seeing?
<seb128> infinity: windows borders on alt-tab
<seb128> they used to be solid on screen, they flick now
<dooglus> with no change to the window manager code
<seb128> that's due to a change between 2.8.3 and 2.8.4 and it's going to be fixed
<dooglus> just libgtk changed
<seb128> dooglus: you are going to debug it? Just to know if I need to work on it or just have to wait
<seb128> :)
<dooglus> seb128: I was going to take a look
<seb128> cool
* Zomb is confused by descriptions of xprt and xprt-xprtorg. Which is one is the recommended one?!
<seb128> let me know if you figure something
<dholbach> good morning mvo
<daniels> Zomb: neither
<seb128> dooglus: I would say it either http://bugzilla.gnome.org/show_bug.cgi?id=316180 or http://bugzilla.gnome.org/show_bug.cgi?id=316871
<Zomb> daniels: I need them however to buy the complete printer list to mozilla
<Zomb> s/buy/pass/
<daniels> Zomb: if you're using firefox, it'll work, but if you really need the original mozilla, use xprt
<dooglus> ok.  i'll also let you know if I don't, and give up...
<pitti> bbl
<mvo> hey dholbach, good morning all
<seb128> hey mvo
<dooglus> ok.  first stumbling block:  the GNOME CVS doesn't seem to have labels for releases.  should I use timestamps instead?  if so, where is it recorded what time a release was made?
<seb128> it has tags
* mvo waves to seb128 
<seb128> dooglus: GTK_2_8_4
<dooglus> ok.  I see tags if I use the cvs command.  I was expecting to see them in the web interface, for example http://cvs.gnome.org/viewcvs/gtk%2B/gtk/gtktexttag.c?rev=1.79&view=log
<dooglus> ok.  i'll shut up now.  they are in the web interface...
<seb128> on the bottom
<seb128> you can pick the branch, etc
<seb128> the tag
<dooglus> yes i see.  thanks :)
<seb128> np
<JaneW> Kamion: ping
<JaneW> Kamion: for the sake of being thorough can we move your remaining BreezyGoals to Completed? https://wiki.ubuntu.com/BreezyGoals
<JaneW> mjg59: ping
<JaneW> mjg59: can we move Laptop testing to implemented now? as it is well underway (it is a slightly unusual goal)
<JaneW> Riddell: ping
<Kamion> JaneW: BrandingForDerivatives: remaining string changes in the installer are deferred; please ask jbailey for the status of the rest
<JaneW> Riddell: you wanted me to ping you about updating the Kubunut BreezyGoals again at the end of the week... so consider yourself *pinged* ;)
<JaneW> Kamion: ok thanks, will do
<Kamion> JaneW: I've moved OEMInstaller to Tested; I still want to give it a bit more going-over
<JaneW> Kamion: ta
<Kamion> JaneW: there are serious bugs in InstallerSimpleResize that I'm working on right now, so it cannot be moved to Completed yet
<Kamion> JaneW: bug #16233 and multiple reports of same make me a little wary of moving MountingHDDFilesystems beyond Implemented just yet; I'll be working on those right after the showstopper InstallerSimpleResize bits
<Kamion> JaneW: I've left notes against those two specs on the goals page to that effect
<JaneW> Kamion: super
<Kamion> JaneW: GraphicalInstaller deferred, the base system won't fit (we're having trouble getting everything in as it is)
<Keybuk> I really should stop using my bugzilla "ubuntu" keyword as a short-cut to get into bugzilla
<Kamion> JaneW: I think most of the metapackage handling and expansion pack stuff from PackageSelection is deferred, but ask mvo for details on that; the base split and debootstrap maintenance simplification are completed
<Kamion> (I'll let you figure out how to represent that in the big table, I guess)
<JaneW> Kamion: ok
<Keybuk> '%s' is not a valid bug number.
<Treenaks> Keybuk: maybe %d is :)
<Keybuk> Treenaks: don't think firefox knows %d
<Treenaks> good point
<dooglus> bug 13724 (non-UTF8 fallen out of NLS data files) has been marked as 'fixed', but it's not fixed for me.  Should I make a comment in the bug?  Or is the update somewhere waiting to be uploaded (and if so, shouldn't the bug be 'pending upload' rather than 'fixed'?)
<doko> Setting up console-data (2002.12.04dbs-49ubuntu5) ...
<doko> Looking for keymap to install:
<doko> [and hangs ...] 
<seb128> anybody here on the translators list?
<Treenaks> seb128: yes
<pitti> jdub: ping
<pitti> something broke my box - no usplash any more, "Creating initial dev nodes" hangs indefinitively, a mess afterward
<pitti> bah
<seb128> Treenaks: could you mail them pointing https://wiki.ubuntu.com/DeskopTranslations ... we will do these uploads today but if some people want to update their menu entry translations, they can put them here today
<seb128> dooglus: http://bugzilla.gnome.org/show_bug.cgi?id=316180 is the issue
<Riddell> JaneW: ping recived thanks :)
<JaneW> BreezyGoals Owners: Please can all BreezyGoal owners with goals that are not yet listed as completed, please update the status and note section of the Goal ASAP. The monthly report is going in today, and there'll be questions about any goals that aren't completed.
<JaneW> Riddell: :)
<dooglus> seb128: I thought it wouldn't be the other one, 'cos I tried metacity without the shape extension and it still failed.
<dooglus> seb128: what tells you 316180 is the issue?
<seb128> dooglus: I've built a package with this one reverted and that fixes the issue
<seb128> dooglus: my build without it :p
<Treenaks> seb128: sent
<seb128> Treenaks: arg, mvo renamed it "DesktopTranslations"
<seb128> there was a typo
<seb128> but thanks :)
<Treenaks> argh!
<seb128> Treenaks: could you reply to your mail with the correct URIs? You can blame me/mvo for the change :) Thanks
<Treenaks> ok
<dooglus> seb128: how did you revert just that fix?  I don't see a patch attachment.
<seb128> Treenaks: or can we do redirect?
<seb128> dooglus: I grabbed it from the CVS
<Treenaks> seb128: should be possible, too
<seb128> Treenaks: let's do that
<Treenaks> seb128: go ahead
<dooglus> seb128: there's a tag for each bugfix?  or what?
<carlos> pitti, hi
<Burgundavia> ajmitch, it seems if we are both saving the same content, it doesn't complain
<seb128> dooglus: no, but there is a comment for every commit
<seb128> dooglus: you just have to pick the commit with the comment described by bugzilla
<ajmitch> Burgundavia: hm?
<Burgundavia> ajmitch, we both hit deskoptranslations at the sametime, both with redirects
<ajmitch> hh
<ajmitch> heh
<pitti> jdub: here?
<dooglus> seb128: it's been a very long time since I used CVS for anything other than 'cvs co'.  How are you finding the commit?
<seb128> dooglus: http://cvs.gnome.org/viewcvs/gtk%2B/gtk/gtkwindow.c?rev=1.310&view=log
<seb128> dooglus: click on "Diff to previous" ... for the line with the comment you want
<dooglus> that's OK if you know which source file was patched - but if you don't?
<seb128> you read the Changelog other way
<dooglus> ok, of course.  thanks.
<seb128> np
<dooglus> I'm used to working with ClearCase rather than CVS, and it's totally different...
<bob2> woah
<ajmitch> evening bob2 
<tepsipakki> hmm, firefox segfaults on me if esd is on
<tepsipakki> works if I either kill esd or comment out the FIREFOX_DSP-things from the wrapper
<pitti> jdub: ping
<pitti> mvo: any news about update-notifier?
<mvo> pitti: did you got my message from last night?
<mvo> pitti: it's working, I need to do the i18n now
<pitti> mvo: ah, cool! no, I didn't
<seb128> if there is something to translate to french please point it :)
<pitti> mvo: I didn't see a new upload
<seb128> jordi: around?
<pitti> mvo: I guess you can do the .de translation yourself :-) 
<mvo> pitti: it will be uploaded today (when I have finished the i18n bit of the generic notification)
<mvo> pitti: heh, yeah :)
<pitti> cool
<pitti> mvo: so I keep myself ready for updating dbus and hal, since this should happen ASAP
<pitti> carlos: hey Carlos, good morning!
<pitti> carlos: I had big trouble with my ISP, but it seems to have stabilized again
<mvo> pitti: normal notifications are like desktop files, not available through rosetta, but I want this one handled via gettext
<mvo> pitti: yes, I'll hurry
<pitti> mvo: maybe you can use po-debconf to merge translations?
<pitti> mvo: the format should be similar
<carlos> pitti, ok
<carlos> pitti, phone, just give me sometime
<pitti> carlos: oh, sure
<ogra> Mithrandir, erm, there is no such string anymore ?
<JaneW> **BreezyGoals Owners**: Please will all goal owners with goals that are not yet listed as completed (i.e. still at implemented or testing), update the Status and Notes sections of the Goal ASAP. 
* fabbione -> food
<mvo> has anyone seen that our init-scripts doing a fsck twice on the same device? I just got two fscks for "/"
<pitti> mvo: I can't reproduce #16678, can you please check what breaks there?
<carlos> pitti, hi (again)
<mvo> pitti: did you used italian?
<pitti> mvo: french
<pitti> mvo: ok, I try italian
<mvo> pitti: I did it with italian and I was very puzzled that a reboot fixed it
<pitti> mvo: after installing the langpack, I can instantly do "$ LANGUAGE= LANG=it_IT.UTF-8 pmount --help" and get italian
<pitti> mvo: same for you?
<pitti> mvo: I try to relogin now
<mvo> mjg59: do you mind if I do another usplash upload that (hopefully) fixes the flicker-before-gdm problem. should I send you patches? or create a branch from your bzr tree?
<pitti> mvo: indeed, I get it with Italian - but restarting gdm helps
<pitti> mdke: ^
<mvo> pitti: so, "iz gtk bong" !
<pitti> mvo: still puzzled why it works for French, but not for Italian
<pitti> I'm sure that is seb128's secret plan to convert the world to French
* mvo suspected something similar
<pitti> mvo: so that he can always close as RESOLVED/WORKSFORME :-)
<mvo> haha
<mvo> :)
<mvo> pitti: you made my morning :)
<Mirv> so translators were informed about translating menu entries during the last day that it is possible.. erh. but what about this "notification-daemon", translations for which are also due to be final today? I've never seen anything about translating it... it's not in rosetta so in which way it's supposed to be translated anyway?
<Mirv> (supposing I have time today to do something about it)
<pitti> Mirv: now would be a good time to coordinate with mvo about translating the new "reboot" notification
<pitti> Mirv: if you have a translation for the language pack upgrade, please send it to me ASAP
<pitti> Mirv: for langpacks, I have French and German ATM
<pitti> Mirv: getting Finnish would be nice :-)
<Mirv> pitti: yes, but is there a po file or something else for the notifications?-) I haven't found anything...
<pitti> Mirv: no, it's not using gettect
<Diziet> usplash seems to have stopped happening on my main breezy testbed.
<pitti> Diziet: for me too, I guess jdub broke it with the new artwork
<pitti> Diziet: $ sudo dpkg-reconfigure linux-image-2.6.12-9-amd64-generic
<pitti> cpio: ./usr/lib/usplash/usplash-artwork.so: Datei oder Verzeichnis nicht gefunden
<pitti> ("file or directory not found")
<pitti> I guess that's what breaks it
<pitti> Diziet: did you experience an udev hang at boot? I did
<torkel> pitti: update-alternatives --auto usplash-artwork.so
<Diziet> No, no hang.  It just boots normally without udev.
<pitti> torkel: but that should be taken care of automatically
<torkel> pitti: i agree
<pitti> torkel: I don't see a reason to change the path at all
<torkel> pitti: a .so should not be in /usr/share/... ?
<torkel> pitti: shouldn't the eq in 'dpkg --compare-versions "$2" eq 0.1-12' usplash.postinst be a ge?
<Mirv> pitti: I will try to ping mvo about the reboot message
<mvo> Mirv: here
<mvo> the current text is: 
<mvo> Description: Reboot required.
<mvo>  To complete the system update a reboot is required so that the new
<mvo>  services get activated. We strongly recommend that your machine is
<mvo>  restarted as soon as possible
<JaneW> **BreezyGoals Owners**: Please will all goal owners with goals that are not yet listed as completed (i.e. still at implemented or testing), update the Status and Notes sections of the Goal ASAP. 
<Mirv> mvo: ah, okay, I will msg it to you
<mvo> suggestions are welcome, it's a generic message 
<JaneW> that was the last time promise ;)
<mvo> Mirv: wait a bit please, there may be suggestions/typos etc
<Mirv> mvo: okay
<mvo> how does the above text sound to native speakers?
<Kamion> "get activated" is the wrong tone
<Kamion> "are activated" would do
<Kamion> I'd drop the full stop from the end of "Reboot required"
<Kamion> and add one at the end of the extended description, which is (unlike the short description) composed of sentences
<Robot101> did anyone fix the "There are 1 item(s) of post-update informations." string? :)
<ogra> is it expected behavior that my system switches to console between usplash abd gdm now ?
<ogra> s/abd/and
<Diziet> Ha, you have a usplash :-).
<Mirv> pitti's string had the whole text after Description: (not new line after a short two words' description)
<mvo> ogra: yes
<mvo> new: Description: Reboot required
<mvo>  To complete the system update a reboot is required so that the new
<mvo>  services are activated. We strongly recommend that your machine is
<mvo>  restarted as soon as possible.
<segfault> "System->About Ubuntu", where does that string come from?
<ogra> Diziet, yes, after a manual reconfigure of linux-image :)
<Mirv> segfault: I guess it's https://wiki.ubuntu.com/DesktopTranslations now :P I've seen it in Rosetta somewhere too, and it's already correct in Finnish
<segfault> humm, didn't know about that link
<segfault> still in time to hit breezy final?
<Mirv> segfault: I didn't know until two hours ago, and this is the last time to submit those
<Mirv> time=day
<segfault> ahh, nice
<segfault> thanks man
<segfault> you saved my life
<segfault> :)
<Mirv> np :)
<nakee> what's ubuntu policy about local markets?
<tseng> nakee: how do you mean
<nakee> in promotion of ubuntu
<nakee> any intrest in sponsoring local linux events?
<tseng> definately through ship-it (free cds) and promotion
<tseng> if you expect more, youd have to mail info@canonical.com
<nakee> what do you mean by promotion?
<tseng> http://fridge.ubuntu.com/
<tseng> "upcoming events"
<tseng> i doubt it would be a problem to add events to that
<mdke> nakee, if you are interested in setting up a local group, also have a look at the various wiki pages starting here: https://wiki.ubuntu.com/LoCoTeams
<mdke> that is quite comprehensive
<nakee> mdke: yea, I ment more investing money in promotion
<nakee> but I  guess for that I should email canonical:)
<mdke> yes
<\sh> ogra_: ping
<\sh> ogra_: after reinstalling the sony (latest daily breezy iso) the problem with the keyboard went away
<ogra_> hrm
<ogra_> its still not working here
<\sh> ogra_: did u reinstall all your stuff?
<ogra_> nope
<\sh> ogra_: looks like we have a problem during upgrade from warty and/or hoary to breezy
<ogra_> i cant, my DVD is broken... and its my main development sysytem
<\sh> eek
<ogra_> \sh, you saw keycodes on the console by just pressing altgr ?
<sistpoty> ping infinity
<\sh> ogra_: yes
<\sh> ogra_: even before the reinstall..so it can be a gnome upgrade problem as well
<ogra> \sh, then its a HW problem on my side i guess.... i dont see any keycodes
<\sh> ogra: hmmm....
<ogra> grmpf
<ogra> @@@@
<ogra> \sh, it works with USB keyboard :(
<dooglus> seb128: just to let you know, I have completely failed to fix the alt-tab bug (16589).  Please feel free to work your magic.
<Mirv> pitti: did you get/save/add the Finnish translation before your irc died?
<Mirv> ok, thanks :)
<pitti> Mirv: I committed them now, thanks a lot
<\sh> hach pgra
<\sh> aeh ogra
<pitti> Diziet: after a hoary->breezy upgrade ffox yells at me: "/usr/share/ubuntu-artwork/home/index.html" not found
<\sh> seb128: do u have the possibilty to do an upgrade from warte/hoary to breezy? 
<pitti> Diziet: is this a ffox upgrade bug or a bug in the current artwork package?
<pitti> \sh: I just did a hoary->breezy upgrade, FWIW
<\sh> pitti: and? no problems with umlauts and/or meta-q/e/7/0/ ?
<seb128> dooglus: k, thanks anyway
<pitti> \sh: I got the dreaded X/Gnome keyboard question again
<seb128> \sh: I've planned to do one this afternoon for some bugs, why?
<pitti> \sh: no, my keyboard works fine
<\sh> pitti: hmmm....I didn't get any question because of the keyboard...but in gnome no special meta-keys were working
<\sh> pitti: it was warty -> hoary -> breezy upgrade 
<\sh> pitti / seb128: after installing breezy from scratch it disappeared
<\sh> so we could have an issue with those upgrades
<seb128> hoary to breezy?
<seb128> what keymap do you use?
<\sh> seb128: warty to hoary to breezy
<\sh> seb128: german, so de with dead keys
<\sh> seb128: not me...a colleauge of ogra and me...
<seb128> gconftool-2 -R /desktop/gnome/peripherals/keyboard/kbd 
<seb128> that before and after update would be nice
<\sh> seb128: now it's too late...I will try to do this again with vmware
<pitti> Is anyone here interested in translating the langauge pack upgrade notification? I already have en, de, fr, and fi
<segfault> pitti: i do
<mdke> pitti, i can post to the -it mailing list, if you like
<pitti> http://people.ubuntu.com/~pitti/langpacks/langpack-upgrade-note.txt
<pitti> please mail to martin.pitt@ubuntu.com or just /msg it to me
<Diziet> pitti: ffox> How odd.  Obviously my machine doesn't do that.
<pitti> Diziet: is this path supposed to be the correct one?
<mdke> pitti, awesome, also maybe you can mail it to ubuntu-translators@lists?
<Diziet> No, I tell a lie, it does.
<pitti> Diziet: i. e. did jdub break the last artwork package or did the path change?
<mdke> pitti, or I can
<Diziet> The path in ffox didn't change.  Or at least, I didn't intend it to.
<Diziet> And obviously I'm pretty sure of that since it worked fine with my test build of ffox ubuntu18.
<pitti> $ dpkg -L ubuntu-artwork|grep html
<pitti> $
<mdke> Diziet, jbailey will explain, essentially the file is moving package
<pitti> jduuuuub!!!
<Diziet> mdke: So why isn't it present ?
<mdke> Diziet, i don't know I am afraid
<Diziet> Is there a bugzilla bug about this yet ?
<mdke> Diziet, yes let me dig it out
<pitti> mdke: I need to subscribe to it, I guess?
<pitti> Diziet: btw, nice work, a hoary->breezy upgrade does not have a single question any more
<mdke> http://bugzilla.ubuntu.com/show_bug.cgi?id=3985
<mdke> i think that is the right one
<segfault> pitti: done
<Diziet> pitti: question> Good.
<Diziet> 3985 ?  Sounds a bit old.  /me reads ...
<mdke> Diziet, it started off as something else
<pitti> segfault: thanks
<mdke> pitti, want me to mail that translation to the translators list?
<pitti> mdke: would be nice, thanks
<mdke> ok
<segfault> is there anything that needs to be translated?
<mdke> pitti, done, you in cc
<Diziet> That bug is against firefox and assigned to jbailey.  Does that mean he's planning to upload a firefox with a different start URL ?
<mdke> Diziet, not sure, but that was what I'd assumed
<Diziet> jbailey: ping
<pitti> Diziet: why should the file be moved in the first place? u-a seems about right?
<Diziet> And why would the file need to move in the filesystem just because the package has changed ?
<mdke> the reason was that the file is also in ubuntu-docs already, and is updated there
<mdke> Diziet, perhaps the sane solution is to put the file back in the same place, in the new package
<Diziet> Oh, well, clearly it ought to be in only one package.
<pitti> mvo: in update-notifier, will "Description-pt_BR work" or just -pt"?
<mdke> Diziet, the move has also caused issues for ogra i think, from what he said yesterday
<jbailey> Diziet: pong
<Diziet> Hello.  See scrool re firefox start page and 3985.
<jbailey> Diziet: I can upload a fixed FF and Ephy easily enough.
<jbailey> Can someone tell me what it should point to? =)
<mdke> jbailey, it should point to an html version of the about-ubuntu document
<Diziet> No, no, I'm not asking you to do an upload.  I'm just (at the moment) trying to figure out what's going on.
<Diziet> I can upload easily enough.  I'm just trying to have some coordination.
<Diziet> Do you have any idea what's going on ?
<jbailey> Diziet: Lovely.  I'd rather not have the "touched it last" tag on FF. =)
<Diziet> :-)
<Nafallo> hehe
<jbailey> Diziet: Only that it's lived in -artwork for a long time, and apparently stopped yesterday.
<Diziet> The proximate symptom is that current breezy's ffox gives a file doese not exist dialogue box.
<jbailey> Lovely.
<jbailey> Lemme see if I can quickly cobble together the HTML page.
<Diziet> Um, if the file has just moved package, I don't understand why it needs to change name.
<fabbione> Diziet: did you notice by any chance that mozilla and firefox are crashorama on amd64?
<Nafallo> jbailey: btw, I runned update-alternatives --auto usplash-artwork.so and it changed instantly. is that something we should run somewhere in the postinst? :-)
<jbailey> Well, the first file wass in /usr/share/doc/ubuntu-artwork. =)
<Diziet> fabb: No, I have no idea about that.
<Nafallo> fabbione: are they?
<jbailey> Nafallo: No, because it should've been auto in the first place.  I thnk you stumbled on a bug from the 6 hours it pointed to the wrong place.
<fabbione> Nafallo: yes.. 
<Diziet> When did this start happening, and what do you do to trigger it ?
<fabbione> Diziet: ok
<fabbione> Diziet: i can't say when it started.. the syntom has always been there since i bought the amd64
<Diziet> OK ?  Doesn't sound OK to me :-).
<Nafallo> jbailey: seems like it ;-).
<Diziet> I see,.
<fabbione> Diziet: it's enough to hit the reload button sometimes..
<fabbione> if i use shift and do it slowly it's ok
<Diziet> Are you sure this machine is OK ?
<fabbione> most of the time just crashes
<infinity> jbailey : Yeah, it went manual on mine too, which generally points ast a serious fuckup in how maintainer scripts are calling update-alternatives.
<fabbione> Diziet: yes
<fabbione> Diziet: everything else works fine
<Diziet> Ha ha.
<Diziet> Umm, I've not heard any other reports.
<Nafallo> infinity: yay! I'm not alone! :-)
<infinity> jbailey : If all is well now, we can't really do much except declare it a casualty of tracking breezy daily, I guess.
<Diziet> Anyone else here with an amd64 ?
<jbailey> infinity: Right.  I made a thinko and put the wrong path in.
<jbailey> infinity: I had put a bit in the postinst that would fix it if it ddn't flip to manual
<jbailey> (remove the bad one, put in the good one)
<jbailey> But for some readon u-a sets it to manual if it's a bad path.
<Nafallo> Diziet: yes, and I don't have those symptoms :-).
<jbailey> Stupid.
<Diziet> inf: Right.  Perhaps a mail to ubuntu-devel saying `if this happened to you, we know about it, here is how to make it right, users won't see it'.
<infinity> jbailey : Try remove the bad, check where it currently points, if still bad, flip back to auto.
<Diziet> naf: Thanks.
<jbailey> infinity: I think probably not worth touching at this point, but I know that now.
<Diziet> fabb: Firefox is, ahm, unusually large.  So it might well crash more readily on bad hardware.
<infinity> jbailey : s/bad/known bad/
<jbailey> And consider it to probably be an 'important' bug on u-a
<infinity> It's been how u-a has behaved for eons.
<jbailey> Sure, doesn't mean it's right.
<jbailey> It makes it a situation where I might override a users chosen settings by forcing to auto.
<Diziet> This reminds me of some bug in the Debian BTS about u-a reverting.
<jbailey> Probably.
<infinity> Well, it's not likely the user would chose to a) point at the same broken path you used, and b) point at it if it's a dangling link (two easy things to test for)
<jbailey> I'm pretty certain that all paths lead to policy violation there.
<Nafallo> jbailey: I would have blamed the kernel if it had not worked after next upgrade ;-)
<mdke> jbailey, any more help needed on about-ubuntu, cos otherwise I am gonna get back to work
<jbailey> Nafallo: Sure, most poeple don't realise the splash is separate.
<jbailey> mdke: I don't think so, thanks.
<mdke> jbailey, great, thanks
<Nafallo> jbailey: well, I would have blamed it cause of the dpkg-reconfigure bailing out with cpio-errors ;-).
<jbailey> Nafallo: Eh, did you see cpio errors?
<Nafallo> jbailey: ehm, IIRC yes. I'll check the private log from yesterday :-).
<jbailey> Nafallo: Doesn't matter now, it's fixed.
<jbailey> I just don't remember anyone mentioning that to me. =)
<jbailey> Diziet: Are trnaslations useful to you, or should it just always be in English for now?
<jbailey> I don't remember if FF/ephy will hunt for a .LANG.html in a directory
<infinity> jbailey : Anyhow, yes, as a casualty of breezy tracking, you should probably mail -devel with a "if usplash artwork doesn't work, and update-alternatives --display upsplash-artwork.so says it's manual, then 'update-alternatives --auto usplash-artwork.so && dpkg-reconfigure linux-image-`uname -r`', have a nice day."
<Nafallo> "cpio: ./usr/lib/usplash/usplash-artwork.so: File or directory doesn't exist"
<pitti> Nafallo: right, same here
<Diziet> 308838, 285686, 87677
<jbailey> infinity: Right, there's one related bug where the postinst hasn't run the alternative yet that I need to fix first.
<jbailey> infinity: So I wonder if I should just look at it in the postinst.
<Nafallo> pitti: hehe. you don't have usplash anymore now :-)
<infinity> jbailey : Easy enough to do.
<jbailey> Just test it with readlink?
<Diziet> jbailey: Translations of what ?  Like error messages ?  Depends on the language, but I can probably cope with error messages in at least many languages with Latin script.
<jbailey> Hmm, readlink, -e the destination.  Is there a sane way to check for manual or auto?
<Diziet> Or do you mean translations of the start page ?
<jbailey> Diziet: Of the about ubuntu page.
<Diziet> Um, you know, I hadn't thought about that at all.
<Diziet> But obviously they should be translated and we should use the right one.
<Diziet> I have no idea what it does if you install non-English.
<infinity> jbailey : --display tells you if it's auto or manual.
<Diziet> I should do a non-English install to dsee what it's like.
<jbailey> Diziet: So far it hasn't flipped to French for me.
<Diziet> But you agree that it shoudl ?
<jbailey> Diziet: Right, so I have to parse the first line.  suck.
<jbailey> infinity: ^^
<Diziet> Parse the first line ?
<jbailey> I wonder if I care?  If it's pointing to /usr/share, and it doesn't exist.
<jbailey> ..
<Diziet> I think I'll install a Dutch version of hoary and see what it looks like.
<jbailey> Diziet: I agree that it should.  I also think that since it never has before, it's a bit late to worry about it for Breezy.
<Diziet> Is it ?  It's probably not very hard to make the start URL depend on language somehow.
<jbailey> Your call.  We have other bugs to chase too, and by any sane measurement all of the text-related freezes have now passed.
<Diziet> I had no idea that it didn't work.
<Diziet> Don't you think it's very shoddy to have that page only in English ?
<janimo> ogra, who/what starts xscreensaver?
<jbailey> 'k, I have the HTML now.   I just need to figure out how to turn <img src="../../images/C/UbuntuLogo.png" /> into a better path
* jbailey wiggles at the thought of doing XSLT
<jbailey> Diziet: Oh sure.  Most things that show up on my desktop in English remind me how far we have to go.
<Diziet> `You have the HTML'.  I'm getting worried here.
<infinity> jbailey : Define "better"....
<jbailey> Diziet: mdke said that the page should point to an HTML version of 'About Ubuntu' from the docteam.
<Diziet> I thought this HTML was already in some package or other.  ubuntu-doc, or something.
<Diziet> So the docteam have it in HTML already ?
<Diziet> Or it has to be converted ?
<jbailey> infinity: One where you can expect to find the image.  Probably an absolutely path to an images directory.
<jbailey> Diziet: Dude, it's docbook. =)
<Diziet> Ahhh.
<infinity> jbailey : But if that relative path is correct when docbook generates it, what are you doing to make it incorrect?... Moving files around willy-nilly?
<jbailey> If you want it in texinfo, I can twist a knob.. =)
<Diziet> So you're making ubuntu-doc spit out HTML ?
<jbailey> infinity: The layout in the repository does not match the final installed layout right now.
<Diziet> Obviously it should be HTML for ff :-).
<jbailey> infinity: It's the same problem as the entity problem you whined about earlier.
<jbailey> Diziet: Bah!  We want inline PDFs!
<Diziet> :-P
<infinity> jbailey : So do the docbook to html generation AFTER moving it to an appropriate layout, not before.
<bddebian> Howdy
<infinity> jbailey : That seems saner than running sed accross everything to munge paths.
<infinity> cp foo build-tree/stuff/lives/here && cp bar build-tree/stuff/lives/there && docbook magic && install from build-tree to debian/
<infinity> (bonus points, cause it buys you a lovely build-tree to rm -rf in clean)
<Diziet> This mixture of Dutch and English in the installer is a bit odd, indeed.  Unfortunately my Dutch is really only up to comprehension and not helping with translation.
<slomo> seb128: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2964
<jbailey> infinity: eh?  There's still a sed pass or something in there.  The source docbook has:                 <imagedata fileref="../../images/&language;/UbuntuLogo.png" format="PNG"/>
<pitti> \sh: here?
<jbailey> infinity: Or perhaps an entity that can be either "../.." or "/usr/share/doc/ubuntu-docs"
<jbailey> infinity: Anyhow, it's a fix-today kind of bug.
<Diziet> These big disks on modern computers are very nice.  My testbed machine has room for a further 4 roomy installs :-).
<jbailey> Diziet: Which timezone are you awake on?  I need to do morning preppish things and can hack after.
<mdz> morning
<Diziet> GB
<Diziet> mdz: Hello.
<jbailey> g'm Matt.
<Diziet> I'll be around until exactly 7 today, ie a little under 5 hours from now, and then I have to go.
<pitti> Hi mdz
<mdz> it is wholly unreasonable to be awake before the sun is up
<jbailey> mdz: That depends if you're still awake or not. ;)
<pitti> mdz: so why you are?
<Diziet> Indeed so.  Go back to bed :-).
<bddebian> mdz: Yes
<mdz> can't sleep
<jbailey> ... clowns will eat me!
<Diziet> *sympathy*  You need more late nights.
<Robinho_Peixoto> pitti: And this bug http://bugzilla.ubuntu.com/show_bug.cgi?id=15820 ?
<Diziet> But, since you're here, I was wondering if you had an opinion about this conversation we're having about the firefox start page.
<Diziet> See scrollback, or I can summarise.
<pitti> Robinho_Peixoto: I hope to build new langpacks today
<Nafallo> pitti: yay! :-)
<mdz> Diziet: I believe firefox looks for .lang.html
<mdz> if it doesn't, it probably should, but if not, it's too late
<Diziet> Right.  I was hoping you'd say that.
<Diziet> I'm checking it now.
<Diziet> Standard rules for locale resolution apply, I hope.
<infinity> If it does, that's news to me.  That sort of negotiation is generally done by webservers, didn't think firefox would emulate an http server when using file:/// URLs.
<Diziet> The default preferences are done by piece of javascript, which AIUI is run when it creates a new profile.
<Nafallo> I agree with infinity. why is that option in apache if ff could do it?
<jbailey> Nafallo: Because it would mean an extra round trip over the wire.
<jbailey> I'd expect it to only do it on file:/// URI
<jbailey> s
<Diziet> No, no, no, I don't want to make it do the equivalent of content negotiation on file:/// URI's.
<Diziet> Not unless it already does :-), which I doubt.
<jbailey> Or possibly several round trips over the wire given locale search orders.
<jbailey> Diziet: How else would it do it? =)
<Kamion> jbailey: ssh-askpass-gnome does that readlink trick you were suggesting, because I couldn't find any other way to avoid the ssh-askpass alternative ending up in manual mode
<Diziet> `Download the required packages from the Internet?  <Terug>  <Ja> <Nee>'> LOL
* ogra grumbles at HW vendors that have webshops only usable with IE 
<Diziet> Oh dear, the timezone setting part of the installer has crashed.
<Kamion> if dpkg --compare-versions "$2" lt-nl <foo> && [ -h /etc/alternatives/<bar> ]  && [ "$(readlink /etc/alternatives/<bar>)" = <baz> ] ; then update-alternatives --auto <bar>; fi
<Kamion> Diziet: hoary?
<Diziet> Oh, well, I'll let it believe I'm in Amsterdam.  K: Yes.
<Kamion> Diziet: fixed in breezy, though I can't remember the bug number right now
<Kamion> was a translation handling problem somewhere in the hideous base-config/debconf/cdebconf stack that's involved there
<Diziet> Sure.  I'm starting with hoary because I want to check a few things with the ffox upgrade.
<Kamion> right, just letting you know in case you were going to file a bug :-)
<Diziet> :-)
<jbailey> Kamion: 'kay, thanks.  I'll do that then and make sure it's solved.
<mdz> jbailey: what do we lose if we revert that whole mess?
<jbailey> Oo, reminds to check.  My dad said that the installer from a week or so ago gave him grief when he selected UTC for a server.
<jbailey> mdz: The artwork page for Firefox?  Nothing.  If we'd rather have the HTML version of about-ubuntu, we can drop it in place int he ubuntu-artwork package anyway.
<mdz> jbailey: oh, I thought you were talking about the usplash alternative
<mdz> jbailey: which seems to continue to generate bug reports
<jbailey> mdz: Sorry, two threads at once, hard to track which I'm on at the moment.
<Diziet> The init.d script startup messages aren't translated, are they ?
<mdz> Diziet: not
<mdz> at all
<Diziet> Maybe for dapper.  It shouldn't be too hard.
<jbailey> mdz: The alternative can be reverted, we lose usplash brnading for kubuntu and edubuntu.
<Kamion> mdz: btw, I thought the non-langpack translation deadline was for translations to arrive in Rosetta, not for uploads, which is why the corresponding installer uploads haven't arrived yet; it takes me some hours of clicking on stuff in Rosetta, waiting for mails, and downloading tarballs by hand to merge installer translations from Rosetta
<mdz> jbailey: http://bugzilla.ubuntu.com/show_bug.cgi?id=16676
<mdz> Kamion: waiting for mails?!
<jbailey> mdz: Yeah, race condition between kernel install and the postinst running in usplash to put the file in the right place.
<Kamion> mdz: uh-huh. have you downloaded translations from Rosetta lately?
<mdz> jbailey: this is too much complexity to drop in at the laast minute
<mdz> Kamion: never
<Diziet> mdz: Also, your message about artwork freeze.  How does that relate to the Firefox fonts issue ?  (Which I will look at a proper fix for later today hopefully, but I think we'll have to go with the `just furtle the aliases' plan.)
<mdz> Kamion: but  involving email in that process sounds unreasonable to me
<jbailey> mdz: 'k, I'll pull that outo then.  I wanted the artwork flexible enough and had been testing it here for a while.
<mdz> Diziet: grey area. please get  the changes in ASAP
<Kamion> mdz: apparently the old useful po-export functionality hung the launchpad appservers for ages while it processed them, so now you have to send an asynchronous request and it e-mails you with a librarian URL when it's done.
<Diziet> mdz: Right.
<Kamion> which is an utter pain in the arse
<jbailey> Kamion: It still loses the requests occasionally.
<chmj> quit --> home 
<Kamion> jbailey: even better!
<jbailey> Kamion: I had to ask a few times for one of the pofiles yesterday.
<Kamion> Diziet: timezone bug => #9160
<ogra> pitti, how is the web management tool (eq. phpmyadmin) for postgres called ? i know there was one... got a user in #edubuntu asking me...
<Diziet> k: 'sok, I'm just going to ignore it.
<pitti> ogra: phppgadmin IIRC
<pitti> ogra: yep
* Kamion goes back to #13250
<pitti> ogra: I never saw it, though
<mdz> jbailey: why does replacing the artwork require a new .so and alternative?  the existing artwork branding worked by swapping one package for another
<Diziet> (phppgadmin ?  Is that what it sounds like ?  A really bad idea, and a strange gargling noise ?)
<ogra> pitti, me neither... but it seems there is a demand for gui admin tools... do we have any other ?
<Nafallo> pitti, ogra: I've used it a bit. it's like mysql with the added complexity of postgresql :-)
<janimo> jbayiley can't the splash be a simple image file?
<jbailey> mdz: The .so is just a compiled version of the pngtobogl output.  It has no xpm loader, and putting all the png loader stuff in the binary is a bit heavy for early userspace.
<pitti> ogra: pgadmin3 is a really nice one
<jbailey> mdz: So /sbin/usplash has the artwork built into it.
<pitti> ogra: depends on whether you want a web-based or local application
<mdz> eeeeek
<Nafallo> s/mysql/phpmyadmin/
<mdz> sorry I asked
<bddebian> heh
<mdz> libpng is all of 146k uncompressed
<jbailey> IIRC, it also wants libgd., another 200k
<mdz> what does?
* jbailey turns on heat, it's too cold to type in here.
<mdz> not libpng, certainly
<jbailey> Ugh, 12 degrees, that would be why.
<sladen> IIRC, libpng only wants zlib
<Diziet> Even so, if it has to be a .so, why can't it be just a different .so in the different packages ?
* jbailey checks why pngtobogl also depends on gd and freetype
<jbailey> Diziet: It can be, but something has to provide the default.
<jbailey> Diziet: That's why it's an alternative.
<sladen> jbailey: probably for drawing and annotations
<Diziet> I don't understand.  Why can't it be a different .so with the same name in different packages, which conflict with each other ?
<Diziet> No need for an alternative.
<Diziet> You get the one you have installed and if you have none installed you get no usplash or it crashes or something.
<jbailey> Diziet: edubuntu-artowkr and ubuntu-artwork don't conflict.
<jbailey> One depends on the other.
<Kamion> ped_geometry_set_start (geom=0x804a8b0, start=The value of variable 'start' is distributed across several
<Kamion> locations, and GDB cannot access its value.
<Diziet> So make a new udeb ?
<Kamion> er, go gdb
<jbailey> Diziet: it's not an installer bit, it's runtime.
<Diziet> Or a new .deb ?
<jbailey>   png = gdImageCreateFromPng (pngfile);
<Diziet> This doesn't seem like rocket science to me.
<ogra> Diziet, edubuntu-artwork reuses lots of ubuntu-artwork... it would duplicate the package contents ...
<Diziet> ubuntu-artwork-base.
<jbailey> Ah, and libgd.so.2 wants freetype png12, jpeg and pthread.  Joy.
<Diziet> Or you could have the executable rpath an extra directory where the foobuntu version lives, so the dynamic linker does it for you.
<Diziet> Then fooubuntu-artwork would conflict with barubuntu-artwork and you could leave ubuntu-artwork as is.
<sladen> jbailey: oh jeeze.  Just write an XPM loader.  Steal it from isolinux/grub/whatever.  It'll be about 20 lines
<jbailey> Diziet: This doesn't *Actually* sound easier...
<Diziet> Doesn't it ?  Compared to racing around with alternatives at runtime ?
<Diziet> rpath is hardly difficult.
<sladen> jbailey: or a PCX loader which isn't much bigger
<jbailey> You still have the same problem that the artwork has to be in and working before the kernel installs.
<Diziet> Come to think of it, are you dlopening it or doing it at executable startup ?
<jbailey> Diziet: At least in this case, you can guarantee a sane startup.
<jbailey> dlopen
<jbailey> The idea was originally to make it so it could take a path.
<Diziet> So you could try dlopen(whateverubuntu) and if that fails dlopen(ubuntu-artwork).
<Diziet> No need for rpath or alternatives.
<Kamion> I don't think we can encode the names of all possible Ubuntu derivatives into usplash!
<Diziet> Just make the whateverubuntu-artwork packages put the file in a fixed overriding location.
<Diziet> k: No, you misunderstand.
<Kamion> oh, fixed override, sure
<Kamion> though then kubuntu-artwork-usplash and edubuntu-artwork-usplash would have to conflict - but that's not *so* bad
<jbailey> Diziet: Keep in mind that a company IT admin might want to add their own branding to this.
<jbailey> Diziet: So it has to be 3 layers.
<jbailey> (Isn't this the problem that alternatives were *designed* to solve?)
<Diziet> jb: So they can edit the edubuntu-artwork package locally.
<jbailey> No, why should they have to?
<jbailey> They should be able to load a localised branding package on top.
<jbailey> IF they edit packages, they lose upgrade ability.
<Diziet> No, alternatives are for if you want to have multiple things installed at once and have a name the refers to the sysadmin's local default.
<Diziet> It makes no sense to have multiple usplash screens at once, since only one will ever be used.
<jbailey> Which you do in this case.  Default, Distro branding, local branding.
<Diziet> You don't have boot arguments saying what branding to have today.
<Diziet> If you think that's important have a list and call dlopen on each one.  This is about 5 lines of code and no fighting with complex configuration management.
<sladen> Diziet: that's always a possibility :)
<Kamion> sladen: with respect, no it's not
<Kamion> I'm not going to hack that sort of horribleness into the installer
<Kamion> (boot args)
<jbailey> Well, more to the point, I don't see what problem it solves.
<infinity> jbailey : Local branding can be done with dpkg-divert.
<jbailey> infinity: All of the gnome branding works by just dropping files in place that are preferred over the regular ones.
<infinity>  /etc/usplash/override-splash.so
<jbailey> Yeah.
<infinity> (not like it's easy to override until that .so becomes a .png anyway)
<jbailey> (ew... You suggested a sofile in /etc)
* fabbione takes a break from install tests
<infinity> So almost no one will do it.
<apokryphos> \sh_away: that SUSE userlist theme, btw: giannaros.org/SUSE 
<infinity> jbailey : Hey's it's only an .so in name.  I look at it as a PNG with a stub. :)
<Diziet> This is very odd.  This hoary install didn't set up sudo for some reason.
<jbailey> infinity: Oh, it's really not.  pngtobogl converts into an array of numbers.  Basically, you're loading in a struct with the image in it.
<jbailey> Diziet: No root for you!
<sladen> Diziet: is it %admin vs. explicit users in /etc/sudoers?
<infinity> sladen : Hard to tell without root to look at /etc/sudoers. ;)
<Diziet> It's a 100% fresh install.  I haven't touched anything.  Maybe I didn't read one of the install questions closely enough but I don't remember there being one about that.
<tseng> is usplash broken universally, or just me?
<Diziet> It set a root password instead.
<infinity> Diziet : Were you in expert mode?
<jbailey> tseng: Depends in which way it's broken.  There are some ways that are known, and others that are specific.
<infinity> tseng : Dexribe your brand of breakage.
<tseng> jbailey: it seems to change vt
<infinity> Describe, too.
<Diziet> inf: No.
<sladen> Diziet: reboot and select (recovery mode)
<tseng> jbailey: then go blank for a bit, then show normal lsb init type stuff
<jbailey> Mm, that's a new one for me.
<jbailey> I think.  It was up for a little bit, right?
<tseng> it was working until yesterday
<Diziet> Oh well, I don't really want to debug hoary now.  The display is crap too - it clearly has no idea how to drive this graphics card.
<infinity> tseng : When was the last time you upgraded, and when's the last time you regenerated your initramfs?
<tseng> infinity: regenerated after 0.1-17
<infinity> tseng : Much goofiness with VT switching and tty* device creation has been going on in the last few uploads.
<jbailey> There's a -17?
<tseng> infinity: it broke after regenerating on -16
* jbailey looks to see what else has changed.
<mjg59> mvo: Go ahead and do the upload
<mjg59> JaneW: Yeah, that's fine
<tseng> -15 work, -16 bork
<jbailey> Dear Scott, please bring us hct soon.
<mvo> jbailey: yes, I uploaded it to get rid of the console-switch flickering
<infinity> Hrm, 16 worked for me, I haven't tried 17 yet.
* infinity tries -17 right now.
<jbailey> mvo: I was only surprised because my working tree was still -14 =)
<mvo> jbailey: that's so 24h ago :)
<Nafallo> hehe
<jbailey> *lol*  Sorry.  Yesterday was evo-exchange, ubuntu-docs, locales troubleshooting, and notification-applet discussion.
<jbailey> I'll try to do better next time. =)
<azeem> Anybody know whether Ubuntu will be present at the Systems expo in Munich at the end of October?
<jbailey> azeem: Unlikely unless a loco team has picked it up.
<jbailey> azeem: With UBZ right after it, I doubt anyone has time.
<Robinho_Peixoto> galera
<mvo> jbailey: heh :) for some reason there is still a problem with the console-font seting. but it's unreleated to usplash it seems, fgconsole --next has only two terminals. do you have any idea about this (assuming it's something with our different early boot stuff)
<azeem> who is in charge of the german LoCo team?
<mvo> azeem: dholbach is probably a good person to talk to and smurfix
<jbailey> azeem: (We have a similar expo here in Montral, but I will be in minisprint with doko)
<Nafallo> azeem: https://wiki.ubuntu.com/LoCoTeamList
<jbailey> mvo: I don't, sorry.  I've never looked into how the whole console font thing works at all.
<Kamion> Diziet: the timezone error probably caused the debconf priority in the installer to be dropped so that you ended up in expert mode, and then you were asked for a root password, which makes the installer decide you probably didn't want to have sudo configured. #9832 coupled with the same kind of thing as #7694.
<Diziet> Oh, yes, the installer did stop being wizard-like.
<mvo> jbailey: thanks. I'll dig into it (sigh) 
<Diziet> That's what you mean by expert mode.
<Diziet> It makes sense now.
<Kamion> Yes, I think that's probably a bug but one has to be a little careful when fixing it because the debconf-priority-dropping is critical to avoiding infinite loops in some cases.
<Kamion> (it means you at least end up at the main menu on error, rather than repeatedly trying the same menu item and failing)
<segfault> In the logout screen of GNOME, which package stores the "Hibernate the computer" string?
<ogra> segfault, gnome-session
<ogra> Kamion, i can confirm 15244 also with a normal X tunnel after logging out and in again...
<ogra> ogra@edubuntu:~$ pgadmin3
<ogra> Error: Unable to initialize gtk, is DISPLAY set properly?
<ogra> updating the bug now
<segfault> thanks.
<Kamion> ogra: you're in a far better position to debug it than I, I expect
<ogra> Kamion, i have no clue about ssh internals 
<ogra> but i'll try
* Kamion writes a program to simulate running libparted over somebody's disk
<\sh> ogra:  want to have a di-524 wlan router? ,-)
<Diziet> So this artwork homepage bug.  Who knows what the new filename is ?
<Diziet> And is there any explanation for why it has to change ?
<ogra> \sh, do you change against a aspire 1520 keyboard without altgr key ? just ordered a new one (3 weeks shipping time :((( )
<\sh> ogra: u give up your acer?
<ogra> \sh, then i wouldnt order a new keyboard for it
<\sh> ogra: Oh it sounds like u ordered a new laptop ,)
<ogra> \sh, but probably i'll do that too... to have something thats lighter than 4kg for travelling :)
<\sh> hmmm...do we have an ubuntu booth on the systems in munich?
<Diziet> jbailey: ping
<\sh> ogra: read the announcement of the 100 $ laptop? mako mentioned it, when he moved to his new location :) it's real ;)
<jbailey> Diziet: pong
<Diziet> jbailey: You say you've made me an html file, but what's its filename ?
<Diziet> And are you the person who removed it from ubuntu-artwork ?
<Nafallo> ogra: wow. you laptop is even heavier than mine :-P.
<ogra> Nafallo, desktop replacement...
<ogra> but annoying to travel with...
<Nafallo> indeed
<Nafallo> 3,6KG here
<pitti> ah, \sh: you touched ntlmaps last
<jbailey> Diziet: No, it was jdub who removed it.  The file isn't in your current ubuntu-docs package, I wired it up while we were talking this morning.
<jbailey> Diziet: Lemme grab the filename.
<pitti> \sh: the changelog says you merged ubuntu changes, but there are no ubuntu changelogs
<Diziet> So why did jdub remove it ?
<Diziet> And why is the filename changing ?
<pitti> \sh: can you please look into this and either sync or merge the new Debian version to fix CAN-2005-2962?
<Diziet> Can't you not change the filename ?
<jbailey> Diziet: We only share a name, dude...  Peering into his thoughts requires possibly more alcohol then I have handy.
<\sh> pitti: ntlmaps?
<Diziet> jb: :-)
<\sh> pitti: yeah will do
<pitti> \sh: thanks
<jbailey> Diziet: Sure.  It's just that it exists in ubuntu-artwork's space, so it would be a bit weird.
<jbailey> IIRC It's /usr/sahre/doc/ubuntu-artwork/ or something like that.
<pitti> \sh: please don't trash changelogs on merging, otherwise it is hard to decide whether we can sync
<\sh> pitti: I learned it not to drop it anymore :(
<Diziet> jb: Um, I think stable names for files are more important than some bureaucracy to do with who owns which namespace.
<Diziet> What boggles me is that he seems to have just deleted this file without really thinking that perhaps he should talk to anyone about it.
<Diziet> So I assume someone must have talked to him about it, or he wouldn't have done it.  But who ?
<jbailey> Diziet: Oh, I don't mean to be bureaucratic.  I just don't feel like fending off the lartings without support from someone else. =)
<mdke> Diziet, i saw the discussion
<Diziet> mdke: Oh, there was discussion ?
<ogra> Diziet, it struck me heavily too yesterday...
<mdke> Diziet, yes, it was when sabdfl rewrote the document,
<ogra> (edubuntu-artwork replaces this file)
<Diziet> mdke: Right ... and that meant it had to move package because ... ?  And move filename because ... ?
<Diziet> And was there any explanation for them not communicating with anyone ?
<mdke> he expressed surprise that the same doc was in multiple places
<Diziet> Or were we just supposed to be hanging around on IRC ...
<Diziet> I didn't know it was in multiple places.
<ogra> Diziet, obviously :)
<jbailey> Diziet: Hanging out on IRC is part of our jobs, mind you.  We're just never permitted to leave =)
<mdke> the discussion was not totally full iirc
<ogra> (but i hang around 24h here and didnt see the discussion)
<mdke> and it was not in this channel
<mdke> it was in -doc
<jdub> pitti: pong
<mdke> ah good
<Diziet> The scrollback is less than informative.
<Diziet> Ah, not in this channel.
<ogra> imho a mail to -devel would have been nice
<mdke> jdub, i was trying to explain the absence of about-ubuntu oin the artowk package, you remember the discussion?
<Diziet> Well, I don't hang around in -doc.
<Diziet> Ah, jdub, hello !
<ogra> me neither
<jdub> mdke: yeah
<jbailey> But there's fun and excitement in there!
<jbailey> All the cool kids are doing it...
<Diziet> jdub: So can you explain what was done and why ?
<jdub> Diziet: the about ubuntu html is no longer shipped in ubuntu-artwork, it's built and shipped as part of ubuntu-docs
<Diziet> And why no-one mailed ubuntu-devel with a quick not to tell us what to expect :-).
<pitti> jdub: the last u-artwork package seems to make Breezy fall apart into pieces
<Diziet> jdub: By `is' you mean `will be'.
<pitti> jdub: the usplash artwork is missing as well
<infinity> jbailey / mvo : Either of you doing a usplash update in the next while?
<Diziet> Since it's not currently on anyone's system.
<jdub> Diziet: it is done that way because there's no point maintaining it in two places, and it's owned by the doc team
<Treenaks> hm, EKEYBUK
<jbailey> infinity: I need to.
<ogra> pitti, not here
<Diziet> Certainly I don't mind which package it's in.
<jbailey> infinity: It's just not obvious to me what update to make atm.
<jdub> pitti: ubuntu-artwork has never owned the usplash artwork, so if jbailey's depending on me to put it in, then i need to know about it ;-)
<pitti> jdub: oh, ok
<infinity> jbailey : Can I get you to patch mvo's chvt magic a bit, to get rid of one icky case of text flicker?
<Diziet> jdub: Well, wasn't it in a previous version of ubuntu-artwork ?
<jdub> pitti: i was of the understanding that usplash had the ubuntu artwork in it by default
<jdub> Diziet: yes
<Diziet> So you just deleted it.
<ogra> pitti, reconfigure your linux-image ;)
<jdub> Diziet: if you mean the about ubuntu html
<jdub> Diziet: yes
<jbailey> infinity: Sure, mind sending it by email?  This channel is a bit fast paced at the moment to track TODOs here.
<pitti> ogra: that didn't help
<ogra> oh
<ogra> helped here
<jbailey> pitti: Eh?  usplash contains the default ubuntu artwork.
<Diziet> I see.  Did it occur to you that something might be using it ?
<pitti> jbailey: ah, I had to call update-alternatives for the artwork file
<jdub> Diziet: i knew very well that it was the default homepage, that was its entire purpose in life
<pitti> jbailey: one of the recent updates broke the alternatives link
<pitti> jbailey: (I wasn't the only one)
<Diziet> Right.  So you deleted the default homepage.  How were you expecting the default homepage to still be provided ?
<jbailey> pitti: The usual problem is that the kernel installed before the update-alternatives ran in the the usplash postinst.
<jdub> Diziet: by ubuntu-docs
<jbailey> pitti: Did you still have to run it yourself after?
<pitti> jbailey: I see
<Diziet> So of course you edited ubuntu-docs to make it provide it ?
<pitti> jbailey: yes, I had; without running it, reconfiguring the linux image didn't help at all
<jdub> Diziet: no - jbailey maintains ubuntu-docs
<jbailey> Diziet: Objection leading the witness, when he clearly did not. =)
<jbailey> pitti: Argh.
<Diziet> So you just decided you'd break it, not tell anyone, and leave the rest of us to figure it out ?
<Diziet> Can you tell yet that I'm annoyed ?
<seb128> slomo: ?
<jbailey> pitti: Do you still have a system in that state?  I'd love to know why the usplash postinst didn't do it?
<jdub> i'm not sure your 50 questions method is really very useful when the answers are pretty obvious, and we can just get on with our lives and fix things
<pitti> jbailey: btw, is it really the right thing to manually reconfigure the linux image to update the ram disk? can't some postinst do this automatically?
<Diziet> So another question: why does the filename have to change ?
<pitti> jbailey: no, unfortunately I already updated-alternatives
<infinity> mvo : What's your one outstanding bug with console setup?
<infinity> mvo : I'm touching that area right now, so maybe it'll jump out at me.
<torkel> jbaily: shouldn't the eq in 'dpkg --compare-versions "$2" eq 0.1-12' in usplash.postinst be a ge?
<Diziet> My point with the 50 questions is to try to suggest that there might be less, erm, confusing, ways of going about things.
<jbailey> pitti: Ther'es an update-initramfs tool, but it requires that it was used to create the alternative in the first place.  The kernel folks weren't comfortable with dropping it in after preview, so it's deferred until dapper.
<ogra> Diziet, just more communication is enough
<jdub> Diziet: perhaps saying, "hey, there are less confusing ways of doing things" would have been more effective communication
<jbailey> pitti: For amusement you can call "update-alternatives -u -t".  The -t is for "takeover" (as in, don't care  that I didn't make t his).  Just -u works after that.
<jdub> regardless, we break and fix, it's not like it's a crisis
<Diziet> Well, I didn't want to diss you until I'd heard your excuse.  Anyway, I've made that point.
<Diziet> Thank you.
<Diziet> What about the filename ?
<Diziet> I think the filename should not change.
<pitti> jbailey: ok, so Dapper won't require us to manually build the ram disk any more? nice
<ogra> Diziet, i was trapped several times by such things in this release cycle, i think we should have a BOF at UBZ to sort out such things in advance for dapper
<jbailey> pitti: Right. =)
<jbailey> pitti: And in fact, the idea is that tools that involve the initramfs can just do the updates themselves all they want and safely.
<jdub> Diziet: that's up to jbailey - perhaps a symlink to the /u/s/doc location would make sense
<jbailey> pitti: It does a sha1sum check to make sure the user didn't alter the file without the tool.
<Diziet> jdub, jbailey: Are you both happy that ubuntu-docs can ship the file at its previous location ?
<jbailey> Diziet: Sure.  Am I shipping the old file, or the HTMLized about-ubuntu?
<pitti> Diziet: this is almost a requirement, given that we can't change user profiles
<jdub> jbailey: html-ised about ubunut
<jdub> jbailey: a symlink would do it
<ogra> jdub, there is a logo in the html file...
<ogra> that needs to be placed properly then
<jdub> ogra: hmm - if it's a directory symlink, that's no problem; if it's not a directory symlink, the logo would have to use a fully qualified path - that might be
<ogra> yup
<pitti> seb128, _mvo_: I moved cdrdao into the "Approved, but not yet ready to promote" queue
<Robinho_Peixoto> pitti: and the update-manager. This don't has in Rosetta
<jdub> jbailey: whatcha think?
<seb128> pitti: why "not ready to promote"?
* jbailey checks what the directory is.
<pitti> seb128: it needs to be germinated
* Diziet returns from phone call.
<pitti> seb128: i. e. either a reverse-dependency or a seed
<seb128> pitti: right, every package does
<Diziet> jb: You should ship whatever file ought to be the default startup page.
<seb128> pitti: you said that like it was a special case :)
<pitti> seb128: in this case we should seed it, a dependency does not make sense (this is more for libs)
<infinity> mvo : unping, I found your problem in backscroll, looking into it now.
<seb128> pitti: agreed
<_mvo_> infinity: my problem?
<mvo> infinity: sorry, my network is playing silly bugger
<jdub> http://news.com.com/Ubuntu+carves+niche+in+Linux+landscape/2100-7344_3-5886194.html
<Treenaks> carves?
<Treenaks> not blasts?
<jdub> haha
<jbailey> carved with a pile driver.
<jbailey> It's a different sort of art.
<Treenaks> jbailey: yay artwork-team
<bddebian> Heh
<ogra> jdub, bah, they mention ltsp but not edubuntu... boycott !
<lamont-away> Setting up scrollkeeper (0.3.14-10ubuntu1) ...
<lamont-away> Rebuilding the database. This may take some time.
<lamont-away> //usr/share/gnome/help/about-ubuntu/C/about-ubuntu.xml:5: I/O warning : failed to load external entity "/usr/share/gnome/libs/global.ent"
<lamont-away> %globalent;
<lamont-away>            ^
<lamont-away>  %globalent; 
<lamont-away>             ^
<lamont-away> neato
<jbailey> lamont-away: Known bug.
<mjg59> Could anyone with working laptop suspend who hasn't already done so email me the output of dmidecode?
* jdub grimaces at some of the message selections in there
<jbailey> mjg59: To which address?
<jbailey> do you have an @ubuntu.com yet?
* lamont-away wonders where xorg...-73 is...
<mjg59> Nope
<mjg59> mjg59@srcf.ucam.org is good
<jbailey> mjg59: Is it worth notign that I had to enable it in /etc/defaults/acpi* to see it in gnome?
<pitti> jbailey: I thoughth the latest libc would support Kurdish locale now?
<jbailey> pitti: Remind me the locale string of it?
<pitti> jbailey: ku_SOMETHING
<pitti> jbailey: what I aim at is that there is no ku_* in /usr/share/i18n/SUPPORTED
<mjg59> jbailey: No, that's normal
<mjg59> jbailey: And it works fine?
<jbailey> mjg59: Yup.
<jbailey> mjg59: I used it all through UDU even.
<Treenaks> mjg59: what info did you and keybuk need for the isapnp junk on the 380ed (re: crystal sound)
<wasabi_> hey jbailey, i was thinking about something else that would be cool in the init scripts. I think I'll work on it this weekend.
<wasabi_> root=/dev/hda:/root.img   
<jbailey> pitti: Can you add a note to that effect to 13871 ?
<ogra> jdub, how does Sam Pohlenz get into that interview ? 
<mjg59> Treenaks: The contents of /sys/bus/pnp/devices/*/id would be good
<jbailey> wasabi_: You know that random changes are not-for-breezy at this point, yes? =)
<wasabi_> Oh sure.
<mjg59> Treenaks: But I suspect that it's not going to be complete
<jbailey> Oh good. =)
<wasabi_> But I want to implement it anyways. ;0
<Treenaks> mjg59: that's in the bug already
<wasabi_> Just wanted to see what you thought about it.
<mjg59> Treenaks: Yeah
<wasabi_> Since you're in that space a lot.
<jbailey> wasabi_: So explain to me what this does?
<Treenaks> mjg59: I'm going to do a -current install on it
<lamont-away> seb128: you around?
<Treenaks> mjg59: (*zzz*)
<lamont-away> gtk-smooth-engine
<wasabi_> The idea is to mount / as a loopback file on another fs. My specific use case is for my embedded flash system.
<wasabi_> I want to be able to "flash" the system with a new image, and I want it to be as simple as on a Cisco or something. 
<wasabi_> You just drop a new .bin file into a directory on the flash disk and reboot.
<jbailey> wasabi_: Okay.  Try hooking that in /usr/share/initramfs-tools/scripts/local-top
<wasabi_> Also prevents the scattered writes that would be caused by upgrading it by extracting an entire file system.
<wasabi_> Which is hard on flash.
<jbailey> Right.
<jbailey> The trick is going to be that you'll need to somehow feed back an altered root variable.
<seb128> lamont-away: yeah, I'll do that now
<wasabi_> Yeah, I'm very unsure how that works. ;)
<lamont-away> danke
<jbailey> wasabi_: Well, right now it doesn't.  You're in a subshell.
<jbailey> I didn't want all of the variables from everyone's scripts messing things up.
<wasabi_> The pivot_root process is pretty unknown to me.
<jbailey> wasabi_: So instead, maybe set root= to something like /dev/loop0 and just set that up?
<jbailey> There's no pivot_root anymore. =)
<pitti> jbailey: ah, sorry, the Kurdish locale was about installing belocs, not adding to libc locales
<wasabi_> Oh.
<jbailey> pitti: Right.
<jdub> ogra: who *is* sam pohlenz?
<jbailey> pitti: BTW, I added your name to LocalesThatDontSuck
<wasabi_> Yeah, good idea.
<jbailey> pitti: For a UBZ bof. =)
<ogra> jdub, my SoC student...
<wasabi_> root=/dev/loop0 loop0=/root.img loopfs=/dev/hda
<wasabi_> something like that
<jdub> ogra: aha
<pitti> jbailey: thanks, I don't want to miss that
<jbailey> pitti: I need to fill in the details, but we have two conflicting proposals.
<Treenaks> wasabi_: sounds UML-ish
<jbailey> pitti: 1) Use belochs.  2) Feed belochs into rosetta, and use rosetta.
<ogra> jdub, he wrote a 100 line pygtk tool to load win drivers into ndiswrapper
<jdub> ogra: yeah, well, supposedly i'm "head" of b&cd :-)
<ogra> heh
<ogra> i love well researched articles
<ogra> lol
<jbailey> wasabi_: Right.  It's easy enough to get those variables out.
<jdub> ah, it was easy to misinterpret
<wasabi_> Cool.
<jdub> i only did the interview with stephen last night
<wasabi_> That'll be neat to have built in.
<jdub> i just don't want jane to drive over me in her tank
<jbailey> wasabi_: And then the only thing you have to do is setup that the root device is mountable in local-top
<wasabi_> Yeah.
<jbailey> wasabi_: You can do that all without altering initramfs-tools in anyway.
<wasabi_> Yeah, just some additional local-top scripts
<wasabi_> what does local-top stand for anyways?
<jbailey> And in fact if you're quick, clever, and beg ogra and dholbach, you might be able to do it for breezy. =)
<pitti> jbailey: you mean like ship the locales itself into the langpacks? Highly interesting and flexible idea
<wasabi_> jbailey, it's not totally useful without ro file system support.
<pitti> jbailey: although installing a locale should not require installing the langpack
<jbailey> wasabi_: There are two layers of hooks.  The init- series, which is always run for everyone.  Then the local- and nfs- series which is run depending ont he mode you select.
<wasabi_> Hmm. Mode?
<wasabi_> How do you change modes?
<jbailey> wasabi_: Change the BOOT= line in /etc/mkinitramfs/initramfs.conf
<jbailey> wasabi_: But they're just sourced in scripts.  You could write your own without altering the initramfs-tools package.
<wasabi_> oh interesting... never saw this file.
<wasabi_> Yeah agreed.
<jbailey> wasabi_: So each of those then has hooks where you can just drop things and expect it to work.
<wasabi_> That's pretty neat.
<jbailey> pitti: Right.  We could generate the entirety of locales from the rosetta export, though.
<pitti> jbailey: yes, that'd rock
<jbailey> The only place where I don't like the idea is in a place that doesn't matter for us: Default character encoding.
<wasabi_> I'll get this working, then figure out someway to do unionfs or other fake-writable support.
<jbailey> Since we set it to utf-8 for everyone, we've pretty much sidestepped the question.
<pitti> doko: I gave ooo1 on ppc a quick test. All apps start and don't entirely fall apart into pieces; anything I should check for in particular?
<jbailey> wasabi_: Right, ask mdz about unionfs love.
<wasabi_> I'm interesting in getting this working, allowing a rw file system, and then having a save script which saves only certain files in /etc.
<pitti> jbailey: yes, and we should aim to get rid of non-UTF-8 locales whereever possible
<jbailey> wasabi_: But *afteR* breezy releases. =)
<wasabi_> For an embedded firewall for instance.
<wasabi_> You'd save specific config files, but reload the rest from scratch
<jbailey> pitti: I'm not convinced that's correct for most places in the world, but it's a vision I can buy into. =)
<doko> pitti: maybe open a document you did save with OOo2 in the OpenDocument format, but nothing more.
<pitti> doko: alright, will do
<infinity> mvo : Dude, I'm looking for those missing VCs, and I can't figure out WTF...
<jbailey> wasabi_: For extra fun, remember that cpio.gz files can be overlayed.
<infinity> mvo : I'm trying to figure out if I should blame jbailey (cause that's fun in general), or sysvinit (which is responsible for spawning them..)
<jbailey> wasabi_: So you can ship a generic piece, and then a configuration file on top of it for choosnig the image.
<wasabi_> Woh.
<wasabi_> Yeah... also, you could allow third party addons
<jbailey> So you can switch root images cheaply.
<wasabi_> But overlaying an addons/ dir
<wasabi_> by
<wasabi_> Or something nifty.
<jbailey> What bootloader does the device use?
<wasabi_> grub or lilo. it's a regular PC.
<jbailey> Lovely.  The hack you want to make this sexy is about 15 lines to grub. =)
<wasabi_> I just need to find some mini-itx board or something which supports ECC ram.
<wasabi_> Because I think that it needs at least that.
<jbailey> mini-itx boards are frigteningly expensive.
<jbailey> And all the ones I've looked at recently still have VGA on them.
<jbailey> Kinda annoying.
<wasabi_> Yeah that's unfortunate.
<wasabi_> Well, I'm building a variaty of little devices for this company.
<jbailey> Ah, cool.
<wasabi_> First the presentation thing, second probably a firewall.
<jdub> oh, we are on the front page of news.com.com too
<mvo> infinity: right, thanks! I banged my head against it this morning too, I have no clue right now
<wasabi_> We have a ceiling mounted projector, I'm setting a mini itx case with it up on the ceiling.
<wasabi_> no fan, no hd
<mvo> infinity: I think iz gtk bug
<jbailey> wasabi_: Ah, cool.  On ubuntu?
<wasabi_> Yup
<wasabi_> It'll boot, and display a "choose the computer you want to see" list from the interface
<wasabi_> And anybody can remote to their own desktop
<jbailey> jdub: wasabi might have a success story for you.
<wasabi_> Not yet. ;)
<infinity> mvo : I wish. :)
<wasabi_> My first big task with it will be getting it working with bluetooth in some way.
<wasabi_> So the CEO and sales can walk into the conference room, and have their computer name pop up on the projector, and just choose it.
<wasabi_> and see their desktop
<wasabi_> laptop, bluetooth, etc.
<zyga> re
<zyga> artwork-people: neat background :)
<Diziet> OK.  I now know where to change firefox so that we can have a translated start page.
<wasabi_> jbailey, http://www.logicsupply.com/product_info.php/cPath/79/products_id/444    cute little rack mount
<Diziet> These translations are in langpacks, aren't they ?
<pitti> doko: I tested ooo2 -> ooo1 with .odt: three fonts, various formatting, a picture; works flawless
<Diziet> Anyone familiar with langpack stuff here ?
<zyga> Diziet: pitti should be :)
<pitti> Diziet: that's mine, mine, mine!
<zyga> pitti: yourrr precioussss
<zyga> ;] 
<Diziet> Right.  So.  The file /usr/share/ubuntu-artwork/home/index.html is going to be part of ubuntu-docs.
<pitti> Diziet: there are no translations of the ffox start page ATM
<jbailey> I was more thinking the seagulls from Finding Nemo. =)
<Diziet> I have a scheme in mind for supporting translations.
<jbailey> pitti: There are. =)
<Diziet> It works like this:
<Diziet> You put a translation of this file in the relevant langpack, called /usr/share/ubuntu-artwork/home/index-LOCALE.html
<doko> pitti: I didn't do more on i386 as well. that should be sufficient.
<pitti> Diziet: where do I get them from?
<Diziet> Well, translators translate things, right ?
<pitti> doko: ok, thanks; glad to get to know your extensive and sophisticated hard test suites :-)
<jbailey> Diziet: They're in rosetta as ubuntu-docs package, pofile about-ubuntu
<zyga> pitti: I'd love to contribute index-pl.html for you
<Diziet> I don't understand how all that stuff works, but you must have ways of getting stuff from translators.
<Diziet> Sorry, I don't mean they want to go into langpack-nl.
<Diziet> They want to go into mozilla-firefox-locale-nl-nl
<pitti> Diziet: we don't touch these automatically ATM
<pitti> Diziet: for now, just putting them into ubuntu-artwork as well wouldn't be too wrong, would it?
<Diziet> And the file /usr/lib/mozilla-firefox/extensions/{83532d50-69a7-46d7-9873-ed232d5b246b}/chrome/nl-NL.jar (!) contains a member locale/browser-region/region.properties which should be changed too.
<jbailey> Diziet: They can only really come from ubuntu-docs for now.
<Diziet> Yes, unfortunately having firefox automatically find these files at runtime is quite hard.
<jbailey> Diziet: All the stuff is stored in there, it's not langpack driven right now.
<doko> pitti: dude! ;-)
<wasabi_> wonder what the best way to create/maintain this flash based image is.
<wasabi_> guess a chroot.
<zyga> pitti: that can be a symlink right?
<Diziet> The reason it has to go into the same package, mozilla-firefox-locale-nl-nl, is so that the correct start URL can always be provided.
<Diziet> The start URL is in that package.
<zyga> pitti: ah - no wait - it's per-user
<Diziet> That is, if you run in the nl locale, you get the start page from that package instead of the one in firefox.
<jbailey> Diziet: What about people who use multiple langpacks and locales on the system.
<Diziet> That's OK.
<Diziet> It'll work just right.
<jbailey> My wife and I share a computer and don't use the same language.
<pitti> Diziet: right, I know, but for now we manually have to update all the m-f-locale-* packages
<Diziet> If the translated document lives together with the configuration in the right .jar in the right -locale- package.
<pitti> Diziet: well, actually, luckily there is m-f-locale-all, so it's only one source package
<pitti> Diziet: and there is already a script in debian/rules which updates the start page
<Diziet> Which takes tarballs from rosetta, or something ?
<pitti> Diziet: should be easy to adapt that to per-lang
<pitti> Diziet: no, it's not connected to Rosetta right now - we plan that for Dapper
<Diziet> Ah.
<jbailey> Diziet: Does epiphany also inherit that same thing?
<Diziet> Right.  So the question remaining is, do we want to try to support this for breezy at all ?
<Diziet> jb: I don't know.
<Diziet> It may be that epiphany reads a different file.
<Diziet> In which case firefox would see the right one and epiphany the English one.
<Diziet> The main question I suppose is do we have the ability to get enough translations done, and incorporated, to make it worth faffing with the  machinery in m-f-locale-all ?
<Diziet> jb: Have you uploaded that new ubuntu-docs yet, BTW ?
<jbailey> Diziet: I have 28 translations of about-ubuntu
<pitti> mvo: ping
<Diziet> And that's the file we're using for English ?
<jbailey> Diziet: No, because I'm not clear that everyone has agreed on the right thing.
<Diziet> OIC.
<jbailey> Diziet: That's the file that jdub has asked me to use.
<mvo> pitti: pong
<Diziet> Right.  Is that the one that sabdfl rewrote ?
<janimo> jbailey, is usplash+pluggable artworks going ahead?
<infinity> mvo : Debian #271013
<pitti> mvo: in the update notifications, will "Description-pt_BR" work?
<jbailey> Diziet: Not that I see.
<mvo> pitti: yes
<infinity> mvo : That's the bug, and it's nothing new, apparently.
<Diziet> jb: So we have a disagreement between jdub and sabdfl, or what ?
<jbailey> janimo: I'm also not clear where that ended up.
<infinity> mvo : init fires up the consoles AFTER it runs the init scripts, not before.
<jbailey> Diziet: Where I think that it's left is that you were trying to figure out how to make FF find the translated files by default.
<jbailey> Diziet: If you have a way, I'll upload all te translations.
<wasabi_> jbailey, how are kernel parameters accessed from these scripts?
<jbailey> Diziet: If not, then I will upload English only.
<wasabi_> I notice the use of the ROOT env var
<Diziet> Right.  I know how to do that, but the translations have to be in the m-f-locale-all package.
<wasabi_> Are they all exported like that?
<jbailey> wasabi_: Look at init-top/usplash
<jbailey> Sorrry, scripts/init-top/usplash
<mvo> infinity: gosh, 1y old? 
<jbailey> wasabi_: Only special ones are extracted for common use.  You can fetch your own this same way.
<pitti> fabbione: what is "Language pack reorganization" on Italic?
<jdub> jbailey: the html output of the doc team's about ubuntu (which is what mark wrote) is what should be used
<infinity> mvo : Well, the bug is older, that's just the first one filed. :)
<Diziet> Because m-f-locale-all contains a file which specifies statically the start URL.
<jbailey> wasabi_: If you're feeling extra sexy, please feel free to write a function to extract them in a pretty way.
<infinity> mvo : It's always been like this, this isn't a regression.
<infinity> mvo : It's just "the way it is".
<Diziet> We can easily make m-f-locale-all generate the file right depending on whether there's a translation at build-time.
<infinity> mvo : So, it's hardly a breezy blocker, though irritating.
<Diziet> But it's much harder to make all this happen on the user's system at runtime.
<jdub> Diziet: that'd be kinda cool, but if it's too hard, don't worry about it
<wasabi_> Ahh, proc command line.
<jbailey> jdub: Ah, okay.  I didn't know who wrote it. =)  All I have is what's sitting int he breezy branch of the docteam's svn. =)
<jdub> mdke: around?
<wasabi_> Might make sense to have them all exported as env vars by default, no?
<jbailey> So there's just the upload all of the translations, or just the English question left.
<jbailey> And then I'll send 'er off.
<jbailey> (Well, I'll fix some other bugs on the way first, probably)
<infinity> mvo : If we're willing to assume our users don't mess much with /etc/inittab, I can just do the console setup on vc1 through vc6, without first verifying that the consoles exist.  It doesn't hurt anything, and when getty spawns, the console should be in UTF-8 mode.
<Diziet> jb: Um, did you see what I said up there ^ ?  These translations are currently in ubuntu-doc, you say ?
<Diziet> But I'm saying they have to be in m-f-locale-all.
<jbailey> Diziet: I did.  I'm telling you that they're docbook files in ubuntu-docs.
<jbailey> I have no way of getting them into that other package.
<jbailey> Not in any sort of sane way.
<jbailey> And I haven't seen pitti buy into the idea yet.
<jbailey> This is why I haven't randomly uploaded. =)
<mvo> infinity: that sounds good to me, I think we should fix it (even if the fix is a bit hackish)
<jdub> Diziet: doesn't m-f-locale-all just care about urls?
<Diziet> Right.  Just a mo, realconv.
<infinity> mvo : Definitely hackish, but I don't think it'll hurt.
<pitti> mvo: btw, can you please ping me when I can upload the new hal and dbus with the reboot notice?
<infinity> mvo : The flicker will be more noticeable, but I'll test that.
<infinity> mvo : Do you have a bug number for this, or just fixing it cause it drives you batty?
<mvo> infinity: thanks. I have a greek install here that I can use for testing too
<pitti> mvo: btw, I don't know whether you saw yesterday's discussion - can you provide a small wrapper around this?
<mvo> infinity: we don't have a bugnumber for that particular problem, but you could import the deb bug
<infinity> mvo : No point importing it just to close it.
<mvo> pitti: yes, the wraper will be called "notify-reboot-required"
<mvo> infinity: right
<pitti> mvo: so that postinsts merely do "if [ -x /usr/share/u-n/trigger-reboot ]  && /u/s/u/t-r"
<pitti> mvo: ah, nice
<infinity> mvo : Want to mail me some UTF-8 text, so I know my consoles are working as advertised? :)
<pitti> mvo: in /usr/share/u-n?
<mvo> pitti: I can upload it now, but I want to fix some smaller issues along the way
<pitti> mvo: well, if I know the exact path, I can already prepare packages
<mvo> pitti: /usr/bin/
<pitti> mvo: and even upload them
<pitti> mvo: uh, why /usr/bin/? that's not really supposed to be called by admins
<pitti> mvo: erm, users
<Kamion> pitti: say what?
<Kamion> I'd have some difficulty using a system as an ordinary user without using /usr/bin/
<mvo> pitti: right, /usr/sbin/? /usr/share/u-n?
<infinity> Kamion : Shh, English isn't always easy.
<jbailey> infinity: I can forward you korean spam. =)
* Diziet returns.
<Diziet> jb: no sane way> Hmmm, I see, yes.
<seb128> pitti: so dholbach is telling me that you took over gamin and its bugs because you like it? :)
<Kamion> infinity: /usr/share/doc/console-tools/examples/ ?
<pitti> Kamion: "that" == the update notice trigger script
<Kamion> infinity: oh, I thought he was confusing /usr/bin with /usr/sbin
<pitti> seb128: only if he takes firefox
<jbailey> Diziet: For dapper, all of this will be langpack driven.  Martin and I sorted that out yesterday.
<dholbach> hahaha
<dholbach> no :)
<pitti> mvo: I'd prefer /usr/share/u-n
<seb128> pitti: deal
<jbailey> Diziet: I even now have a basic script that does the extract and generates all of the needed pieces.
<Diziet> jb: Right.
<mvo> infinity: send you some nice 's
<dholbach> simple question, simple answer :)
<seb128> dholbach: you won firefox
<Diziet> m-f-locale-all does indeed only care about URLs.
<seb128> pitti: you won gamin
<jbailey> 
<seb128> seb128: you won some sleep :p
* infinity boggles at the file in /usr/share/doc/console-tools/examples/ that appears to be named after musical notes...
<Kamion> infinity: try http://www.cl.cam.ac.uk/~mgk25/ucs/examples/UTF-8-demo.txt
<Diziet> But we can't just have m-f-locale-all generate those URLs for every language because we'd have to keep them in synch.
<infinity> I haven't the first clue how to type or tab-complete that...
<Diziet> I mean, the list of translations.
<Kamion> infinity: that's why there's a README.strange-name in the same directory :)
<Diziet> Oh, just a mo, here's an idea:
<pitti> seb128: but you know that I then will replace gnome with fvwm, OOo with latex, nautilus with mc, and X with a nice fb console? :-)
<Diziet> This file (the index.html) is quite small.
<jbailey> Diziet: Right, this might be unsolvable in this timeframe.
<Diziet> And we could use symlinks.
<Diziet> Here's my idea:
<HiddenWolf> mvo, is xscreensaver your package?
<infinity> Kamion : Ahh. ;)
<pitti> seb128: talking to yourself?
<jbailey> Diziet: FF could also do with some hacking to make it do language negotiation on file:/// URIs
<Diziet> We make a complete list of all locales we've ever heard of.
<seb128> pitti: GetRideOfTheDesktop? :)
<Diziet> jb: You must be joking.
<seb128> pitti: yeah, that's friday :p
<pitti> seb128: exactly
<Diziet> Then, we have the m-f-locale-all package always rewrite the homepage URL to include the locale, iff the locale is in that list.
<Diziet> And we have the ubuntu-docs package provide _all_ of those files for every locale.
<Diziet> If there is no translation, it provides a symlink to the English.
<pitti> Diziet: see? breezy's design is hopelessly deprecated even before it is released :-)
<wasabi_> jbailey, what is the appropiate place in the initramfs to mount to device that holds the image? Is there a /mnt or what?
<jbailey> wasabi_: ${root}, I think. =)
<infinity> Hrm.  Our default console faunt is pretty shit for UTF-8...
<infinity> faunt?
<infinity> font.
<wasabi_> ${root}?
<Diziet> Since this design is ephemeral, for this `complete list' we could just take the list of translations that are currently available plus a few that look plausible, or something, and copy it about manually this once.
<infinity> Wow, what happened there, I wonder.
<mako> \sh_away: the $100 laptop isn
<pitti> infinity: sure that you started unicode_start?
<mako> \sh_away: the $100 laptop isn't real yet.. but it has a design and work is certainly progressing on it here
<wasabi_> I thought ROOT was the path to /dev/loop0
<wasabi_> I mean, the temporary fs, holding the .img file itself.
<jsgotangco> hey mako nice seeing you again
<lifeless> mako: ola
<lifeless> how you going
<jbailey> Lemme look, I might be confused.
<Diziet> jb,pitti: What do you think of this plan ?
<infinity> pitti : Yes.
<Kamion> infinity: you can only have 512 glyphs in a console font, so we can't really win
<infinity> pitti : Perhaps my using a vesafb has something to do with it using a sucky font?
<infinity> Kamion : Oh.  Then why do we even care about unicode consoles?
<Kamion> (according to Denis Barbier in $some_bug_I_forgot)
<infinity> Kamion : I get pretty much zero codepoint coverage here.
<Kamion> infinity: the installer attempts to pick a sensible-ish font depending on your language
<pitti> Diziet: that sounds sane; in fact that's what I planned with carlos :)
<infinity> mvo : We may be fighting a losing battle here.
<jbailey> Diziet: So does ubuntu-docs still provide the base translations?
<Kamion> we have to care about Unicode consoles because we only install a Unicode locale by default
<Diziet> jb: `base' translations ?
* infinity just makes the changes to make all the consoles properly unicode, and gives up caring that the font is still useless.
<jbailey> Diziet: Sorry, the about-ubuntu translations?
<Diziet> Yes.
<jbailey> Cool.
<jbailey> Then if Martins happy, just lemme know where I should stuff 'em.
<mvo> infinity: oh crap :/
<Diziet> jb: We need a list of the translations that you (a) have now or (b) might have for breezy.
<mako> jsgotangco: hey there! :)
<mako> lifeless: i'd like to talk to you
<lifeless> mako: sure
<pitti> mvo: so, /usr/share/update-notifier/notify-reboot-required ?
<Diziet> Then for each locale LOCALE in that list, provide a file /usr/share/ubuntu-artwork/home/index-LOCALE.html which is the translation if it exists or a symlink to the English if it doesn't.
<Diziet> Can you do that nicely ?
<spayne> yo all
<Diziet> And then pitti changes m-f-locale-all to contain a copy of your list in its source, and it writes those URLs into the region.properties files.
<Diziet> Are you with me ?
<pitti> Diziet: sounds fine
<ogra> erm, how do i go with my derivative artwork package then ?
<jbailey> Diziet: Yes.
<ogra> that means i need to replace *all* m-f-locale packages for edubuntu ? 
<jbailey> Diziet: I think the translations are largely fixed now, mod post-Breezy updates.
<wasabi_> Hmm. Done. Heh.
<wasabi_> Now to test somehow.
* wasabi_ starts vmware
<wasabi_> Oh, how do I get losetup into the initramfs?
<Diziet> ogra: Um, why ?
<jbailey> You need a hook script!
<pitti> ogra: no, I thought the m-f-all just contain a reference to the files?
<jbailey> wasabi_: Look at /usr/share/initramfs-tools/hooks
<jbailey> grep for copy_exec
<Diziet> That's right, m-f-l-all just contains the filenames.
<ogra> Diziet, because about-edubuntu exists only untranslated
<wasabi_> Ahh hah
<jbailey> that will copy the binary and any libraries it might depend on.
<Diziet> Right.  So just ship it as index.html and every index-LOCALE.html that you see in ubuntu-docs.
<pitti> Diziet: did I understand you right? m-f-locale-all just changes the homepage location, it does not ship the start pages itself, right?
<Diziet> That's right.
<pitti> ok
<ogra> ok
<jbailey> I'll do that.  I just need to know where to put them.
<Diziet> But you change the homepage location IF AND ONLY IF the new location is in the list from ubuntu-docs.
<pitti> ogra: well, then you just need to have an edubuntu-artwork with the translated (and english) start page and it should DTRT
<Diziet> That's why there has to be some minimal coordination.
<pitti> Diziet: yes, of course
<jbailey> Teamwork! \\o/
<mvo> pitti: yes
<pitti> Diziet: but if we build all this in a central place, langpack-o-matic can figure this out
<Diziet> It would be better to have some actual source-level dependency to shuffle this list about but if it's just for breezy we can just have one blessed list.
<jbailey> pitti: Right.  But that's totally not breezy material.
<pitti> jbailey: of course
<Diziet> OK, glad we've got that sorted.  Do you think I should write it up ?
<Diziet> I mean, send an email to ubuntu-devel with details ?
<pitti> Diziet: I'd rather write it up on the wiki
<pitti> Diziet: better for integrating into UBZ specs, and the like
<Diziet> Sensible.
<jbailey> pitti, Diziet: That should be linked from LocalesThatDontSuck
<jbailey> Diziet: Sending it somewhere so that we can all work from it with a clear list of what will be at what path would be useful.  I'm still not sure where all the varioous HTML files should go.
<Diziet> jb: Sure.
<Diziet> I thought this might need a proper writeup.
<martinhj> jbailey: we talked a while a go about lvm and breezy.. I would like you to know that the usplash works together with lvm (but I suppose you already know)
<jbailey> martinhj: I always appreciate success reports. =)  It's a nice change from the pile of failure reports. =)
<martinhj> jbailey: yeah, like lilo doesn't work;-)
<pitti> jbailey: hmm, is there any chance we can have the Kurdish locale in locales proper?
<jbailey> martinhj: Right. =)
<jbailey> pitti: Yes, dear.
<jbailey> pitti: seb128 asked me to hold off the locales update while we figure out a gtk bug.
<Darknight> hello
<pitti> jbailey: I just got a question from the Turkish user group, which wants to heavily promote Ubuntu, but can only do that if Ubuntu supports it OOTB
<jbailey> I have some first_weekday patches that aren't clear if they should go in or not.
<Darknight> sorry, byt can anyone help me with setup of tv card in breeze?
<jbailey> They're right from glibc's POV, but gtk seems to behave poorly.
<pitti> jbailey: ah, thanks
<seb128> jbailey: have you read Denis's reply?
<jbailey> seb128: I did.
<jbailey> seb128: Alhtough that was several hours ago, and I should reread it. =)
<seb128> jbailey: my conclusion is that the locales are screwed anyway
<jbailey> seb128: So the French can suck it up and cope with the week starting on Tuesday? =)
<wasabi_> Wow that was remarkably easy.
<seb128> no, drop the patch
<wasabi_> gg initramfs people
<seb128> it will make the .fr work fine
<seb128> but de_DE is b0rked by example
<pitti> seb128: that's release critical then :)
<seb128> pitti: say that to mdz :)
<lamont-away> seb128: the only thing remaining is for you to email elmo asking for gtk-smooth-engine to be removed from the archive.
<lamont-away> assuming that gtk2-$mumble now delivers gtk-engines-smooth
<seb128> lamont-away: no, as said the universe package is still useful for the gtk1 binary
<lamont-away> except that it has no binaries installed, because the upload is rejected.
* lamont-away points at http://archive.ubuntu.com/ubuntu/pool/universe/g/gtk-smooth-engine/
<lamont-away> the only binary there is  gtk-engines-smooth_0.5.6-4_powerpc.deb
* pitti asks himself if releasing an USN at Friday evening will annoy server admins
<lamont-away> which is probably warty-ish
<lamont-away> pitti: heh
<pitti> lamont-away: good morning, btw :-)
<lamont-away> pitti: g'morning.
<lamont-away> and I have to leave for a few hours.
<lamont-away> later
<Diziet> https://wiki.ubuntu.com/BreezyFirefoxStartPageTranslation
<Diziet> jbailey: You need to add the list of Translateable locales to that wiki page.
* Yagisan thinks pitti should release the USN - go on annoy the server admins
<pitti> Yagisan: too late anyway, it's already out :-)
<pitti> Yagisan: well, every sensible German worker is already in the weekend now, so they won't notice anyway :-)
<jbailey> Diziet: Done.
<Diziet> Thanks.
* Diziet fixes the formatting.  This is a particularly stupid wiki we're using, isn't it ?  And it seems very slow to me.
<bob2> I guess you missed the ZWIKI STRIKES BACK episode
<Diziet> I suppose I'll just have to do the somewhat-wrong thing for firefox fonts.
<infinity> mvo : Alright, console-tools will be uploaded in a while, with increased cleverness.  Took a few (!) reboots to get it doing what I wanted...
* infinity goes to take a break before committing his final changes to console-tools
<mdz> Diziet: actually this is the best wiki we've found; do you have one that you've found to be superior?
<Diziet> I much prefer twiki.
<Diziet> OTOH it depends how much you want to worry about people putting random arbitrary HTML in.
<fabbione> Diziet: the same as the one used to root freedesktop?
<jdub> fabbione: yes :)
<ogra> heh
<Diziet> I didn't hear about that.
<fabbione> jdub: i knew the answer :P
<jdub> they're now using... moin :-)
<bob2> well, it got a local account
<fabbione> jdub: i was sitting less than a meter from daniels when that happened
<bob2> it took hard work fro mthe kernel team for it to get root
<jdub> yay team
<lifeless> what the world needs now
<lifeless> is just another wiki
<jdub> sweet wiki
<ogra> couldnt we just run it with thttpd ? so vulnerabilitys go straight through then ? 
* fabbione -> shower
<mvo> infinity: rock!
* jdub hopes a replacement hdd fixes his lappy
<pitti> mdz: can you please import Debian #329127 into bz?
<pitti> mdz: a friend of mine complained about our "cvs" package crashing all over the place, pro'lly a compiler bug
<zyga> could any hacker tell me how to compile coreutils as static stuff?
<bob2> zyga: might be easier to use sash?
<zyga> bob2: thanks, I'll check it out
<Kamion> I wish translators would read the comments left there for the benefit of translators
<zyga> Kamion: ?
<Kamion> # This menu entry may be translated.
<Kamion> # However, translators are required to keep "Choose language"
<Kamion> # as an alternative separated by the "/" character
<Kamion> # Example (french): Choisir la langue/Choose language
<Kamion> _Description: Choose language
<Kamion> that one in particular
<Kamion> it's depressingly common for the comment to be ignored
<jdub> at least the french got it right
<Kamion> I've been filling in replacement suggestions in Rosetta, but I have no idea if anyone pays attention to those
<jdub> you'd think they'd screw it up on political grounds
<zyga> Kamion: who/what chooses final translation from various suggestions?
<zyga> last used?
<Kamion> zyga: translation team, as far as I know
<Kamion> but in the case of what actually gets into the installer, me ;)
<Kamion> (I can do a number of sanity-checks even if I don't speak the language, such as "strings with wildly different meanings in English ought not to translate to the same string in another language")
<Kamion> and I tend to go with Debian translations where available just because the merging gets insane for me otherwise
<zyga> Kamion: I was thinking about a possible scenario where two people keep changing the same translation over and over
<Kamion> well, that would be dysfunction within the translation team; Rosetta doesn't let you change a translation directly if you're not in the translation team - you can only make suggestions
<zyga> Kamion: I am in the translation team
<zyga> bob2: thank's sash looks great!
<Kamion> presumably you're in contact with your fellow team members then
<\sh> gnarf
<\sh> anybody knows which version of madwifi drivers we're shipping in the restricted modules?
* zyga is remastering dsl to a very custom cd :-)
<_mvo_> infinity: can you please ping me after you uploaded the console-tools? I would like to test it here too 
<Kamion> Rosetta is going to give me RSI at this rate
<doko> RSI?
<Kamion> http://en.wikipedia.org/wiki/Repetitive_strain_injury
<Mirv> can anyone pick from today's ubuntu-devel e-mails the command that was supposed to be run on a laptop that has working suspend-to-ram, and the e-mail address of the person who asking for it :) [also, an _up-to-date_ archives link is okay] 
<mjg59> Mirv: sudo dmidecode, mail to mjg59@srcf.ucam.org
<Diziet> I've had to switch to mousing left-handed when I'm having a bugzilla nightmare day, because it's so awful.  That way I spread the load.
<seb128> Diziet: are you going to do a firefox upload soon?
<Mirv> mjg59: ok, thanks
<Diziet> seb: No, why ?
<Diziet> I'm going to fix the fonts, yes, but that's in fontconfig, which I'm preparing now.
<ogra> yay
<segfault> strange, seems that the archives of the lists is not being generated
<segfault> err, are.
<mvo> pitti: update-notifier uploaded, you can use /usr/share/update-notifier/notify-reboot-required now and it will be translateable via gettext/langpacks
<pitti> mvo: yay
<seb128> Diziet: because we have some translation updates for the .desktop
<mvo> pitti: yeah, sorry that it took so long :/
<jsgotangco> good night =)
<Diziet> seb: Ah, right.
<seb128> Diziet: https://wiki.ubuntu.com/DesktopTranslations has them if you do an upload
<Diziet> Can you file a bugzilla bug P1 against firefox ?
<seb128> sure
<Diziet> Put that URL in.
<Diziet> Then I'll fold them into the next upload.
<seb128> cool, thanks
<Diziet> I'll make sure to do the upload before the RC.
<infinity> I WIN.
<infinity> mvo : Being uploaded right now.
* dholbach hands the CUP over to infinity 
<mvo> infinity: cool, I'm away for ~1,5h now, but I'll test it when I come back
<infinity> mvo : Spiffy.
<infinity> mvo : Keep in mind that you'll probably still be hindered by the crap font (but you can load/specify another, if that takes your fancy), but all the VCs should be in UTF-8 now.
<infinity> mvo : Care to see the ugly-hack debdiff?
<mvo> infinity: oh yes!
<mvo> infinity: I would have debdiffed anyway :)
<tseng> is it possible to get ubuntu.com addresses for launchpad teams
<tseng> to act as Maintainer:
<mvo> infinity: can you send it to me? I really need to go now
<infinity> mvo : It's actually not that bad, just took a bit of thinking to get it right.  Very little typing once the thinking kicked in.
<infinity> mvo : http://cerberus.0c3.net/~adconrad/console-tools.debdiff
<infinity> mvo : Download it and cherish it.
<mvo> infinity: will do :)
<mvo> cheers and bye
<Diziet> I just love programs which crash when my chroot hasn't got /proc mounted.  Great error handling that.  Not as bad as the hideous lvm tools though.
<bddebian> Bah, where's lamont
* Diziet uploads fontconfig.  There you go everyone, have fun.
* Treenaks hands Diziet the asbestos suit
<Diziet> Thank you.
* Treenaks gets out of the way
<CarlFK> The Etherboot mail list has agreed that making a UNDI net driver for Linux is a good idea, but no one has time. Where is a good place to post the "job" to see if someone wants to do it?
<CarlFK> This would probably benefit the Ubuntu LTSP project. and any other linux thin client
<slomo> seb128: ? what do you ask? ;) i just gave you the link to a CAN regarding abiword... maybe something we should fix for breezy
<infinity> slomo : Another one?... We just fixed a security hole in abiword.
<ivoks> g-v-m says run gnome-cups-add on printer connection
<ivoks> but there is no g-c-a
<slomo> infinity: the rtf thing?
<infinity> Yeah, CAN-2005-2964
<slomo> exactly... ok, seb128 just ignore me ;)
<pitti> slomo: I only know about one current vuln in abiword (the rtf thing)
<\sh> pitti: where was your sec list webpage again?
<pitti> \sh: http://people.ubuntu.com/~pitti/ubuntu-cve/
<\sh> pitti: hmmm...I can't read it :(
<slomo> hm, why don't we have eclipse for amd64?
<\sh> the official announcement I mean
<pitti> \sh: hm? it's http and unrestricted
<\sh> pitti: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2962
<pitti> \sh: ah, it might still be unprocessed by mitre
<pitti> \sh: https://www.ubuntu.com/usn/usn-188-1
<\sh> thats 2964 ;)
<\sh> i need 2962 ntlmaps
<pitti> \sh: ah, I see; sorry
<pitti> \sh: http://www.debian.org/security/2005/dsa-830
<pitti> \sh: however, just looking at the sid package should be fine
<pitti> \sh: the question is just "merge or sync"
<\sh> pitti: I'll check
<\sh> pitti: we have 0.9.9-3* and debian's fix is in 0.9.9-2 (sarge)
<pitti> "For the unstable distribution (sid) this problem has been fixed in version 0.9.9-4."
<pitti> \sh: it's not in -2, but in -2sarge1
<\sh> wah...yes
<\sh> can someone give me an information about the madwifi version in the restricted modules?
<Treenaks> "it exists"
<\sh> well...so we can forget that wpa-psk (wpasupplicant) + dhcp is working correctly
<\sh> if madwifi is >= CVS snapshot from 20050707
<\sh> s/=//
<slomo> infinity: do you know why eclipse isn't built anywhere except x86?
<\sh> pitti: I think a sync is ok...
<\sh> pitti: will you request or should I?
<pitti> elmo: please sync ntlmaps (ubuntu override ok according to \sh)
<slomo> infinity: it is arch any... so it would be pas?
<elmo> pitti: are these two language packs going to get fixed any time soon?
* \sh tries to reproduce #16539
<infinity> lucifer:~/build/dak/srcdep/> grep eclipse Packages-arch-specific
<infinity> %eclipse: i386
<infinity> slomo : ---^
<slomo> infinity: ok, thanks... i'll try to get it working on amd64... at least the eclipse guys have amd64 packages ;)
<pitti> elmo: the -support packages? doko asked me to leave them as they are since he wanted to fix them soon
<CarlFK> \sh, is there a way to simulate a GR keyboard?
<elmo> pitti: support-{lt,bs}
<elmo> pitti: well I just don't want them to be forgotten for RC
<elmo> we really shouldn't be shipping uninstallable packages
<segfault> who is responsible for the wiki template?
<pitti> elmo: yes, right; ooo2 currently doesn:'t build ooo2-l10n-{lt,bs}
<pitti> elmo: if they aren't there by monday, I just drop these dependencies
<jdub> segfault: hno73 
<elmo> mdz: around?
<elmo> pitti: ok - thanks
<\sh> CarlFK: a GR? greek? 
<CarlFK> \sh, "So no german keyboards (or any other keyboards with special keys via AltGR) "
<mdz> elmo: yes
<\sh> CarlFK: altgr == meta- ;)
<mdz> I suck at this 'day off' business
<elmo> mdz: I promoted edubuntu-artwork-usplash as 'obvious' (binary of a source package already in main) - have you looked at the sip stuff at all needed to fix python2.4-qt ?
<mdz> elmo: no, I haven't
<mdz> elmo: if pitti gives it the OK, it's fine with me
<CarlFK> elmo, I think the 2 bt seeds for http://cdimage.ubuntu.com/edubuntu/daily/current/ are behind firewalls or something - im not getting any connections
<CarlFK> elmo - Im working on figuring out what the problem really is, so if it isn't obvious I may have more info later
<segfault> is there any howto on how to change the default splash? i saw there's a .so separated file now..
<jbailey> segfault: Not yet, but I can put one up for next week.
<jdub> segfault: easiest way to grok it would be to get the edubuntu-artwork source and have a look :)
<elmo> why do our main inclusion report not include a "requested-by" field?
<jbailey> segfault: Fundamentally, the .so is the compiled output of pngtobogl turned into a shared library for dlopening.  You have to made sure that it's all named right.
<segfault> jdub: thanks, i'll look.
<segfault> jbailey: humm, seems easy to do so. i'll try it now.
<jbailey> segfault: Take a look at the package, feel free to ask questions if you have them.
<jdub> mjg59: ping
<dholbach> have a nice evening
* pitti wholeheartedly curses at the langpacks
* \sh does the back to the future show now ;)
<jdub> night dholbach 
<slomo> hi backports-r-us ;)
<dholbach> not going to bed ;)
<backports-r-us> slomo: greetings :)
<pitti> backports-r-us: hi! btw, http://people.ubuntu.com/~pitti/ubuntu-cve/unfixed.html shows some nice backport targets (gaim and abiword)
<backports-r-us> pitti: Cool -- can you email that to me? On a text-only console right now :)
<pitti> backports-r-us: the link? sure
<backports-r-us> pitti: Wasn't Abiword brought up to 2.2.7 during a recent USN?
<pitti> backports-r-us: yes, but I patched the current version due to the freeze
<pitti> backports-r-us: sent
<backports-r-us> pitti: thanks
<slomo> wasabi: ping?
<mdz> backports-r-us: do you track USNs and make sure to update the versions in backports to incorporate security fixes?
<elmo> Riddell: ?
<backports-r-us> mdz: roughly manually; what's a good way to keep track of them?
<segfault> jbailey: are those image 16 colors only?
<mdz> backports-r-us: subscribing to ubuntu-security-announce
<jbailey> segfault: Yes.
<jbailey> segfault: And take care to keep foreground/background and failed colours separate.
<backports-r-us> mdz: k, already do that :)... I'm usually OK with keeping up to date with USNs
<pitti> mdz: I just mailed him my tracker page url
<mdz> pitti: you have a page? send that to me too
<backports-r-us> pitti: just too a look; awesome tracking page :)
<backports-r-us> took*
<pitti> mdz: you don't know it? http://people.ubuntu.com/~pitti/ubuntu-cve
<pitti> mdz: it's automatically generated; it's my "security big brother"
<mdz> thanks
* bddebian summons lamont
<backports-r-us> bddebian: am I allowed to summon yet?
<backports-r-us> Guys, successful upgrade report from Warty to Breezy :)
<backports-r-us> (and it had old-style sf.net backports, too!)
<slomo> backports-r-us: depends on what you want to do :)
<bddebian> backports-r-us: Sure :-)
* backports-r-us tries to load GUI on old computer
<segfault> jbailey: is this ok? https://wiki.ubuntu.com/USplashCustomizationHowto
<mvo> segfault: nice!
<jbailey> segfault: Looks right.  you should add something like the following, though:
<jbailey> segfault: The PNG must be: 640x480 16 colours.
<jbailey> segfault: The following pallettes are used for the usplash display:
<jbailey> segfault: Background colour: 0, Progressbar color: 1, Progressback background: 4, Text background: 0, Text foreground: 2, Failured colour: 13
<jbailey> segfault: But this is awesome, thanks.
<jbailey> mjg59: (The progress background is what you recently added, right?)
<crimsun> jbailey, yes, in -16
<segfault> jbailey: ok, will do that.
<jbailey> crimsun: Cool, thanks.  I'm wondering how it looks on the kubuntu and edubuntu pallettes. =)
<bddebian> Anyone a .mime file expert?
<Mirv> hmm, where has the Ubuntu-style lock screen dialog gone? And where are those "Switch user", "OK" and "Cancel" in the new dialog translatable?
<seb128> can anybody gives editbugs rights to petermcv@clarkson.edu ?
<mvo> infinity: sorry for spoiling the fun, but the console-tools changes seem to not fix the problem here (greek install)
<infinity> mvo : That's because I'm retarded, there's another upload just sent.
<segfault> just updated: https://wiki.ubuntu.com/USplashCustomizationHowto
<bddebian> seb128: Do you or do you know anyone who knows .mime files?
<seb128> bddebian: context?
<infinity> mvo : Can you manually remove the "!" from the "pidof usplash" test at the top of /etc/init.d/console-screen.sh, then test? :)
<bddebian> seb128: gnome-apt doesn't self register .deb files.  It has a gdeb.mime which doesn't seem to get installed but the syntax of it looks wrong
<mvo> infinity: sure :) 
* mvo reboots his test-system
<seb128> bddebian: /usr/share/mime/packages/glade.xml 
* mvo should consider actually learing greek, so that he actually understands the text in his test-system
<seb128> bddebian: you want to do a such .xml for the current mimetype implementation
<infinity> mvo : That's just crazy talk.
<mvo> infinity: unfortunately yes
<pitti> seb128: do you have time to test the new french langpacks?
<mvo> infinity: hm, after chaning the ! in console-tools it works again for vt1, but no luck with vt2-6 :/
<bddebian> seb128: That file doesn't exist
<seb128> pitti: sure
<seb128> bddebian: it's a part of glade-common-2
<seb128> bddebian: ls /usr/share/mime/packages/
<zyga> hmm :-)
<zyga> usplash keeps dissaparing
<zyga> is this common for others
<zyga> ?
<mvo> zyga: disapparing in what way?
<mvo> not coming up at all?
<infinity> mvo : Erm.  I'll have to reboot more here, then...
<jbailey> segfault: Nice, thanks for the update!
<infinity> mvo : That init script is the one from the package, right?  Not one you've altered?  (other than reversing that test)
<bddebian> seb128: OK, thx.  Do I have to do anything special to update the mime database or just putting the .xml file in the proper directory?
<pitti> seb128: http://people.ubuntu.com/~pitti/langpacks/
<mvo> infinity: yes. but I will double-check again
<infinity> mvo : What does "vt-is-UTF8" return on vc2-6?
<seb128> bddebian: the package has to use dh_installmime
<mvo> infinity: Single-byte char mode 
<bddebian> seb128: OK, I'll give it a try thx
<infinity> mvo : Bah.
<bddebian> seb128: Oh and the .desktop should use gksudo not gksu correct?
<seb128> correct
<bddebian> Thanks
<infinity> mvo : Worked here on my last boot...
<mvo> infinity: let me first double check that thre isn't something bad on my system
<zyga> mvo: after some updates usplash is disabled
<zyga> mvo: yes 
<pitti> ah, update-notifier in German :-)
<pitti> seb128: they work fine for me, no obvious breakage and Rosetta goodness :-)
<segfault> pitti: how about in pt_BR? :)
<mvo> zyga: there was a problem with /usr/lib/usplash/usplash-artwork.so and update-alternatives on some systems
<mvo> pitti: yeah!
<pitti> jbailey: ah, and new langpacks work fine with belocs, too
<pitti> mvo: language-selector is not translated, though
<pitti> seb128: I'm waiting for your ok, then I upload the stuff
<mvo> pitti: it went into rosetta late, I guess I should do a translation myself
<seb128> pitti: playing with them, a sec
<zyga> mvo: any idea how to fix this?
<pitti> seb128: I can't ignore my gf any longer, otherwise I won't have a gf any more :-)
<seb128> pitti: works fine for me, GO
<jcohen85> jbailey, i have all the latest updates including the new usplash and i'm still not seeing a splash screen.
<pitti> mvo: there is a mo file, but some strings are missing in it
<pitti> seb128: yay
* pitti pulls the lever
<mvo> infinity: ok, the problem seems to be that it works fine with usplash, but not without usplash. could you please try booting without splash and see if vt2 is unicode for you then?
<mvo> infinity: and with usplash the font seems not to be setup correctly. sorry for being so negative :/
<pitti> segfault: uploading now, find it out yourself :-)
<bddebian> seb128: Sorry to keep bugging you but hopefully one last question.  Do you know if the mime xml file should be for gnome-apt or for gdeb?
<jcohen85> is anyone else not seeing the splashscreen?
<Kamion> Nafallo: would it be possible for you to work with the d-i Swedish translation team to get your changes in there? I'm incorporating your changes to Ubuntu-specific strings, but the problem with taking changes to generic strings (ones in both Debian and Ubuntu) in Ubuntu is that I'm then stuck later with having to merge changes in a language I don't speak
<jcohen85> it looks as it if is coming up and then goes back to the boot screen
<seb128> bddebian: gdeb if that's gdeb which is used for that
<Kamion> Nafallo: (as it happens I can make out Swedish well enough, but usually not at the level of being able to decide which string out of two alternatives is better ...)
<bddebian> Uhmm OK
<mvo> pitti: for language-selector?
<infinity> mvo : Negative works.  How do I set a different enough font that I can tell it's working?
<lamont> hrm... no daniels
<infinity> lamont : Well, it is 6am on Saturday morning here.
<lamont> infinity: true
* lamont was looking for -73
<lamont> before I upload it with just my fix.....
<mvo> infinity: I used "lat1-08" in /etc/console-tools/config (SCREEN_FONT=lat1-08)
<infinity> GAH.
<mvo> infinity: it's ugly as hell, but it's definitly differnet from the default one :)
<infinity> My last upload was nothing but a changelog entry, I didn't actually invert the test.
<infinity> I might be tired.
<mvo> infinity: 6am? no wonder!
<zyga> hmm
<infinity> Anyhow, no big deal, since it looks like I'll need another upload. :)
<zyga> how do I run nautilus in gdb?
<mvo> infinity: you didn't got up right early, you are still awake?
<infinity> Yeah, I'm still awake.
<infinity> Lord only knows why.
<lamont> seb128: why don't my uxterms get a utmp entry anymore, I wonder....
<infinity> I think I just like rebooting.
<mvo> heh
<\sh> lamont: what?
<mvo> infinity: it's fun when you get a "mount-count exceeded" message two times a day
<\sh> lamont: uxterm comes from xterm...so it can be me you want to ask ;)
<zyga> hmm
<lamont> ok.  why doesn't it get a utmp entry?
<seb128> lamont: no clue, you may want to ask \sh
<\sh> lamont: I'll have to check....
<Kamion> lamont: not setgid utmp?
<pitti> mdz: new langpacks with Rosetta love on the way :-)
<lamont> Kamion: 755 root root
<lamont> that'd be it.
<zyga> nautilus keeps crashing when I try to reassign program responsible for opening given file type
<lamont> pitti: what did you do to me?
<Kamion> -rwxr-sr-x  1 root utmp 285272 2005-09-01 01:31 /usr/X11R6/bin/xterm
<Kamion> on Debian
<pitti> lamont: context?
<Kamion> uxterm can be 755 root:root with no problem
<lamont> /usr/bin/xterm is 755 root:root
<Kamion> \sh: make /usr/bin/xterm's permissions be like the above, and it should work properly again
<pitti> lamont: you mean your buildds now have something to chew at?
<lamont> Kamion: uxterm is a script that runs xterm
<Kamion> lamont: indeed
<slomo> elmo: thanks for accepting mosml :)
<lamont> pitti: I figured you'd de-rooted xterm
<bddebian> lamont: Are you the enlightenment expert? :-)
* pitti wanders off - good night everybody and have a nice weekend
<bddebian> Gnight pitti
<pitti> lamont: IZ DANIELS BUG
<zyga> night pitti 
<elmo> pitti: no, it's not, it's a \sh bug
<elmo> daniels isn't the one who breaks xterm these days
<pitti> anyway, I wasn't it :-)
<lamont> bddebian: I've been known to elighten people, but not even sure what a package called enlightenment might _do_, let alone how.
<\sh> pitti: my fault
<pitti> night!
<lamont> damn he's quick
<\sh> lamont / kamion: I'm busy right now...will do a bugfix tomorrow evening when I'm coming home from work :(
<bddebian> lamont: Well your name is all over the changelog :-)
<lamont> Kamion: I'm figuring it's close enough to that magical 3 or 4 thing I mentioned earlier... unless you'd rather I didn't....
<Kamion> it's a bit too much of a Friday evening for me to care
<\sh> grmpf vmware is slow...really slow on this 1.6GHz cpu
<infinity> mvo : Okay, to make sure I'm getting the same results you are...
<backports-r-us> \sh: vmware shouldn't be THAt slow
<backports-r-us> \sh: unless you really don't believe in RAM :)
<infinity> mvo : With usplash enabled, everything worked (font and UTF)...
<infinity> mvo : With usplash disable, font worked, but UTF8 didn't (on 2 through 6)
<infinity> mvo : If your system did the same as mine, I know why, and the fix is easy.
<\sh> backports-r-us: I'll believe in 256 MB ram ;) so it's slow...when the other 256 are used by the rest of breezy ;-)
<infinity> mvo : If your results were different, I hate you and you can die.  A bit.
<backports-r-us> \sh: yeah, that shouldn't be too bad then
<backports-r-us> \sh: think of it compared to qemu ;)
<\sh> backports-r-us: don't let me think of it...I tested livecds with qemu
<backports-r-us> \sh: I did that last week :-/... painful even on AMD64
<\sh> 26mins to hoary  now :(
<elmo> of course it's slow if you don't give it enough RAM
<elmo> 'cos all your actually testing is linux's ability to swap and/or thrash
<\sh> elmo: please send me add. 512 MB for hp nc6000 ,-)
<segfault> pitti: thanks!
<\sh> elmo: but anyways...if I can reproduce the bug ... would be great...so someone has more work until the 11th ;)
<\sh> daniels or seb128 one of the two ;)
<tseng> elmo: is it possible to get @ubuntu.com addresses for launchpad teams
<tseng> elmo: for group Maintainer
<segfault> tseng: i think you should be approved as ubuntu member first
<Kamion> he already is
<tseng> segfault: yes :)
<Kamion> segfault: see https://launchpad.net/people/ubuntumembers/+members/
<segfault> then he alread has an email i guess?
<elmo> segfault: that's not what he's asking for
<tseng> that wasnt exactly the question
<elmo> tseng: ugh
<tseng> but close :P
<Kamion> segfault: he said "for launchpad teams"
<segfault> ah!
<\sh> elmo: btw..thx for the latest syncs 
<segfault> heh, ignore me
<segfault> :P
<elmo> tseng: maybe - it brings up some issues; like, e.g. we don't currently police the namespace
<bddebian> Shit, I don't know what to do with the <match type> entry
<Kamion> elmo: @teams.ubuntu.com?
<Kamion> or something like that
<tseng> hm
<Kamion> maybe lists are better anyway
<tseng> i think pkg-mono points at a list..
<elmo> actually, yeah, I think lists are a better idea
<tseng> yes
<bddebian> seb128: Am I allowed 1 more question? :-)
<bddebian> lamont: Seriously do you know enlightenment or not?
<tseng> elmo: is that still jeff?
<seb128> bddebian: sure
<bddebian> seb128: Any ide what I would use for the <match type=" ".. /> entry for gdeb?
* fabbione wonders why he has 2 lp accounts
<elmo> tseng: jeff can still do them yeah
<bddebian> s/ide/idea
<tseng> elmo, Kamion thanks
<lamont> bddebian: the software, no.
<bddebian> lamont: Then why are you all over the changelog? ;)
<seb128> bddebian: they seem to start with "!<arch>
<seb128> debian-binary"
<lamont> bddebian: because I uploaded it.
<lamont> you think I actually _know_ the code I hack on?
<bddebian> lamont: Of course :-)
<zyga> can usplash theoretically use more than 640x480x16?
<lamont> bddebian: nah - I just fix things
<bddebian> seb128: This is what glades looks like but I can't make sense out of it:
<bddebian>       <match type="string" value="&lt;!DOCTYPE glade-interface" offset="0:256"/>
<bddebian>       <match type="string" value="&lt;glade-interface" offset="0:64"/>
<lamont> fixing something that's broken does not require understanding the thing, only understanding the problem.
<bddebian> lamont: Well it FTBFSs for me on i386 now :-)
<seb128> bddebian: mimemagic
<jdub> Kamion: how ready-for-prime-time would you regard oem-config?
<lamont> bddebian: sounds like it should get fixed... :-0)
<seb128> bddebian: if the files has a "!DOCTYPE glade-interface" string between 0 and 256 chars it's a glade file
<seb128> bddebian: or glade-interface between 0 64
<qbertibur> hi
<bddebian> lamont: Aye no shit.  The question I guess was whether to bring in the newer debian version or not :-)
<bddebian> seb128: Hmm, do you think I need those entries at all?
<qbertibur> Who is working on the new ubuntu init-system?
<seb128> bddebian: you can try without them, but that's the way to get an efficient mime
<bddebian> seb128: OK, well google ain't helping much. :-)
<\sh> guys...what do u say to this:
<\sh> Automatically selecting en_US.UTF-8 locale in addition to en_US.
<\sh> xserver-xorg config warning: migrating xserver-xfree86 templates to
<\sh>    xserver-xorg.
<\sh>    xserver-xorg config warning: failed to infer keyboard layout from layout/lang
<\sh>       'us--'
<mvo> infinity: my system looks like this right now http://people.ubuntu.com/~mvo/00001.jpg
<lamont> infinity: -73 inbound
<jdub> mvo: looks like ass. :-)
<mvo> jdub: yep, console-fonts are a real PITA
<janimo> jdub, what are the prerequisites for seeding xubuntu stuff?So I know what I do in the weekend :)
<jdub> janimo: given that you've got a metapackage already, you're most ofthe way there
<janimo> hmm we'll need to transition those to main?
<jdub> janimo: we just have to convince Kamion to eek out some time to set up builds :)
<jdub> nup
<janimo> ok that's great than I'll put some more stuff in the meta as people on the list tend to agree on what we shoudl have 
<seb128> janimo: I'm looking on your patch, will upload rsn
<jdub> then someone will have to lead you through setting up the seed lists from the packages you've already selected
<qbertibur> Does nobody know who might be working on an improved init?
<janimo> seb128,yupee!
<jdub> that could be myself or kamion
<jdub> qbertibur: no one is atm
<jdub> qbertibur: we're stabilising for release! :)
<jdub> highly unlikely we'd do something along those lines for dapper, either
<qbertibur> There will be a time after the release ;-)
<janimo> jdub, whenever you guys will have time let me know a bit in advance and I'll be there
<jdub> ok
<tseng> jdub: so dude, how do i get a mailing list
<jdub> tseng: you email mailman@lists.ubuntu.com with what you want :-)
<jdub> what's the list for?
<tseng> mono group
<tseng> to be the target of the Maintainer: field to start
<jdub> wow, rad - you've enough people interested in ubuntu-specific mono work?
<tseng> 3 regulars
<jdub> ah, maintainer field
* jdub groks
<jdub> cool
<tseng> slomo and ajmitch help out all the time :)
<jdub> ubuntu-mono@lists... etc?
<tseng> yeah pretty much
<janimo> jdub, the motu folks - dholbach especially - have requested a spearte ml a while ago, what do you think?the motu is expanding
<tseng> janimo: what would we talk about
<janimo> and havinf the same stuff which is discussed on irc
<jdub> janimo: yeah, we should definitely do that now
<janimo> archived for generations of motus would be nice
<tseng> devel is only too much traffic because of people posting bugs and replying to spam
<janimo> tseng, the irclogs look very similar to half a year ago
<janimo> similar blunders, questions
<tseng> janimo: and we documented most of it on the wiki
<janimo> tseng, but since you cannot decrease level on devel...
<tseng> janimo: im not sure its our fault people keep asking the same
<janimo> whether it's our fault or not is besides th epoint :)
<janimo> it would definitely help new motus learn
<janimo> I had such a break from motu that I could use some ml searching if it was in place ;)
<bddebian> seb128: What do you think: <match type="string" value="debian" offset="0:8"/> ?
<jdub> that would be a good list to mirror on the forums, too
<backports-r-us> p.s. I love the new xscreensaver lock dialog
<backports-r-us> looks very professional
<seb128> bddebian: "!<arch> debian-binary"  seems better, I bet that other stuff match "debian" here
* \sh has to go to bed...only a couple of hours sleep until we have to rackmount some nice hp servers into our DC...
<bddebian> seb128: Use that as string?  At what offset?
<seb128> bddebian: as a string with an offset of 20
<seb128> 22
<tseng> jdub: bwar, have you found your dell batteries to be suck?
<tseng> jdub: my second one seems to be dying
<seb128> janimo: bash: x-www-browser: command not found
<janimo> seb128, hmm
<janimo> aren't all browsers register with update-alternatives?
<seb128> janimo: I change it for "sensible-browser"
<janimo> seb128, ok
<janimo> I thought it was a debian standard that all X browsers register that
<janimo> do you have epiphany only installed?
<janimo> or maybe I am grossly mislead
<seb128> hum
<seb128> mine was pointing to galeon
<seb128> which is not installed
<seb128> alternatives are bogus, I don't like them
<bddebian> seb128: http://pastebin.ubuntulinux.nl/2674  if you get a second
<janimo> I don;t know much about them
<seb128> bddebian: have you tried it?
<bddebian> seb128: I can't until I get home :-(
<jdub> ogra: nice work on the xscreensaver lock dialogue :)
<seb128> bddebian: BTW that's not a space between both, but a 0xa
<infinity> I WIN!
<jdub> seb128: hrm, not getting distributor-logo love
<juliux> hi i have a problem with the ppc kernels in breezy can some one help me?
<jdub> seb128: oh, should i delete the icon-theme.cache for hicolor?
<bddebian> seb128: Sorry, not a space between both what?
<seb128> jdub: yeah
<seb128> bddebian: no, a 0x0a
<jdub> ah, there it is
<jdub> vuntz: mmm! thanks for the distributor-logo patch :-)
<bddebian> seb128: Where?
<jdub> seb128: ooh, about-ubuntu should use that now too ;)
<seb128> bddebian: sudo apt-get install ghex
<seb128> ghex2 file.deb
<seb128> and read the start
<bddebian> seb128: Oh, ok
<seb128> jdub: right, I'll change that with next upload
<joh> Uhm, anything know about any problems with the latest madwifi drivers?
<seb128> bddebian: that's a LF, not sure of how to code that with the xml file
<jdub> seb128: thanks :)
<seb128> jdub: np
<jdub> BREEZY IS THE NEW HOTNESS!
<jdub> seb128: maybe we should make sure that cache file isn't there
<bddebian> seb128: OK, I'm going to try it when I get home.  Thanks for all your time
<seb128> jdub: why? Some people have a cron to make them probably
<seb128> bddebian: np, thanks for working on that
<bddebian> seb128: One other quick thing before I head home.  There is a newer version in Debian.  Do I dare bring that in?
<infinity> mvo : Still aorund?
<seb128> bddebian: depending of the changes
<bddebian> seb128: OK, fair enough.
<bddebian> Later folks
<seb128> janimo: lpi changes uploaded
<janimo> seb128,thanks alot
<janimo> so sensible-browser?
<seb128> janimo: no, I've used your patch
<janimo> hmm, so can't it cause probs if x-www-browser is not there?
<janimo> althugh when gnome-open isn't we'll make sure ff isin xubuntu
<mae> HA! I made gtk/glib totally flip out by creating a HBox with 500 buttons
<mae> had to restart x
<mae> nothing would click
<tseng> that sounds useful
* HiddenWolf amused
<mae> well the thing is
<mae> creating thousands of button objects is no prob
<mae> but then when you display them in a container
<mae> all hell breaks loose :)
<seb128> mdke: bugzilla is not the right place to keep the new stuff to code
<mae> my screen flickered a bunch too
<HiddenWolf> seb128, is there any reason why gtkfilechooser suddenly shows unmounted cardreader slots?
<seb128> HiddenWolf: ask pitti when he's around
<seb128> mdke: upstream http://bugzilla.gnome.org/show_bug.cgi?id=154029
<HiddenWolf> seb128, ok
<slomo> wasabi: you maybe want to look at http://www.backports.org/~mkoch/unstable/. they have working eclipse packages for amd64/ppc/x86... maybe you can get the fixes into our packages
#ubuntu-devel 2005-10-06
<crevette> hello
<crevette> hello seb128 
<mjg59> jdub: Hi
<mjg59> jbailey: Yes
<jdub> mjg59: do you have some form of voip thingy?
* mvo goes to bed for today
<mjg59> jdub: Nope
<jbailey> mjg59: Eh?
<mjg59> jdub: I'm afraid I'm just about to cook and then hit bed - can I get back to you tomorrow?
<mjg59> < jbailey> mjg59: (The progress background is what you recently added, right?)
<jdub> yep
<jbailey> mjg59: Right. =)
<jbailey> mjg59: Thanks.
<elmo> umm, so why was the html page removed from ubuntu-artwork if firefox still defaults to looking for it there?
<jdub> elmo: out of sync changes, it'll be fixed soon enough
<elmo> k
<crimsun> elmo, hi, please sync tor from Sid
<elmo> crimsun: done
<crimsun> thanks!
<tseng> elmo: can you axe gtk-sharp-unstable source and binaries?
<tseng> elmo: or better not the binaries, they are the same names
<jbailey> segfault: Still there?
<tseng> elmo: just gtk-sharp-examples-unstable gtk-sharp-gapi-unstable  are unwanted
<joh> k
<joh> (whops :P)
<jdub>    * drivers-scsi-libata-passthrough: Support for ata passthrough with hdparm
<jdub>      and smartmon tools. (Closes: #14931)
<jdub> BenC: MWAH!
<jdub> WOOOHOO!
<jdub> elmo: unlikely ping
<elmo> eh?
<jdub> oh, hey
<jdub> what are the chances of getting awstats on humboldt? i can run it all as my user
<jdub> or at least own the config
<elmo> jdub: installing
<jdub> thanks
<jdub> rock, we're going to have our first podcast bit on the fridge soon
<jdub> though it was not what i expected our first podcast to be
<jdub> just did an interview for LA update -> i thought i'd be doing the interviewing!
<Keybuk> mmm, fridge
<Keybuk> it's a lovely word to say, that
<jdub> meanwhile, my freezer needs defrosting
<jdong> Anyone here w/ contact info for Daniel G Taylor?
<jdong> http://programmer-art.org/debins tell him to stop telling people to copy unmanaged files into /usr/bin :)
<segfault> jbailey: yes, now
<jdong> oh, yeah, is A4 still the default paper size for everything from CUPS to OOo?
<CarlFK> it was a few weeks ago
<CarlFK> I keep forgetting to ask: couldn't that be driven by one of the location settings? 
<jdong> CarlFK: exactly what I wanted to say
<jdong> I've considered a bugzilla rant about it :)
<segfault> jbailey: you around?
<jdong> CarlFK: technically, I suppose it's a personal preference, but at least in USA the sensible default is Letter
<maswan> jdong: yeah, if you got to have just one default though, everywhere outside of USA is A4
<jdong> maswan: I agree with that, but IMO a special-case with USA should be implemented in debian-installer's location dialog :)
<maswan> jdong: yeah, it would increase the just works part of usa installs
<jdong> maswan: especially since there's no easy-to-use, human-being-friendly way of changing that setting :)
<Keybuk> jdub: my old freezer used to just defrost itself when it felt like it
<bddebian> kick ass
<Keybuk> it'd get iced up so the door wouldn't quite seal
<Keybuk> and you'd come back to find the kitchen flooded and the freezer with a smug "well, I needed defrosting" look on it
<jdub> Keybuk: "new NYAH-NYAH brand!"
<bddebian> Anyone have a clue how I do a 0x0a in a mime xml file?
<bddebian>  \x0A
<bddebian> Oh thx bddebian 
<Keybuk> *sigh* at evo ... get off that bloody futex
<Keybuk> bddebian: &#x0a; isn't it in xml?
<bddebian> Dunno, that's how they do it on an example at freedesktop.org
<eruin> I just sent a whopping load of translations for synaptic at lauchpad, and I'm wondering when/if I can expect this to surface in breezy?
<jdub> eruin: might want to ask pitti when he's around
<eruin> willdo, thanks
<bddebian> Hmm, it doesn't like my &gt or \x0A
<Keybuk> <!ENTITY>
<elmo> btw, nice side affect of usplash is that my monitor warns me I'm destroying my eyes whenever I switch to the console
<bddebian> Keybuk: ??
<Keybuk> jdub: you forgot to update screenshot.png again
<Keybuk> the naked people are *so* last year
<jbailey> segfault: Back now, I went out shopping. =)
<segfault> no problem
<bddebian> jbailey: Really?  What did you buy me? ;-)
<jbailey> bddebian: A vodka ice.  But if you want it, you have to get here before I drink it.
<jbailey> I'd hate to let alcohol go to waste. =)
<bddebian> Heh
<segfault> did you want to talk with me?
<jbailey> segfault: I wanted to ask you about the wiki page.  It's missing a final step, but I didn't want to edit it without talking to you.
<segfault> ah, no problem.. you should edit it
<jbailey> 'kay cool.
<segfault> what is step is missing?
<jbailey> The regenerate the initramfs step. =)
<jbailey> Nothing that happens on your harddrive is relevant until that happens. =)
<segfault> ah, yeah, mkinitramfs
<jbailey> Right. =)
<desrt> k.. so i want to burn a shitload of breezy cds for an installfest on sunday
<desrt> i take it i'm best off with a daily snapshot?
<jbailey> desrt: I suggest you do it either after tonight's or after tomorrow nights.
<jbailey> There's still enough little bugs being fixed that it's worth pushing it as late as you can get away with and still have enough.
<desrt> btw... have you noticed that canadian installs get 'a4' paper?
<jbailey> Eh, really?
<jbailey> I hadn't. =)
<desrt> they do as of colony 3
<desrt> they did for hoary at one point but it got fixed
<desrt> so... regression i guess?
<desrt> when do the nightly builds hit the server?
<jbailey> I think about 4am Eastern, but I'm not sure
<segfault> the language pack released today hasn't the new translations
<desrt> (and where?)
<segfault> anyone knows why?
<jbailey> segfault: Martinis likely to only one who'd know, and he's (hopefully) asleep. =)
<segfault> ah, ok
<CarlFK> desrt - you should do your installs using https://wiki.ubuntu.com/Installation/LocalNet
<segfault> tomorrow maybe we'll have some news
<CarlFK> you can rsync the latest CD image 20 min before you start, and then everyone can hit that imge over the LAN
<desrt> CarlFK; i don't have etherboot/pxe/whatever for the 1000s of insane network cards in people's machines
<CarlFK> desrt - if you had a little more time, you could have had everyone play with http://rom-o-matic.net
<desrt> CarlFK; cds are easy and fast enough :)
<desrt> CarlFK; and if i use a daily build from tonight or tomorrow night it'll be fine
<desrt> (where are they??)
<desrt> oh.  nm
* desrt stops using google and looks in the logical place
<CarlFK> 1000's? how many people do you expect?  
<jmg> whats the "right way" for me to submit a source diff to malone?
<jmg> i have modified the source tree from apt-get source and my built package fixes the bug im filing, what next?
<\sh> jmg: attach it as patch
<\sh> jmg: which package btw.
<mdke> has anyone else complained about weird things happening on mailing lists?
<jsgotangco> how weird
<jsgotangco> i haven't been receiving emails lately
<mdke> over the last two days I've noticed a number of threads on -it and -doc that haven't been in the mailman archive
<mdke> yesterday, -it received an email from a guy who complains that he never sent it
<mdke> perhaps there is a ghost in the server
<jmg> \sh: kvpnc
<jmg> ] sh: is there a right way to do the patch? using dpkg-source or soemthing?
<jmg> \sh: is there a right way to do the patch? using dpkg-source or something?
<Keybuk> HAPPY MAILMAN DAY EVERYONE!
<mdke> ?
<robitaille> mailman day?   the application, or the guy who walks to my door everyday with the mail?
<Keybuk> gosh, people who don't know about mailman day
<Keybuk> Mailman day is the first day of each month
<Keybuk> when all around the world, millions of people feel a little warm fuzzy feeling when their inbox gets spammed by all the password reminders for all the lists they're on
<robitaille> never heard of that one
<mdke> hmm
<robitaille> ah.  that day!
<mdke> mailman day didn't visit me today
<mdke> lol http://www.crackmonkey.org/pipermail/crackmonkey/2002-December/034294.html
<Keybuk> dunno who started it, but it's been tradition for a few years now to wish everyone a happy mailman day when you get your first one
<robitaille> still haven't received one.  But usually I have half-dozen of these reminders
<jdub> Keybuk: eyah
<Keybuk> I remember one month, a few years ago now when I worked at the Demon NOC, someone bought in party hats for everyone to wear on mailman day
<mdke> jdub, have you noticed anything odd with the mailing lists recently?
<jdub> well, i saw lions running through the city streets earlier
<jdub> but nothing in particular with the mailing list
<mdke> that is more interesting
<mdke> jdub, i've noticed that some threads that I get in my mailbox and that appear on gmane don't go into the mailman archive
<mdke> jdub, i'll give you an example.
<jdub> thanks, was just about to ask :-)
<mdke> jdub, this thread http://thread.gmane.org/gmane.linux.ubuntu.doc/3242 doesn't appear here: http://lists.ubuntu.com/archives/ubuntu-doc/2005-September/thread.html
<mdke> jdub, further, the last message here: http://lists.ubuntu.com/archives/ubuntu-it/2005-September/thread.html is from the 28th. At least the top 5 threads here http://news.gmane.org/gmane.linux.ubuntu.user.italian/ do not appear on the archive
<Keybuk> looks like the mailman archive stalled a couple of days ago
<mdke> ah
<Keybuk> all of the lists are showing it
<Keybuk> did rince run out of disk space again?
<jdub> no, checked that as soon as mdke mentioned it
<Keybuk> or did Mark remember the root password and do bad things to it?
<mdke> ;)
* Keybuk bets $10 that it's suddenly running breezy
<jdub> haha, no
<mdke> jdub, the other thing that I would just report is that a user on -it reported that a mail, with some weird png attachment, wasn't sent by him at all. But I dunno if you can figure out what went on there
<jdub> sounds like it's very much related to the lions running through the streets
<mdke> damn lions
<jdub> let's just hope the messiah doesn't turn up again and zap us all into dust
<Keybuk> hey, I'm totally ready for the rapture!  got my potato right here
<jdub> it was pretty depressing when that happened last time
<jdub> the stench!
<robitaille> the ubuntu project has enough daniels around to deal with all these lions :)
<mdke> heh
<Keybuk> yeah, we've run out of adjectives
<Keybuk> daniel the taller, daniel the wider, daniel the brazilianer, daniel the germaner
<Keybuk> just doesn't work
<calc> robitaille: i thought you meant someone cloned daniels ;)
<jdub> hrm
<jdub> that's unfortunate 
<jdub> i was thinking of calling them "Daniel of ..." where ... == region
<jdub> but it turns out that berlin's province is berlin
<jdub> which is totally uncool
<jdub> "Daniel of Brandenburg" would be way cooler
<jdub> "Daniel of Amazon"
<robitaille> Daniel of Victoria has a nice feel to it
<jdub> robitaille: that's actually "Daniel of Mexico"
<mdke> call him brandenburg anyway
<Keybuk> Daniel of the West Midlands
<jdub> well, brandenburg does enclose berlin
<Keybuk> ...no, bob2 would wet himself
<jdub> kinda like nsw/act here
<mdke> jdub, if it helps, that rogue email that I mentioned above is this one http://article.gmane.org/gmane.linux.ubuntu.user.italian/6261
<jdub> yo vuntz 
<mdke> no it isn't!
<jdub> vuntz: thanks for the distributor-logo hack :)
<mdke> jdub, i mean this one http://article.gmane.org/gmane.linux.ubuntu.user.italian/6282
<vuntz> jdub: :-)
* robitaille likes the new canonical logo in the gnome panel
<jdub> robitaille: s/canonical/ubuntu/ !
<vuntz> jdub: hrm... doesn't the logo look a bit "weird" when you click on the menu (ie, when it's highlighted)?
<jdub> vuntz: yes, there's a glow behind it - i will probably muck with it a bit to make the glow both more pronounced, but much closer to the object
<crimsun> due to the image border? e.g., the "block"
<robitaille> oh yes, just looking at http://www.canonical.com/   ;  never noticed its logo  was different from the ubuntu logo
<mdke> are there going to be firefox translations for breezy?
<jdub> robitaille: dude, our first podcast bits on the fridge in a few minutes :)
<ajmitch> jdub: rock, what's it about?
<jdub> well, unfortunately it's an interview with me
<robitaille> jdub,  cool.  by the way, I should an small article about MOTU somewhere in the queue since yesterday; but I can't see it :(
<ajmitch> it'll be lively at least :)
<jdub> robitaille: yes, been meaning to email about that
<ajmitch> robitaille: what dirty MOTU secrets are you exposing?
<jdub> robitaille: i think we should try to summarise and link to the full notes
<robitaille> ajmitch,  the meeting notes.
<ajmitch> ah right
<ajmitch> in slightly more readable for the average person format?
<robitaille> jdub,   yeah;  I ran out of time, so decided that just the notes would work this time around
<jdub> ajmitch: mmm, so, "here are the big points - yay team - click here for the full summary"
<robitaille> they were old news anyway.  The meeting was on the 22th...
<ajmitch> yeah
<ajmitch> we usually get the meeting notes out to the lists within a few days
<ajmitch> imo the meeting notes generally aren't terribly exciting
<mdke> what is the relationship between the fridge and http://www.ubuntu.com/news ?
<jdub> spite, disgust, etc.
<mdke> jdub, is there an overlap?
<robitaille> that reminds me to go update http://www.ubuntu.com/ubuntu/press with some recent news clips
<ajmitch> jdub: where do you want us to report website broken links? :)
<jdub> haven't quite figured that out, either the fridge will double report the Totally Officious news on w.u.c, or we'll republish a category from the fridge on w.u.c
<jdub> now, ubuntu/press is *definitely* replaced with the fridge
<jdub> so robitaille - don't bother ;)
<robitaille> soon?
<jdub> when we officially announce the fridge, we'll display the feed of press on w.u.c from it
<jdub> yeah
<jdub> ajmitch: yeah, i guess :)
<robitaille> great.    I was wondering the other day was I was asked to do that :)
<robitaille> (updating .../press)
<ajmitch> jdub: well http://www.ubuntu.com/merchandise has broken 'bounty fund' link 
<robitaille> should it links to this one?   http://www.ubuntu.com/community/bounties/
<ajmitch> yes, I think so
<jsgotangco> hi everyone, please take a look at https://wiki.ubuntu.com/BreezyReleaseNotes and update as needed. We'll be needing this document in a few days so please participate in shaping this doc. Thanks
<jmg> guys whats the best way for me to diff a source package after ive fixed a bug
<bob2> ?
<bob2> you mean "how do I produce a patch for a bug fix I did?"?
<jmg> i have modified the source tree from apt-get source and my built package fixes the bug im filing, what next?
<jmg> is there a right way to do the patch? using dpkg-source or something?
<bob2> easiest way is to unpack the original somewhere else and use diff to get a patch between them
<bob2> another option is to use interdiff on the old and new .diff.gzs
<Keybuk> jmg: if you have the old source dsc and your new source dsc file, use the "debdiff" tool in the devscripts package
<jmg> Keybuk: thanks@
<jmg> !
<jmg> gah kvpnc is not even registered on malone
<ajmitch> jmg: and what was the problem with kvpnc?
<jmg> ajmitch: option "refuse eap" does not refuse eap
<jmg> as in, the source was missing the stanza to write refuse-eap to the config file
<jmg> so i added it
<ajmitch> ok
<jmg> should i send my patch directly to upstream
<ajmitch> you can, but we're not likely to get in a new upstream version at this stage
<jmg> ok
<jmg> cool
<jmg> ajmitch: it seems wintendo 2k3 recently started supporting eap
<jmg> ajmitch: but it doesnt actually work
<jdub> ok dudes
<jdub> what are some rad podcast clients in hoary?
<jmg> ajmitch: so you have to explicitly say refuse-eap and use mppe
<jmg> in hoary?
<jdub> yeah
<jdub> want to point people to stuff they can use now
<jdub> from the fridge
<jmg> does amarok support it?
<jdub> will also have "stuff in breezy" too
<jdub> dunno
<ajmitch> jmg: just put the debdiff somewhere we can see it (we usually get people to upload to revu.tauware.de)
<robitaille> jdub,  in Hoary?  podcast tool?  I don't think there are any.   ipodder is only in Breezy.  the Wiki has instruction to install it in Hoary
<jdub> wow, really?
<robitaille> is monopod still in revu?
<ajmitch> jdub: podcasts just weren't cool back in hoary's day :)
<ajmitch> robitaille: possibly, unless someone has uploaded it
<jdub> it's not in the repo
<jdub> ajmitch: yeah, stupid old hoary
<jdub> everything six months old SUCKS!
<robitaille> but that's only for breezy as well possibly.  Some people also use bashpodder, but that's not rad, and I don't think it is packaged
<ajmitch> jdub: yeah, I was thinking how old my (small) stack of hoary cds is now :)
<jdub> ok, i guess i will just point to ipodder and the wiki page for putting it on hoary
<robitaille> ajmitch,  hey, I only got my hoary CD a few weeks ago.  I still haven't finished distributing them :)
<Keybuk> hmm, anyone got much experience with either libcurl or libneon?  which is the easier HTTP library?
<ajmitch> breezy has spoilt me
<bob2> baz uses libneon
<bob2> that may be reason enough to use curl
<jdub> you have a nasty, whorish mouth
<jdub> </anchorman>
<Keybuk> I basically need to make an HTTP request to get a cookie, than make a couple of other HTTP requests with that cookie and get the data
<jdub> perl? python? :)
<Treenaks> LWP::Simple ;)
<jdub> (not necessarily in that order)
<mdke> is usplash coming back in breezy?
<bob2> it's already in breezy
<Treenaks> mdke: "coming back"? was it away?
<bob2> and is the default
<bob2> etc
<jdub> mdke: there's just a funny bug with it atm
<Keybuk> jdub: and then I need to parse the resulting data, and maintain a socket to a server which uses a hideous binary protocol that involves lots of bit-banging
<mdke> Treenaks, it is not working since yesterday
<mdke> jdub, ah cool
<Keybuk> so C is the language of choice here <g>
* jdub uploads 12MB via http
<jdub> Keybuk: sounds like you need a python enema
<Keybuk> jdub: Python is by far my favourite hammer
<Treenaks> Keybuk: but you're writing stuff for the initrd?
<Keybuk> sadly this is delicate bone china that needs glueing together
<jdub> python will turn up in our initramfs soon enough
<Keybuk> it so won't
<infinity> Keybuk : cURL's API is really simple to get into.  neon's not all that difficult either, though, so I'd pick whichever one's already installed on your system. :)
<jdub> yeah it will
<jdub> and you know it
<jdub> you're just trying to delay the inevitable
<Keybuk> I'll hardlink /bin/sh and claim it's sufficiently cut down that the language is slightly different <g>
<Keybuk> infinity: both seem to be
<jmg> ajmitch: see https://launchpad.net/products/kvpnc/
<jmg> malone is strange indeed
<Keybuk> curl looks ...odd
<Keybuk> neon looks more like I was expecting "make a request, send it, get the response"
<jmg> ajmitch: how did i do
<ajmitch> jmg: looks good, I think :)
<ajmitch> jmg: it would be good if the debdiff you made included a changelog entry
<ajmitch> and even nicer if you used some patch system, if possible
<jmg> how can i make a changelog entry without being a maintainer
<ajmitch> you don't have to be
<jmg> ajmitch: i was asking about patch systems before
<ajmitch> just add one in with your name & email
<ajmitch> right
<jmg> ajmitch: which one to use
<ajmitch> but it looked like you were asking how to make the patch to give to us
<jmg> ok
<ajmitch> we (motus) tend to use dpatch & have the patch sit in debian/patches
<ajmitch> otherwise it gets easy to lose across upstream revisions
<ajmitch> at least until Keybuk has hct ready for us :)
<jsgotangco> lists are borked?#
<jmg> ajmitch: added changelog diff
<bob2> hah
<ajmitch> bob2: yes sir? :)
<ajmitch> jmg: I see no change, you rebuilt the source package before running debdiff?
<jmg> arrgh
<jmg> i used debchange, thought that would have done it :P
<ajmitch> sure, but not to remake the diff :)
<jmg> next thing to do is patch kernel-source to remove my errata and see if speedstep really does hang
<jmg> 2 hours of battery life is bogus
<bob2> wow, nautilus changed a lot
<jmg> ajmitch: reuploaded
<ajmitch> jmg: new version number, we can't have the same one as in the archive :)
<jmg> ajmitch: how can i delete my attachments?
<ajmitch> no idea sorry
<Yagisan> Where do I report an important bug with the breezy installer (it stops the second stage of the install) ?
<mdke> Yagisan, bugzilla.ubuntu.com
<Yagisan> mdke: what package is the installer ?
<Yagisan> mdke: debian-installer ?
<mdke> Yagisan, guess so, in any case if that is wrong it will be reassigned
<Yagisan> mdke: thanks.
<zyga> morning
<Kamion> jdub: it's got a few problems: UI is OK but not superb, it shouldn't create a user in the first stage if you're doing an OEM install, it doesn't install language packs for you, and something else seems to be wrong with localisation of questions in oem-config itself
<Kamion> jdub: but it's not too far off, I think
<Kamion> Yagisan: in what way is the bug you reported different from #16742? it seems like a duplicate to me
<Kamion> Yagisan: the second stage of the installer is just a mostly-normal boot
<jdub> Kamion: cool, thanks :)
<jdub> Kamion: wondering at what level i should pitch it as a BREEZY NEW HOTNESS feature - worth mentioning, not worth saying it's the cure for cancer. :-)
<Kamion> jdub: you might like to try 'install preseed/file=/cdrom/preseed/oem.seed' with a vaguely recent install CD and see what you think yourself
<Kamion> I'll make that be a proper boot option before RC
<Yagisan> Kamion: I wasn't aware that the second stage wasn't any different. Did I at least get the right package ?
<janimo> Kamion, do ubuntu/kubuntu/edubuntu have different questions in the install process?
<Kamion> Yagisan: debian-installer is a fine catch-all package if you don't know installer internals
<janimo> if different packages are installed their debconf is run?
<Yagisan> Kamion: OK. I just noticed it does the same thing with ext2
<Kamion> Yagisan: ! stick that in the bug, I'll take a look
<Kamion> that sounds incredible
<janimo> I'd like to know how feasible is to ask the user to chose their preferred windowmanager in the xubuntu install
<azeem> janimo: doesn't XFCE have a default windowmanager?
<janimo> azeem, yes
<Kamion> janimo: different default answers, but basically the same set of questions
<janimo> but people said that if we have space left on the CD we may include icewm and fluxbox as a choice
<janimo> just a possibility if it turns out that it's easy to do
<Kamion> janimo: certainly debconf questions for different packages are asked, although generally without actually interacting with the user
<jdub> janimo: let users switch to them later - make it 'just work' by default :-)
<azeem> they could install it optionally
<janimo> jdub, ok
<janimo> it was the ubuntulite people's proposal
<jdub> janimo: the kind of users who care will know how to do it (or know how to find out)
<Kamion> janimo: thing is, you have to have some package that asks that question
<Kamion> janimo: the installer won't do it for you - not its place
<jdub> janimo: ah, so the ubuntulite people could easily use a kickstart or preseed file to sort that stuff out
<Kamion> and that gets kinda complex when multiple packages are involved
<janimo> Kamion,sure so if I have a dummy xubuntu-wm pacakge with debconf data in the default install it will ask the question?
<Kamion> janimo: yeah, although I tend to agree with jdub here
<janimo> sure, I'll take your word for it I know nothing bout the install process
<Kamion> janimo: the normal approach would be to have the window manager packages notice if multiple ones are installed, rather than having a separate multiplexing package
<jdub> holy crap!
<Kamion> kind of like how display managers work
<jdub> the fridge is a podcast too!
<jdub> :-)
<Kamion> that gets rather complex to sort out at short notice, though
* ajmitch runs to the fridge
<janimo> Kamion, ok we'll just stick with xfce default for now
<janimo> what is with Tasks: in the package descriptions?
<jdub> the codenames poll is running at 74% to 26% with > 400 votes
<janimo> I see edubuntu has different versions for some of them than ubuntu
<janimo> for some package apt-cache shows two package versions (ubu & edubu) 
<crevette> hello
<janimo> jdub, when I configure xubuntu-devel I missed the privacy option, and only enabled it 3 days later
<jdub> 210.55.230.17 - - [01/Oct/2005:11:39:18 +0100]  "GET /files/jeff-waugh-on-la-update.ogg HTTP/1.0" 200 12366022 "-" "iPodder/2.1 +http://ipodder.sf.net/"
<zyga> crevette: hello
<janimo> so the list archives are visible but are laggin 3 days behind
<jdub> janimo: heh :)
<ajmitch> jdub: that'd be me :)
<Kamion> janimo: that Task: stuff is essentially an implementation detail of the installer
<jdub> janimo: ah, no, that's a separate problem
<Kamion> anything that's to be installed as part of the Edubuntu desktop, e.g., gets Task: edubuntu-desktop
<Kamion> jdub: hmm, what should the OEM install do about users in the first stage? it really ought not to create a non-privileged user; but that means setting a root password, else you're locked out?
<Kamion> at the moment, passwd.config requires you to do at least one of (set a root password) and (create a non-priv user)
<jdub> is this for the initial setup phase, or the first boot phase?
<Kamion> initial setup
<Kamion> oem-config will ask you for a username/password/etc. if and only if there isn't a non-privileged user already
<jdub> maybe create an 'oem' user that is removed on cleanup?
<jdub> perhaps preseed oem:oem
<Kamion> ... and hope that the OEMs don't decide to install openssh-server? ;-)
<jdub> i don't get what that would break
<Kamion> the system is networked on firstboot; if we have a default password and the OEM decides to install openssh-server, you can start trying to opportunistically ssh to places with oem:oem
<Kamion> hmm, another option could be to ask the OEM to set a root password, and disable root again in oem-config
<Kamion> OEMs should be able to cope
<jdub> but you want them to log in as an unprivileged user
<Kamion> I don't want the OEM to log in at all
<jdub> and be able to happily kill off that user
<jdub> ah,ok
<Kamion> oem-config runs as root with a special display manager
<Kamion> it has to run as root anyway
<jdub> so how do i munge files?
* jdub thinks the opportunistic hacking thing is a really limited thing which could be documented as a warning :)
<Kamion> oh, I think they might as well log in as root for that
<Kamion> it's not like it should last long
<jdub> so no user, but they get root
<Kamion> and they'll always be munging system files, never user config
<jdub> yeah
<jdub> i guess oems can handle lack of purty desktop
<jdub> we can say "suffer in your jocks" in the documentation
<Kamion> probably depends on the OEM
<Kamion> so the flow at the moment is roughly:
<Kamion> first stage mostly as normal (modulo different username/password stage)
<Kamion> second stage mostly as normal, but at the end of base-config, it offers to let you run a system test
<Kamion> which is hwdb-client with the serial numbers filed off
<jdub> heh
<Kamion> when that exits, you get the gdm login screen, and can mess around
<jdub> as root?
<Kamion> (I guess that would be inconvenient without a root user - doesn't gdm forbid logging in as root by default these days?)
<jdub> yeah :-)
<jdub> perhaps not running gdm would be the right thing to do there
<Kamion> then when you next reboot, you get oem-config popping up; when you finish with that, you get gdm
<jdub> "now you can log in and muck around, or shut down ready for duplication"
<Kamion> alternatively, we could create an oem user as you say, but make the OEM supply a password
<Kamion> that would satisfy my concerns
<jdub> seems a little bit more ubuntuish
<Kamion> and avoid awkwardnesses with running as root
<jdub> ooh, we could set a background image with "HEY! DON'T SAVE STUFF HERE! THIS USER WILL BE REMOVED!"
<jdub> or maybe a translated zenity popup :-)
<Kamion> jdub: ESTRINGFREEZE
<Kamion> but apart from that, sure ;)
<jdub> heh
<jdub> hey spayne 
<jdub> congratulations on finally choosing a distribution
<jdub> though i'll reserve full judgement until next week
<jdub> :-)
<spayne> next week?
<Kamion> so ok, we preseed username = oem, fullname = "OEM Configuration", suffer a slightly obscure password prompt, and say something at the end of oem-config-test to tell them that they can log in as the oem user with the password they provided
<jdub> when you change your mind again
<spayne> jdub: what happens next week
<Kamion> I guess that'll work, with sufficient docs
<Kamion> cheers jdub
<jdub> Kamion: obscure because it's "enter password for ... say what?"
<Kamion> yeah
<Kamion> but a pain to fix at this stage
<Kamion> although we could let them enter the username of their choice, too ...
<jdub> Kamion: i can write up some stuff about doing system-level defaults configuration with gconf-editor for this, btw
<jdub> and just delete all users?
<Kamion> just makes it a little less trivial to delete later, but not insuperably so
<jdub> seems bong
<Kamion> remember the first one, delete that
<Kamion> or check the name from the installer debconf db
<jdub> surely we'd have to delete all users-- hrm
<jdub> hmmm
<ajmitch> jdub: good podcast :)
* jdub thinks about the server case, where you could set up a number of role-based users
<Kamion> I think if we looked up the name that the installer created, that would do
<Kamion> people who run oem-config on non-OEM installs would kinda lose though
<jdub> what do we do about uid 1001+ ? :)
<Kamion> we delete the OEM user *before* running adduser
<Kamion> the oem user wouldn't be used in the end-user-firstboot stage anyway
<Kamion> could easily set a special preseeded flag to say that it's an OEM install and it's OK to delete the first user
<jdub> right, but what if the intention of the dude installing the system is to prime it with, like, four role-based admin users?
<Kamion> could tell them that the user they created is only temporary, and to add additional users if they want users to persist
<Kamion> as long as it's only the installer-created user that's temporary, it doesn't seem too bad
<Kamion> dunno, it's a bit awkward
<jdub> perhaps, for this version, we should just document that it's only intended for the single user case, and we can worry about the other cases later :)
* infinity is still puzzled about why you need to create/delete an OEM user at all...
<jdub> infinity: so you can log in and set stuff up
<infinity> What's wrong with the pre-first-boot bypassing login?
<infinity> If you want them to have GUI config tools on that pre-first-boot, just do a hard startx, bypassing both login and gdm.
<infinity> Then when they're done, put the proper first-boot sequence in place.
<jdub> running as root? bah
<infinity> They need to gain root to do any system configs ANYWAY.
<jdub> Kamion: maybe you could create the oem user with uid 20000
<infinity> I don't really see the difference here.
<Kamion> jdub: btw, oem-config doubles as a proof-of-concept of the debconf+python+glade idea we discussed way back in Oxford
<jdub> infinity: running everything as root sucks
<jdub> Kamion: oh, seriously? rad!
<infinity> jdub : <shrug>... I'm just seeing this as an extension of the (run-as-root) installer.
<Kamion> yeah, I filter the debconf protocol and pop up python/glade dialogs whose answers are then fed back into the debconf db before returning control
<jdub> how much does that help a future ubuntuexpress?
<infinity> It's not like they're logging in to USE the system, just configure an image.
<jdub> infinity: being d-i, which i trust more in a user's hands running as root than, say, nautilus
<Kamion> jdub: I tried to make it fairly generic, although it's rather hard to write code in that model; we'll see
<Kamion> I tend to agree with jdub here
<infinity> jdub : What are you afraid nautilus will do, and what, precisely, are we trying to prevent these oems from doing?
<Kamion> although using nautilus to do stuff as root when you aren't root is hideously painful, no?
<jdub> infinity: "hrm, look at all this crap, /me drags /dev to the trash"
<Kamion> either we tell them to do everything at a shell, or we run nautilus as root ...
<infinity> No one would, they'd just fire up a console, sudo themselves, and fiddle that way.
<jdub> Kamion: yes
* jdub personally thinks there are *NO* use cases for nautlius-as-root
<infinity> And if we're telling them to do everything with a shell, then they don't need X at all, and still don't need an OEM user.
<jdub> and every time a possibility is mentioned, it's better solved in other ways
<Kamion> yeah, we could just shove them into a login shell
<infinity> jdub : If an OEM drops /dev in the trash, I hardly think that's our problem.
<infinity> jdub : They can do the same on the command line, too.
<jdub> infinity: but we're not. i would like to write gconf-editor docs for setting defaults and stuff.
<jdub> infinity: nevertheless, running the entire desktop as root is crack, and we don't have to anyway
<infinity> jdub : You can just run X with gconf-editor as the foreground application. :)
<Kamion> jdub: re above, I don't think the uid of the oem user really makes a significant difference
<jdub> Kamion: so, i reckon making an oem user with a weird uid would work - if the dude setting it up adds users, they get to exist at 1000+ -> in fact, we could even skip user creation in first boot if uid 1000 exists
<infinity> (But seriously, I'm just trying to understand what you intend to prevent.  People can delete things all manner of ways, if an OEM breaks their image due to stupidity, that's not our problem)
<Kamion> we already skip it in that circumstance, but I still don't see how that makes the slightest difference
<infinity> The OEM is meant to be another handholding buffer between us and the user, not someone's whose hand WE have to hold.
<jdub> infinity: i intend to prevent any desktops running as root.
<infinity> (In general)
<Kamion> although, hmm, I guess it means OEMs can add a user at 1000 and then have the firstboot prompt skipped
<infinity> Kamion : The only nice thing about using a weird uid is that they get 1000 for adduser.
<Kamion> ok, I can see how that would work
<jdub> Kamion: hrm; if the oem user is created as uid 1000, and i create another one, it's 1001 -> so you can never skip first boot user configuration because there's never a uid 1000 user
<jdub> yes
<Kamion> jdub: yeah, gotcha, belatedly :)
<jdub> :-)
<jdub> that'd be rad
<jdub> i think that solves the server case
<Kamion> ok, if I can make passwd.config do that somehow, I will
<jdub> very neatly!
<infinity> ... server?
<jdub> sweet :-)
<jdub> infinity: we were talking about a case above where you want to prime the machine with a bunch of users
<hno73> Kamion, Riddell, mdz: did you guys get my email about space constraints on the live CD?
<jdub> it's the kind of thing that would help when building departmental server images and stuff like that
<hno73> Is 650MB a hard limit?
<infinity> jdub : Yeah, but I'd also assume that an oem-config server setup would start with ubuntu's "server" install, so no GUI, no frills, and we can just drop you into a root shell.  The oem user there would be useless (as you'd just "sudo su -" out of the oem user's shell to configure it anyway)
<hno73> If so, I have a new suggestion. But OOo2, FF and perhaps Gaim on the Ubuntu CD
<Kamion> hno73: we've been discussing that a lot. I think moving past 650MB for the Ubuntu live CD will get me a lot more bug reports; I already get a *LOT* due to bad media
<Kamion> hno73: but it's not hard, just the subject of debate
<hno73> and all sorts of other cool winfoss on the Kubuntu one
<Kamion> hno73: frankly, I'd much rather use extra space on the Ubuntu live CD for language packs
<infinity> Where does one find either a burner or a CD blank limited to 650MB anymore?
<jdub> infinity: well, that's a different issue to the multiple user problem we were figuiring out :)
<Kamion> hno73: our live CD is English-only right now, due to space constraints. This sucks.
<hno73> Kamion: I agree
<jdub> Kamion: i'm excited. :-)
<Kamion> infinity: pretty sure I've seen them for sale in the UK
<hno73> How much space could you sensibly use?
<Kamion> not that unrecently
<infinity> Kamion : The UK is weird.
<jdub> Kamion: which means i'm going to pimp it more. which is dangerous. ;-)
<Kamion> hno73: arbitrary; probably ask pitti for numbers
<Kamion> he's got some table somewhere of what they add up to
<Kamion> *ideally*, I'd like to have the top dozen or so languages there
<Kamion> but I suspect this is an unrealisable ideal
<Kamion> jdub: as long as you try it first so that you know what you're pimping :-)
<hno73> Kamion: So If we dump OOo2 and a few minor things, we can have the whole winfoss part down to 40-50mb
<infinity> Could we produce two sets of ISOs, at 650 and 700?
<jdub> Kamion: haha
<Kamion> infinity: no thanks
<infinity> (The pressed ones can be 700 with no real issues)
<Nafallo> http://people.ubuntu.com/~pitti/langpacks/support-bysize.txt
<Kamion> I have enough to test
<infinity> Yeah, true that.
<hno73> If we add OOo2 to the pressed version only, that shouldn't involve any testing
<hno73> All ISOs would have the same language packs (quite a few)
<Kamion> hno73: sorry, but I really have to refuse to have different pressed and burned images
<infinity> We'd need to test the larger ISO to make sure OOo2 isn't borked.
<hno73> The download version would be sans OOo2 and pressed with it
<Kamion> it's just not an option for me
<Kamion> we have 27 images for release at the moment
<Kamion> no, 24, no Edubuntu live CD
<hno73> Kamion: OK, I'm sure you have good reasons for that
<hno73> right, ok
<infinity> Time constraints, I'm with Kamion, though I think it sucks.
<Kamion> and ultimately, *somebody* has to manually sanity-check every one before release
<Kamion> even if it's only once ...
<Nafallo> maybe we should skip winfoss on the *ubuntu-cds and point people to theopencd...
<Kamion> if nobody else does it, that somebody ends up being me
<hno73> Do the same language packs generally gt used for Ubuntu and Kubuntu?
<Kamion> hno73: so, I'm kind of ambivalent about 650MB/no-OOo2 vs. 700MB/OOo2
<Kamion> hno73: different selection
<Kamion> hno73: I'm probably going to give into using 700MB CDs, but I think it's a shame to do that without improving our language support at the same time
<hno73> Kamion: well, I can prepare both versions so we can decide close up to the wire if need be
<Kamion> hno73: so, 130MB for the tarball with OOo2 uses up 30MB of the extra, which leaves 20MB; if we can get a sensible number of extra langs into that, I think that's worth it
<Kamion> I'm not sure what the numbers for Kubuntu are at the moment; IIRC they're already oversized for 650MB
<Kamion> so the tradeoffs may be different there
<hno73> Kamion: cool, let me try to slim it down even a bit more
<Kamion> from pitti's table, it looks like an extra 20MB should easily give us the top-dozen languages
<HiddenWolf> Kamion, what will caving in give you? A year from now, we'll have added some more goodies, and this discussion will go about using dvd-images
<Kamion> HiddenWolf: that's certainly the problem
<Kamion> maybe then we go beat up sabdfl to remove the python modules from desktop ;-)
<HiddenWolf> Kamion, if only we'd want to use mono/beagle and that auric applet that lives in gnome-cvs, that'd be your 20mb gone.
<Kamion> but I'll fight my future battles when it's the future
<Kamion> we might as well fill up the images we've got now
<HiddenWolf> :)
<Kamion> and look at the FirstAgainstTheWall spec at UBZ
<Kamion> if we keep the install CD to 650MB, then it's not a showstopper if the live CD grows to 700MB
<Kamion> and the install CD isn't under so much pressure
<Kamion> anyway, it's Saturday, off to do weekend things
<jdub> later Kamion 
<TheMuso> O/c
<pitti> Hi
<ajmitch> hi pitti 
<jdong> pitti: what's the status on that firefox backport?
<pitti> jdong: on my list for next week, unless Diziet is faster
<pitti> jdong: do you have a debdiff already?
<jdong> pitti: no :(
<jdong> pitti: I'll be patient :)
<crevette> why ubuntu doesn't provide an MTA anymore ?
<pitti> crevette: we provide two, but not by default
<pitti> crevette: the reason is mainly our "no open ports in the default install" policy
<crevette> pitti> yeah I know, but in the old days postfix was provided
<pitti> crevette: so we had to cripple postfix in warty and hoary
<crevette> :)
<pitti> crevette: yes, but it didn't really work
<pitti> crevette: now, if you need need an MTA, just install exim or postfix and get something working
<crevette> done
<crevette> :)
<Chipzz> hi
<Chipzz> something is wrong with the usplash package I suspect
<infinity> Define "something".
<Chipzz> I've been getting this message for the past couple of days:
<fabbione> are lists.u.c down?
<Chipzz> Setting up linux-image-2.6.12-9-686 (2.6.12-9.19) ...
<Chipzz> cpio: ./usr/lib/usplash/usplash-artwork.so: No such file or directory
<infinity> fabbione : I think so.
<fabbione> i can see new source pkgs.. but no mails to changes
<fabbione> infinity: ok
<infinity> Chipzz : sudp update-alternative --auto usplash-artwork.so && sudo dpkg-reconfigure linux-image-`uname -r`
<Chipzz> I tried googling for that message, but no luck; also no luck on packages.ubuntu.com for /usr/lib/usplash/usplash-artwork.so
* fabbione just saw a new gcc-4.0 and wonders what is going to break
<infinity> Chipzz : You're a casualty of tracking breezy a bit TOO closely, and the upgrade path from the one broken version being a bit wrong.
<infinity> Chipzz : s/update-alternative/update-alternatives/
<infinity> If only I could type...
<Chipzz> infinity: aha; so, why wasn't there anything in the changelogs?
<Chipzz> I have apt-listchanges installed; a mention of that would have fixed the problem for me
<infinity> Chipzz : Changelogs usually don't mention when the current code is broken. :)
<infinity> * Inserted bug; cope.
<infinity> I meant to fix it in the usplash upload I did, but I think I got sidetracked due to it being 9am and me not having slept the previous night.
<Chipzz> infinity: well, it's fixed now :)
<Chipzz> infinity: thx for the help :)
<spayne> nice new artwork!
<bddebian> Hello
<eruin> pitti, here?
<pitti> Hi eruin 
<CarlFK> Anyone know were the Sep 29/30 messages are? http://lists.ubuntu.com/archives/ubuntu-devel/2005-September/thread.html
<CarlFK> or I guess, why aren't they there?
<Chipzz> infinity: more usplash(-related) brokeness (I suspect)
<Chipzz> before (when usplash didn't) work, I could shutdown gdm from the console (with sudo /etc/init.d/gdm stop)
<Chipzz> now (usplash working), if I do that, gdm shuts down, but the text-console is garbled (well, not exactly garbled, but the bottom half is empty when before it was not), and doesn't show any text I type (if it is accepted at all, which I'm not sure)
<Chipzz> ctrl-alt-delete does work though
<Chipzz> but shutting down gdm from within X (same command as above) does not give these problems
<Chipzz> (nvidia (GeForce 2 Go) chipset btw
<infinity> Chipzz : Chipset shouldn't matter. :)  Let me look at that.
<infinity> Chipzz : gdm stop from a virtual terminal (ie: text console)?
<infinity> Bah.
<infinity> Chipzz : You're being dumped to tty8 after you stop gdm.  If you hit Ctrl-Alt-1, you'll get a useable console.
* infinity blames mvo for that.
<Chipzz> infinity: nopes
<Chipzz> hitting alt-f1 does not work
<Chipzz> tried that
<infinity> Chipzz : Well, that's what happens to me here.  I get dumped in vc8, which isn't actually active.
<Chipzz> if I hit alt-f8, it shows the bootup messages
<Chipzz> (hit alt-f8 when it still works)
<mvo> Chipzz: what do you see on vt1-6? nothing at all? (alt-f1-6)
<Chipzz> mvo: no reaction, nothing works
<Chipzz> except cad
<infinity> mvo : Who do I blame for usplash running on vc8?.. I can't find it in the changelog.
<Chipzz> it actually *is* dumping me back to tty1, which is where I shut down gdm from
<mvo> not login prompt anywhere? strange
<mvo> infinity: uplash -c runs it in vt8. it's like this forever
<infinity> Chipzz : Oh, that's more curious.
<Chipzz> mvo: it shows half what was on the screen before - which is the login prompt
<infinity> mvo : Oh.  Maybe I'm unobservant, then.
<Chipzz> but it is not active
<mvo> infinity: but it was broken by jbailey when he moved udevstart after usplash and /dev/tty8 wasn't created
<Chipzz> ie no blinking cursor or anything
<infinity> mvo : I assume us getting dumped back to vc8 is because gdm stores the last vc we were on when it runs?...
<mvo> infinity: probably, yes
<infinity> But Chipzz thing is more fun...
<mvo> infinity: if you run without gdm, the usplash stop script takes care of chvt
<Chipzz> btw, if I shutdown gdm from within x, and then start it again from the console, stopping it fmor the console works as expected
<infinity> Chipzz : Typing gets you nothing?... "reset", "clear", etc?
<Chipzz> s/fmor/from/
<Chipzz> infinity: nothing at all
* infinity wishes he could reproduce this.
<mvo> Chipzz: if you run without usplash everything works fine I assume?
<Chipzz> well, nothing that shows up on the screen anyway
<Chipzz> mvo: yes, then everything works fine
<infinity> Chipzz : Anything that doesn't show up on the screen?... ie, try "sudo reboot". :)
<infinity> I want to know if the VC is dead, or just... invisible.
<Chipzz> infinity: would access to the laptop help any?
<infinity> Chipzz : Only if it was in my hands...
<Chipzz> I can give you an account if you wish
<infinity> Stuff like this is hard to "see" without seeing.
<Chipzz> well I do have a desktop here that I can get online frmo at the same time
<infinity> Hrm.
<infinity> Well, an account may help.
<infinity> Maybe I can hack at stuff remotely and have you test things.
<slomo> elmo: please sync swt-gtk from debian... this one builds on amd64
<Chipzz> infinity: hmmm I was messaging you in private, but you seem to have messages form unregistered users disabled
<mvo> Chipzz: I wonder if that might be caused by the recent addition of the vesafb driver?
<infinity> Doesn't freenode have that disabled, period?
<infinity> mvo : I'm using vesafb with usplash.
<azeem> you can opt-in
<jdub> you can turn it back on again
<Chipzz> I think the messages stuff was enabled by default
<infinity> Ahh, how do I opt in?
<Chipzz> mvo: not sure
<mvo> Chipzz: you could disable it (for testing) in /usr/share/initramfs-tools/scripts/init-top/usplash ... (and then re-generate your initrd)
<Chipzz> mvo: let me try that
<mvo> infinity: maybe your vesa-bios behaves differently (i.e. better)
<infinity> I dunno... Once the fb is actually loaded, it should either work or not work.
<infinity> There's not a lot of grey area there.
<segfault> hello.
<infinity> (Except when doing fun things like suspend/resume)
<mvo> infinity: hm, ok
<Chipzz> mvo: change line 25, I presume?
<Chipzz> ok, so entering a command when the console is in that state doesn't work either
<Chipzz> (sudo reboot does not work)
<mvo> Chipzz: I assume it does not work for your without vga= something?
<infinity> Alright, so it's not invisible or black-on-black or anything, the VC is actually just plain not there.
<Chipzz> it shows the first 13 lines of vc1
<Chipzz> no cursor
<mvo> Chipzz: in this case, forgot the vesa change
<Chipzz> but I can ssh into it
<mvo> if you have no keyboard ..
<Chipzz> mvo: I made the vesa change, but have not actually rebooted with the new ramfs
<Chipzz> mvo: I do, because ctrl-alt-delete reboots the laptop
<Chipzz> or do I?
<infinity> Chipzz : If you ssh in and "rmmod vesafb ; insmod vesafb", does that do anything interesting?
<Chipzz> hmmm wait
<infinity> s/insmod/modprobe/
<Chipzz> If I press alt-f1
<Chipzz> and then type sudo reboot
<Chipzz> it does reboot
<infinity> Ahh.
<infinity> Right, you're being parked on vc8 when gdm exits, we established that.
<infinity> And vc8 isn't active, so no keyboard input.
<infinity> So, then you hit vc1, and you can type, but get no output?
<infinity> FUN.
<Chipzz> the screen shows (the upper half) tty1 when coming from X though, but I suspect it actually is on tty8
<infinity> How do you know it's the upper half of tty1?
<Chipzz> parked on vc8, but with the output of vc1
<infinity> vc8 should have all the init script output junk on it.
<Chipzz> because I was editing the file mentioned before on tty1, and it shows the remains of vim
<infinity> Ahh. :)
<infinity> Kay.  Even more curious.
<infinity> Chipzz : Did you regen your initramfs yet?.. If not, don't.
<Chipzz> I did
<Chipzz> hmm curious
<janimo> I have a dpatch situation
<Chipzz> it doesn't show the last line completely
<janimo> there's a debian/patches/00_patch
<janimo> and I want to fix the same problem (conflicting patches differently)
<infinity> Chipzz : Oh, wait.  Are you using vga16fb, or vesafb?
<janimo> do I make a 01 which applies over 00
<infinity> Chipzz : (do you have "vga=nnn" on the command line?)
<janimo> or patch the debian patch itself?
<Chipzz> it shows "Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by"
<janimo> I assume 1 is cleaner but may need additional rules file hacking
<infinity> janimo : Tailor the Debian patch, if you want to change it.
<Chipzz> but the curly thing under the y is chopped off, so it looks like a u
<infinity> janimo : If you want to change different things, add your own patch.
<janimo> tailor, you mean overwrite it with myversion right?
<jdub> "Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by this character encoding."
<Chipzz> root@Vertex:~ # cat /proc/cmdline
<Chipzz> root=/dev/hda5 ro quiet splash
<mjg59> Ah, it's just vga16fb breakage, then
<Chipzz> jdub: ROFL :)
<infinity> Chipzz : Ahh, I think you're suffering from vga16fb being teh suck on some hardware.
<infinity> Chipzz : This is a laptop, you said?
<Chipzz> infinity: dell inspiron 8600c
<janimo> mjg59, just to be sure can /proc/acpi/ac_adapter contain more than one entry?
<infinity> Chipzz : Panel resolution?
<Chipzz> panel? you mean lcd?
<Chipzz> lcd is 1280x800
<mjg59> janimo: It's theoretically possible, but very unlikely
<janimo> mjg59, ok
<Chipzz> hmmm both vga16fb and vesafb are loaded
<infinity> Chipzz : Can you try booting with vga=791?
<infinity> (That'll be 1024x768, so it may look like ass, but it should work)
<Chipzz> http://chipzz.studentenweb.org/modules
<Chipzz> lemme try
<Chipzz> rebooting...
<segfault> jdub: did you recieve my mail?
<Chipzz> infinity: with vga=791 I have a corrupted text-console when switching back from X
<Chipzz> without restarting gdm that is
<Chipzz> full of garbage
<infinity> Wow, your laptop is love.
<Chipzz> uhu :)
<infinity> Okay, no vesa for you, then.
<infinity> (Did usplash work okay in that mode, though?)
<Chipzz> but X stays fine :)
<Chipzz> didn't check, was reading this screen
<Chipzz> nopes
<Chipzz> garbage instead of usplash
<infinity> Kay. :)
<mjg59> Chipzz: When did you last regenerate your initramfs?
<Keybuk> fabbione: do you mind doing me a small favour?  Can you check some of my code for IPv6-correctness
<Chipzz> hmmm after commenting out the vesa stuff :P
<Chipzz> which amy explain :P
<Chipzz> but I think that shouldn't matter
<fabbione> Keybuk: sure.. if it's not too complex
<Chipzz> garbage from the moment there should be kernel messages
<Chipzz> so even before usplash starts
<infinity> Erm, the vga=??? stuff only works with vesa. :)
<mjg59> Chipzz: Commented out what vesa stuff?
<Chipzz> infinity: yes, but the vesa module is still included, right?
<Keybuk> fabbione: just "open a socket, look up a host and connect to it"
<fabbione> Keybuk: i can also test it :)
<infinity> mjg59 : You missed the part where mvo had him comment out vesafb from init-top. :)
<Keybuk> fabbione: http://www.netsplit.com/bzr/live-f1/src/stream.c
<mjg59> Oh, right. Yes, that's not going to work.
<mjg59> It'll be loading vga16fb, which will then explode everything
<fabbione> Keybuk: checking now
<Chipzz> mjg59: changed line 25 of /usr/share/initramfs-tools/scripts/init-top/usplash
<infinity> Speaking of exploding, I think I'm going to go pretend it's the weekend some more.
<Chipzz> infinity: have a nice weekend :)
* infinity hands Chipzz and his framebuffer issues off to mjg59, since he's looking more helpful, and less 1am-tired.
<Chipzz> infinity: thx :)
<mjg59> Chipzz: Reinstall usplash and regenerate your initramfs
<mjg59> mvo: Uh, adding vesafb support to usplash changed nothing. The only thing that happens now is that vesafb gets loaded before usplash instead of after it
<Chipzz> I changed the line back to the original and am regenerating the initramfs
<mvo> mjg59: ok, thanks for explaining that
<fabbione> Keybuk: it looks ok, but there is only one thing you don't parse 
<Keybuk> fabbione: oh?
<fabbione> Keybuk: struct addrinfo has a pointer to a list
<fabbione> hey Saba_Z 
<fabbione> Keybuk: because the same host name can have multiple ips
<Saba_Z> fabbione: Hey
<fabbione> Keybuk: with your way (that works) you always hit the first one
<Keybuk> right, I should iterate that and not just try the first one?
<fabbione> Saba_Z: satisfied? ;)
<fabbione> Keybuk: it depends from glibc behaviour.. really
<Saba_Z> fabbione: thanks , lots of fun:D
<Keybuk> *nods*
<fabbione> Saba_Z: cool! :)
<fabbione> Keybuk: but anyway.. for a first shot is fine
<Keybuk> cool
<Keybuk> been a while since I done it
<Keybuk> thanks
<fabbione> Keybuk: you might want to try to use other ip's (if any) in case you fail to open a connection with the first one
<Saba_Z> fabbione: i cant continue the projectb but reza promised me to continue it with his friends
<fabbione> Saba_Z: oh.. 
<fabbione> i see
<Saba_Z> fabbione: what are the most important things which are missing ?
<fabbione> Saba_Z: for now it looks fine
<fabbione> Saba_Z: but we will talk about it again at UBZ
<Saba_Z> fabbione: ubz?
<Chipzz> aha
<Chipzz> all works fine with vga=791
<fabbione> Saba_Z: Ubuntu Below Zero.. next conference in Montreal
<Chipzz> (and line commented back in)
<fabbione> Saba_Z: wiki.ubuntu.com/UbuntuBelowZero
* desrt . o O ( hmm.. where's that dh fellow... )
<Saba_Z> fabbione: i think there should be a better linux support for authentication
<fabbione> Saba_Z: you are welcome to add your ideas in the wiki.. or mail them to me
<fabbione> Saba_Z: because there will probably be another SoC next year
<fabbione> Saba_Z: and proposing improvement won't be an issue i guess
<segfault> update-notifier is not completely translated after the languague pack released yesterday, although it is fully translated in Rosetta. Does anyone know why?
<Saba_Z> fabbione: yes , but i work just for fun ..
<fabbione> Saba_Z: it has to be fun first!
<fabbione> Saba_Z: i am just sad you won't continue working on it
<fabbione> because you have done an excellent job
<Saba_Z> fabbione: i dont continue the development as an active developer but i will help the new developers to continue until they get started 
<fabbione> Saba_Z: that's good too
<mvo> segfault: what bits are missing in the translation?
<fabbione> Keybuk: you also want to add a check for the socktype you are asking and the one you get back from calling getaddrinfo
<fabbione> Keybuk: that might be another reason for parsing the list
<Saba_Z> fabbione: and i can work on spare time
<fabbione> otherwise we should check how glibc will return that list sorted
<segfault> mvo: the main app is untranslated, like the strings "Packages to install:", "Software Updates", "Available Updates"...
<fabbione> Saba_Z: sure :)
<fabbione> Saba_Z: that's what a lot of people already do
<Keybuk> fabbione: the docs say that asking for a particular socktype means you only get those back
<fabbione> Keybuk: what manpage are you looking at?
<Keybuk> Stevens Unix Network Programming v1 (second edition)
<fabbione> i am reading man getaddrinfo
<fabbione> -ENOSUCHBOOK
<fabbione>        The  hints  parameter specifies the preferred socket type, or protocol.
<fabbione> "preferred" is the keyword for me to say that it will return all of them
<fabbione> but well..
<Saba_Z>  Isn't there any breezy+1goals yet?
<Nafallo> Saba_Z: no
<jdub> new feature on the fridge! :)
<Nafallo> yay
<jdub> on the left hand side there's a "shuffle"
<jdub> it shows random cool stuff :-)
<tseng> not seeing it
<jdub> RELOAD HARDER
* jdub double checks that anon users can see it :o
<jdub> whoa, n/a
<Nafallo> yes
<Nafallo> I see n/a :-P
<infinity> mvo : Do you have open bug reports about update-notifier spinning the CPU for no good reason out of the blue?
<infinity> mvo : Cause it's just started eating mine..
* jdub fixes
<glick> hello
<glick> you guys are all cvs experts id imagine?
<jdong> glick: I think Ubuntu devs are more bazaar/svn/svk experts :)
<glick> in cvs do should you update before you submit?
<glick> an update wont just over write your file will it?
<bmonty> glick: yes and no
<CarlFK> glick - in svn, you will get a confict and it will create file.1 and file.2
<CarlFK> guessing cvs is the same.
<bmonty> cvs won't overwrite your local changes
<jdong> glick: depends on the situation
<jdong> glick: in no case is any information lost
<CarlFK> as long as we are OT, anyone in charge aware about problems with the mail lists ?
<glick> ok kool
<jdong> glick: when changes are made in different parts of files, they're both "merged" together automagically
<jdong> glick: but when there's overlap, CVS will mark your file as conflicting, and allow you to manually merge together the changes
<jdong> glick: then again, your fixed merge could theoretically conflict, and you can be spending the rest of your life and afterlife resolving conflicts :)
<Chipzz> jdong: no, it will insert ugly markers
<Chipzz> <<<<<<<<<<<<
<Chipzz> ============
<Chipzz> >>>>>>>>>>>>
<jdong> Chipzz: well, that's CVS's way of "helping you out" ;)
<Chipzz> like that
<Chipzz> doesn't exactly qualiify as "not modify" in my book
<jdong> Chipzz: no; it doesn't. I never said that CVS doesn't modify your files. The merge symbols are especially annoying in certain preformatted syntaxes
<jdub> Nafallo, tseng: fixed :)
<jdub> spayne: you're monopolising the flickr results for ubuntu ;-)
<Nafallo> jdong: I know :-)
<Nafallo> jdub: ^ sorry :-P
<jdong> Nafallo: tab button evil :)
<Nafallo> indeed ;-)
<spayne> jdub: is that a bad thing?
<jsgotangco> hey hno73
<spayne> Nafallo: are you a MOTU?
<jdub> spayne: heh, no, just the top 10 results are your 'tour'
<Nafallo> spacey: yes, and in a meeting ;-)
<hno73> jsgotangco: hey
* spayne is sick of being called spacey
<jdub> so the fridge's flickr shuffle is all you
<Nafallo> lol
<Nafallo> solly :-P
<hno73> Has System -> Admin -> Boot options been removed on purpose?
<jdub> hno73: seb128 may have disabled it because it sucks
<hno73> The new kernel install removed my WinXP Grub link 
<spayne> Nafallo: when you are finished, could you check my resapplet package for me?
<hno73> How to I set the boot options from the CLI?
<jdub> hno73: edit /boot/grub/menu.lst
<hno73> What file do I edit?
<Nafallo> spayne: dunno. I have a bunch of reallife stuff I have to take care of.
<hno73> jdub: thanks :)
<jdub> title           Windows XP
<jdub> root            (hd0,1)
<jdub> chainloader     +1
<jdub> boot
<jdub> 
<hno73> great
<jdub> ^ stick one of those in, changing the root spec depending on disk/partition
<hno73> I don't often use XP, but I really do need it now :)
<jdub> your secret is safe with us
<jsgotangco> jdub: hmm you need to send the article to an editor to post to fridge?
<jdub> jsgotangco: atm yeah
<jdub> jsgotangco: fridge-devel@lists.ubuntu.com
<jsgotangco> ahhh
<Chipzz> other question... anyone with an alps touchpad working on ubuntu? I had the scrolling functionality working a while ago, but then it broke...
<jsgotangco> Chipzz: mine's borked as well in a Tecra
<Chipzz> (the reason I'm asking here is I have had it working with this config a while back, so something must have changed...)
<Chipzz> hmmmm :/
<hno73> jdub: I've emailed you output from that live CD; lo and /etc/hosts
<hno73> seems lo is enabled
<glick> hey is it possible in ubuntu to have a icon on your desktop that when you click on it it opens up a console ssh shell on a remoe machine without the need to put in your password and such?
<Treenaks> glick: sure
<glick> Treenaks, how?
<mjr> yes, by using ssh-agent for authentication (should be started automatically, you need to ssh-add) and creating the appropriate shortcut
<Treenaks> glick: just create a regular one, which asks for a password
<Treenaks> glick: then look up how ssh-agent works :) it's started automatically, all you need is ssh-add and a key
<Chipzz> heh
<Chipzz> ssh is outdated :P use rsh with kerberos enabled :P
<Chipzz> ;)
<Treenaks> Chipzz: does that encrypt everything?
<Chipzz> no
<Chipzz> but you do not have to enter a password ;)
<jdub> the auth is secure, but what goes over the wire isn't
<Chipzz> (and that remark was not intended seriously btw ;))
<Treenaks> Chipzz: defeats the purpose then, what if you ssh from that remote host#
<Chipzz> Treenaks: no problem if your ssh is kerberos-enabled
<Chipzz> well actually there is more than one side to enabling kerberos for ssh, but that's another story
* Chipzz mumbles something about theoware :P
<Chipzz> but if all you need is just secure authentication, kerberos is fine. makes sense for large file transfers over ftp for example
<Treenaks> depends on the file and the network :)
<Yagisan> so very true
<Chipzz> say a movie for example
<Chipzz> I couldn't care less if anyone noticed I was pulling over a 700MB movie :P
<Chipzz> well maybe under some circumstances I would, but then :P
<Chipzz> anyway scp/sftp make less sense there (cpu overhead for encryption), and ftp (without telnet) makes less sense too (password sniffable)
<Yagisan> I'd rather ssh anyway (with my thin pipes I want compression enabled)
<Yagisan> if you use blowfish - it's not much cpu overhead
<Yagisan> my vpn endpoints are sub 300Mhz - they use blowfish and sit idle most of the time with full traffic load
<Yagisan> but that is over 1500/256 adsl
<Chipzz> it will still slow down the transfer
<Treenaks> Chipzz: that's why my CPUs have VIA Padlock (i.e. on-die AES :))
<Chipzz> I doubt you can use (not even close to) 100% capacity of a 100MB network
<jsgotangco> night all
<Yagisan> depends on the pipe - with my pipes we benchmarked it. the bottleneck is the pipe
<Treenaks> Chipzz: padlock scales up to several gigabits afaik
<Chipzz> well not 100% anyway, collisions and stuff
<Yagisan> night jsgotangco
<Chipzz> but then ssh has to be compiled iwth support for it
<Treenaks> Chipzz: only openssl
<tseng> jdub: i just see seb payne
<Chipzz> same thing :)
<tseng> jdub: no shuffle
<tseng> jdub: oh
<tseng> jdub: i get it
<Chipzz> anyway this is hardly relevant here :)
<Chipzz> and I have to go to the shop
<jdub> tseng: there will be lots of different/cool/wacky stuff in the shuffle :)
<tseng>  jdub i want a pony
<tseng> *refreshes harder*
<jdub> tseng: keep refreshing :)
<Treenaks> argh! ipodder requires xmms
<tseng> jdub: YES
<robertj^> mdz: you handy?
<eruin> hey, usplash worked fine on a fresh install of colony 5, but is now nowhere to be seen. should I submit a bug about this or is it intentional?
<infinity> eruin : Do you see any error messages when you run "sudo dpkg-reconfigure linux-image-`uname -r`"?
<eruin> apart from a message about no splash image found, no
<infinity> No cpio error, or such?
<eruin> nope. I think it stopped working on a kernel upgrade
<eruin> oh, wait
<eruin> Yeah, I see a cpio error. can't find /usr/lib/usplash/usplash-artwork.so
<infinity> Right.  I'll uplod a fix for that right now, it seems to have been more widespread than we thought.
<eruin> sorry, I'm oblivious when it comes to non-english error messages ;-)
<infinity> You can wait for that, or fix it with "sudo update-alternatives --auto usplash-artwork.so && sudo dpkg-reconfigure linux-image-`uname -r`"
<eruin> cheers
<mjg59> jdub: Hello?
<jdub> yo mjg59 
<mjg59> jdub: You were looking for me yesterday?
<jdub> probably
<jdub> oh yeah
<jdub> i was asking about voip stuff
<jdub> wanna do an interview some time?
<mjg59> For what?
<tseng> :D
<jdub> for the fridge
<jdub> about laptop mission, usplash, stuff like that
<mjg59> Ah, ok
<mjg59> Could do
<mjg59> I've got no voip stuff, though
<jdub> got windows?
<mjg59> Oh, software-wise I can manage
<mjg59> But I don't think I've got anything with a microphone
<jdub> oh right
* j^ checks all windows of his flat for microphones
<jdub> yo j^
<jdub> j^: the trick is to figure out if there are any laser beams pointing at your windows, measuring vibrations
<jdub> microphones are so old hat ;)
<j^> you could use text2speech
<robertj^> nows an excuse to go buy a bluetooth headset and adapter
* j^ pulls the plug from this huge WiFi antenna he found at one window
<slomo> multiverse packages are moved to multiverse automatically, right? i should not set the sections to multiverse/bla?
<slomo> infinity / lamont-away: can you remove eclipse from asp? my next upload works at least on x86, ppc and amd64
<jdub> slomo: ooh
<slomo> jdub: ?
<doko_> slomo: please don't touch eclipse.
<slomo> narf
<slomo> why?
<slomo> now i worked the complete afternoon on it and you tell me not to touch :(
<doko_> I told you already yesterday, the packages are ready
<slomo> you did? i didn't noticed it then :( where are the packages?
<doko_> http://people.ubuntu.com/~doko/
<slomo> thanks, i'll take a look at them... what is holding them back?
<doko> the buildd's need the just uploaded gcj-4.0
<slomo> ok... hm, looks nice... you used Michael Koch's package as a base? i took some patches from him and changed some minor stuff in rules to make it work... well, your's seems to be the cleaner solution as the old package had some other issues which michael fixed...
<slomo> when do you plan to upload? this weekend?
<slomo> doko
<doko> tomorrow, when the buildd's have the new gcc
<slomo> ok, fine :)
<slomo> while you're at it you can also request a swt-gtk sync from elmo ;) this version now works with 64bit architectures
<\sh> *yawn* beer, shower, xterm fix
<harrytuttle> hi. is the zd1201 (wifi) firmware included somewhere? the driver is in 2.6.12 vanilla and apparently the firmware is released with mpl license, would be nice to have in breezy
<harrytuttle> or is it non redistributable?
<poningru> I wanted to talk to someone about one of the bofs for ubz
<poningru> its the firefox plugin thing
<zyga> poningru: and?
<poningru> basically asking if anyone has an idea of implementing it
<zyga> poningru: what is 'bofs'?
<poningru> birds of a feather
<poningru> https://wiki.ubuntu.com/UbuntuBelowZero/BOFs
<Nafallo> hmm
<Nafallo> we should have DapperBirds instead of DapperGoals :-)
<poningru> I had some ideas that I wanted to throw out there regarding that bof
* zyga just noticed that backports promotion is easy
<zyga> a list of pre-defind repositories+descriptions/explanations that are easy to enable in gnome-software-properties
<poningru> wouldnt it be better to have that in synaptic?
<zyga> poningru: it's integrated with synaptic
<poningru> oh ic
<poningru> sorry
* poningru does not know the code very well
<jdub> Nafallo: DapperEggs? ;)
<Nafallo> jdub: no, the eggs are not involved in the making anymore :-). we use feathers these days ;-).
<jdub> heh
<maswan> regarding the BOFs there, can I add wiki informations to things important to me, despite it being (very) unlikely that I make it to UBZ?
<jdub> and tar?
<jdub> maswan: yeah, particularly if you write a spec
* jdong fully amused with Newton
<Nafallo> well, tar IS in main so... ;-)
<maswan> jdub: we do have some perspectives to the (HPC) cluster thingies
<jdub> maswan: rad
* fabbione prefers DapperCrack
<jdub> maswan: "my cluster filesystem is better than your cluster filesystem" ;-)
<maswan> jdub: that, and some other thingies. "my matrix multiplication library is better than your matrix multiplication library" :)
<jdub> heh
<jdub> maswan: have you looked at liboil? is it appropriate/interesting for HPC stuff?
<fabbione> maswan: eheh than you want to talk with me :)
<fabbione> maswan: i did propose that BOF
<fabbione> so i expect to lead it too
<maswan> fabbione: ah, neat.
<maswan> fabbione: you going to LCSC in linkping?
<fabbione> nope :(
* maswan nods
<fabbione> but i am going to UBZ :P
<maswan> I don't know if I am either, this year. but generally that's the "big" swedish conference for [acaemic]  HPC stuff
<fabbione> maswan: i am looking into openmosix at the moment..
<fabbione> (well started 20 minutes ago again after 5 years)
<maswan> fabbione: you might want to take a look at Slurm too, as a batch execution enviroment
<fabbione> maswan: if you have time just send me a mail with what you think it's worth looking
<\sh> argl...
<\sh> ssh+screen+gnome-terminal == nono
<\sh> +irssi I forgot
<fabbione> \sh: screen is either broken on UTF8
<maswan> fabbione: I think I will write up a overview of our software enviroment and use cases for you guys.
<fabbione> it's the same with BitchX
<jdub> \sh: hrm? i regularly use that combination, only suffer breakage when i change the gtk+ theme
<eruin> what package should a misconfigured /etc/environment after install be assigned to?
<fabbione> maswan: that would be totally RAD!
<\sh> jdub: I just had blue fillings on my screen..with irssi...
<\sh> jdub: hoary that is :(
<fabbione> maswan: btw... http://cdimage.ubuntu.com/ports/daily/current/ <- 
<fabbione> maswan: it's not state of the art yet :)
<jdub> \sh: yeah
<fabbione> maswan: but we are getting very close ;)
<jdub> fabbione: ooh, sparc cds?
<jdub> yay!
<\sh> fabbione: hmmm.upstream knows about it? 
<fabbione> jdub: yes.. it should be possible to install ubuntu-desktop
* jdub looks at ultra 5 and 220R... hmm.
<fabbione> jdub: but there are still glitches with the installe
<fabbione> +r
<maswan> fabbione: :)
<fabbione> i can't type today
<fabbione> if you wait tomorrow's image there will be at least 3 errors less
<\sh> ok...xterm fix just ready to upload
<jdub> fabbione: ok
<maswan> fabbione: it is for us too, if you guys understand what we are trying to do and what we want, perhaps you make a better OS for us. :)
<\sh> and the first klsch is just finished
<fabbione> maswan: that's why i am totally happy to get info from you
<fabbione> maswan: i did push already HA into breezy
* maswan nods
<fabbione> maswan: i expect to expand that and add some kind of HPC
<fabbione> specially now that i have 6 i386 machines :)
<maswan> :)
<fabbione> i just need a gigabit switch
<fabbione> :)
<mdke> jdub, do you have an ETA on the mailing lists?
<maswan> fabbione: expect something next week
<jdub> mdke: not a usefully clear one, have to figure out what's happening - will look at it on tuesday
<fabbione> maswan: it's enough i get something immediatly after release so that i have a couple of weeks to look around before UBZ
<mdke> jdub, you know they are not delivering mail now either right?
<jdub> mdke: they so are
<mdke> oh
* jdub tests
<mdke> i haven't had anything all day
<fabbione> jdub: no.. lists are down
<mdke> and the one I sent to loco-contacts never arrived
<jdub> ok, cursory look before didn't provide any useful evidence
<jdub> oh
<jdub> i know why
<jdub> ok, lists are running
<fabbione> jdub: did you power it off again?
<jdub> but archives are a different matter
<mdke> jdub, ok thanks
<jdub> fabbione: mailman restart always fails on that machine, have to stop/start
<mdke> bah
<fabbione> jdub: tsk
<mdke> have you got it on a 386?
<jdub> fabbione: yeah, my bad ;-)
<fabbione> jdub: you need to move to a more sane country man :)
* jdub totally wants to switch exim for postfix on that obx too
<fabbione> walking upsidedown has bad effects
<jdub> heh
<jdub> fabbione: but this machine is upside down too!
<fabbione> is that why it runs exim and not postfix?
<jdub> it runs exim because it was upgraded from debian somethingorother
<desrt> will the breezy installer resize fat/ntfs?
<mdke> yep
<desrt> awesome.
<fabbione> desrt: it already does
<mdke> hoary did
* desrt getting bombarded with pre-installfest questions :)
<desrt> will it resize even if the FS is fragmented?
* fabbione goes for a smoke
<fabbione> desrt: hmm i think so..
<desrt> good.
<mdke> desrt, ntfs is quite experimental still afaik
<fabbione> desrt: i didn't try that in a loooooooong time
<mdke> so backup
<jdub> bah, some podcast client tries to get a bunch of stupid files when it hits the server
<jdub> desrt: you going to do an event report for the fridge?
<fabbione> jdub: fridge.u.c?
<tseng> jdub: monopod
<jdub> fabbione: yes
<tseng> that reminds me, i should upload it
* fabbione looks
<jdub> tseng: oh, really? it does that?
<jdub> tseng: i'm so going to flame edd
<tseng> jdub: oh, i dunno
<tseng> jdub: i was telling you to use it in place of whatever bollox you have
<jdub> oh
<jdub> no
<jdub> i'm looking at the logs
<tseng> edd is my hero
<jdub> files/jeff-waugh-on-la-update.ssa not found.
<jdub> files/jeff-waugh-on-la-update.smi not found.
<jdub> files/jeff-waugh-on-la-update.srt not found.
<jdub> files/jeff-waugh-on-la-update.sub not found.
<jdub> files/jeff-waugh-on-la-update.txt not found.
<jdub> files/jeff-waugh-on-la-update.asc not found.
<tseng> .asc, boggle
<jdub> really weird
<jdub> google suggests they're captioning formats
<tseng> jdub: i set up my first mergedfb today
<jdub> AHA
<jdub> i think i know the culprit
<tseng> jdub: and like, i am finding stuff from you and snorp about that sucking in gnome from like 2002-2003
<jdub> hahahahaha
<jdub> http://kaffeine.sourceforge.net/index.php?page=faq#question7
<tseng> jdub: the background capplet still sucks
<jdub> heh
<tseng> i like quesiton 1
<jdub> wow
<jdub> funny
<tseng> sounds like something from gentoo forums
<tseng> jdub: puc still hates me
<slomo> jdub: want to add me to pub? :)
<tseng> puc dude
<jdub> slomo: hrm?
<jdub> tseng: grr, i have to get elmo to delete the cache file :|
<tseng> jdub: GAR GAR
<slomo> jdub: haha... puc even :)
<jdub> slomo: you're a member? got a feed?
<slomo> jdub: sure... http://slomosnail.de/feed/
<jdub> slomo: *blink* i don't know why i've never associated your nick with your name before.
<jdub> sorry :-)
<slomo> jdub: no problem :)
<Nafallo> hehe
<jdub> oh, that's right, i have to get rob collins to help with a baz borkage
<spayne> elmo: ping
<\sh> hmmm
<\sh> something I'm doing wrong
<\sh> after make install, I'll do a : chmod g+rs /usr/bin/xterm but the app doesn't have the permission in the package...grmpf...
<slomo> \sh: maybe dh_fixperms is resetting the permissions
<\sh> oh yes....grmpf
<\sh> did miss the call
<desrt> jamesh; ping
<\sh> Kamion: xterm utmp bugfix uploaded
<\sh> elmo: please morgue eric3 (universe) asap ... eric is now the correct package for this python ide 
<gouchi> Hi
<gouchi> don't know if it has been discused
<gouchi> but why you don't disable stars when you ask password in DI ?
<gouchi> users are very disturbed because they think it didn't work 
<gouchi> why you disable star when typing the password in DI sorry :)
<desrt> one has to wonder what "DI" stands for?
<jdub> debian installer
<gouchi> sorry ;-)
<desrt> uhm... doesn't breezy now display *s for the initial account password?
<gouchi> don't test yet
<desrt> i'm reasonably sure that it does
<gouchi> I hope too ;-)
<gouchi> because users are very disturbed by that 
<desrt> i agree
<desrt> whenever i tell new users how to change their password with 'passwd' i almost always get someone asking "why isn't it working?"
<ivoks> :)
<gouchi> :)
<ivoks> or "keyboard is broken"
<gouchi> any news about http://bugzilla.ubuntu.com/show_bug.cgi?id=15031 ?
<\sh> hmmm..did anybody see my xterm upload on -changes?
<ivoks> no
<slomo> \sh: -changes is laggy atm... my last upload was already build and in the archives one hour before it was on changes ;)
<sebest> how does ubuntu support software wlan switch?
<ivoks> sebest: on what model? :/
<ivoks> there are hardware switches and software switches
<sebest> fujitsu siemens amilo M 7400
<sebest> i use the module fsam7400
<sebest> i must echo 1 > /proc/driver/wireless/radio
<ivoks> and that works?
<sebest> i wrote a simple script to handle this
<sebest> ivoks: yes
<ivoks> sebest: you have switch button on keyboard?
<sebest> yes
<sebest> but i can't bind it to my script with gnome
<ivoks> hm...
<Seveas> sebest, can you bind the key to another command?
<sebest> Seveas: i don't know how to do this from gnome
<Seveas> deep inside gconf-editor you can set manual keybindings to whatever you want
<sebest> Seveas really??
<Seveas> sebest, system -> prefs -> keyboard shortcuts
<sebest> ivoks: how does ubuntu handle the other models using software switch?
<Seveas> if the key works there for a random action, you can (ab)use gconf-editor to make it launch your script 
<ivoks> that gnome keys bind is broken anyway
<ivoks> sebest: join #ubuntu-laptop
<sebest> Seveas: thx i'll try this
<ivoks> sebest: that key. shourtcats doesn't work for my windows key :)
<ivoks> grgrgrg.... s/sebest/Seveas :)
<Seveas> lol
<Seveas> then your win key may be mapped to meta oslt
<ivoks> meta4+x works
<ivoks> but meta4+f doesn't
<Seveas> ah, that
<Seveas> happens to me if I use alt/ctrl too
<Seveas> probably some bad paths
<ivoks> heh
<Seveas> Have been planning to look at it more closely since may or so...
<sebest> Seveas do  you know where is it in gconf?
<Seveas> sec
<jmg> hey all
<Seveas>  /apps/metacity/*
<ivoks> hi jdub 
<jmg> is there a sane reason why Xv is not enabled by default?
<mjg59> jmg: Given that Xv is enabled by default here, I doubt it
<ivoks> here too
<mjg59> jmg: But if you give more details, it may be possible to work out why
<jmg> mjg59: so xserver-xorg set option VideoOverlay on in your xorg.conf?
<jmg> because its not on on my last 2 breezy installs.. radeon 9200 and i915
<mjg59> jmg: No, because it's not a valid configuration option in the i810 driver
<mjg59> Or, indeed, in the radeon driver
<jmg> mjg59: huh?
<mjg59> VideoOverlay is a fglrx-specific option
<jmg> I810(0): video overlay key set to 0x83e
<jmg> mjg59: electricsheep reported "No xv aperture found" until i set that option
<mjg59> jmg: Yes. I have that in my logs.
<mjg59> jmg: The string "VideoOverlay" does not appear in the i810 driver
<mjg59> Of the Free drivers, it seems to be MGA, S3 and tdfx-specific
<jdub> $ sudo hdparm -T /dev/hda
<jdub> /dev/hda: Timing cached reads:   2480 MB in  2.00 seconds = 1239.57 MB/sec
<jdub> ^ laptop
<jdub> root@katia:~ # hdparm -T /dev/sda
<jdub> /dev/sda: Timing cached reads:   484 MB in  2.01 seconds = 240.95 MB/sec
<jdub> ^ server
<mjg59> jdub: That's fairly meaningless
<jdub> i should bonnie them
<jmg> mjg59: how unusual
<mjg59> jmg: No, that's fairly normal
<mjg59> Anyway
* mjg59 goes out
<ivoks> enjoy
<jmg> mjg59: let me try something, brb
<jmg> mjg59: i guess it fixed itself
<jmg> mjg59: electricsheep needs to be bumped anyway
<jmg> 2.6.2 cant connect to server
<jmg> debmake - helper package for debian/rules (deprecated).... deprecated by what?
<\sh> debhelber ?
<\sh> debhelper even
<\sh> okokok...please dear callcenter agent, please call me if it's really, _really_ important, but please not because you want to have a nagra smartcard provisioned
<jmg> \sh: isnt there a command to initially debianise a source tree?
<\sh> dh_make
<jmg> ahh, its not in debhelper, thanks
<\sh> jmg: for starting question please join #ubuntu-motu :)
<jmg> \sh: sssh :p
<jmg> \sh: actually i was interested in seeing if the new dh_make automatically debianised python modules with setup.py
<jmg> doesnt appear to, still requires Makefile
* jmg apt-get sources some other python modules to see how they do it
<\sh> jmg: well...dh_make is templating nothing else...providing you with a default template :(
<jmg> \sh: some packages all you need is to run dh_make and edit control and changelog
<\sh> I think I'd try only once dh_make...and that was my ubuntu start
<jmg> ok
<thesaltydog> dh_make is quite unuseful... if you know what debian/ dir is..
<harrytuttle> jmg: if you use dh_make with cdbs there is a template for setup.py: https://perso.duckcorp.org/duck/cdbs-doc/cdbs-doc.xhtml#id2501656
<jmg> thesaltydog: it makes it easier
<thesaltydog> jmg, yes.. sometimes
<jmg> harrytuttle: thanks
<jmg> thesaltydog: i agree if you dont know how to write rules and control its not going to really help :)
<jmg> ajmitch: ill just keep filing bugs with patches until release
<jmg> ajmitch: assuming my last upload was up to scratch or is there an Even Better Way(tm)
<thesaltydog> jmg it provides you with a full template of stuff. Sometimes it is easier to copy your debian dir from a similar package you have just packaged.
<jmg> thesaltydog: i agree
<ajmitch> jmg: alright
<jmg> thesaltydog: or use cdbs... thanks to harrytuttle for pointing that out
<jmg> ajmitch: as i find bugs and have time to fix
* jdub copies debian dirs and uses cdbs :-)
<jmg> ajmitch: using breezy on all my workstations now until release :)
<ajmitch> great :)
<ajmitch> jmg: I'll certainly make suggestions on your patches before we upload :)
<jmg> ajmitch: totally sold on it when it picked up all (yes all) my hardware
<jmg> on my new lappy
<ajmitch> so far you've just got a patch for 2742 in?
<jmg> ajmitch: figure i may as well make release as best as i can by making sure it also do everything i need for work
<ajmitch> are #331 & 332 fixed?
<jmg> do/does
<jmg> i dont use kdevelop anymore :) but i will check and see if they can be closed
<ajmitch> ok
<jdub> jmg: got my servers running breezy since before preview ;-) very helpful
<ajmitch> jmg: latest kvpnc patch is looking better, dpatch might be nice though
<jdub> difficult to catch serverish bugs in fast six month cycles if no one's brave/stupid enough to push them
* ajmitch was running breezy on his laptop since a day or so before UDU ;)
<jdub> me too ;-)
<jmg> jdub: i have some xen domains on servers running breezy
<jdub> everyone at udu was like, "um, huh?"
<jdub> jmg: i should so install xen
<ajmitch> since I was silly enough to do the dist-upgrade at a friend's place in sydney
* jdub wishes the xen goal was met for breezy :|
* ajmitch also
<jmg> jdub: dont worry i will work on it breezy+1
<ajmitch> I'll be back in a couple of hours & look at that patch again
<desrt> what ever happened to the dingo?
<jmg> jdub: i think i will eventually get debian maintainership of xen since adam is overloaded
<jdub> cool
<jmg> ajmitch: point me to something on dpatch
<ajmitch> http://tseng.ath.cx/log/?p=7
<jmg> jdub: xen on debian is a clusterfrell right now because 2.6.11 is locked out and xen-2.0.7 depends on kernel 2.6.11
<jdub> fun :|
<jmg> tell me about it
<jmg> so my asterisk box wound up running on naked hardware
<jdub> haha
<jdub> in xen land
<jdub> that is terrible!
<jmg> which is dissapointing
<jmg> jdub: just means i will have to convert once we can unfrell the situation... looks to be release of xen 2.0.8 and checkin of kernel-source-2.6.12
<jmg> will fix the issue
<jmg> in the mean time im flying on very unofficial kernel-source-2.6.11 i cooked up myself
<jmg> but i havent made a kernel-patch so nothing can reverse so stuff like module-assistant wont work (which i need for misdn to do my * box the debian way)
<jmg> actually i lie... i made a kernel-patch... but nothing applies to it :)
<jmg> is mirror.clarkson.edu open for anyone?
* jmg decides a coral: protocol for konqueror would be very useful right now
<jmg> hmm may not be so easy
<jmg> how to configure so coral:http://www.google.com/linux becomes http://www.google.com.nyud.net:8090/linux
<Kamion> gouchi: yes, I made cdebconf show stars in password prompts ages ago
<harrytuttle> does coral works with something different than http?
<gouchi> Kamion : cool 
<gouchi> Kamion : on Breezy so ?
<Kamion> yes, cdebconf 0.78, end of May
<gouchi> ok ;-)
<jmg> harrytuttle: no it is http... the rule is just append .nyud.net:8090 to your request
<jmg> harrytuttle: but i dont know if konq web shortcuts can do that
<harrytuttle> coral://www.google.com/linux looks better
<jmg> so it does
<jmg> but not even that is doable
<jmg> coral:www.google.com linux is doable
<gouchi> http://www.google.com/mozilla/google.xul :)
<desrt> this is an interesting creation
<gouchi> ;-)
<desrt> i worry if something like this poses a security risk
<\sh> g'night gentlemen
<mdke> night \sh 
<jmg> ajmitch: yes they are fixed :)
* jmg doesnt even have mozilla
<jmg> ajmitch: i want proper xen on my laptop so i will be probably fulfilling the xen goal in breezy+1
<jdong> hey, any devs here use/(are familiar with) ReiserFS?
<jdong> I'm concerned about whether or not journal replay happens properly with Ubuntu (Hoary/Breezy)
<jdong> Ubuntu first mounts ro (skipping journal reply), then remounts rw, but nowhere can I find evidence of journal reply while remounting...
<jmg> is anyone here able to reach mirror.clarkson.edu?
<jdong> jmg: timing out
* jmg emails webmaster
<jmg> where is clarkson?
<jdong> jmg: USA? ;)
<jdong> jmg: why not ASSume webmaster@clarkson.edu?
<jmg> because the google cache says it is web@cosi.clarkson.edu
<jmg> jdong: wonder if it is offline because of hurricane ;)
<jdong> 8 Clarkson Ave., Potsdam, NY 13699
<jdong> doesn't sound too hurricane prone
<jdong> so, anyone have a word on reiserfs?
<jmg> hmm
#ubuntu-devel 2005-10-07
<Sepheebear> potsdam, ny? maybe a cow fell on it
<jdong> hey guys, what's going on with ubuntu-artwork and the start page?
<jmg> hmm i dont think ipython is working as it should
<jmg> %run doesnt conserve namespace
<doko> infinity, lamont-away: please could you have a look why fakeroot did fail on the i386 buildd?
<crimsun> jdong, "the start page"?
<crimsun> jdong, if you're referring to firefox's start page, that's just a desync. It'll be fixed in firefox soon enough.
<jdong> crimsun: that's what I meant. Thanks for letting me know
<jmg> can anyone confirm ipython issues?
<bddebian> Heya
<desrt> jdub; http://www.badgerbadgerbadger.com/ ?  you must be kidding me.
<jdong> desrt: lol, such a waste of time.... :)
<desrt> jdong; ya.  that's what i said :)
<jdong> lol http://www.opensuse.org/ opensuse servers hacked
* jdong thinks Novell should run better background checks on employees :)
<bddebian> Heh
<jdong> kinda sucks for them, since they're flagship Apparmor apparently failed in this case :)
<ajmitch> jmg: placed your kvpnc patch in debian/patches, since it's using cdbs & simple-patchsys already
* jdong nervously audits all his systems
<martinhj> I'm getting a error about usplash-artwork.so when I'm trying to ubdate my initramfs
<martinhj> no such file...
<Nafallo> martinhj: please update to the latest usplash (-19)
<martinhj> Nafallo: ah, I thought I had (was in the same update as the kernel), but maybe apt updated the kernel first
<martinhj> sorry:-)
<Nafallo> no problem
<Nafallo> that version hit the archive today ;-)
<martinhj> Nafallo: hmm, I got -19, but I still got the problem..
<Nafallo> hmm, damn. that means the fix didn't work I guess :-/
<martinhj> but the file is there..
<martinhj> (/usr/lib/usplash/.../
<Nafallo> what does ls -l /etc/alternatives/usplash-artwork.so say?
<Nafallo> /usr/lib or /usr/share
<martinhj> it's a dead link
<Nafallo> /usr/share then
<martinhj> there is no /usr/share/usplash directory
<Nafallo> that's very correct
<Nafallo> infinity: ping
<Nafallo> I can see why the bug is still there ;-)
<martinhj> but /etc/alternativses/usplash-artwork points there
<martinhj> any more you want me to check out, let me know
<Nafallo> I know what the bug is. it's another typo... this will be fix as soon as I find an alive main-uploader :-)
<crimsun> ajmitch should be alive
<Nafallo> yea, asking him on motu :-)
<ajmitch> I can't upload to main
<Nafallo> dang
<ajmitch> yes, but I can't do anything about it :)
<martinhj> is it possible for iFolder to be included in universe for later versions of Ubuntu,or is it problems with the license?
<martinhj> seems at least interesting
<ajmitch> still license issue at the moment, which are getting sorted
<ajmitch> so hopefully for dapper
<martinhj> what is the issue?
<ajmitch> libflaim
<martinhj> I'll look it up...
<Nafallo> so, this is bugzilla 16794 for any awake main-uploader ;-)
<mirak> is there lvm support in the initrd of ubuntu ?
<jdong> mirak: yes
* desrt sees new artwork
<slomo_> jdong: are you now a regular irc user? ;)
<backports-r-us> are any devs awake here? ;)
<backports-r-us> I've got some acpi issues to report :)
<bob2> bugzilla.ubuntu.com
<backports-r-us> k, I'll use bugzilla instead
<backports-r-us> k; filed #16799
<bob2> that could probably do with model numbers
<bob2> and kernel versions
<bob2> and what happens when you run 'xset dpms force on' normally
<backports-r-us> bob2: absolutely nothing :)
<bob2> and force off?
<bob2> and the other things?
<backports-r-us> bob2: force off doesn't work either
<backports-r-us> bob2: when the lid closes, the BIOS kicks in and shuts off the screen, but nothing revives it short of vbetool
<bob2> then you need to include the bios version, too
<bob2> filing bugs without any specific detail just means someone has to chase you down later to get it
<mjg59> Your BIOS is shit
<mjg59> Buy a better laptop
<mjg59> Or scream at your vendor until they fix it
<backports-r-us> mjg59: I've noticed that... it's a free laptop... I get what I pay for
<backports-r-us> mjg59: but what's the hurt in using vbetool instead of xset?
<mjg59> If nothing short of vbetool post gets the video back, there's no way we can fix it
<mjg59> It screws up various machines
<backports-r-us> mjg59: oh, ok. nvm then
<backports-r-us> mjg59: I'll just work around locally :)
<mjg59> (Less shit machines)
<backports-r-us> feel free to mark it invalid :)
<mjg59> You can work around it by dropping something in /etc/acpi/local/lid.post or something like that
<backports-r-us> mjg59: yep; already did :)
<backports-r-us> well, good night everyone
<jdong> slomo_: I keep gaim logged into IRC :)
<jdong> slomo_: after a dev yelled at me throught the list about IRC :)
<segfault> who is taking care of integrating https://wiki.ubuntu.com/DesktopTranslations?
<moyogo> hi, anybody here?
<bob2> moyogo: best to just ask your development-related question right up
<moyogo> bob2: i don't know if this is the right place
<bob2> meta-questions consume more time than just asking it to begin with
<moyogo> i'd like to know if it's possible to contribute to the ubuntu title font made by canonical?
<crimsun> does apache on {us.}archive.u.c need to be poked?
<crimsun> err, desrt already asked.
<desrt> :)
<desrt> i love how there are all these separate channels and everyone is still in all of them :)
<infinity> Hrm, maybe someone really did down apache on both hosts at the same time.
<infinity> Weird.
<desrt> so the question is -- do they know what they're doing and are in the process of fixing it?
<robitaille> interesting.  It was exactly 1 week ago the last time the repos were down.  Must be a Saturday night thing for the server...
<infinity> Actually, checking the date and time, it looks like a cron.weekly tihng.
<infinity> Which would explain how two machines got taken out at the same time.
<robitaille> ubuntu... a very regular and on time distro; even for our server outages :)
<fabbione> infinity: did you send an sms to elmo/znarl?
<infinity> On it.
<fabbione> ok
<fabbione> pointless to bomb them together
<desrt> mmm
<desrt> this fresh breezy install on my laptop is blissfully good
<infinity> Really?
<infinity> That's kinda nice to hear.
<fabbione> infinity: don't you trust your own capabilities? ;)
<desrt> don't get your hopes up boy.  it picked the wrong paper size!
<infinity> <laugh>
<fabbione> desrt: of course it did pick the right one.. for the wronf country
<desrt> now i have to find somewhere that sells A4 so i can fill my printer with it
<infinity> fabbione : As we near release and I look at the bug lists (as well as pet bugs/issues), I always fear we won't get enough stuff fixed in time.  I'm mostly just paranoid, I think, though.
<desrt> infinity; we all feel this way
<desrt> actually
<desrt> i feel more like (a) i'll miss something
<desrt> or (b) one of my fixes will introduce a regression that isn't caught until it's too late
<fabbione> infinity: the opposite.. we have only 230 Maj bugs.. spreaded over 3 releases.. it's not bad at all
<fabbione> infinity: in proportion we had more for hoary
<infinity> desrt : Both will happen.  Guaranteed.  The only upshot is that with 6-month release cycles, you don't have to live with it for very long.
<fabbione> + i am sure tons of these have been fixed.. but bugs never closed
<desrt> infinity; 6 months seems like a long time
<desrt> where is that daniel h fellow!
<infinity> desrt : Not nearly as long as I had to live with my boneheaded mistakes in Woody.
<fabbione> infinity: what was that??
<infinity> Oh, just small things here and there, but they all added up to extreme rsutration when I'd keep getting the same bugs over and over again. :)
<fabbione> archive is up again
<infinity> Especially when none of them were particularly important enough to justify a proposed-updates upload, just annoying enough to generate bug reports.
<fabbione> yeah
* robitaille thanks whoever solved the archives problem
<fabbione> it looks to me like it's only apache2 that dies
<desrt> YES!  floss!
<infinity> fabbione : It's probably not restarting properly after cron.daily/logrotate, is my guess.
<crimsun> cron.weekly?
<infinity> It was about the right time for cron.weekly, but cron.daily/logrotate/apache2 also tends to be in sync with cron.weekly.
<infinity> So, pick one.
<crimsun> hmm, true
* desrt leaves the diagnosis up to the professionals :)
<infinity> Unfortunately, archive.ubuntu.com is running not-terribly-well-tested packages of apache 2.1.3 (for LFS support), so they may be a bit dodgy, compared to the apache 2.0.54 packages in the archive.
<crimsun> infinity: Nafallo has probably bugged you already about this, but /etc/alternatives/usplash-artwork.so is a dangling symlink in -19
<infinity> Er... WTF.
<infinity> crimsun : What to?
<crimsun> /usr/share/usplash/usplash-default.so
<infinity> Oh, I suck so much it hurts.
<infinity> Bad copy and paste, BAD.
<infinity> crimsun : I assume it's only dangling for people it was already dangling for, I didn't break it more, right? :)
<crimsun> infinity: I can't say; I've been suspending and resuming for a few days now :)
<fabbione> infinity: possibly.. yeah
<infinity> Fix uploaded.  Meh.
<crimsun> infinity: awesome, thanks :)
* infinity wishes there was a way to delete from queue/unchecked, so he didn't have to upload twice in 30 seconds and look even more retarded.
<jdub> wow, holy crap
<jdub> lots of referers from distrowatch for the fridge
<jdub> like
<jdub> *LOTS*
<crimsun> I finally read that CNet article
* fabbione hits openmosix with a cluebat
* \sh listens to jdubs interview ;)
<fabbione> jdub: can you do me a favour on the fly?
<jdub> i don't tend to sit on insects
<fabbione> ehehhe
<jdub> but i can do you a favour :-)
<fabbione> svn co svn://openmosix.snarc.org/om/userspace/trunk <- can you stick it in a tarball somewhere on people?
<fabbione> it seems i can't connect to it
<fabbione> perhaps you can
<jdub> you can't connect to people?
<fabbione> no, i can't connect to that svn server
<jdub> oh
<fabbione> but i can connect to people
<fabbione> so if you can do the checkout and pushit on people that'd be great
<jdub> (wow, i have svn on my laptop)
<jdub> oh, yeah, it's coming down
<fabbione> thanks
<jdub> fabbione: http://people.ubuntu.com/~jdub/random/om-userspace-trunk.tar.bz2
<fabbione> jdub: thanks!
<sivang> morning all!
<poningru> whats the link to malon?
<poningru> err +e
<jdub> poningru: launchpad.net, click on bugs
<\sh> launchpad.net
<poningru> thanks
<mdke> jdub, overnight another day's worth of email have come onto the -doc archive, looks like it is just keeping 3 days behind
<jdub> intriguing
<jdub> thanks
<mdke> last emails on all the archives I've just checked stop at about 10.30 CDT on Thu Sep 29 2005
<\sh> harhar...."sabdfl is your title" "oh noohoononono" ,-)
* \sh laughs
<\sh> jdub: nice interview :)
<jdub> ;-)
<Mirv> when are those translations at https://wiki.ubuntu.com/DesktopTranslations to be integrated? (just wondering as the deadline for those was on Friday)
<\sh> and for jdub, just exclusivley: "Ubuntu is the one that I want" 
<\sh> to the sound of Olivia Newton-John
<zyga> hello
<zyga> I'm doing a hoary->breezy upgrade at the moment
<zyga> and I've noticed something strange regarding liboil
* sivang is amazed by the amount of press Ubuntu and the other operations receives, linked from the fridge.
<sivang> jdub: that's outstanding 
<ajmitch> jdub: it's great that you got to talk about the MOTUs a bit :)
<zyga> I've got many warnings regarding some illegal instructions in gstreamer packages
<zyga> does anyone know what that's all about/
<crimsun> zyga: what sort? Could you paste on paste.ubuntulinux.nl?
<mdke> is the breezy universe security repo working?
<mdke> W: Couldn't stat source package list http://security.ubuntu.com breezy-security/universe Packages (/var/lib/apt/lists/security.ubuntu.com_ubuntu_dists_breezy-security_universe_binary-i386_Packages) - stat (2 No such file or directory)
<zyga> crimsun: unfortunatly I did not tee the dist-upgrade ....
<zyga> crimsun: is apt-get keeping any logs?
<crimsun> zyga: no, but aptitude does
<zyga> eh
<zyga> I could reinstall hoary and try again
<zyga> crimsun: I'm sure it was about liboil0.*
<zyga> crimsun: I'm doing the upgrade on an old pentium 2 laptop
<zyga> maybe it does not have required instructions?
<zyga> like sse
<crimsun> I'm thinking of something different, I believe.
<zyga> yes?
<zyga> like?
<crimsun> it's an ffmpeg issue, and it's totally unrelated.
<dholbach> hi
<mdke> art.ubuntu.com is down
* zyga learns a new thing
<sivang> hey dholbach 
<sivang> dholbach: 'sup ?
<dholbach> hey sivang ... just listening to jdub's interview
<ajmitch> dholbach: you're mentioned closer to the end :)
<dholbach> yeah.... just heard it :)))
<sivang> dholbach: good for you :)
* dholbach hugs jdub 
* ajmitch is surrounded by celebrities
<\sh> hmm..."there is daniel holbac" ,-)
<\sh> dholbach: u will like the interview ;) 
<dholbach> yeah... "dholback" is my favourite nick name :-p
<\sh> dholbach: hehe...yeah...just like mine "hrman" ,-) "hermann" ;)
<dholbach> haha :)
<\sh> there was a running gag in 2001 when I was in US at RH HQ..."what's your email?" "shermann@redhat.com" "like the tank?" "no, with double n at the end of the username"
<sivang> \sh: you worked for red hat?
<\sh> they didn't understand that
<\sh> sivang: yes
<sivang> \sh: wow nice, under what position ?
<\sh> sivang: web engineering/development and web marketing manager EMEA
<\sh> sivang: and yes, it was one of my worst experiences in my work life
<sivang> \sh: oh, why so? I would reckon it would be interesting/nice working for them no?
<pef> hello
<pef> does cdrdao scanbus works for you ? I have Device or resource busy errors
<\sh> sivang: the most interesting work was done in distro development...and we were only responsible for the *censored* rh europe online shop...and had to fight with *censored* marketing bosses who didn't have a clue
<\sh> sivang: and rh europe is quite different from rh us 
<sivang> \sh: I see. I regret to here that, hope you don't carry on too much with you from ther e:)
<\sh> sivang: it's a nice name on my CV...but nothing more...and there are some good people I would like to see to work for ubuntu, harald hoyer is one of them
<mdke> headhunt them!
<\sh> mdke: hahaha....no..I can't do that...I don't have the money to pay them ;)
<mdke> kidnap them!
<sivang> \sh: who's he?
<ajmitch> \sh: work harder & then pay them! :)
<\sh> sivang: http://people.redhat.com/~harald/
<\sh> ajmitch: bah....isn't it enough that you want me to fix universe? ,-)
<sivang> \sh: nice, did you get to knoe Michael K. Johnson ?
<ajmitch> \sh: oh. you mean it's not fixed yet?
<sivang> \sh: (I have his book, a very good piece, I also got to talk to him on IRC sometime ago, he's a canon and very nice as well)
<\sh> sivang: not that I know of..
<ajmitch> reminds me, I should see if I can get madduck's book in NZ yet :)
<\sh> sivang: but for books...I can give u the advise to read "under the radar" from Robert 'Bob' Young..
<sivang> \sh: sure, send me a link 
<\sh> sivang: are u at ubz?
<\sh> sivang: I can give u mine...it has a personal signature of him in it..
<ajmitch> \sh: nice :)
<\sh> sivang: http://www.amazon.com/exec/obidos/tg/detail/-/1576105067/qid=1128248479/sr=8-8/ref=pd_bbs_8/102-0247898-9876161?v=glance&s=books&n=507846
<sivang> \sh: nice
<ajmitch> \sh: got any other copies? :)
<\sh> ajmitch: no only this one :)
<ajmitch> oh well :)
<sivang> \sh: well, you can give it to ajmitch :-) I'm currently more interested in reading technical books, until I feel satisifed with my current knowledge ;-)
<sivang> \sh: the MKJ book is this http://www.ladweb.net
<ajmitch> sivang: no I couldn't take the book off you, \sh offered it to you
<\sh> sivang: it's not technical..it's more "how bob young managed to create the RedHat Hype" ,-)
<sivang> \sh: hmm, then maybe we should all read toi know how to become more strong ubuntu evangelists :)
<ajmitch> just emulate jdub 
<sivang> right 
<\sh> oh well...then I'm jdub2 ,->
<sivang> he's really good at it
<ajmitch> \sh: scary thought
<sivang> LOL
<jdub2> "and we have sabdfl"..."So it's your title?" "oh nohohonononhohonono"
<dholbach> haha
<ajmitch> heh :)
<\sh> dholbach: this is the funniest part in the interview..
<ajmitch> \sh: certainly
<sivang> LOL
<\sh> dholbach: actually I managed to evangelise finally 6 people in our company to work only with ubuntu :) and one of them has 2 laptops running with ubuntu ;)
<dholbach> wow
<dholbach> when will they start in the MOTU crew? :)
<\sh> dholbach: even our "I love suse" colleague has ubuntu running now on his laptop and on one of his servers
<ajmitch> there's not even 6 people in the company I work in
<ajmitch> but I handed one a hoary cd set on friday
<ajmitch> and possibly ubuntu on the new server :)
<highvoltage> anyone know if elmo is around? i forgot the name of the server i need to log into to upload the edubuntu html files.
<\sh> but I'll pre-ordered now 300 breezy cds and 100 I will put in each mailbox in our company :)
* ajmitch wonders how many will be brought to LCA :)
<\sh> and...now it's a secret, I'm normally not allowed to share it with you...but I think it's worth it to share this with you (hello google ;)))
<sivang> \sh: I managed to pull our Japan representative into Ubuntu, 3 sales person that are now using it to display demos, antoher chinesse representative, and all of the customers of my cousing in NYC :)
<\sh> "Unity Media (aka ISH + IESY), the 2. biggest cable provider in germany, is running ubuntu on 6 DNS Servers
<\sh> hmmm..lets wait for next week if I get my pink slip ;)
<sivang> \sh: you're trying to let google cache this chat ? :)
<sivang> \sh: pink slip? 
<\sh> sivang: the logs you can find on google ;)
<\sh> sivang: the firing papers...
<sivang> \sh: why are you burning papers ? :)
<ajmitch> hah
<\sh> sivang: eeks
<ajmitch> \sh: you convinced them to change? :)
<\sh> ajmitch: yepp
<ajmitch> \sh: good work :)
<\sh> ajmitch: we throw out 6 sun R280s with solaris 8
<sivang> ah now I get it :)
<mirak> hi
<sivang> \sh: don't worry, they will only thank you for releaseing them for the hell of solaris :)
<\sh> ajmitch: I'm working now on the adventure "replacment of our webservers" 
<sivang> hey mirak 
<ajmitch> \sh: that'll be a good challenge
<sivang> \sh: you should do a reality show about tht
<mirak> I asked about LVM in #ubuntu but got no answer, so I ask here, can I ?
<mirak> does ubuntu initrd have LVM support ?
<\sh> sivang: ah well..I asked for permission..but PR and Marketing are not so convienced of the idea to release this...
<\sh> but I'm a bad guy...
<ajmitch> mirak: yes, and it has since hoary
<mirak> ajmitch: so I have some troubles booting my LVM install
<ajmitch> \sh: very naughty indeed
<\sh> ajmitch: I would name it "jdub in germany" ,-)
<\sh> ajmitch: I just wait for the moment, when I'm sitting on a chair in a public place with dropped pants and speaking about ubuntu ,-)
<sivang> \sh: don't worry, when we'll meet in UBZ, I'll tell you what I did for Ubuntu, which is really starting to touch the burning papaers :-))
<\sh> sivang: so I'll take the book with me :)
<mirak> when choosing the root device for the kernel, should I use /dev/mapper/volume1-linux or the symlink that goes to it should be ok ?
<terrex> in my laptop, when I unplug the ac-line and goes to battery, 2 or 3 minutes later, the laptop "hangs" and I must to power-off extracting the battery. With hoary kernel this didn't occur. Anybody know why?
<hunger> mirak: I can't find dmsetup in /usr/share/initramfs-tools, so my guess is that / on lvm is not supported.
<mirak> hunger: crap ! :/
<mdke> terrex, file a major bug in bugzilla
<mdke> terrex, against acpi-support
<hunger> mirak: I have not bothered with the initrd setup so far, so I might be wrong.
<terrex> ok thanks
<mdke> terrex, it sounds like a kernel bug but if you file it against acpi-support, the right person will see it
<ajmitch> hunger: / on lvm is supported as long as you have a separate /boot
<mirak> hunger: is there a way I can know it could work ?
<ajmitch> at least with grub
<ajmitch> you can have a fully lvm setup with lilo
<mirak> ajmitch: I have a separate /boot
<ajmitch> mirak: then it should work
<hunger> ajmitch: It is? Cool;-)
<ajmitch> since that's how my laptop has been for several months :)
<mirak> ajmitch: well it failed to find my /dev/volume1/linux
<hunger> ajmitch: Any idea whether crypted disks are supported as well?
<ajmitch> hunger: possibly, I can't recall if cryptroot is 
<mirak> ajmitch: is there something to configure abou lvm ?
<ajmitch> mirak: so try the /dev/mapper/lv-name syntax instead
<hunger> mirak: Have you tried using /dev/mapper/volume-linux?
<mirak> ajmitch: ok
<mirak> hunger: no
<mirak> I will try that
<ajmitch> these questions are more for #ubuntu, really :)
<mirak> ajmitch: nobody answers
<mirak> they are incompetent
<mirak> :p
<ajmitch> heh
<hunger> ajmitch: My root is unencrypted... but my swap is, so hibernation is broken for me.
<mirak> ho we got a winer !
<ajmitch> mirak: you asked that before, but you didnt' try it? :)
<mirak> ajmitch: I am tired of rebooting :p
<sivang> \sh: cool :)
<pitti> Hi
<ajmitch> hey pitti 
<ajmitch> how are you?
<pitti> hi ajmitch 
<pitti> ajmitch: fine, thanks!
<ajmitch> good :)
<ajmitch> had a quiet weekend?
<dholbach> it's still weekend in germany
<dholbach> even a long one :)
<sivang> hey pitti  !
<ajmitch> dholbach: lucky for some, I've got work in 9 hours ;)
* dholbach <- cooking
<ajmitch> ok, sleep time
<ajmitch> see you all tomorrow
<sivang> ajmitch: good night
<dholbach> see you andrew
<sivang> laterz
<hunger> I guess it is not ok to copy config files from /etc/ into the initrd, is it?
* hunger wonders how to enable resume from his encrypted swap.
<doko> Kamion, if you're still around, please could you process eclipse from NEW, if necessary?
<mirak> I fixed my problem with LVM
<mirak> the issue was /dev/mapper/volume1-linux wich doesn't have a symlink at boot time
<spayne> what is up with lists.ubuntu.com?
<spayne> after the latest usplash upgrade, i no longer have a splash screen on boot
<spayne> is this a known bug?
<mjg59> spayne: Upgrade again
<spayne> i just did five minutes ago
<spayne> mjg59: do you know what is up with lists.ubuntu.com
<mjg59> spayne: ?
<mjg59> It's delivering mail fine
<spayne> mjg59: on the archives, there is nothing for October
<fabbione> Keybuk: ping?
<mjg59> There's no archives since the 29th
<mjg59> So, at a guess, the archiver has fallen over
<Keybuk> fabbione: 'sup?
<mjg59> Beyond that, no, I have no idea. I'm afraid I'm not a source of secret knowledge.
<fabbione> Keybuk, yo.. i did review the connection code again
<fabbione> actually.. while i was painting the roof
<jdub> DO IT AGAIN!
<jdub> :-)
<Keybuk> fabbione: yup, I put in the loop you suggested
<fabbione> Keybuk, you must put the loop
<fabbione> there are other reasons why you want to re-iterate
<fabbione> like multiple servers
<fabbione> but one of them isn't providing the service
<Keybuk> yeah, or an AAAA and A address and fallback, etc.
<fabbione> connect would fail
<fabbione> exactly
<jdub> jamesh: ping
<tseng> jdong: https://launchpad.net/distros/ubuntu/+sources/mono/+bug/2597 do you have any idea where these came from?
<fabbione> i am off...
<fabbione> cya guys
<jdub> Riddell: around?
<dholbach> jdub: nice interview :)
<dholbach> jdub: and thanks for the flowers :)
<jdub> :-)
<ivoks> jdub: i have one success story for planet :)
<tseng> jdub: that show is really boring if you download the wrong one
<tseng> jdub: and you arent on it
<jdub> heh
<Riddell> jdub: hi
<ivoks> dholbach: what interview? :)
<tseng> ivoks: fridge.ubuntu.com
<jdub> should the current qt3-mt package 'provides' the one it replaces?
<ivoks> ah, fridge :)
<tseng> ivoks: refresh for my pony
<jdub> Riddell: skype (ugh) requires the old package name, but works with the new one
<jdub> (serious distrowatch linkage coming in to fridge atm)
<tseng> i hope they like ponies
<Riddell> jdub: which old package name?
<jdub> Riddell: libqt3c102-mt
<tseng> libqt3-mt-bogglewoo102
<tseng> or that
<jdub> heh
<jsgotangco> ahhh oktoberfest...
<tseng> -mt-mysql shares a similar fate
<jdub> libqt3cplusplusisspecialyo102-mt
<jsgotangco> jdub: pony?
<Riddell> jdub: hmm, is there a way to get round that?
<jdub> jsgotangco: have you seen him?
<jdub> Riddell: Provides: libqt3c102-mt
<jdub> if it's acutally compatible
<jdub> but running skype seems to work
<jdub> it's just hideously slow and ugly
<jdub> well, once it appears it's okay, but it takes a looooong time to appear
<Riddell> jdub: won't that break things that break with libqt3c102-mt?
<jdub> but it certainly seems to be happily linking to qt3
<jdub> Riddell: if there's an abi change between libqt3c102-mt and libqt3-mt, then it would be silly to add a Provides
<jdub> but whatever skype uses, it works okay
<azeem> jsgotangco: oktoberfest?
<j^> maybe its possible to ask them to change it to libqt3-mt (>= 3:3.3.4) | libqt3c102-mt (>= 3:3.3.3.2)
<jsgotangco> azeem: yeah i
<jsgotangco> azeem: lots of beer
<azeem> jsgotangco: you are ircing from the oktoberfest? :)
<tseng> jdub: haha i caught you
<tseng> jdub: GOOD MORNING SKYPE LOVERS
<jdub> ;-)
<jdong> tseng: looking into it.... kina suspicious without ~ubp trailers though
<bddebian> Morning
<jdong> against my better judgement, I shall recompile my firefox with crazy CFLAGS
<slomo_> jdong: why?
<Kamion> doko: please ask elmo; this isn't my primary responsibility and I have a ton of stuff to do before the freeze for RC, at the weekend even
<bddebian> Do we have any good info on the whole X11 include/lib dirs ?
<infinity> jdub, Riddell : if anyone changes libqt3-mt to provide libqt3c102-mt, I will smack them very hard.  The package definitely had an ABI change. :)
<bddebian> Heh
<infinity> jdub : Asking skype to compile a package with g++-4.0 for Debian/sid and Ubuntu/breezy would be the Right Thing.
<jdub> infinity: hmm, i guess they'll do that soon enough
* jdub invokes the virtual suit and tie
<jdong> slomo_: trying to get Breezy firefox to match SuSE firefox speed
<jdong> slomo_: currently we are 3.5 times slower
<slomo_> wtf
<jdong> slomo_: interestingly, Epiphany is unaffected by the slowdown
<jdong> hmm, what were those CFLAGS that turned on sse/sse2....
<jdong> -msse/-msse2 :)
<`anthony> jdong: --pretend-that-youre-opera-not-firefox
<jdong> `anthony: lmao
<jdong> are there any cool new optimization flags with GCC 4
<`anthony> jdong: check the gentoo lists *ducks*
<dholbach> :)
<jdong> `anthony: at gentoo forums now :)
<`anthony> glad it's you and not me ;)
<`anthony> why not grab the suse source package and see what flags they use?
<`anthony> or is that cheating?
<desrt> dholbach; patch?
<jdong> `anthony: it looks like just -march optimizations
<infinity> jdong : Our buildds already -mtune=pentium4 -march=i486
<dholbach> desrt: i tried it and it still behaves the same
<desrt> i hate me
<dholbach> desrt: i told mvo to check it
* dholbach hugs desrt 
<infinity> jdong : We can't get much better than that and maintain compatibility.
<desrt> no no no.. that's not right.. it's:
<desrt> you make me hate me
<jdong> infinity: Two possibilities here: (1) -march=486 is not aggressive enough, or (2) pentium4 causes regressions on K8
<dholbach> oh come on... everybody loves you
<desrt> dholbach; k... so i think it's interaction with the other bug
<desrt> dholbach; which i still don't understand for shit
<dholbach> L A O L A   for  desrt !!!     come one! :)
<desrt> dholbach; O_o
<dholbach> YAAAY! :)
<desrt> heh.
<infinity> jdong : Are you sure the slowdown isn't due to things we link to?  (ie: Is SuSE using gtk 2.8 and cairo?)
<desrt> dholbach; here's the story
<jdong> infinity: I'm _quite_ sure that SuSE 10.0 would be using GTK 2.8, but maybe not cairo
<`anthony> maybe just email whoever packaged the suse version and ask them?
<desrt> dholbach; today i'm doing an installfest... hopefully someone's laptop starts acting up
<Mithrandir> or look at the SRPM?
<jdong> infinity: isn't cairo theoretically supposed to improve render speeds via hardware accel?
<dholbach> desrt: excellent
<infinity> jdong : In time.  Currently, it slows things down a bit (though not enough that most people should care)
<`anthony> do other gtk apps have the same speedup?
<jdong> how about I ask you guys: Why's epiphany 2x faster than Firefox, if they use the same Gecko engine?
<`anthony> 2x faster for what?
<jdub> ... and how did you measure?
<jdong> scragz rendering test; confirmable by day-to-day experience
<jdong> http://scragz.com/tech/mozilla/test-rendering-time.php
<`anthony> they using the same compiled code (same shared libs &c?)
<jdong> `anthony: why else would epiphany have dependencies on firefox?
<jdong> bugzilla #15534, btw
<jdub> jdong: GTK+ 2.8 requires cairo; there's no hw accel underneath atm
<jdong> jdub: k, that clears up the Cairo bit, but at the same time frees SuSE of guilt
<jdong> for the record, mozilla.org's binaries ALL match SuSE's speeds... It's something wacky with our firefox  package
<jdong> Kinda wacky, but GCC4 regression? *ducks
<Kamion> or local patches
<`anthony> try rebuilding with older gcc?
<jdub> what are opensuse using?
* jdub bets it's gcc4
<jdong> Hmm, Opensuse using GCC 4.0.2 CVS
<jdong> I suspect local patches
<jdong> Are all "our" patches within debian/patches?
<infinity> No.  firefox doesn't use a patch system.
<jdong> i.e. if I get ticked and reverse them all, am I back at official sources?
<infinity> You get to dig through the debdiff.
<jdong> k
<jdong> is GCC 3.4 binary-compatible with GCC4?
<shackan> any idea why one can't use KDE progs (like amarok) in gnome ?
<infinity> In theory, the output of both compilers should be ABI compatible.
<jdong> shackan: you cant?
<jdong> shackan: it's a PITA, but certainly not impossible
<jdub> it's a PITA?
<jdong> jdub: kbuildsyscocoa and friends have to run on first KDE app, which takes quite a while
<jdub> that is not a PITA :)
<`anthony> shackan: er, i run kde progs under gnome all the time
<jdong> I run K3B under GNOME all the time
<shackan> ok, test case  : Joe user clicks Applications -> Add applications to see if there's some cool software to check out, he installs amarok, but amarok won't work
<jdong> amarok runs here under GNOME
<jdong> there's a 15 second delay on my 1GHz system though :)
<janimo> infinty, are you working on http://bugzilla.ubuntu.com/show_bug.cgi?id=6316, the low memory install bug?
<shackan> but you started dcopserver, kbuildsyscoca etc by hand?
<shackan> jdong, argh
<shackan> this sucks dog nuts
<jdong> shackan: no, I didn't. That runs automatically, and seemingly stalls for several seconds
<`anthony> shackan: it's only first time you start a kde app in a given session
<jdong> It's terrible on slow computers
<jdong> with an AMD64, I can't complain :)
<infinity> +// Use LANG environment variable to choose locale
<infinity> +pref("intl.locale.matchOS", true);
<infinity> +
<shackan> `anthony, any idea why it does not here ? ( up-to-date breezy )
<infinity> Anything that changes default locales always smells suspicious for speed issues.
<`anthony> shackan: Nope. 
<`anthony> WFM
<Kamion> mmm, could be a running-in-UTF-8-locale slowdown
<jdong> infinity: oh?
<`anthony> Kamion: ASCII is the answer.
<shackan> `anthony, I'm not familiar with debian's TLAs :)
<`anthony> Works For Me.
<Kamion> that's not a Debian-specific acronym
<shackan> ah, okay
<shackan> I'll try reinstalling it..
<Kamion> infinity: what janimo said above - I thought you were on the l-r-m udeb enormousness bug
<infinity> Kamion : Did you ever talk to mdz about dropping that udeb completely?... You were supposed to ping me back about that. :)
<Kamion> I know, but I thought I'd asked you to make it smaller in the meantime ...
<infinity> Wires may have been crossed halfway through that conversation, then. :)
<infinity> I'll shrink it first thing in the morning when I'm at "work" again.
<Kamion> I think we are going to keep it, but there'll have to be a binutils-static-udeb (ugh)
<Kamion> ta
<infinity> Kamion : And to be crystal clear on this, we only want madwifi, none of the other drivers lrm ships?
<Kamion> anything that qualifies as a "NIC module", nothing else
<infinity> Well, I'm a bit fuzzy on how to classify the AVM ISDN stuff.
<Kamion> none of the ISDN stuff
<infinity> Check, then just madwifi it is.
<Kamion> so yeah, looks like ath_hal only
<janimo> Kamion, do you think a sync of dh_make from sid would risky? Fixes cdbs mode.
<janimo> would be I mean
<infinity> Packaging tools in stable releases don't matter too much to me anyway, as I figure people doing packaging should be tracking the latest and greatest in the development releases.
<infinity> So, if we release with a broken dh_make (either cause it's broken now, or cause we break it syncing), does it matter? :)
<janimo> no  Iinstalled dh_make manually form sid
<janimo> but the motu's still use breezy and will for a while until dd starts.No big deal just would be nice
<Kamion> now really isn't a good time for syncs of stuff that we haven't had time to test in the context of Ubuntu, imho
<janimo>  I assumed devel tools are low impact, but fine
<jdub> users/isvs will build packages on this release
<jdub> a broken dh_make would be embarrassing and silly :)
<janimo> just cdbs and bzip2 support are borken I think :)
<janimo> http://packages.debian.org/changelogs/pool/main/d/dh-make/dh-make_0.40/changelog
<jdong> infinity: yeah it matters... the backports team will be clawing at you for the next 6 months and 13 days :)
<sistpoty> infinity: could you plz. check if c2hs is a p-a-s? it should built on amd64 as well according to debian-changelog entries
<infinity> Backporters would never have a use for dh_make.
<infinity> sistpoty : Looks like.
<infinity> sistpoty : Just i386 and amd64?
<sistpoty> infinity: to changelog it should build on any arch, but i haven't seen other arches in debian
<sivang> sistpoty: what is p-a-s ?
<infinity> sistpoty : Ahh... It used to build-dep on ghc{4,5}
<infinity> sistpoty : Now builds with ghc6, so it should be good on all arches.  I'll clear it up.
<sistpoty> infinity: thx
<sistpoty> sivang: package arch specific... will be built only on selected arches (file stored on buildd iirc)
<jdong> have you guys thought about doing more errata updates for stable releases?
<desrt> +1
<jdong> like how even today Warty's Nautilus FTP client still destroys binary data?
<Kamion> janimo: how much have you tested dh_make from sid to make sure it's not broken in various normal use cases?
<Kamion> jdub: you too
<Kamion> we need somebody to take active responsibility for the workingness of syncs at this late stage, and to monitor them after they enter the archive
<janimo> Kamion, TBH I only called it once to generate my cdbs package :) so not intesively
<janimo> but I can look at the diff to see if it poses risks
<Kamion> I'd prefer actual testing
<Kamion> I can look at the diff too, but I don't have time to put it through its paces
<janimo> ok 
<janimo> hmm there's a bug filed against the latest version about incorrect orig.tar.gz names so risky it is.
<janimo> btw is there a dh_make equiv for generating CDBS packages then?
<Kamion> janimo: if that bug exists in 0.39 too, it's OK
<Kamion> it doesn't look major to me
<jdub> Kamion: oh, i thought you were concerned the sycn would be broken - didn't realise it's broken atm!
<Kamion> jdub: the current package is (apparently) only broken in certain cases. I am concerned the sync will be broken in other ways, since it has many changes; eleven days to release is a very short time to discover problems in a program that's only used rarely by a small number of people
<Kamion> that is why I would like people to test the new version rather than just blindly syncing it
<jdub> yeah, ugly
<j^> mjg59 MODULES_WHITELIST="e100" in acpi-support does not play well with my e100 NIC
<j^> i.e. cat /sys/class/net/eth1/carrier does not work
<mjg59> j^: Hrmph. Right.
<mjg59> I'll remove it for the next version
<sivang> jdub: just talked with my .il IBM contact, going to fetch db2 validation scripts CD today probably :)
<jdub> http://slashdot.org/article.pl?sid=05/10/02/1424228&from=rss
<jdub> sweet
<jdub> oh, that's the old one
<jdub> bah
<sivang> jdub: is still sweet :)
<michele> jbailey, friday I was here with a non working usplash (the totally black screen, remember?)
<michele> it's been fixed with 0.1-19 or -20
<janimo> I am making an artwork package for xubuntu who do I put in copyright holder? The guy drawing the logo, the maintainer, canonical, all of these, none of these ?
<robtaylor> janimo: all
<janimo> (cc) ?
<janimo> just read jdubs entry :)
<Kamion> whoever actually holds the copyright
<zyga> has anyone seen pitty lately?
<Kamion> so the artwork creator for the artwork, and yourself for the packaging if you feel so inclined
<Kamion> I don't see why Canonical copyright would be involved unless you're using something that a Canonical employee did
<sivang> zyga: he was here today morning, read some email and went back for testing I suppose
<janimo> Ok, I;ll just put the artwork guy
<robtaylor> Kamion: good point. i missed that he's snuck canonical in there =)
<sivang> jdub: the israeli branch of the Global Technology group are psyched to help us since their linux guru was astonished to know the all famous Ubuntu folks want to have DB2 certified on their OS :)
<robtaylor> Kamion: i guess if he has anything derived from a original logo, he'd need that
<Kamion> presumably, yeah
<janimo> well it looks very similar :)
<janimo> so I'll put everybody in noone will mind I guess
<Kamion> providing you're abiding by the terms of the licence on any original logo, sure
<robtaylor> what licence is the defualt ubuntu artwork under?
<jdub> sivang: cool
<jdub> sivang: the local LTC dudes did a presentation to dan frye about us - good stuff happening :)
<sivang> jdub: we are makeing waves worldwide :)
<sivang> jdub: they want "us" (it's actually only me here) to come visit them in the TA ibm center, I need to find a free day and go lecture them some Ubuntu :)
<zyga> sivang: I wanted to know if the new .pot exporter is working
<sivang> zyga: I have no idea, but I will make sure to ask it for you
<martinhj> my cdrom drive has not been set up with DMA earlier - is this going to be resolved in breezy?
<martinhj> (CD-rom/DVD-drive) - not been able to use it to watch DVD-movies without editing the hdparm conf-file
<martinhj> that is noe problem for me, but I know of a lot of people it would be a problem for..
<dholbach> bbl
<sivang> jdub: just googled for dan, he an IBM fellow ?
<sivang> hehe  , "In an interconnected world, if the Linux community can work this way, we sure as heck can." 
<jdub> sivang: director, LTC
<sivang> jdub: yeah, very nice. He was once part of the Emerging technologies group which I work with as well.
<jdong> for the Firefox moment of truth.... :)
<jdong> 4.80 seconds.... 1.6 seconds better than before; still doesn't beat SuSE
<jdong> now watch.... Epiphany probably will be a speed demon
<jdong> holy crap, 2.0s
<jdong> matches with Win32 IE4 now :)
<jdong> k, not worth it; rolling back to official
<lamont-away> Mithrandir: should oo.o2-amd64 have 'ia64' in the architecture line?
<lamont-away> likewise, who broke ia32-libs for ia64???
<Kamion> lamont-away: last I checked oo.o-amd64 really dealt with anything that required ia32-libs; I haven't checked oo.o2-amd64
<Mithrandir> lamont-away: probably, yes.
<lamont-away> oo.o2-amd64 dies at dh_gencontrol, because ia64 isn't in the arch list
<lamont-away> and for dapper, ia64 gets mono..
<mdke> jdub, here?
<lamont-away> anyway, back later
<jdub> mdke: yo
<mdke> jdub, how do the timezones work on the fridge calendar? it is wrong on http://fridge.ubuntu.com/node/27 (the meeting is marked as 16:00 UTC in the topic in #-meeting)
<jdub> Start: 2005-10-03 16:00
<jdub> End: 2005-10-03 17:00
<jdub> Timezone: Etc/GMT
<jdub> is that wrong?
<jdub> 16:00 GMT (UTC)
<sivang> jdub: how can I present my self to the GTG here ? (they wanted to know my affiliation to Ubuntu/Canonical)
<jdub> sivang: you're an ubuntu member, right?
<sivang> jdub: true :)
<mdke> jdub, GMT isn't UTC
<mdke> it is an hour later
<mdke> right?
<jdub> ok, so "i am a member of the ubuntu project, with no affiliation to canonical" ;-)
<Nafallo> no, GMT != BST
<sivang> jdub: cool then
<mdke> Nafallo, ah ok, thanks
<jdub> i was of the understanding that GMT and UTC were only different at the very anal retentive atomic clock level
<mdke> ok my bad
<jdub> if you sub to it in evo, and you're on BST time locally, it'll give you the right time
<jdub> churning in the hits from distrowatch
<j^> did an upgrade hoary->breezy the other day by replacing hoar w/ breezy in synaptic, after that i upgraded in synaptic, it failed upgrading mozilla-firefox, i had to open the terminal to make it restart the servies after upgrading libc, nautilus crashed and did not show any icons during upgrade, trying to logout and reboot, gnome-session crashed -> x crashed; after rebooting x complained about broken keyboard setup.
<j^> some upgrade tool other than using synaptic might be needed
<Nafallo> my girlfriend upgraded using synaptics without any troubles at all.
<segfault> morning.
<Kamion> libc problem's known, I believe jbailey is working on that
<Kamion> jbailey: ^-- just checking
<j^> Nafallo did she have the latest hoary-security and hoary-updates installed?
<j^> the problem with the icons is most likely related to changing the theme
<Nafallo> j^: at the time. ofcourse...
<Nafallo> pre firefox 1.0.7 though
<j^> i did it yesterday so i had the latest security fix for firefox installed
<Nafallo> yea, she made the jump around preview...
<j^> after it failed to overwrite some file i just restarted the upgrade again. so the firefox thing was a minor issue
<j^> also X did not start after crashing, but that might have been related to me modifying xorg.conf to addd my wacom tablet
<sivang> oh well, I'm out. Be back later.
<jdong> my usplash hasn't been showing up for the past few days
<tseng> mine is fixed as of today
<tseng> try updating it and dpkg-reconfigure linux-image-`uname -r`
<jdong> off to reboot
<dholbach> re
<Kamion> gar, I hate parted_server
<jdong> tseng: thanks, works great now
<jdong> so why isn't there usplash for shutdown?
<Nafallo> jdong: ENOTIME, probably for dapper.
<jdong> ENOTIME... lol, you know you're talking to a *nix developer when....
<jdong> pinging members of security team....
<jdong> https://rhn.redhat.com/errata/RHSA-2005-772.html are we affected too?
<jdong> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2874
<Nafallo> we are not
<Kamion> jdong: http://people.ubuntu.com/~pitti/ubuntu-cve/
<zyga> sivang: thanks :-)
* zyga travels alot today ;-)
<zyga> screen is usefull :>
<lllmanulll> Hey there, anybody able to use apt-get build-dep ?
<lllmanulll> No matter which package I try to "build-depend", apt tells me it cannot meet the dependencies, is that a known problem these days ?
<Kamion> perhaps your existing system is inconsistent, which apt doesn't like; try 'apt-get -f install'
<lllmanulll> Nope, no problem with that
<lllmanulll> (Only 1 package not updated, which is mplayer)
<lllmanulll> mplayer-k6 actually
<dholbach> lllmanulll: does another 'apt-get update' help?
<Zomb> lllmanulll: the build-dep code sucks, it often fails on pretty reasonable dependency list
<lllmanulll> No...
<lllmanulll> Ah, I see
<Kamion> and you *do* have deb-src lines in /etc/apt/sources.list, right?
<Kamion> (appropriate ones, generally should match the deb lines)
<lllmanulll> Well, I've already tried to ./configure and install whatever it asks me, but it gets tricky :)
<Kamion> that won't help, and will probably hinder
<lllmanulll> Yes, I do have the appropriate deb-src lines
<lllmanulll> Huh wait, I do have a backport line without its deb-src match
<lllmanulll> Nope, doesn't solve the problem (I did apt-get update)
<lllmanulll> Huh, is there another way to know on which packages a given package build-depends ?
<lllmanulll> Maybe from the web ?
<Seveas> apt-get build-dep solves that for you
<Seveas> but this channel is *not* for support
<Seveas> please use only #ubuntu for support
<lllmanulll> All right, sorry, I thought it belonged here since it's development stuff
<lllmanulll> And the problem is precisely that build-dep seems faulty
<lllmanulll> Anyway, thanks :)
<Keybuk> lllmanulll ... now there's a nickname that should be illegal
<Keybuk> don't you know we have Welsh speakers on the channel?
<Keybuk> some of them are choking trying to pronounce that
<lllmanulll> Well, manu is always taken :-p
<lllmanulll> Definitely shouldn't try to pronounce that ^^
<jdub> Keybuk: i added a new feature to the fridge the other day
<jdub> Keybuk: there's a block on the left hand side with random cool stuff in it
<jdub> Keybuk: one of them, i think you will like
<Keybuk> jdub: oh?
<jdub> Keybuk: you may have to reload a few times ;)
<Keybuk> jdub: Ubuntu on Flickr ?
<jdub> Keybuk: keep going ;)
<jdub> (though that is fun)
<Keybuk> You want a pony?
<jdub> :-)
<Keybuk> http://www.netsplit.com/tmp/no.jpg
<jdub> :-)
<Keybuk> just that and the fridge magnet so far
<janimo> keybuk, jdub, it is funny enough without knowing the background, but is there one for this pony thing?
<janimo> ancient zulu folklore?
<jdub> heh
<Keybuk> janimo: NO, PONY
<jdub> it's a joke that resonates pretty broadly
<jdub> hoighty young girls begging for ponies
<jdub> as if their lives depended on it
<janimo> well so much for all your base are belong to us 
<Keybuk> I don't want your base
<janimo> ah, you want a pony
<jbailey> win 88
<jbailey> win 82
<jbailey> Feh
<Keybuk> lose 170
<Keybuk> you die
<jbailey> *thump*
<jbailey> (The sound of me falling to the ground)
<bmonty> elmo: can you please morgue hostap-modules-i386 and hostap-driver?  These packages are unnecessary since this module is now part of the kernel image.
<Keybuk> so, is the list server down?
<Keybuk> I find it hard to believe that there have been so few mails today
<bmonty> Keybuk: I've gotten a bunch
<mjg59> Keybuk: I got mail 10 minutes ago
<mjg59> So "down" seems unlikely
<Keybuk> I've had a few, but nowhere near the usual volume
<bmonty> slow day :)
<Keybuk> 'twas the weekend before preview, and all though the lists, not a user 'twas stirring ...
<Kamion> final holiday before the storm?
<jdub> mail's definitely going through
<mdke> yeah i'm getting it ok i think
<whiprush> 400-ish turn out for my Ubuntu talk at ohio linux fest. 900+ CDs distributed.
<jdub> whiprush: rock and roll :-)
<jdub> whiprush: report for the fridge? :-)
<whiprush> going to bed now, so tired.
<whiprush> yes. I'm so behind.
<jdub> gute nacht!
<jdub> countdown articles start today
<jdub> i'm going to do one when i come home from boating
<whiprush> ugh.
<whiprush> ok, I'll try to get one done tonite.
<jdub> we got ten days ;-)
<whiprush> sorry, been so busy lately. 
<jdub> no probs
<jdub> i will probably write a couple on the plane too
* jdub has a nap
<whiprush> you doing a n-m one?
<whiprush> I'd like to do that one.
<jdub> not for the lead up articles - only going to cover supported stuff
* whiprush nods
* whiprush naps ...
<jdub> will do 'stars of the universe' for universe love
<dholbach> "stars of the universe"?
<dholbach> what will that one be?
<dholbach> jdub: ^ :)
<bddebian> Any of you gurus know how xmkmf works?
<azeem> daniels!
* Zomb does not and does not want to...
<bddebian> azeem: Aye but I think he's gone into hiding :-)
<bddebian> Kamion or infinity: ping?
<Kamion> bddebian: ?
<bddebian> Kamion: Do you know how to manipulate how xmkmf works?
<Kamion> not me
<bddebian> The manpage is lacking :-(
<Kamion> closest I've got to it was while making gxditview not link to libxp6, and even then I just read the bits of the source I needed to read, made the fix that seemed least insane and that worked, and then purged my brain of the horror
<bddebian> Heh
<sivang> dholbach: what's the stars of the universe is ? :)
<Kamion> I'd generally start by grepping around in /etc/X11/config/cf/
<Kamion> but it would probably depend what you're trying to do
<Kamion> anyway, far too much work for a weekend; night all
<dholbach> sivang: what jdub intends to with them
<bddebian> Kamion: Gnight
<sivang> dholbach: what is it ? :)
<dholbach> sivang: that's why i asked
<Keybuk> *sigh*
<Keybuk> not for the first time, I wish there was a recalloc
* sivang is back home. At last working on my bug again.
<bddebian> Is there any chance that the .tmpl files in our xmkmf package are just wrong?
<Keybuk> Kamion: don't suppose you know, off-hand, an easy way to debug a curses app? :p
<Keybuk> gdb and curses don't appear to be friends
<Keybuk> (other than putting a big sleep in it, and attaching quickly)
<bddebian> Keybuk: I don't suppose you know xmkmf? :-)
<Keybuk> bddebian: nope
<Keybuk> I've always avoided it
<bddebian> That seems to be everyone's answer :-(
<bddebian> Where has daniels been?
* ivoks hugs you all!  bye
<Keybuk> ooh, /me learns about "tty /dev/pts/X"
<Keybuk> yay, that spat all over the other terminal <g>
<sivang> Keybuk: could you teach /me ?
<Keybuk> sivang: what would you like teaching about?
* Keybuk can teach you fight.sword.melee for 15412 XP
<bddebian> Hehe
* Keybuk can teach you craft.software.program.C for 45929591359 XP
<bddebian> Oh, oh, I'll take that one
<sivang> Keybuk: about the tty /dev/pst :)
<Keybuk> sivang: in gdb?  well, there's a "tty" command, if you give it the tty of another window you have open, all your program output goes there while your existing terminal stays the same
<bddebian> doko: Hey, do you know xmkmf? :-)
<Keybuk> so if you're running gdb in emacs, and want to debug a curses app, you can send all the curses stuff to a different window
<Keybuk> and still set breakpoints and stuff
<sivang> way cool
<dholbach> bddebian: doko knows everything
<Keybuk> handy
<sivang> Keybuk: what's the program you're debugging ?
<Keybuk> sivang: I've been on/off writing an app that can understand the live timing stream from the Formula 1 website
<Keybuk> so I don't need to run their icky Java thing
<bddebian> dholbach: You know qt3? ;-)
<doko> bddebian: ask daniels, and he'll tell you it is crap
<dholbach> bddebian: no :)
<bddebian> doko: That doesn't surprise me but I have a package that is using it :-(
<doko> bddebian: tough luck
* bddebian gets NO love
<jordi> Kamion: ping?
<jordi> does anyone know how the ubuntu installer team handles translations?
<sivang> mjg59: ping
<mjg59> sivang: Hi
<sivang> mjg59: 'sup? do you have a couple of minutes? I've seen your email about suspension,
<sivang> mjg59: I can send you the inspirion 8200 output, but I need to be able to sleep with nvidia bin drvr
<sivang> mjg59: someone showed me once how to do that, do you know if it's enough to have only the VBESTATE=true ?
<sivang> mjg59: http://muse.19inch.net/~sivan/dmidecode.txt, now you have inspiron 8200 int :)
<sivang> s/int/in/
<dholbach> i'm off guys... have a nice evening
<sivang> dholbach: c'ya
<sivang> jordi: from what I know, Kamion is handeling in some way - last time I helped him with some transaltion and he merged and added them to the PO files
<sivang> anyway all, I'm beat
<sivang> good night
#ubuntu-devel 2005-10-08
<mjg59> sivang: Hrm. The default settings have to work with the default driver
<Nafallo> jordi: AFAIK he downloads the whole pack and merge them by hand.
<sivang> mjg59: I have the proprierity driver installed. Is it the default driver?
<mjg59> Nope
<mjg59> nv is default
<mjg59> If nv works without POST_VIDEO, then we can go with that
<sivang> mjg59: I see, so I guess it works with it, it even worked splendid with the prop. drivers,
<mjg59> sivang: Sorry, I don't quite follow
<sivang> mjg59: however I don't recall the settings invloved.
<mjg59> sivang: Did you need to change the settings for the propriatory driver to work?
<hno73> Riddell: I've uploaded a tarball for you: http://www.theopencd.org/winfoss/kubuntu/current/
<sivang> mjg59: yes
<mjg59> Ok
<mjg59> And with those changed settings, does the nv driver work?
<hno73> Riddell: also see: http://www.omma.org.uk/files/winfoss-shots/Kubuntu01.png
<Kamion> jordi: I try to keep in sync with Debian as much as I can (up to upstream version freeze); where I can't, I've recently started inefficiently merging some translations from Rosetta
<Kamion> jordi: it's not anywhere near as slick as the upstream d-i translation process, which is why I'm increasingly trying to get our strings back into sync with Debian's
<Kamion> 22:59 < CIA-2> debian-installer: joeyh * r31126 packages/partman/partman-base/ (debian/changelog visual.d/bootable visual.d/method):
<Kamion> oh, hooray
<Kamion> 22:59 < CIA-2> debian-installer: * Removed all the fancy utf-8 symbols that noonone understood (the
<Kamion> 22:59 < CIA-2> debian-installer:  tamagushi, black smiley, white smiley, and lightening bolt).
<Kamion> 22:59 < CIA-2> debian-installer:  Just use the same letter abbrevs used in non-utf mode.
* Kamion -> bed
<Nafallo> Kamion: what do you do when we improve strings in Rosetta?
<Nafallo> hmm, missed him
<Riddell> hno73: yeah, got your e-mail, thanks so much
<dilinger> have you guys made plans for the post-breezy kernel yet
<dilinger> ?
<Kamion> Nafallo: I totally ignore them where possible and ask you to go upstream, if they're strings that are already in Debian
<Riddell> hno73: now I just need to grab my flatmates' laptop so I can try it out
<Kamion> I refuse to end up acting as go-between for patches to translations into a language I don't speak
<Kamion> 21:10 < Kamion> Nafallo: would it be possible for you to work with the d-i Swedish translation team to get your changes in there? I'm incorporating your changes to Ubuntu-specific strings, but the problem with
<Kamion>           taking changes to generic strings (ones in both Debian and Ubuntu) in Ubuntu is that I'm then stuck later with having to merge changes in a language I don't speak
<hno73> Riddell: cool, enjoy :)
<Kamion> 21:10 < Kamion> Nafallo: (as it happens I can make out Swedish well enough, but usually not at the level of being able to decide which string out of two alternatives is better ...)
<Riddell> hno73: is the 700MB a final decision for the live CD?
<Nafallo> Kamion: hmm, I should be able to work with him, yes :-).
<Nafallo> Kamion: but the whole everything seems to be a mess when it comes to the installer. I find the same string i templates on Rosetta.
<Nafallo> s/i/in\ x/
<hno73> Riddell: I guess for Kubuntu that decision is much up to you, no? 
<mjg59> jdub: Still around?
<hno73> Riddell: I can easily remove stuff if you need me to
<Riddell> hno73: I'd like to keep in line with ubuntu
<mjg59> Riddell: Did you have any joy with klaptopdaemon?
<hno73> Riddell: OK. So in that case, I don't think the decision is final. Kamion, mdz?
<Riddell> mjg59: yes, just need to tidy up my changes, top of my todo list for tomorrow
<mjg59> Riddell: Rock, thanks!
<Riddell> mjg59: what do you think I should set the default action for "almost no battery life left" to?  hibernate?
<mjg59> Yeah
<nomed> hi all .. just a question
<nomed> how can i unpatch the ubuntu kernel source ..? i need to remove just the vesafb patch 
<mjg59> nomed: Why?
<nomed> it seems the breezy kernel config  it just perfect for my livecd ..
<nomed> but i need  to enable the bootsplash
<nomed> "need"
<mjg59> Heh
<mjg59> Get the kernel source, edit debian/patches/00list, remove the line that references the vesafb patch, fakeroot debian/rules binary
<mjg59> You may need to edit the configs to change vesafb to Y rather than M
<nomed> ok mjg59 thanks
<lifeless> mjg59: what do I need to do to get my hibernate key supported ?
<lifeless> mjg59: oh, and hi :)
<mjg59> lifeless: What sort of machine is it?
<bddebian> Hey mjg59 or Riddell, you guys know anythying about xmkmf? :-)
<lifeless> mjg59: dell X1, I have given you the keys list thrice
<mjg59> bddebian: The day I know anything about xmkmf is the day I die
<mjg59> lifeless: Should work now, except X will probably get confused
<bddebian> Damn that seems to be everyones answer :-)
<lifeless> mjg59: oh cool. I'll try after todays update
<mjg59> bddebian: There's a reason for that
<Riddell> bddebian: what's the problem?
<lifeless> mjg59: what sort of X confusion should I expect? Other than the current screen saver fuckage
<bddebian> Riddell: I think our .tmpl files are wrong
<mjg59> "X becomes unusable when you press the hibernate key"
<lifeless> cool
<lifeless> what causes that ?
<bddebian> It's looking for X binaries in /usr/X11R6/bin instead of /usr/bin
<Riddell> bddebian: have you asked daniels?
<mjg59> The key sends a key down, but no key up
<lifeless> sweet mother of god
<lifeless> does stand by do the same thing ?
<mjg59> So if autorepeat is on, the universe ends
<mjg59> No, standby doesn't
<mjg59> We've hacked around that, but I don't know if Daniel has uploaded it yet
<bddebian> Riddell: I haven't seen him and he usually ignores me :-)
<lifeless> mjg59: man, serious breakage. I take it someone else has a x1 to have given this info ?
<mjg59> lifeless: It seems to be the same on all Dells
<mjg59> I've confirmed it with mine
<lifeless> mjg59: but this is a samsung
<lifeless> mjg59: ;0
<mjg59> Yes
<lifeless> ok
<lifeless> I'll try and report
<mjg59> But it conforms to the Dell spec
<mjg59> It's possible that you'll need to nuke your gnome config
<lifeless> say its not so
<mjg59> It doesn't seem to deal well with new shortcut settings being added
<nomed> mjg59, i can't find the debian dir in linux-source-2.6.12 .. :/
<mjg59> nomed: How did you get the source code?
<nomed> do you mean to download a vanilla kernel and remove that patch from linux-pathces
<nomed> apt-get ..
<nomed> dpkg -L linux-source-2.6.12
<nomed> /usr/src/linux-source-2.6.12.tar.bz2 <--
<mjg59> apt-get source linux-image-2.6.12-9.386
<mjg59> apt-get source linux-image-2.6.12-9-386
<mjg59> even
<Riddell> bddebian: what program is crazy enough to use xmkmf?
<bddebian> Riddell: xfonts-jmk
* mjg59 engages in the half-hour hate for Sony
<mjg59> mdz: If possible, I'd like to be able to make acpi-support depend on radeontool and smartdimmer (both tiny packages)
<elmo> tseng: ?
<tseng> elmo: hm, yes?
<elmo> tseng: why did you upload myththemes rather than requesting a sync?
<tseng> elmo: i didnt realize you could sync from random sources
<tseng> elmo: noted
<elmo> I can sync from anything with a Sources
<daniels> elmo is the syncmastah
<slomo> elmo: did you already remove eclipse from pas? doko fixed it for amd64 and powerpc afaik
<daniels> he lives and breathes for syncs
<bddebian> daniels: !!!
<bddebian> daniels: Do you know xmkmf?
<daniels> ... depends on why you're asking.
<bddebian> daniels: Do you know if our .tmpl files are wrong?
<daniels> in the sense that they have built our monolithic tree virtually untouched for about 18 years now, probably not.
<daniels> why?
<bddebian> In trying to build xfonts-jmk it's looking for bdftopcf in /usr/X11R6/bin and not /usr/bin
<bddebian> And it appears to be getting that after running xmkmf
<daniels> mmm, possibly
<daniels> but that would be in X11.rules rather than in .tmpl
<daniels> try -DXBinDir=/usr/bin
<bddebian> daniels: Will do, thx
<bddebian> daniels: Sorry, I know dumb question but add that to the xmkmf line?
<bddebian> daniels: Well the command seemed to work but it still reverted to /usr/X11R6/bin/bdftopcf :-(
<bddebian>  /etc/X11/config/cf/X11.rules:41: warning: "XBinDir" redefined
<bddebian> Damnit, it appears I've lost him again..
<daniels> try -4 of xmkmf
<bddebian> daniels: From Debian?
<desrt> daniels; who did you say fields l-r-m these days?
<daniels> desrt: infinity-ish
<desrt> heh.  thx :)
<crimsun> mjg59: missing fi on line 26 of /etc/init.d/acpi-support if it hasn't already been reported
<daniels> bddebian: just uploaded to breezy about 45min ago
<mjg59> crimsun: D'oh. Sorry.
<mjg59> 0.42 uploaded
<crimsun> mjg59: great, thanks :)
<bddebian> daniels: OK great thx, I'll try it
<bddebian> daniels: That worked, thanks again!!
<daniels> bddebian: no worries
<wakeless> hmmm, I have found a bug in the preview release of Breezy, it's in Bugzilla and I'm not sure what else I need to do to help.
<wakeless> could someone point me in the right direction please?
<daniels> if it's in bugzilla, it'll be fixed before the final release if it can be
* daniels kicks lamont-away.
<bddebian> Heh
<bddebian> How/where should SONAMES be derived in packages?  libmetakit is getting it wrong.
<Keybuk> derived from what?
<bddebian> It creates the symbolic link:  libmetakit4.so -> libmetakit4-2.4.9.3.so  but libmetakit4-2.4.9.3.so isn't built
<Keybuk> odd
<daniels> probably the debian packaging
<bddebian> Well the .install files do look a little odd
<bddebian> libmetakit2.4.9.3.install has "debian/tmp/usr/lib/libmk4-*.so  usr/lib"  but the -dev.install doesn't.  Is that right?
<daniels> you'd be wanting to look at .links
<bddebian> Even weirder.  There is no .links except for python-metakit.links
<bddebian> Wow, sometimes I can actually fix shit..
<lamont-away> daniels: ??
<lamont-away> ohj
<lamont-away> nm
<daniels> lamont-away: -73 just for hppa?
<lamont-away> well, um, I checked first...
<lamont-away> 27530 Segmentation fault      chroot $ROOT apt-get -y install $LIST </dev/null
<lamont-away> hrmpf
<mae> Hey, what editors do you guys use for source code.. I like vim but it is not very easy to integrate into windowing env.. cut and paste is at best clunky.
<mae> not within the prog mind you, but between other apps
<bddebian> nano.  What else is there? :-)
<mae> bah
<mae> :)
<mae> i'll take vim to nano any day
<mae> GUI editors?
<calc> coughs at nano
<bddebian> mae: Kate? ;-P
<calc> mae: vim-gtk?
<ajmitch> bddebian: emacs, of course
<ajmitch> but let's not have a riot
<lifeless> ajmitch: editors, not kitchen sinks
<lifeless> ;0
<bddebian> lifeless: Amen brutha ;-)
<mae> is there a gnome emacs?
<lifeless> sortof
<mae> or is it as lame as vim-gtk
<lifeless> there is an xemacs with handwaving gtk support
<daniels> yawn, editor wars
<lifeless> daniels: so, I need help filing a bug
<lifeless> daniels: I've no idea how to effectively document what I'm experiencing
<daniels> lifeless: ... just blame it on gtk and seb will fix it?
<infinity> lifeless : Videos?
<lifeless> daniels: heh.
<daniels> either that or buy me a flight up to sydney for debsig and I'll fix it then.
<lifeless> infinity: maybe. if I close the lid and open it again, the screen stays dark
<daniels> (don't forget to buy me beer and a steak sandwich too.)
<lifeless> presumably something is alive, but the only thing I can get to work is the standby button
<infinity> lifeless : I meant "take videos to document it".
<daniels> lifeless: when you run xset dpms force off followed by xset dpms force on, does it come back?
<lifeless> daniels: as root or as me ? I'll open a console in preparation
<daniels> lifeless: as you -- it requires access to $DISPLAY.
<lifeless> it works when it comes back from standby FWIW
<daniels> uh
<daniels> oh, okay
<daniels> yeah, try the xset thing
<lifeless> ok, trying. brb
<lifeless> xset dpms force off brought it back 
<lifeless> I didn't tree the 'force on' line
<lifeless> s/tree/try
<daniels> er
<daniels> if xset dpms force off brings it off, something's wrong
<daniels> so if you run force off, then force on, in a normal session, does it work okay?
<lifeless> xset dpms force off turns the display off
<lifeless> when I hit the up arrow to edit the line (which I can't see), it comes back on by itself
<infinity> I wonder if I'm the only one who wishes the new xscreensaver dialog had the time displayed on it, so I didn't have to login to see what time it is..
<daniels> interesting
<lifeless> doing force on has no apparent effect
<daniels> mjg59: wake up
<bob2> infinity: me too
<\sh> infinity / lamont: please give-back rrdcollect-0.2.3 to the buildds, thx
<bob2> ajmitch: monodevelop should be working in breezy, right?
<ajmitch> bob2: yes, scream if it doesn't
<bob2> ** (/usr/lib/mono/1.0/mcs.exe:7262): WARNING **: The following assembly referenced from /usr/lib/mono/1.0/mcs.exe could not be loaded:
<bob2>      Assembly:   System    (assemblyref_index=1)
<bob2>      Version:    1.0.5000.0
<bob2>      Public Key: b77a5c561934e089
<ajmitch> and.or file bugs with the problems
<ajmitch> umm
<bob2> The assembly was not found in the Global Assembly Cache, a path listed in the MONO_PATH environment variable, or in the location of the executing assembly (/usr/lib/mono/1.0).
<bob2> tho mcs givs a similar error
<ajmitch> that's the main class library
<ajmitch> and mono-classlib-1.0 is installed, right?
<bob2> yes
<ajmitch> ls -la /usr/lib/mono/1.0/System.dll
<bob2> hm, doesn't exist
<ajmitch> hm, that's a worry
<ajmitch> ls -la /usr/lib/mono/gac/System/1.0.5000.0__b77a5c561934e089/System.dll
<ajmitch> does that one exist?
<bob2> no
<bob2> dpkg says System.dll should, tho, so it looks like my system is screwed
<ajmitch> they both should, and only one of them is a symlink
<ajmitch> we were having problems with symlinks & upgrades that has been fixed
<bob2> and now it works
<bob2> thanks :)
<sabdfl> morning guys
<ajmitch> morning sabdfl 
<fabbione> hey sabdfl 
<sabdfl> how's the badger?
<Yagisan> G'day
<fabbione> looking very very good
<bob2> ajmitch: is nunit in ubuntu/debian anywhere?
<ajmitch> bob2: I sponsored the upload to debian last week
<fabbione> sabdfl: this time we will also get Breezy Sparc (for Developers mainly)
<bob2> ajmitch: oh, yay
<ajmitch> so it should be in now
<ajmitch> bob2: I'll try & get it synced for breezy then, shall I?
<bob2> ajmitch: that would be awesome, thanks
<ajmitch> ah, nunit is on incoming.debian.org if you want it now
* ajmitch will bbiab, anyway
<sabdfl> fabbione: fantastic! with installer?
<fabbione> sabdfl: yes of course
<fabbione> ubuntu-desktop in full afaict
<fabbione> we miss OO2.. but well.. it will be in for dapper
<fabbione> not enough spare time to even look at it :(
<fabbione> the rest is all there
<fabbione> but we can't really release for Users yet.. unfortunatly X autoconfig is not state of the art for sparc and all the people involved have headless machines :(
<sabdfl> ok, it's still a good start
<sabdfl> and community feedback should help to address the OO.o2 and X issues during the Dapper cycle
<\sh> fabbione: usable for sun blade 1000? looks like I have one as spare in our office...
<fabbione> sabdfl: exactly :)
<fabbione> \sh: should be.. yes
<jbailey> fabbione: That's not entirely fair, my machine is headed.
<fabbione> jbailey: oh right.. but you have a PCI card :) that doesn't address all the different SUN GFX's
<jbailey> Ah, all of my sparcs have had PCI video on them.
<jbailey> I thought they did away with the on-board stuff with sparc32?
<fabbione> the U60 i have doesn't
<\sh> fabbione: hmm...i could test xinerama with it...it has 2 wildcat 3d cards and the usual one on board ;)
<fabbione> but the mobo/cpu are still broken
<fabbione> \sh: xinerama works.. what we need to ttest more is the installer
<\sh> fabbione: isos at the usual places? well...tomorrow I'll grab one
<fabbione> \sh: not exactly the usual place...
<fabbione> but i will ping you when to use one. i need to see if Kamion has time to build a new one first
<fabbione> \sh: http://cdimage.ubuntu.com/ports/daily/current/
<\sh> fabbione: np...today's german reunion day...so u have one day more ;)
<jsgotangco> oktoberfest?
<jsgotangco> heh
<fabbione> oh right
<\sh> jsgotangco: reunion day...
<\sh> jsgotangco: oktoberfest starts in september...and it ends..oh well, today :(
<jsgotangco> ohhhh
<rob^> mmm lots of german beer..
<rob^> a couple of years ago some drunken idiot smashed a glass stein over someones head and since then we only have plastic steins at the local events here
<\sh> rob^: oh sorry...but this happens during the oktoberfest all the time...that's why avoid this party at all...and it's in munich, bavaria...so a no go for me ;)
* rob^ sobs something about being poor
<\sh> k...time to do some real life work....
* ajmitch returns to life
<rob^> I've had the plesure (?) of climing thru roofs all day, I guess it isnt a good thing that my eyes and chest now kind of hurt a little
<rob^> dam fiberglass
<ajmitch> rob^: it's not generally a good sign
<mdke> your james bond lifestyle is bad for your health
<rob^> I should have taken the air ducts :)
<mdke> live and learn eh
<rob^> never trust dodgy contractors who tell you that you don't need protection..
<bob2> ajmitch: hm, dunno if it's a bug per se, but monodoc complains it can't show the nunit docs
<ajmitch> with nunit installed?
<ajmitch> morning seb128 
<seb128> hi ajmitch
<bob2> ajmitch: yeah, I have gnunit libnunit-cil libnunit-doc nunit nunit-console  installed
<ajmitch> when do you see the monodoc error?
<bob2> run monodoc, select Various -> Nunit Libraries, get "Unhandle URL" error
<ajmitch> bob2: right, I'll check if it's compatible with the rather old monodoc we have
<bob2> ah
<bob2> (debsums says all the other mono stuff is ok now;)
<infinity> Hrm.  Is there a way to select one plugin over another in Mozilla/Firefox, short of deleting the one you don't want used?
<infinity> If not, then perhaps mozilla-mplayer should dpkg-divert the totem firefox plugin out of the plugins directory when it's installed.
<\sh> infinity: did u get my request from this morning? 
<infinity> Which was?
<\sh> give back rrdcollect 0.2.3-2 (didn't build on 21. september) because of one build-dep...should be fine now
<infinity> Pretty sure it's built and installed now.
<\sh> well...not yesterday 
<infinity> Yes, well.  Ask the archive before you ask me if I've done something for you. :)
<\sh> infinity: when it's in the archive, it should not be listed in unmet-deps list ;)
* infinity points at the archive.
* ..[topic/#ubuntu-devel:Kamion] : Ubuntu Development (not support, even with breezy) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | http://wiki.ubuntu.com/HelpingWithBugs | MOM/NDA producing bad diffs | Colony 5 released: http://cdimage.ubuntu.com/releases/breezy/colony-5/ | Breezy locked down for RC, uploads with mdz/Kamion's approval only
<\sh> infinity: thx ;)
<Kamion> (that's enforced, as usual - you can upload, but it'll sit in the queue until approved. check first if in doubt.)
<infinity> Oh, dang, I should have got that apache2 patch in over the weekend. :)
<infinity> Oh well, not I'll just have to explain it to someone again before I upload.
<infinity> Kamion : And your fixed lrm is on the way-ish.
<Kamion> great, thanks
<infinity> Things got a lot uglier / more complex when we dropped linking.
<infinity> ie: kernel-wedge had a sad.
<Kamion> I've still got several oem-config changes to get in, but there you go
* \sh is blaming madwifi drivers for not having wpa-psk + dhcp 
<infinity> \sh : madwifi seems to work fine, for some value of "work"...
<infinity> \sh : Not sure if they could be made to work BETTER, but there you go. :)
<\sh> infinity: well..it works somehow...wpa-psk + dhcp does not, but wpa-psk + static routes is working
<infinity> Curious.
<\sh> s/dhcp/dhcp requests/
<infinity> Timing issue, perhaps?... dhclient is running while the card is still associating, and it fails?
<\sh> no
<\sh> wpa-psk auth is already done
<ajmitch> \sh: how about with updated wpa_supplicant that went in today?
<ajmitch> hi koke 
<\sh> ajmitch: tested already..no changes
<Mithrandir> Kamion: ok to fix 16780 with the obvious patch?
<ajmitch> ok
<Kamion> jbailey: your ubuntu-docs changelog is concerning
<Kamion> +  Note: This page needs work as the image doesn't display and the CSS
<Kamion> +  file crashes firefox, but this kills the annoying error.
<Kamion> jbailey: I feel *so* comfortable approving that :-P
<\sh> infinity: http://bugzilla.ubuntu.com/show_bug.cgi?id=16785 <- there is a link to a slackware howto...and this guy mentioned the same strange behaviour
<ajmitch> \sh: nothing obvious when running it in foreground & debug on?
<\sh> ajmitch: nothing
<Kamion> Mithrandir: yes - I mostly assigned it to you to confirm that it was the right thing to do
<Mithrandir> Kamion: I haven't actually tested that it will fix what he claims, but it's obviously correct to me, so if it doesn't it's a bug in other places. :-)
<\sh> ajmitch: well...if it was something with wpasupplicant, then static routing shouldn't work at all
<\sh> ajmitch: and tested with two different wlan routers 
<infinity> \sh : You could make that same argument for madwifi.
<Kamion> Mithrandir: certainly a change in languagelist will change LANG; I was mostly checking that you've actually run breezy with LANG=nb_NO.UTF-8
<infinity> \sh : At any rate, this doesn't look like the sort of thing we can fix for breezy, as a week isn't a very long time to roll back to a completely different CVS snapshot, get widespread testing, and call it "good enough".
<Kamion> but yeah, diff is fine
<\sh> infinity: this is for dapper...I know, because I had only now the possibilty to test the wifi 
<ajmitch> \sh: sadly I switched away from madwifi with the new laptop, otherwise I could have tested it
<ajmitch> since I'm using wpa-psk & dhcp here also
<infinity> Someone could always courrier me an atheros PCMCIA or USB card for testing.
<infinity> :)
<\sh> infinity: ah one more thing...running dhcp on separate computer and dhcpd disabled on the wlan router works ;) with wpa-psk ;)
<infinity> But yeah, not for breezy.  Bouncing around in CVS history, looking for the golden snapshot is far too risky.
* ajmitch probably could, it'd only cost a few $ to ship to au :)
<ajmitch> except the card isn't mine :)
<infinity> \sh : Oh, curious.  So, you are getting linkbeat, and dhcp packets are getting through, it's the router itself that's not speaking to you as you'd like.
<ajmitch> \sh: eh, that sounds a bit broken :)
<\sh> infinity: two routers, different mades?
<infinity> All very weird.
<\sh> infinity: one was a d-link di-524 and the other one a linksys wrt54g with orig firmware and with dd-wrt
<\sh> first I thought, the d-link waits for something special from dhclient somethind ms-ish
<infinity> Well, if people want ath to rock for dapper, send me cheap hardware. (or, bring some disposable hardware to UBZ)
<\sh> cause on windows it works as expected
<fabbione> doko: ping?
<infinity> \sh : Try sending a hostname with dhclient.
<infinity> (It doesn't by default)
<infinity> (and Windows does)
<\sh> gnarf
<\sh> lets test it directly
<infinity>  /etc/dhcp3/dhclient.conf --> send host-name "foo.bar.com";
<\sh> infinity: yeah...
<ajmitch> infinity: I'll bring the madwifi pcmcia card to UBZ, if you can do anything in a few days
<\sh> sometimes I don't think about those things...
<infinity> (Windows only sends the unqualified part, but an fqdn would work just as well...)
<\sh> infinity: if this is the cause...we should change the dhclient config
<infinity> I have an odd feeling that the hostname may have to match the hostname that wpa_supplicant sent, or something equally weird.
<infinity> Your router could be using that as added "security".
<infinity> (For some silly reason)
<\sh> I don't have a hostname in wpa_supplicant..only the shared secret ;)
<infinity> Yeah, I'm not familiar with the WPA protocol.
<infinity> I meant that it might send the hostname as part of the protocol.
<infinity> I have no clue. :)
* infinity still uses old skool, easily-crackable wireless "protection".
<infinity> I have no secrets, it's just to keep the neighbours from leeching my bandwidth, y'know?
* ajmitch can sympathise with that one..
<\sh> I think my neighbours are running wifi scanners ;)
<\sh> no
<\sh> doesn't work
<Yagisan> \sh: If I were them - I would :)
<\sh> yes..my daily disconnect 
<\sh> anyways..static routing works ;)
<\sh> and wep40/128 + dhcp as well
<ajmitch> mm, nice & crackable :)
<infinity> wep40 4 lyf.
<\sh> ajmitch: thats why I'm running wpa-psk + something routing-ish ;)
<carlos> seb128, hi, around?
<seb128> hey carlos
<pschulz01> Greetings, I have tried installing ubuntu colony 4 onto a USB HDD (ipod). I had some problems. Has anyone here tried this.
<Kamion> pschulz01: what architecture?
<pschulz01> Intel. 
<carlos> seb128, we still have problems with evolution, no .pot file. Latest tarball is from 20050915....
<carlos> seb128, did you reupload that package with the fix?
<Mirv> seb128: hey, when are those DesktopTranslations from wiki going to be integrated?
<pschulz01> I could also try it on a mimi mac (currently runnign ubuntu) but I have 
<pschulz01> no ida how to make it boot from a USB disk.
<Kamion> pschulz01: where does it break?
<Kamion> pschulz01: Mac is even less likely to work - it's excruciatingly hard to get yaboot to boot from a USB disk automatically
<pschulz01> Kamion: The installer detects the USB drive ok, but GRUB seem to insist on messing with the boot sector on 'hda' rather than 'sda'.
<Kamion> you should be able to override where grub-installer wants to install the boot sector
<pschulz01> Kamion: Other than this, installer seems to work OK. 
<Kamion> grub does sometimes get drive ordering wrong, annoyingly
<pschulz01> Kamion: I now have a broken Redhat instalation though.
<infinity> That could be seen as a feature. :)
<Kamion> that's what rescue mode's for :)
<pschulz01> hehe.
<Kamion> if you answer "no" to the "Install the GRUB boot loader to the master boot record?" question, it'll prompt you for a boot device
<pschulz01> Is this being looked at? I was dumbly doign a 'chicken' install.
<\sh> pschulz01: u won't miss redhat ;-)
<pschulz01> \sh: I think I will still have to fix it.. It is used by others in the office.
<carlos> Kamion, hi, could you tell me the module you are waiting for being imported into Rosetta? I think it should be already imported but I don't remember the name to check it
<pschulz01> Kamion: Doesn't it prompt for 'partition'?
<pschulz01> I'll have to try it again..
<torkel> fabbione: ping?
<seb128> carlos: I know, I've planned to fix that with 2.12.1 tarballs today
<\sh> anyways..time for me to leave the show here...and enjoy the show with my son :) later dudes
<seb128> Mirv: today, why?
<seb128> jordi: ping?
<carlos> seb128, ok, thanks
<fabbione> torkel: pong?
<seb128> carlos: np
<Kamion> pschulz01: by default, if it thinks it detected all other operating systems on the disk, it just says "can I install to the master boot record?" - no point giving people who won't understand it an obscure partition prompt
<Kamion> carlos: um ... was I waiting for one?
<torkel> fabbione: never mind. I thought it was you doing the last work in ubuntu on memtest86+, but I rememberd wrong
<carlos> Kamion, you asked me last week about something related to debian-installer
<carlos> but I don't remember the details, that's why I'm asking you...
<carlos> anyway, if you don't remember it I suppose it's not too important :-P
<fabbione> torkel: ehe no problem
<torkel> I need a memtest with serial console support turned on :-)
<pschulz01> Kamion: My fault... I'll try again to see it it works. I guess I want to install the bootloader in the master boot record of the USB disk.
<Kamion> carlos: I would have been asking about updates to existing imports, not new imports
<carlos> Kamion, ok, do you remember which ones are?
<Kamion> carlos: for instance most of the updates in https://launchpad.net/distros/ubuntu/breezy/+sources/partman-auto/+pots/pkgconf-partman-auto and https://launchpad.net/distros/ubuntu/breezy/+sources/base-config/+pots/pkgconf-base-config were applied in the distro a few days ago
<Kamion> carlos: not the full list
<Kamion> carlos: well, at least anna archive-copier base-config base-installer cdebconf cdrom-checker cdrom-detect kbd-chooser localechooser partman-auto
<pschulz01> Kamion: Cheer. BFN
<seb128> daniels: hey. Got my mail?
<bob2> ajmitch: any idea if there's an emacs C# mode in ubuntu/debian?
<ajmitch> bob2: probably not, I think the one I used is grabbed off the net somewhere
<carlos> Kamion, seems like all those are imported already...
<daniels> seb128: just got it.  any chance you could get Xorg.0.log too?  sorry, forgot to ask for that earlier ...
<bob2> ajmitch: yeah, I found some guys alleged C# mode, which seemed to be a zip file with 17 modified versions of standard emacs
<seb128> daniels: I'll ask
<daniels> seb128: thanks
<seb128> np
<bob2> ah, there's a standing ITP
<Kamion> carlos: they don't all seem to be up to date
<hunger> I can not burn CDs in breezy: cdrecord (or k3b) assumes the device to use is /dev/sg0 while it actually is /dev/sg1... I guess sg0 is my HD. Is this a bug in cdrecord or udev?
<Kamion> carlos: I know they've been imported - I downloaded translation updates for them from Rosetta ...
<jordi> seb128: pong
<carlos> Kamion, which ones are not?
<seb128> jordi: I guess than you want to do .ca versions of https://wiki.ubuntu.com/DesktopTranslations
<jordi> yes
<seb128> jordi: do they now, we are already a few days late on those uploads
<Kamion> carlos: anna, base-config, partman-auto at least; I haven't found one that *is* updated yet, since ~Friday
<carlos> Kamion, oh, you did a new upload on Friday?
<carlos> that's possible
<Kamion> yes - some yesterday too, those were cdrom-checker and cdrom-detect
<Kamion> but the rest of the ones I listed I uploaded on Friday
<Kamion> this import process seems to be very slow and makes Rosetta difficult to use for me
<carlos> hmmm
<carlos> Kamion, in fact... anna was updated on Saturday, so it should be 100% up to date
<Kamion> we have ten days until we release; delays of three days are a very significant fraction of that :-)
<Kamion> carlos: in that case I think you must have a bug, because it's showing purple bars in the overview page for translations I know I imported
<carlos> Kamion, well, it's just that we had a huge queue to reimport after we fixed a bug, usually the queue should be fast enough...
<sabdfl> carlos: with the main import done, why can't we keep up with the buildd's? any new package built should automatically have transaltions imported, right?
<carlos> sabdfl, right, it should be working
<carlos> Kamion, for instance Swedish?
<Kamion> hmm, let me just download the new translations to check
<Kamion> I updated Hungarian, Slovak, and Swedish on Friday
<lifeless> mjg59: ping
<carlos> ok
<seb128> carlos: do you know what's going on with the control-center-2.0 potfile ?
<carlos> seb128, isn't it fixed already?
<seb128> carlos: the bar is all purple
<seb128> carlos: I've uploaded the fixed package like 4 days ago
<mjg59> lifeless: Hi
<lifeless> mjg59: hibernate is still broken
<lifeless> mjg59: by still, I mean since a fortnight back when I installed
<lifeless> mjg59: comes back up with the swsusp output, acpi IDE device handler is NULL, then stops
<Kamion> carlos: as far as hu, sk, and sv are concerned, the tarball Rosetta gives me now for pkgconf-anna is identical to the one it gave me on Friday afternoon
<Kamion> diff reports no differences
<mjg59> lifeless: Hrngh.
<mjg59> lifeless: Are you using LVM?
<lifeless> mjg59: I don't believe so
<lifeless> mjg59: its my hoary laptop install, upgraded
<Kamion> -rw-rw-r--   1 katie katie 31962 2005-09-30 19:15 anna_1.15ubuntu2_i386.udeb
<mjg59> lifeless: Crap. I'm entirely unable to reproduce hibernate failure.
<tepsipakki> mjg59: fails here too, using LVM
<tepsipakki> has worked
<lifeless> mjg59: tell me what you'd like me to do, short of shipping my laptop to you
<mjg59> lifeless: Short of shipping your laptop to me, this is going to be difficult
<Kamion> carlos: hmm. if a translation is fuzzy in the package, but fully translated in Rosetta, does it show up as blue or purple?
<Kamion> maybe anna is not the best test case
<lifeless> mjg59: I expect that
<lifeless> mjg59: however, its less difficult than the whining I'll do at UBZ if its broken still ;0
<Diziet> Can someone tell me what wnck is ?  (libwnck, wnck-applet)
<mjg59> lifeless: Given that I'm not going to be there...
<mjg59> Diziet: Window Navigation Construction Kit
<mjg59> Or something like that
<Diziet> Ta.
<lifeless> mjg59: garh.
<carlos> Kaloz, purple
<lifeless> mjg59: dodging out like that
<carlos> s/kaloz/kamion/
<Kamion> carlos: oh, ok, maybe anna is ok then
<lifeless> mjg59: seriously though, what would you do to diagnose this ?
<Kamion> carlos: base-installer is still confusing me, though; Greek and Spanish are both 100% translated in the package, but Greek has an all-green bar in Rosetta and Spanish has a purple bit
<carlos> Kamion, anyway, if you download a .po file from Rosetta and import it again without changes setting the 'published' flag, the purple color should disappear
<jordi> seb128: done
<Kamion> and both Greek and Spanish were updated in the last upload
<carlos> Kamion, if you don't upload it by hand, the purple should disapper with next update
<seb128> jordi: thanks
<Diziet> Damn, looks like there might be two (or more!) things that crash when window titles are far too long.
<Kamion> carlos: I don't have privileges to upload by hand, and in any case it's ridiculously time-consuming to upload every .po file by hand ...
<carlos> Kamion, let me investigate a bit with the db....
<carlos> Kamion, it was just a note about how Rosetta works
<Kamion> ok
<carlos> Kamion, if you add them to the .deb package, Rosetta will do the reupload
<Kamion> right
<mjg59> lifeless: Seriously, I have no idea
<mjg59> lifeless: If you do echo -n disk > /sys/power/state, does it suspend/resume?
<carlos> seb128, I will look into control-center after this
<lifeless> mjg59: should I kill X first ? or leave it running
<seb128> carlos: thanks
<Mirv> seb128: ok, thanks.. I was just interested because the deadline was on Friday and I didn't see them integrated then or during the weekend
<mjg59> lifeless: With X, to start with
<Kamion> carlos: it's all a bit confusing because I'm only doing partial updates from Rosetta, based on my judgement of what won't cause difficult-to-resolve merge issues for me when we open up dapper
<carlos> Kamion, sorry, I don't understand the issue...
<Kamion> carlos: basically because automatic exports from Rosetta are so difficult (and in any event I still have to import translations into installer packages by hand), I have to rely on the blue/purple bars to see when something's been updated
<daniels> lifeless: (the X40 works fine)
<HiddenWolf> mjg59, usplash stopped working for me over the weekend, what do you need for a bugreport?
<carlos> Kamion, please, if you have some time, describe the best way you think we should be using to do that so we can prepare a kind of language packs but for debian-installer...
<Kamion> carlos: but because I don't update everything from Rosetta, only Ubuntu-specific strings and ones that are untranslated (because that would put me in a position later of having to decide between multiple conflicting translations in 30-odd languages I don't speak), I don't always get the bars completely updated
<Kamion> carlos: the installer cannot use language packs; it's not technically feasible
<Kamion> (memory constraints, etc.)
<carlos> I know
<carlos> I'm talking about something like...
<carlos> so we give you a tarball with all translations
<carlos> and you move the .po files into their own place
<Kamion> but jordi sent a mail last night which I've yet to reply to, about the merged all-installer-translations files; that should help
<carlos> or something like that
<mjg59> HiddenWolf: Ideally something more than "it stopped working"
<janimo> daniels, are the messages in .xsession-errors starting with the line _IceTransTransNoListen: unable to find transport: tcp
<janimo>  harmless if otherwise X starts ok?
<mjg59> HiddenWolf: Any error messages when you generate an initramfs?
<Kamion> I talked about this with either you or daf in the hoary cycle, though
<jordi> carlos: not feasible either
<jordi> carlos: d-i doesn't use mo files r po files
<Kamion> jordi: huh?
<Kamion> jordi: it certainly does use .po files
<jordi> Kamion: not at runtime
<jordi> it uses generated template files
<Kamion> jordi: yes, but that doesn't matter, this would all happen at build-time
<Diziet> Aaargh!  That firefox index.html is _still_ missing !
<jordi> Kamion: oh, right
<Kamion> Diziet: it's sitting in the approvals queue because the changelog scared me
<HiddenWolf> mjg59, how do I generate one?
<Kamion> Diziet: the changelog claims that the new CSS file crashes firefox, or something like that
<jordi> for Lliurex, we came up with a system to include updated translations for the udebs
* Diziet reads scrool.  Aargh.
<daniels> janimo: yeah
<Kamion> jordi: I've seen it, but I'd much rather steer clear
<Diziet> Is the source in pool ?
<Kamion> cdebconf is very delicate in that area
<jordi> Kamion: surely. We lack the resources to do custm builds for all the udebs though.
<carlos> seb128, ok, found the problem with control-center, it's a bug that prevents us to import it
<mjg59> HiddenWolf: dpkg-reconfigure linux-image-`uname -r`
<Diziet> No, I see it isn't.
<seb128> carlos: bug from the package or from rosetta?
<Diziet> k: Where can I get the source to try it for myself ?
<carlos> seb128, Rosetta
<seb128> k
<Kamion> Diziet: http://people.ubuntu.com/~cjwatson/tmp/ubuntu-docs/
<Diziet> Ta.
<seb128> carlos: what trigger it? just curious
<Kamion> jordi: right. we don't :-)
<carlos> seb128, a plural form
<carlos> seb128, the .pot changes the msgid_plural
<HiddenWolf> mjg59, "not touching initrd/image symbolic links - searching for splash image... none found, skipping"
<mjg59> HiddenWolf: Sounds fine
<carlos> and the .po files are still using the old one and Rosetta gets confused
<mjg59> That's the grub splash, not usplash
<Kamion> carlos: http://people.ubuntu.com/~cjwatson/installer-po/ is buggy for some reason at the moment (it's missing partman-auto at least, possibly others), but if I fix that, would it be possible for you to import it?
<seb128> carlos: the .pot has ""Plural-Forms: nplurals=INTEGER; plural=EXPRESSION;\n"" ... that's coherent with the .po files no?
<Kamion> it's a merged set of translations for (theoretically) all installer packages, roughly paralleling the master files in upstream d-i
<Diziet> k: Did you have to approve ubuntu-artwork (0.2.25-1) ?  Because I'd like to point out:
<Diziet> ubuntu-artwork (0.2.25-1) breezy; urgency=low
<Diziet>     - removed browser homepage
<carlos> seb128, that's part of the template, yes
<lifeless> mjg59: ok
<HiddenWolf> mjg59, anything I can do otherwise when I file a bug?
<lifeless> it did better
<Kamion> Diziet: yes, I know; no, the archive was not locked down yet at that stage
<carlos> Kamion, yeah, we can do that
<Diziet> Ah, right.  How unfortunate.  Oh well.
<Kamion> Diziet: I realise the current situation is broken, and I'm not intending to leave it that way until preview release
<mjg59> lifeless: Ah, ok. That's good.
<Diziet> k: Yes, I was just wondering whether that one needed approval.  Looks like it slipped in.
<carlos> Kamion, will you add those .po files to any .deb source package?
<Kamion> Diziet: I just didn't want to approve something that seemed to imply it would cause the browser to crash on startup on default installs
<Diziet> Yeah.
<Kamion> carlos: no
<daniels> Kamion: (release candidate)
<lifeless> mjg59: what it got right : 
<Kamion> daniels: er, yeah, right, that one
<lifeless> it gave me the shell back 
<lifeless> mjg59: what it got wrong:
<lifeless> it didn't power off the laptop
<mjg59> lifeless: In that case, can you try removing chunks of /etc/acpi/hibernate.sh and/or /etc/acpi/prepare.sh ?
<carlos> Kamion, ok, then we are going to add them as a product outside the /distros/ url
<mjg59> lifeless: Uhm. So it didn't actually suspend?
<carlos> Kamion, do you agree?
<lifeless> I confused X terribly by switching back to alt-f7 without running my 915-resolution-thing
<carlos> Kaloz, just like the ddtp templates
<lifeless> mjg59: it saved a snapshot to disk, then said 'shutting down
<Kamion> carlos: not really - they're intrinsically associated with the Ubuntu Breezy installer
<lifeless> S|
<carlos> s/Kaloz/Kamion/
<lifeless> sda1 shutdown
<mjg59> Or it just didn't power down, but when you powered down manually it then resumed ok?
<lifeless> halting machine
<lifeless> but didn't actually power down
<Kamion> carlos: the hoary version of the same would be totally different
<lifeless> yes, when I powered down manually, it then resumed
<carlos> Kamion, it's a matter of create different branches
<mjg59> lifeless: Ok, yes, that's better
<mjg59> lifeless: Can you try the hacking /etc/acpi/hibernate.sh and prepare.sh, then?
<carlos> Kamion, to put it inside /distros/, I need a sourcepackagename to associate it with
<Kamion> carlos: those branches are just the same as the /distros/ tree though
<lifeless> mjg59: yep
<Kamion> carlos: if it's a matter of needing a reserved piece of the namespace, you can safely use debian-installer
<mjg59> lifeless: Thanks
<carlos> Kamion, https://launchpad.net/products/ddtp-ubuntu
<lifeless> why is the vbestate saving disabled ?
<carlos> Kamion, we can do it as you wish
<Kamion> although there's already a source package called debian-installer which contains .po files for the manual
<Kamion> but it could be a different template within that source package
<carlos> Kamion, that's not a big proble unless both have the same name
<carlos> right
<Kamion> carlos: yeah, that would be best if you can arrange it; if not, the /products/ddtp-ubuntu/-style thing is workable, but it just seems wrong and confusing
<Kamion> I'll try to figure out what's up with the installer-po/ build process today
<carlos> Kamion, ok, I will put you as the owner so you can upload updated .pot files, ok? as part of debian-installer
<mjg59> lifeless: It isn't?
<lifeless> mjg59: >!
<HiddenWolf> mjg59, anything else I can try for debugging usplash?
<mjg59> HiddenWolf: Does it still not work?
<mjg59> lifeless: Video POSTing is
<Kamion> carlos: that would be great, thanks (although it'll be for dapper, as we're past the non-langpack translation freeze now; but best get it set up now)
<HiddenWolf> mjg59, I'll reboot in a minute, but I'm afraid it won't.
<Kamion> carlos: is there any way to upload those automatically?
<mjg59> HiddenWolf: It's only software, there's no need to be scared if it's broken
<Mithrandir> anybody know where ogra is?
<HiddenWolf> mjg59, I'm scared out of my pants, really
<HiddenWolf> :)
<carlos> Kamion, if you add them to the debian installer sourcepackage, that's enough
<Kamion> carlos: you mean in an upload?
<carlos> Kamion, yeah
<Kamion> carlos: that really isn't feasible - uploads of the debian-installer source package are complex and mildly scary
<carlos> Kamion, hmm, if you are not going to use it for breezy, I should not setup it yet, we should wait for dapper in Launchpad
<Kamion> and require special effort from the archive admins
<Kamion> carlos: something I could trigger from a cron job on rookery would be ideal
<carlos> Kamion, another option is that you "emulate" the buildd output
<Kamion> then it could stay up to date automatically without requiring me to upload something all the time
<carlos> Kamion, adding the tarball to people.ubuntu.com/~lamont/translations
<lifeless> mjg59: interesting thing
<lifeless> mjg59: I can cause serial-sleep events
<lifeless> if I hit standyby a few times before it kicks in
<nomed> i'm trying to compile the breezy kernel with gcc-3.3 .. i receive Unknown symbol error for all the modules i try to modprobe from the initrd .. is it normal?
<mjg59> lifeless: Hm. Maybe we should create the lockfile earlier, then
<Kamion> carlos: hmm, interesting, that might be possible given sufficient collusion with lamont
<carlos> Kamion, ok
<Kamion> carlos: thanks, I'll see what I can do about that
<lifeless> the right way to trigger hibernate without the button is via gnome's logout menu ?
<mjg59> Yeah
<bob2> nomed: did you update the initrd to include the modules you compiled?
<nomed> bob2 yes
<bob2> nomed: the default kernel is built with gcc-3.4 and modules compiled with gcc-3.3 are probably not compatible
<Mirv> carlos: is the upload queue again stuck? I tried to upload an utf-8 version of gaim's Finnish translation, but it's been about two days now and no reply (I used "public upload" because of the new charset)
<nomed> yes .. that's possible .. i was just trying .. but it seems it's not compatible
<bob2> nomed: why are you recompiling it with gcc 3.3?
<nomed> i would just use the gcc i had in hoary ..
<Kamion> carlos: yeah, I can definitely confirm that pkgconf-base-installer's idea of what's in the archive is wrong
<bob2> nomed: gcc-3.4 is in hoary...
<carlos> Kamion, what's wrong with it?, outdated?
<carlos> Mirv, let me check...
<Kamion> carlos: yeah, for example Spanish is 100% translated in the package
<nomed> bob2, yes .. now i installed it .. i was meaning that i would use the gcc i already had in hoary
<carlos> Kamion, ok
<carlos> Mirv, where did you upload it?
<Mirv> carlos: https://launchpad.net/distros/ubuntu/breezy/+sources/gaim/+pots/gaim/fi/+translate (so the newest gaim 1:1.5.0-1ubuntu3 package)
<Diziet> kamion: That CSS doesn't seem to be included in the .deb.
<Diziet> It makes the page pretty spare, but it doesn't crash.
<carlos> Mirv, Still 500 files to import since Wednesday (more than 7000 files already imported since then) so I suppose yours is waiting in the queue.
<Diziet> In fact, it's looking for /usr/share/libs/aboutubuntu.css, AFAICT.
<HiddenWolf> mjg59, seems it was initramfs, working like a charm now.
<Kamion> Diziet: ok, thanks - approved, it'll be on archive.u.c in ~25 minutes
<Diziet> Yes, strace confirms that.
<Diziet> Ta.
<Kamion> well, source will, binaries will be ~30mins later
<Mirv> carlos: okay, thanks. it'd be nice to have the better translation in breezy.
<Diziet> It still needs sorting out, badly.
<Diziet> And if the CSS crashes Firefox I'd like to investigate it !
<Kamion> indeed
<Diziet> Jeff seems to know about it: `Fixed in 5.10-5, but further improvements needed to the page (missing image,
<Diziet> missing stylesheet)'
<seb128> carlos: I can drop the translation patch from gnome-panel now, right?
<carlos> seb128, I think so, yes
<seb128> cool
<carlos> let me check it to be 100% sure
<seb128> the patch has basically the translations for the "System" strings 
<carlos> yeah, downloading the .po file to be sure that we have it imported
<seb128> k
<carlos> Kamion, the files that are not updated at Rosetta are due the current queue size, I hope it will be imported tonight
<Kamion> carlos: ok, great; thanks for your investigation
<carlos> np
<mjg59> lifeless: Any joy?
<carlos> seb128, is the patch you want to remove the one that adds this?:
<carlos> #: ../gnome-panel/panel-menu-items.c:939
<carlos> msgid "System"
<carlos> msgstr "Sistema"
<seb128> carlos: yeah
<carlos> seb128, ok, go ahead, Rosetta has that
<seb128> cool, thanks
<lifeless> mjg59: some info, no joy
<lifeless> mjg59: I commented out all of hibernate, no impact
<lifeless> mjg59: so i commented out all of resume, no impact
<lifeless> mjg59: I am thinking it is X. is it reasonable to run /etc/acpi/hibernate.sh from a console ?
<mjg59> lifeless: But. Uhm. If you comment out all of hibernate.sh except the echo call, it's identical to what you tested.
<lifeless> mjg59: I know. the only variable seems to be being in X when it starts
<mjg59> I thought you were in X before?
<lifeless> mjg59: which is why I want to try it without using the gnome knob.
<mjg59> When you did the echo call
<lifeless> I had X running, was sitting in a console when I did the echo -n > disk
<mjg59> Ah, right
<mjg59> Hrm
<mjg59> prepare.sh does a chvt away from X
<mjg59> So it ought to be identical
<lifeless> I'll try echo -n disk > /s/p/s now from within X
<mjg59> Ok
<tepsipakki> mjg59: is swsusp known not to work with LVM?
<mjg59> tepsipakki: It is currently unlikely that it will work
<tepsipakki> mjg59: it used to work here, but now it just tells that is found the data on swap but doesn't load it
<tepsipakki> it found..
<tepsipakki> boots up normally
<mjg59> tepsipakki: If you could produce the exact messages, that would be helpful
<tepsipakki> ok
<tepsipakki> mjg59: how do I get that in /var/log/messages?
<tepsipakki> i mean, the message is lost otherwise
<tepsipakki> lunch first ->
<jdub> mjg59: pong
<mjg59> jdub: What's the best way to get more people to send me information about their working laptops?
<Mithrandir> offer them free beer
<hno73> infinity: ping
<lifeless> mjg59: so that failed
<jdub> mjg59: i can see why working laptops would be more challenging
<jdub> mjg59: hmm
<mjg59> lifeless: Right. If you run /etc/acpi/hibernate.sh from the console, does it work?
<lifeless> exactly what I was about to try
<lifeless> mjg59: I have this in prepare:
<lifeless> # And then try to save some video state
<lifeless> #if [ x$SAVE_VBE_STATE = "xtrue" ] ; then
<lifeless> #  VBESTATE=`tempfile`
<lifeless> #  vbetool vbestate save >$VBESTATE;
<lifeless> #fi 
<jdub> mako: ping
<lifeless> ~line 79
<lifeless> mjg59: do you ?
<mjg59> lifeless: Yes. That's correct. It's saved on boot.
<mjg59> That way we have known good state rather than weird X-addled state
<lifeless> ok.
<lifeless> testing...
<HiddenWolf> mjg59, in any case, you should sent detailed instructions to the -users list
<HiddenWolf> mjg59, I'd tell people "if you fulfill condition A B and C, please run this script, and send me result.tar.gz"
<mjg59> HiddenWolf: I did
<HiddenWolf> mjg59, no reply?
<daniels> mjg59: don't ask them to, just collect and submit the information anyway
<mjg59> HiddenWolf: A small number of replies
<HiddenWolf> daniels, evil! :P
<HiddenWolf> Ubuntu Phone Home
* HiddenWolf calls slashdot. ;)
<jsgotangco> sabdfl, nice page *grin*
<mjg59> lifeless: Anything?
<lifeless> mjg59: yes, echo > /s/p/s from a console isn't working anymore
<lifeless> mjg59: :[
<mjg59> lifeless: Hurrah
<lifeless> mjg59: so, with that failing, what next
<mjg59> lifeless: Can you try when booted into single user mode?
<lifeless> ok.
<zyga_> pietrus: /nick zyga
<lifeless> mjg59: so
<lifeless> mjg59: echoing from single user mode console
<lifeless> didn't power off, did save snapshot
<lifeless> it did resume 'better' - but it did *something* graphical in nature, I got a 640x480ish white square
<lifeless> which I couldn't do anything with
<lifeless> mjg59: I'll pick this up tomorrow.wednesday
<lifeless> mjg59: getting late
<mjg59> lifeless: Ok, thanks
<lifeless> stevea has the same model as me
<tepsipakki> mjg59: umm, after resume I get no sound anymore
<tepsipakki> suspend-to-ram
<jbailey> Kamion: The changelog is to avoid the beatings of "OMG that page is so ugly"
<jbailey> Kamion: The text is correct, and generated from the docbook.  We had thought that symlinking from the old ubuntu-artwork location to the current place would be fine, but that doesn't help the image path.
<jbailey> Kamion: And when I added the CSS file in, FF crashes at startup.
<Nafallo> hmm
<Nafallo> that's english ;-)
<jbailey> So now at least people aren't getting the file not found, message (which was a critical bug in bugzilla), and it gives me a day to figure out with the docteam what should go there.  And probably pre-generate the HTML file with the paths touched by hand and such so that everything's happy.
<jbailey> Kamion: I'm more concerned by the firefox crash with the stylesheet.
<`anthony> tepsipakki: tried unloading and reloading the sound driver?
<tepsipakki> anthony: not yet
<tepsipakki> mjg59: the message from swapon: /dev/mapper/divari-swap: software suspend data detected. Reinitializing the swap.
<tepsipakki> `anthony: reloading helped. funny though, because I don't recall having such a configuration before
<tepsipakki> besides I need to kill all programs that use the device in order to remove the module, which is not nice
<`anthony> tepsipakki: add it to the list in /etc/default/acpi-support?
<Kamion> jbailey: ok
<Kamion> jbailey: (I approved the upload a while back after Diziet tested it to confirm it didn't break fx by default
<Kamion> )
<tepsipakki> anthony: and if I have, say, rhythmbox running when suspending, it can't remove the module..
<Nafallo> use the --force tepsipakki 
<tepsipakki> ok, no need to remove the module.. rhythmbox playing is hung when I resume, but works again if i hit the pause/play button. sound is restored when touching the mixer.. still, this used to work without any fuss
<`anthony> tepsipakki: add a bugzilla?
<tepsipakki> against what? linux?
<Mirv> who is developing language-selector? the country names should come eg. from CLDR or other direct, official source instead of having all the names in a PO file
<Mirv> it's waste of resources to have country names translated again and again
<Mirv> same for languages
<WaterSevenUb> mirv, there was an upload http://lists.ubuntu.com/archives/breezy-changes/2005-September/011966.html
<WaterSevenUb> mirv, was it supposed to solve that?
<WaterSevenUb> mirv, not sure.... how are things in Rosetta?
<jbailey> Kamion: Cool, thanks.  Should be no breakage (tested here), fixes yelp breakage (also tested here), just ugly. =)
<Mirv> WaterSevenUb: might be.. I'm speaking of Rosetta and it has all the strings still in there. so maybe Rosetta just isn't updated? but I was happy to notice that most of the string there were these when I started translating...
<Mirv> WaterSevenUb: but the upload looks nice
<Kamion> Mirv: mvo
<Kamion> Mirv: yes, getting translations from iso-codes should have fixed that
<Mirv> Kamion: yes, mvo just isn't around here atm. it seems the source package in Rosetta is from the same day, probably before the upload.
<seb128> Mirv: is language-selector already translated for your locale?
<seb128> Mirv: you should get the po, run the piece of code from the package to update it and upload the update po file to rosetta
<Mirv> seb128: I just translated the non-country/language strings in Rosetta, before that there was no translations (in Finnish). so it has to be done manually?
<seb128> yep
<seb128> the package po/get-iso-codes-i18n file does that
<Mirv> okay, will do that, let's hope the advertised Rosetta improvements actually make the uploads fly too ;)
<seb128> get the po from rosetta
<seb128> use this piece of code
<bob2> there has to be a "holy fuck leave my network alone" option for network manager
<seb128> and upload your updated po
<bob2> aside from killing dbus
<daniels> bob2: PLEASE GOD YES
<lllmanulll> seb128, Did you solve the problem about untranslatable categories in gnome-panel ?
<seb128> lllmanulll: quite of, but I'm really annoyed by this bug let's take that to a query :)
<pitti> Hi
<Nafallo> morning pitti 
<zyga> pitti: hello :)
<zyga> I missed you pitti :)
<pitti> Hi zyga 
<pitti> zyga: just returned from a long hiking tour, we have a holiday here in .de
<zyga> pitti: did you rest well? :)
* zyga is sick and hacks on his new SMP box
<Kamion> pitti: re ubuntu-cve, openssh >= 1:4.0p1-1 is not vulnerable to CAN-2005-2666
<pitti> Hi Kamion 
<Kamion> hi
<pitti> Kamion: humm, it's not marked as vulnerable on unfixed.html??
<pitti> cve-nonvulns.txt:CAN-2005-2666 openssh breezy
<Kamion> pitti: the Debian version's marked as vulnerable
<Kamion> CAN-2005-2666 	
<Kamion> openssh [Ubuntu: 3.8.1p1-11ubuntu3.1]  [Debian: 1:4.2p1-4, vulnerable] 
<pitti> Kamion: ah, I see
<pitti> Kamion: ubuntu-cve can't override that, it's just parsed from the changelog
<Kamion> ok, I'll edit history
<pitti> Kamion: this Debian part is actually only useful for seeing whether something is fixed
<pitti> Kamion: it's handy for checking which universe packages can be synced, and the like
<Mirv> seb128: very nicely working script, that get-iso-codes-i18n :) uploading now to Rosetta
<seb128> Mirv: cool
<seb128> hey pitti
<zyga> pitti: when you have a second, tell me about the new all-.pots download utility
<doko> hrm, trying to blacklist a driver module (8139too), adding it to /etc/hotplug/blacklist.d/local, then rebuilding the initramfs, but the module is still loaded. what am I doing wrong?
<pitti> Hi seb128 
<pitti> zyga: carlos' tarballs contain the pot files now
<zyga> pitti: where can I fetch them>
<pitti> zyga: right now you can't, I can only publish the last tarball I got
<zyga> pitti: that's good enough :)
* zyga is trying to pinpoint several annoying messages
* Diziet reads scrool.
<Diziet> jbailey: Can you reproduce that css crash ?  If so I'd like to investigate it.
<zyga> pitti: will you accept a trivial, obvious i18n patch for gnome-system-tools
<pitti> zyga: sure
<ploum> Hello
<ploum> is it normal that gksudo doesn't grey out the background anymore ?
<desrt> yes
<seb128> lu ploum
<seb128> ploum: jdub requested to drop that
<ploum> hello seb128 
<ploum> why dropping that ?
<seb128> ask jdub
<seb128> basically some people don't like to get the whole screen changing for entering a password that should be a quick stuff
<zyga> ploum: AFAIR there were some issues (performace or something)
<jdub> it's a bad performance hit, and it's a very scary full screen transition
<jdub> we do need to fix window borders and stuff though
* zyga thought it was better - the window is invisible now
<ploum> ok, because it's rather strange to have a borderless window. 
<zyga> (no chrome - bad)
<seb128> hey jdub :)
* ploum liked the grey background
<zyga> carlos: Can't exec "/home/carlos/gnome2/bin/msgmerge": Nie ma takiego pliku ani katalogu at ../intltool-update line 793.
<zyga> ekhm!!!
<Diziet> jbailey: ping
<zyga> gome-system-tools
<ploum> but thanx for answers :-)
<zyga> cd po && make update-po
* zyga hates autocrap
<jbailey> Diziet: pong
<Diziet> Hello.
<Diziet> Did I hear right that you have some css which crashes firefox ?
<zyga> pitti: what should I do with such an error? I can fix this easily but with automess I don't know what to upload so that others don't have to do this again
<pitti> zyga: no idea, that looks odd; maybe you can use /usr/bin/intltool instead of using the package's?
<jbailey> Diziet: *sigh* Yes.
<zyga> pitti: I did a intloolize  && autoconf && ./configure 
<jbailey> Diziet: When used against the new FF start pasge.
<tepsipakki> mjg59, anthony: my suspend/sound -worries were fixed by running "alsactl restore" after resume
<pitti> zyga: uh, that doesn't qualify as "simple patch" any more
<zyga> pitti: that's not the original problem
<zyga> pitti: one message was not tagged, I just wanted to update .pot and .po's
<pitti> zyga: the pot is automatically generated during package build
<Diziet> jbailey: Well, I'd like to fix it.  We can't have it crashing.  It's probably a vulnerability - a good proportion of crashes are.
<pitti> zyga: and calling intltool update manually should work, doesn't it?
<Diziet> So if you could give me a `how to reproduce' or a reference to a bugzilla bug or something then that would be nice :-).
<jbailey> Diziet: Will do, gime a few minutes.
<jbailey> Diziet: If it's a potential vulnerability, should I avoid putting it in Bugzilla?
<zyga> pitti: hmm, maybe - I can just send the diffs for .c and a pl.po if you're okay with that
<Diziet> jbailey: I don't mind.  Email would be fine.  Nicer, even - no web ui to fight :-).
<carlos> zyga, hi
<carlos> zyga, I'm not that Carlos, sorry....
<carlos> I know nothing about gnome-system-tools
<jbailey> =)
<carlos> zyga, ping 'garnacho' at gimpnet
<segfault> pitti: will https://wiki.ubuntu.com/DesktopTranslations be merged into the langpacks?
<zyga> ah
<zyga> carlos: okay - thanks :)
<seb128> segfault: I'm working on that atm
<pitti> segfault: no, that's not possible
<seb128> segfault: and no, language-pack don't ship desktop files
<WaterSevenUb> pitti, were the desktop translations uploaded already?
<pitti> WaterSevenUb: not sure what you mean, but at Friday I uploaded fresh langpacks
<WaterSevenUb> pitti, I mean... ".desktop" files :-D
<seb128> WaterSevenUb: read the 3 lines before your question?
<pitti> WaterSevenUb: I didn't upload any desktop file update, I wasn't asked to
<seb128> am I transparent or something today? :p
<WaterSevenUb> seb128, lol :)
* pitti thought somebody was talking ... :.-)
<bddebian> Hello
<pitti> Hi bddebian 
<seb128> hi bddebian
<bddebian> Hello pitti, seb128
<zyga> hello hello hello
<bddebian> Hello zyga
<segfault> seb128: ah, thanks.
<zyga> aw... pitti is gone
<zyga> could anone please accept an i18n patch + pl.po for gnome-system-tools
<segfault> who else handle langpacks?
<seb128> zyga: use rosetta
<zyga> seb128: that's a source fix 
<zyga> seb128: I can upload the po but it's still useless
<seb128> zyga: we are string frozen
* bddebian whistles innocently
<zyga> seb128: well then it's a string frozen bug I guess 
<seb128> I'm going to do an upload, point me the fix you want to get applied
* zyga thanks seb128 
<zyga> http://www.suxx.pl/ubuntu
<seb128> k, will use it for the upload
<zyga> seb128: the critical thing is: -		return _(g_strdup_printf ("Partition %s", last));
<zyga> +		return g_strdup_printf (_("Partition %s"), last);
<zyga> someone was blind-tagging stuff I guess
<seb128> nice bug :p
<zyga> :)
<netstar> Shouldn't lspci and lsusb be 64-bit compiled to avoid issues with 64-bit kernels?
<netstar> lsusb has some issues with ppc64 breezy, I wondered whether this was the cause
<Kamion> segfault: just pitti
<ogra> grmpf... where is my gcompris upload gone...
<Kamion> ogra: it's sitting in the approvals queue because it has a totally inadequate changelog to justify an upstream bump three days before RC, and I haven't had time to investigate it yet. Read the topic.
<Lathiat> unstable black hole?
<Lathiat> ah
<Lathiat> does rc lockdown including universe?
<ogra> Kamion, its the only way to fix it... 
<Kamion> Lathiat: no
<Lathiat> Kamion: ok
<Kamion> ogra: write decent changelogs in future
<ogra> ok
<Kamion>    * patched to 7.0.2 fixes #15706, #16476 and #16471
<Kamion> ... is not helpful to reviewers.
<Diziet> Or archaeologists, either :-).
<Mithrandir> ogra: what are we doing wrt content filtering?  I've got a user question about it.
<Kamion> considering especially that #16471 isn't anything to do with the upstream bump
<ogra> yes, patched from cvs7.0.0
<Kamion> right, and I'd rather let mdz approve that sort of thing
<ogra> Mithrandir, postponed to dapper 
<Mithrandir> ogra: ok
<Kamion> I have enough to do approving a billion GNOME uploads :)
<ogra> Mithrandir, squidguard is in universe
<ogra> Kamion, ok
<ogra> Mithrandir, dansguardian
<ogra> too
<jdub> Kamion: you say billion like it's some kind of big number!
<seb128> carlos: around?
<carlos> seb128, yes
<Diziet> kamion: Just FYI, I'm planning a firefox upload tomorrow, to fix: (a) the overly-long title metacity segfault (I can't get a total metacity fix so I'll truncate in firefox) and (b) a few translations in the .desktop.
<seb128> carlos: can gnome-system-tools 05_translations be droppeD?
<Kamion> Diziet: ok, thanks
<carlos> seb128, can I see that file?
<carlos> seb128, chinstrap.ubuntu.com/~dsilvers/paste
<seb128> carlos: msgid "Synchronize _Now", msgid "Install NTP support"
<carlos> seb128, copy&paste it there, please
<seb128> k
<seb128> the patch?
<netstar> is there anyway ntp sync at boot's timeout be reduced, because it takes ages if not connected?
<carlos> seb128, don't worry, what you pasted already is enough
<seb128> cool
<seb128> thanks
<bob2> netstar: it's not ntp's fault.
<netstar> it's the client you use though no/
<bob2> indeed
<seb128> zyga: what is your name? credits for the patch :p
<netstar> on my 1.8ghz ppc it doubles the booting time
<Nafallo> netstar: is that breezy?
<netstar> yes
<Nafallo> works fine here, it fails instantly if I'm not connected.
<netstar> not here :/
<nomed> i compiled the breezy kernel with gcc-3.4 but it seems i have still the same errors .. Unknown Symbol on modprobe module (eg: sbp2|ide-cd)
<bob2> why are you re-compiling the kernel?
<bob2> also, #ubuntu
<nomed> i load the kernel with grub on a cdrom .. is it possible that those errors are related to System.map file ?
<nomed> bob2 ok .. 
<segfault> pittiiiiii
<nomed> bootsplash patch .. just this
<segfault> why translations in http://people.ubuntu.com/~pitti/langpacks/import-buildd.tar.gz are not up2date?
<carlos> seb128, feel free to remove that patch
<seb128> carlos: cool, thanks
<carlos> seb128, Rosetta has it already
<seb128> zyga: ping?
<Simira> open applications are still supposed to be shown on the bottom gnome panel bar, right? 
<zyga> seb128: pong
<zyga> seb128: Zygmunt Krynicki <zkrynicki@gmail.com>
<pitti> lifeless: ping
<lifeless> pong
<seb128> zyga: thanks
<zyga> seb128: thank you :-)
<Lathiat> pitti: mmm, in the reboot notifications
<Lathiat> pitti: we should lose the second 'reboot required'
<Lathiat> pitti: else it says it 3 times, once in the title, twice in the body, seems silly ?
<zyga> seb128: did you also add the translation or should I upload it to rosetta?
<seb128> zyga: rosetta
<zyga> seb128: k, uploading
<pitti> Lathiat: we recently factored this into one reboot notification
<pitti> Lathiat: ah, you mean in the text itself, sorry
<pitti> Lathiat: can you please bug mvo about it tomorrow?
<zyga> pitti: is it possible to translate the notification system messages?
<Lathiat> pitti: ok
<pitti> zyga: yes, it is
<pitti> zyga: just manual work ATM (the only exception is the reboot notice, which should be in Rosetta)
<zyga> pitti: any hints on where to start?
<pitti> zyga: there are just two notes ATM - the language pack update and the reboot notice
<pitti> zyga: the latter should be in rosetta, translations for the former can go to me
<zyga> and the original text?
<zyga> (to be sure)
<pitti> zyga: look in /var/lib/update-notifier/user.d/
<pitti> zyga: but ignore the notification-2.6.12* kernel thingy, that will go awa
<pitti> y
<Keybuk> Kamion: which CD would you recommend we give out at Expo?
<Keybuk> Preview?  Colony 5?  Daily?
<zyga> pitti: k, I'll send you translations okay?
<pitti> zyga: for the langpack update?
<zyga> pitti: hmm
<zyga> ah okay
* zyga sees how this works now :)
<Lathiat> mjg59: new kernel -> reboot -> loading modules -> depmod -a -> usplash timed out
<zyga> hmm
<zyga> pitti: wait
<zyga> pitti: I checked /var/lib/update-notifier/user.d/language-pack-pl_20050701
<zyga> and it has lots of non-polish translations too
<pitti> zyga: IIRC I already have a polish translation
<zyga> pitti: okay I'm stiupid - where are the polish texts again? 
<Mirv> does someone happen to know where exactly the strings for breezy's lock dialog are located? I've tried to find them in gksu, gnome-screensaver and xscreensaver.. (not sure about xscreensaver yet as I've to get the whole po file from rosetta first)
<pitti> zyga: right in the file, Description-pl and Name-pl
<zyga> pitti: the language-pack-pl* has no polish translation, it has german, french and english text
<pitti> zyga: hm, I don't have Polish yet
<zyga> why is it named -pl if it has french and german then?!?
<pitti> zyga: I also have finnish, Portugise, Dutch, and Italian
<Lathiat> mjg59: hrm, actually, it just plain take stoo long, and times out every time
<pitti> zyga: it is for the Polish language pack
<zyga> is this autogenerated by language-support stuff?
<pitti> zyga: yes
<Lathiat> mjg59: noticed that stage of boot has been long for a long time
<zyga> pitti: I have poilsh support and i18n installed - no message though... 
<zyga> strange
<pitti> zyga: just /msg me the translation, that's easiest
<wasabi_> so ubuntu-minimal is about 191M
<zyga> pitti: okay
<wasabi_> any meta package to get it smaller?
<pitti> zyga: I was wrong, I don't have a Polish translation
<zyga> pitti: hmm I have polish translation
<zyga> no, sorry my mistake
<zyga> okay I'll msg you
<Lathiat> jdub: is the new ubuntu about page intentionally just black/white ?
<Lathiat> jdub: it appears to link to a wrong location for a css file
<jbailey> Lathiat: The CSS file was left out intentionally for now because it seemed to cause a segfault in firefox.
<jbailey> Lathiat: The about page will be fixed up shortly, but at least this way it's not giving errors for people.
<Lathiat> jbailey: oh ok
<Lathiat> jbailey: cheers
<Lathiat> jbailey: i wont bother filing a bug then
<jbailey> "FF default page fUgly"
<jbailey> Right, already known. =)
<Lathiat> ah
<Lathiat> i was looking for one
<Lathiat> searchign for css or something
<seth_k> any bug including the word "fugly" is always worth bothering to file :P
<bddebian> Heh
<bddebian> Anyone see a big problem with syncing the newer openswan from Debian?
<bddebian> Riddell: ping?
<Riddell> bddebian: hi
<Lathiat> also, what is the reasoning behidn the Desktop/System menu rename
<bddebian> Riddell: Heya.  kvpnc is an rdepend for openswan.  Do you see a problem with bringing in the newer openswan from unstable?
<Riddell> pef: you uploaded kvpnc didn't you?
<Kamion> Keybuk: Colony 5. Daily *should* be OK at the moment but I haven't QAed it and it would be embarrassing if it were broken
<Keybuk> *nods*
<Riddell> bddebian: poke pef until he answers
<pef> Riddell: yes
<bddebian> heh
<Keybuk> I can't think of anything majorly bad with C5
<Kamion> wasabi_: no
<Riddell> pef: see bddebian's question above
<Kamion> wasabi_: below that, you have to ditch metapackages and start trimming stuff for yourself
<bddebian> Although it appears someone fixed the current openswan so maybe there is no good reason to do it?
<wasabi_> seems like a few things in minimal should go... imo anyways
<pef> bddebian: are you talking about the 1:2.4.0-1 openswan's revision ?
<bddebian> pef: Aye
<Kamion> we moved a bunch out to standard in breezy, but more suggestions are certainly welcome
<wasabi_> like, alsa?
<Kamion> that needs to be in minimal because it needs to be installed in the first stage in order to get hotplug blacklists installed by the time of the first reboot
<Kamion> or at least that was the reason last time I checked
<wasabi_> Hmm. That's holding python in too it looks like
<bddebian> pef: It builds/installs clean but maybe it's unnecessary ?
<Kamion> wasabi_: python ain't coming out as long as Mark is in charge
<pef> bddebian: I don't see problems about this sync
<bddebian> pef: OK, I'll ask elmo.  Thanks
<daniels> seb128: thanks man
<pef> bddebian: kvpnc last version is released today, I will test with openswan 
<bddebian> pef: OK, great
<seb128> daniels: np, do you have any idea of what's wrong and if you can change that for 5.10?
<daniels> seb128: i have a vague idea what this is, but dunno if I can fix it for breezy
<daniels> hah! anticipated your question
<seb128> :)
<seb128> what is the issue?
<daniels> basically, I think pipe setup and mode validation are happening in the wrong order in one very specific instance
<Kamion> wasabi_: also, we have python-minimal in essential, and we made a commitment to the python developers that we would never ship real systems (i.e. discounting ones people put together themselves out of our packages in unusual ways) with python-minimal but without python
<daniels> of course this would all be a lot easier if I actually had one of these laptops to test with, as with anything, but I'll do what I can
<zyga> language-selector is a really crappy name
<zyga> it is very difficult to translate
<wasabi_> Hmm.
<WaterSevenUb> zyga, there is a helpful script that uses iso-codes... see the log of this channel 2 hours ago.
<Kamion> wasabi_: (because apparently it makes the python developers' lives harder when they get lots of bug reports from systems that turn out to have only bits of python installed, rather than the whole thing)
<Mirv> hmm, ok.. could someone with a non-English breezy check if the locked screen's dialog is translated? that way I'd at least know that it's translatable somewhere
<zyga> WaterSevenUb: ?
<zyga> WaterSevenUb: I ment the name itself 'language-selector'
<seb128> daniels: that's a desktop, not a laptop
<daniels> seb128: er, laptops -> machines
<daniels> my brain is fried
<mdz> morning
<pitti> Hi mdz
<wasabi_> Kamion, I don't mind customizing this myself, just having a clean "it is good for an embedded system" starting point would be nice.
<Kamion> seb128: gnome-panel FTBFS everywhere
<Kamion> checking for CLOCK... configure: error: Package requirements (gtk+-2.0 >= 2.7.1 libgnomeui-2.0 >= 2.5.4 libecal-1.2 >= 0.0.97 libedataserverui-1.2 >= 1.2.0) were not met.
<seb128> Kamion: I'll fix that, thanks
<bddebian> Heya mdz
<seb128> Kamion: will fix wnck too
<Kamion> I hadn't noticed that one yet
<Kamion> daniels: the changes to debian/scripts/vars and debian/scripts/vars.hppa in xorg -74 look like a misapplied patch (although they're harmless)
<Lathiat> hrm, new gnome splash is interesting, not sure i 100% like it tho
<bddebian> Uhm, WTF is this in /usr/include/linux/config.h??
<bddebian> #error "Compilation aborted. Please read the FAQ for linux-libc-headers package$
<bddebian> #error "(can be found at http://ep09.pld-linux.org/~mmazur/linux-libc-headers/d$
<daniels> bd	as it says ...
<Kamion> it looks like an instruction to read the FAQ to me
<daniels> kami	gar! frig.  i'll sort tat in the morning with -75.
<Kamion> daniels: no rush to upload *just* for this, as I say it's harmless
<daniels> Kamion: okay
<segfault> seb128: can you fix http://bugzilla.ubuntu.com/show_bug.cgi?id=16448?
<daniels> i'm going to sleep now (hell, the west oast is up and about) anyway, so it's not going to get done before then. ;)
<seb128> segfault: no, I don't maintain this package
<bddebian> Kamion: Aye but I'm not sure I understand the FAQ :-(
<Mirv> mjg59: the latest acpi/someother update seemingly broke Suspend-to-RAM on my laptop, I've tried multiple reboots etc. before that I sent you an e-mail with dmidecode output saying that it works...
<Kamion> bddebian: "don't include stuff in linux/*.h or asm/*.h from userspace"
<Kamion> (paraphrase)
<Kamion> kernel headers don't provide a stable interface. you're supposed to use the glibc headers where available, or if not - though it may seem barmy - copy the specific definitions you need from the kernel headers into your package
<Kamion> things like kernel syscall interfaces are very stable anyway
<mdke> Kamion, thanks for your reply on the docteam string change, I've replied
<Kamion> mdke: ok - it didn't make it to ubuntu-doc@ due to moderation though
<mdke> Kamion, ok someone will push it through
<mdke> as long as jbailey gets them :)
<Kamion> daniels: how much testing has this i830 change had?
<Kamion> daniels: ("> 0" is an acceptable answer :-))
<mako> jdub: pong
<daniels> Kamion: >0, yes
<Kamion> ok, good
<Kamion> you left a junk file around in the top directory, confused me for a bit while debdiffing
<daniels> Kamion: the change looks obviously okay to me.  had never been bitten by that bug, and just as I was in the middle of compiling with that fix, it bit me for the first time.  go figure.
<daniels> oh, fun.  oh well, -75 for the cleanup, I guess.
<segfault> humm, weird. "System->About Ubuntu" is gone. Is this expected?
<mdke> no
<Nafallo> hmm
<Kamion> mdz: gcompris in queue/accepted/ is yours to review as far as I'm concerned - I'd have rejected it at this stage except that it seems to be critical for Edubuntu
<Nafallo> here to :-P
<segfault> maybe gnome-panel missed something?
<bddebian> Kamion: Ahh, then any suggestion on what to do with openmosix? :)
<bddebian> Kamion: And thx btw
<vuntz> segfault: this is probably because the file for about ubuntu is not there anymore
<mdke> segfault, file a bug pls
<mdz> ogra: ?
<Kamion> bddebian: that depends on what it's trying to use from kernel headers and what glibc provides; you'll have to investigate
<bddebian> Kamion: Bah, that sounds too much like work. ;-P
<wasabi_> So what about an ubuntu nano?
<wasabi_> which is seriously nothing except what is neccassary to boot.
<azeem> boot into GNOME?
<segfault> can't do it right now
<segfault> i have to go
<mdke> oh well i can reproduce that
<mdke> segfault, i'll file it
<Kamion> wasabi_: there's a spec for it - https://wiki.ubuntu.com/%c2%b5buntu
<Kamion> but it needs people to work on it
<Nafallo> should I have the gnome-foot at my toppanel now or the ubuntulogo?
<seb128> depending if ubuntu-artwork is installed
<Nafallo> it is
<Nafallo> but it's still a foot
<seb128> so you should have it if you have restarted your panel
<mdke> jbailey, #16916 for you :)
<Nafallo> this change was some days ago, right?
<mdke> yes
<seb128> Nafallo: ls -l /usr/share/icons/hicolor/48x48/apps/distributor-logo.png && dpkg -l gnome-panel
<Nafallo> -rw-r--r--  1 root root 4345 2005-09-30 11:10 /usr/share/icons/hicolor/48x48/apps/distributor-logo.png
<Nafallo> ii  gnome-panel    2.12.0-0ubuntu4 launcher and docking facility for GNOME 2
<seb128> Nafallo: should work
<vuntz> if it doesn't work, then it's seb128's fault ;-)
<seb128> vuntz: who provided this patch, hum? :)
<Nafallo> I'll reinstall the packages ;-)
<vuntz> seb128: can't remember :-)
<seb128> sure, reinstalling will change the code
<seb128> that's not windows :)
<ivoks> :)
<Nafallo> hehe
<seb128> you should better strace it to know what happens
<Diziet> Damn, I'm having to run etags on the ffox source.
<ivoks> well, gnome isn't so far with gregedit, err, gcong :)
<ivoks> typing in dark...
<seb128> ivoks: that's what people who don't know gconf usually say :)
<ivoks> seb128: i admit, i don't know it so well...
<Kamion> Diziet: see you in a week, then ...
<Nafallo> is there a way to kill gnome-panel without having it respawning now? ;-)
<seb128> gnome-session-remove gnome-panel
<doko> Kamion: with todays OOo2-amd64 upload, the deps on -base (in -evolution and -gnome) are gone on all architectures
<vuntz> seb128: it seems you're ready to become a gnome-panel maintainer :-)
* seb128 slaps vuntz
<Nafallo> hmm, I should have told the trace to got to a file ;-)
<seb128> strace -e open
<ogra> mdz, ?
<bddebian> OK screw openmosix
<ivoks> bddebian: ?
<mdz> ogra: <Kamion> mdz: gcompris in queue/accepted/ is yours to review as far as I'm concerned - I'd have rejected it at this stage except that it seems to be critical for Edubuntu
<bddebian> ivoks: I was trying to build openmosix but there's some weirdness about it.
<ivoks> bddebian: /me has years of exp. with openmosix... need a hand?
<ogra> mdz, ah, yes
<mdke> jbailey, given you back #3985 too
<ogra> mdz, i had to bump the patch from 7.0.0 to 7.0.2 for the fixes... and added a good bunh of missing icons
<Nafallo> seb128: it should show up with grep dist tmp/gnome-panel.txt, right? :-)
<ogra> bunch even
<bddebian> ivoks: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=232810
<mdz> ogra: what patch?
<ogra> mdz, it doesnt affect ubuntu 
<ogra> the dpatch in the package
<mdz> ogra: can you explain why it is critical for Ubuntu?
<mdz> er, edubuntu?
<ogra> its a essential package 
<seb128> Nafallo: yep
<Nafallo> seb128: doesn't ;-)
<seb128> Nafallo: are you sure that you run gnome-panel from the package?
<ogra> mdz, its a core component and the 7.0.0 patch fixed ftbfs but had still bugs apparently
<ogra> mdz, most critical a lot missing icons...
<Nafallo> seb128: yes, but I could add the full path to be safe.
<ogra> mdz, which made the admin interface pretty useless..
<mdz> ogra: why are the icons missing?
<ogra> mdz, because they were not in cvs ... 6.5.3 had no admin interface... the ftbfs fix added it too.. abut it wasnt complete... 
<Nafallo> seb128: no change
<ogra> mdz, partially explained in #15706 and #16476
<mdz> ogra: so this bug has existed since August 4th?
<mdz> that's when 7.0.0 was uploaded
<Nafallo> same with a reinstall of gnome-panel gnome-panel-data ubuntu-artwork, just for the fun of it...
<Kamion> doko: hooray, thanks
<ogra> mdz, yes, but the icons didnt before 7.0.1 was released and the last version was puled partially from cvs 
<ogra> pulled even
<jbailey> mdke: re: 16916, from which menu?
<Kamion> doko: although a bit late for tocd3.1
<mdke> jbailey, system - about ubuntu is gone
<mdke> jbailey, changed the path or something?
<seb128> Nafallo: what arch?
<Nafallo> seb128: amd64
<jbailey> Yeah, I moved the path, but I thought seb128 said that it didn't need the path.
<ogra> mdz, in fact it fixes more than it even *could* break... i'd have adde it a week ago, but the screensaver was higher priority and gcompris simply takes ages to fix and testcompile...
<seb128> jbailey: when did I say that?
<ogra> *added
<seb128> jbailey: the panel look for the file to add the menu item
<jbailey> seb128: Doesn't the Systme,  propos Ubuntu just clyelp with a parameter?
<mdke> whoosh
<jbailey> call yelp, rather.
<jbailey> mdke: I haven't seen that yet, because I haven't logged out of this session. *sigh*
* jbailey fires up the laptop for this test.
<mdke> jbailey, you don't need to
<mdke> the panel updates all the time
<jbailey> mdke: It's still here on mine, then...
<seb128> jbailey: right, but the panel code for that is 
<seb128> 	if (g_file_test (DATADIR"/gnome/help/about-ubuntu/C/about-ubuntu.xml",
<seb128> 			 G_FILE_TEST_IS_REGULAR))
<seb128> 		panel_menu_items_append_from_desktop (menu, "ubuntu-about.desktop", NULL);
<mdke> i just updated and saw it without killing the panel
<mdke> jbailey, updated recently?
<jbailey> mdke: A dozen times with my packages when I was working on them yesterday.
<vuntz> seb128: hrm
<vuntz> seb128: shouldn't it test if the desktop file exists?
<seb128> vuntz: oh, shut up now! :)
<mdke> jbailey, hmm
<mdke> jbailey, well i only just got it with today's update
<seb128> vuntz: no, the same package ship it
<mdke> this mornings was fine
<vuntz> seb128: .desktop and .xml are in the same desktop?
<jbailey> mdke: Strange, I guess something else caused a refresh.
<jbailey> seb128: Where's that code so I can fix it?
<seb128> vuntz: no, the desktop is with gnome-panel, the xml is not
<bddebian> Could one of you main types take a look at this Malone bug with my debdiff?: https://launchpad.net/distros/ubuntu/+sources/xfonts-terminus/+bug/2344
<vuntz> seb128: this is... broken. :-)
<seb128> jbailey: on my disk, what is to fix? I've to do an upload anyway
<seb128> vuntz: how so?
<vuntz> seb128: .desktop file should be provided by the package with the .xml
<jbailey> mdke: I was doing all my tests with LANG=FOO yelp; so I could test it in the various languages. =)
<mdz> ogra: why is 7.0.2 packaged as a patch instead of a new upstream?
<vuntz> it makes more sens
<vuntz> e
<seb128> vuntz: doesn't make a difference
<Nafallo> seb128: can I do something else to figure out why it doesn't work here?
<mdke> jbailey, i'm seeing it in en
<vuntz> seb128: well... it seems more logical to me
<mdke> jbailey, segfault reported it with pt_BR
<vuntz> seb128: but I'll shut up :-)
<seb128> Nafallo: ask vuntz he wrote this patch
<Nafallo> vuntz: ^ :-)
<Kamion> mdz: think it would be a good idea to take openoffice.org2-base (the database component) off the CD?
<ogra> mdz, because it enhances the already existing dpatch and you forbid a completly new upstream version... 
<vuntz> Nafallo: apt-get install gnome-panel-dbg
<mdz> ogra: I'm not happy about it, but I've approved the upload.  test it as soon as it builds and make sure it hasn't obviously regressed
<seb128> vuntz: I've a lot of other stuff on my list before moving stuff that work :)
<vuntz> Nafallo: gnome-session remove gnome-panel && gdb gnome-panel
<Kamion> ogra: hiding new upstream versions in patches is deprecated
<ogra> mdz, i did nothing else the whole weekend, its tested and runs fine
<mdz> ogra: the upstream version restrictions are about new code; packaging new upstream code in a patch doesn't let you bypass the release guidelines
<vuntz> Nafallo: need to find the right function. wait a minute :-)
<mdz> ogra: you need to test the binaries that we are actually going to ship
<ogra> mdz, ok. i'll regard that in the future
<ogra> mdz, yup, i know... i dont expect them to work different, but will test them as well as i did with the others
<Nafallo> vuntz: oki.
<doko> Kamion, mdz: I see, that -base is explicitely mentioned in the ubuntu-docs firefox start page
<Kamion> ah
<mdz> Kamion: isn't it a dependency of the package we seed?
<Kamion> that would make translators' lives difficult
<vuntz> Nafallo: br panel_get_distributor_logo
<Kamion> mdz: not any more; doko removed that dependency so that we could remove it from TheOpenCD
<vuntz> Nafallo: run
<Kamion> mdz: well, it's a metapackage dependency, but that's all
<vuntz> Nafallo: let's continue in a /query :-)
<mdz> I absolutely hate that name, by the way
<mdz> "Base"
<Kamion> but it sounds like it's better to consider it one of FirstAgainstTheWall for dapper
<Kamion> mdz: <aol>
<mdz> Kamion: if the dependency is gone, it will just fall out on its own, no?
<mdke> argh
<mdke> openoffice-base is not in breezy?
<Kamion> mdz: nah, the old problem was that -core or something depended on it so you couldn't remove it even with seed changes
<Kamion> mdke: you are reacting prematurely
<mdke> nono
<mdke> i'm not reacting, just curious
<Kamion> openoffice.org2-base | 1.9.129-0.1ubuntu3 |        breezy | i386, powerpc
<mdz> it is late in the day to consider it
<Kamion> mdke: we were discussing a possible change, but seems like it's too late
<doko> the openoffice.org2 meta package depends on it
<ogra> mdz, several people asked me about the workaround you would have provided for the NFs timeout bug for ltsp, what is this fix ? there is nothing added to #12942 except the kernel opts that wont work with our initramfs
<mdke> Kamion, np, sorry if i sounded a bit ott
<mdz> ogra: I don't know what you mean
<mdz> ogra: I added a sleep which seemed to cause it to trigger less often
<segfault> back
<mdz> ogra: has anyone tested the kernel parameters?
<ogra> mdz, someone told someone in #edubuntu you'd have worked out a workaround with jim mc quillian to somehow provide the parameters to te kernel, but he couldnt remember how
<highvoltage> ogra: where can i find these kernel parameters? i can test it now.
<ogra> mdz, doesnt work, they dont get handed out through initramfs
<jbailey> ogra: Any idea why?
<ivoks> seb128: ping
<ivoks> can somebody check something for me?
<ogra> jbailey, nope, but you wanted to add nfs options, remember ? 
<ivoks> in g-v-m, what's the command for adding printer?
<ivoks> gnome-printer-add or gnome-cups-add?
<ogra> highvoltage, #12942
<jbailey> mdke: Ah, it's the gnome-about update I think that triggered it to notice the file not there.
<dholbach> hi
<mdke> jbailey, aha
<seb128> hey dholbach 
<seb128> ivoks: pong
<dholbach> hey seb :)
<Diziet> It's very strange, this firefox source.  It's huge, but every time I want to change something there's only about one place I need to do it.  It makes me wonder what all of the rest of it is doing.
<ivoks> seb128: i'm looking at gnome-volume-manager
<ogra> mdz, apparently it works if the parameters reach the kernel... but they dont get through through a MOPTS commandline
<ivoks> seb128: it says gnome-printer-add
<Diziet> Normally with giant bloatware it's so full of clone-and-hack that any change has to be made many times.
<ivoks> seb128: shouldn't it say gnome-cups-add?
<mdz> ogra: MOPTS?
<jbailey> ogra: If there's something you need, just say, or just add it.  You're the only ones who are really using that code.
<seb128> ivoks: dunno, pitti maintains this code
<ivoks> seb128: ah, sorry
<ogra> mdz, yes, the provided fix in the bug
<mdz> jbailey: what's the best way to provide parameters for modules loaded in initramfs?
<mdz> jbailey: will /etc/modprobe.d work?
<jbailey> mdz: If it's copied in, it will be respected, yes.
<jbailey> mdz: I don't copy it in right now.
<mdz> ogra: MOPTS is an ltsp-specific thinig
<ogra> mdz, yes, thats y prob
<ogra> my
<jbailey> mdz: But I'm just using the system modprobe, so anything that it respects will also be repsected in the initramfs.
<mdz> jbailey: right, I meant having a hook script copy one it
<mdz> in
<azeem> Diziet: maybe it's a giant distributed effort to calculate the true name of god.
<jbailey> mdz: Is it consistantly the same, or will it vary from system to system?
<mdz> jbailey: it will be universal
<jbailey> mdz: If you use manual_add_modules modules paramters
<jbailey> mdz: It ought to pass them in, too.
<jbailey> So which every way is easiest for you.
<jbailey> Or I guess force_load modules parameters
<jbailey> if you always want it loaded.
<jbailey> module singular there.
<ogra> mdz, initramfs tools apparently provides and nfs opts parameter, but jbailey told me its not yet implemented... and after i was told that someone was in #edubuntu while i was away who had a workaround provided from you i was wondering how to do it...
<spayne> what is going on with lists.ubuntu.com?
<ogra> s/and/an/
<mdz> ogra: I see no evidence of someone having tested whether rsize/wsize actually fix the problem as observed in breezy
<jbailey> ogra: Looking at it a workaround could be to add them after the ROOTPATH by separating it with a space.  That's fragile, though.
<jbailey> ogra: Adding the extra variable is changing one line in the NFS only script, though, for testing.
<mdz> ogra: just hand-edit the nfs script and modify the mount command line to test it
<ogra> mdz, its hrd to prove if you cant get the parameters through :) i'll test what jbailey said...
<mdz> see if it actually works before we try to implement it
<ogra> yup
<mdz> ogra: this is trivial
<mdz> ogra:         nfsmount ${roflag} ${NFSROOT} ${rootmnt}
<mdz> edit that line in /usr/share/initramfs-tools/scripts/nfs
<ogra> thanks :)
<mdz> nfsmount -o rsize=2048,wsize=2048  ${roflag} ${NFSROOT} ${rootmnt}
<mdz> ogra: then dpkg-reconfigure linux-image-...
<ogra> yup
<mdz> then sudo ltsp-update-kernels outside the chroot
<ogra> mdz, i'd like to rip out the sessions menu from ldm as long as we dont provide any... ok with you ?
<ogra> lang should stay though
<mdz> jbailey: I thought nfs.ko allowed defaults for these parameters to be set as module parameters, but it doesn't, so if this workaround works, we'll need to do it in initramfs (basically the change I just explained to ogra)
<mdz> ogra: the nfs test is more important
<ogra> mdz, for me both is  :)
<mdz> ogra: one causes thin clients to completely fail to boot, the other is a confusing non-functional menu item
<mdz> ogra:  there is no comparison
<ogra> mdz, i didnt compare them, but its on my edubuntu buglist :)
<mdz> it is not a showstopper
<mdz> but it should be simple and safe
<ogra> nope, thats true
<mdz> so it is reasonable, but only after higher-priority items are fixed
<ogra> yup
<jbailey> mdz: 'kay.  Hardcode that, or do you want another variable read in from the conffile?
<mdz> jbailey: from the file is fine, so long as it's set by default
<jbailey> 'k.  I'll wait for the success report.
<wasabi_> wonder if grub can read from vfat
<dredg> it can
<wasabi_> yippy
<dredg> i have kept my grub directory on C: more than once
<dholbach> hey dredg 
<dredg> dholbach: hi
<ogra> mdz, another thing, do you want mknbi shipped by default ? i think its approved now... 
<Riddell> mdz: can I upload the adept release candidate (and final release tomorrow)?
<mdz> Riddell: what's changed from the version we have?
<bddebian> ogra: Finish fixing tyvis will ya. ;-P
<Riddell> mdz: I sent you the changelog by e-mail last thursday
<ogra> bddebian, nope
<mdz> ogra: no; we've never been able to test whether it works properly
<ogra> bddebian, at least not before edubuntu is in shape
<bddebian> ogra: :)
<ogra> mdz, Yagisan tested it several times
<ogra> mdz, he uses etherboot images
<mdz> Riddell: ok, will review
<mdz> ogra: so it works for him by simply installing mknbi and running ltsp-update-kernels?
<ogra> mdz, (but he tests in vmware)
<ogra> mdz, i wnated to aks for a howto for the wiki
<ogra> havent done it yet
<mdz> ogra: can you give me a URL for his success report?
<ogra> mdz, only the #edubuntu logs
<mdz> Riddell: does it require a new tagcoll?
<ogra> some time before i started with xscreensaver again, i'll look it up for you and mail you the url
<mdz> Riddell: this changelog is not only bugfixes
<Riddell> mdz: yes I think it needs tagcoll 0.3.3
<Lathiat> mm, so i found the drawing code in notification daemon that buggeres up the arrow position
<Lathiat> and next to it it has a nice comment /* HACK! HACK! HACK! */
<Lathiat> mmmm. :)
<ivoks> :)
<Nafallo> seb128: the problem was /usr/share/icons/hicolor/icon-theme.cache.
<seb128> ah ah
<seb128> slaps jdub
<Nafallo> maybe we would want to run gtk-update-icon-cache -f in postinst or something? :-)
<seb128> Nafallo: no, we want not make any cache for hicolor
<seb128> Nafallo: because that's what happen if every single app that install an icon to this dir is not patched
<seb128> Nafallo: jdub screwed
<Nafallo> hehe, oki :-)
<Riddell> Kamion: is it possible to get kubuntu/edubuntu themed usplash on the live CD?  does it just need to be seeded?
<Kamion> Riddell: it's already seeded; I'd've thought that would be enough
<Riddell> oh yes, from the desktop seed
<Riddell> but doesn't seem to work using today's kubuntu live cd
<Kamion> check whether kubuntu-artwork-usplash is installed
<Riddell> Kamion: how can I check that (not got the CD booted up just now)
<mjg59> Riddell: I've just reassigned a bug to KDM, but it seems to have been attached to debzilla.
<zyga> hi
<zyga> did anyone notice that recently nautilus-cd-burner causes the recorder to *!@#$ after recording a cd?
<Riddell> mjg59: number?
<zyga> the drive breaks hard and kernel hangs after trying to mount the cd (after reboot things are well)
<mjg59> riddel: 16485
<sivang> Morning all
<sivang> TB meeting is in 20 minutes right?
<mdz> Riddell: that amarok changelog URL doesn't work for me
<mdz> times out
<Riddell> mdz: their webserver seems to have died
<Riddell> mdz: http://www.google.com/search?q=cache:mQfq-spaD9YJ:amarok.kde.org/content/view/60/66/+&hl=en&ie=UTF-8
<mdz> Riddell: it's a new feature release
<ogra> jbailey, mdz, setting nfs options doesnt change it
<mdz> ogra: :-/
<mdz> ogra: please comment in bugzilla
<ogra> mdz, any idea why we start portmap twice ? (one time in rcS and onetime in the runlevel ?)
<mdz> ogra: do you have a repeatable test case?
<mjg59> Mirv: "Broke suspend to RAM" is not a useful bug report
<mdz> Riddell: if alsasink is the important bit, perhaps that can be backported
<mjg59> Mirv: Please file something in Bugzilla describing the hardware and how it fails
* mjg59 goes out
<Riddell> mdz: ok, I'll ask the developers if that's possible
<mdz> ogra: we start it 3 times I think :-)
<mdz> rcS.d/S43portmap, rcS.d/S45mountnfs.sh, rc2.d/S18portmap
<ogra> mdz, yup, i even tried noloc, and setting the values to 1024, 4096 and 8192 didnt help either, but i had one case where it booted right through after shuffling portmap after nfs (not reproducable) ... i'll do more testing here, i think its some kind of race condidtion rather than a module or nfs-server thing
<mdz> ogra: it fails before even mounting root; I don't see how anything in init could change things
<\sh> Riddell: amarok-1.3.2? lets backport it when dapper is opened, we will have enough problems with updated sqlite stuff 
<ogra> mdz, i doubt its something on the client side
<mdz> ogra: oh, you mean moving portmap on the server?
<ogra> yes
<ogra> it worked once , i have no idea why
<ogra> (it never worked for me on first boot here)
<mdz> they are nfs requests which are not receiving responses, right?
<mdz> not portmap requests
<ogra> yup
<Kamion> Riddell: it's not in the .manifest files; I assume that it was promoted to main after the last livefs build
<sivang> mvo: Hi, have you sorted the lpi warnings already?
<mvo> sivang: no, sorry
<Kamion> Riddell: http://cdimage.ubuntu.com/kubuntu/daily-live/current/, the .manifest files say what's in the livefs images
<sivang> mvo: no it's, I want to work one some trivial stuff / non intrusive , so I'll try work on them some
<sivang> *ok
<Kamion> sivang: no, today's Monday, TB meeting's Tuesday
<sivang> Kamion: ah k, thanks, I think it's stated 3rd Oct on the #u-m topic
<Riddell> Kamion: it's on the install CD 
<ogra> sivang, help with some MOTU stuff... thats all non intrusive ;)
<ogra> sivang, tyvis needs someones love i heard... ask bddebian 
<bddebian> sivang: Yeah, I have a big list.. ;-)
<bddebian> tyvis, gnat-gps, cyphesis-cpp
<Kamion> Riddell: the live CD build process is more complicated and involves more cron jobs
<sivang> ogra: after lpi warnings? ;) (it's in main...)
<Kamion> not all on the same machine and not all directly controlled by me
<ogra> sivang, as you like ;)
<segfault> ogra: when you play with xscreensaver again, could you fix bugzilla's #16448?
<ogra> segfault, there are only two bugs on my prio list for xscreensaver now.. let me see
<segfault> ogra: it's easy, just change the desktop name
<ogra> segfault, thats already the fix  ?
<ogra> (the mentioned one in the bug ?)
<ogra> then i'll fix it in the next upload
<segfault> ogra: yeah
<ogra> :)
<segfault> ogra: just change some chars, heh
<ogra> oki
<zyga> mvo: good evening :-)
<sivang> 'vening zyga 
<sivang> zyga: found pitti eventually?
<jdong> I'm investigating backporting launchpad-integration from Breezy to Hoary... (as recommended by mdz) -- any objections or pointers?
<zyga> sivang: yes :)
<mvo> hey zyga 
<zyga> I'm trying to get ruby application working
<zyga> ruby --version shows 1.8.3
<zyga> apt-cache show ruby | grep -i version says 1.8.2
* jdong converts system to reiserfs while waiting for devs to smack him
<zyga> people say that 1.8.3 is broken and should never be used
<zyga> could anyone give me a hint on what to do?
* ogra smacks jdong for using a crappy fs ;)
<jdong> ogra: it's a helluva lot faster than ext3... I can feel it on my secondary system
<jdong> (and I've yet to have any catastrophes with it, unlike XFS :) )
<ogra> jdong, i'd rather take jfs/xfs than something hans reiser designed ;)
* carstenh hopes jdong has good backups
<jdong> carstenh:  already did that 
* dholbach can feel the missing security aspects resulting in more speed ;-p
<jdong> ogra: jfs is damn slow; XFS has lost me a lot of data
* dholbach is just trolling
<jdong> dholbach: explain?
<carstenh> jdong: ok, then using reiserfs is not a risk :)
<jdong> lol
<ogra> jdong, its a matter of being able to use xfsrepair ;)
<dholbach> jdong: i can't... i was just trolling
<jdong> ogra: I've always confused xfsrepair with rm -rf random_directory_list
<dholbach> jdong: the imagination of "it's faster - we left out the double-checks" was just too tempting :)
* ogra has seen companies going down the drain with reiser and to old backups :)
<bob2> fsck.resierfs appears to  be a shell script that does "cat /dev/urandom > $1"
<jdong> bob2: I thought that was xfs_repair?
<sivang> bob2: LOL
<sivang> guys, just use ext3 :)
<sivang> sweet, sound and safe
<jdong> but seriously, nothing against XFS... it's a wonderful FS if I can guarantee my system doesn't go down
<jdong> sivang: don't mention takes forever, too
<ogra> sivang, doesnt work if youre a speed junkie ;)
<jdong> back on topic... any objections to lp-integration"?
<ogra> not at all
<ogra> you'll need it anyway for all backports
<jdong> ogra: yeah, as I'm realizing :)
<ogra> and its trivially small :)
<sivang> jdong: lp-integration is my middle name, any questios? :)
<ogra> sivang, backports o hoary :)
<jdong> sivang: does it do anything else other than add an annoying translate link to every program?
<ogra> to even
<jdong> sivang: j/k :)
<Nafallo> yes, a support link to :-)
<jdong> LOL
<zyga> anyone knows ruby here?
<ogra> zyga, some guys in -motu do
<jdong> zyga: isn't that a currency in some zelda game?
<zyga> jdong: no, that's ruppies
<jdong> oooh, ok
<zyga> jdong: you are talking to a hudge zelda fan - beware
<sivang> jdong: also can open the "get help" page for each app
<sivang> jdong: s/app/package/
<jdong> zyga: you're talking to someone who's an expert at breaking packages, so beware :)
<jdong> sivang: I see...
<Nafallo> hmm, they got ruppies in indonesia IIRC :-)
<zyga> ruby might be broken for ubuntu
<zyga> and at leas is mis-tagged in the control file
<zyga> s/leas/least/
<jdong> convertfs looks cool (testing on bogus partition)
* jdong has learned the hard way before that it doesn't work in-place on the root fs
* jdong 's current success rate is 0.0% with convertfs
<bob2> I'm shocked to find you can't convert your rootfs, live, to another random FS
<Nafallo> :-)
<ogra> hmm...
<jdong> bob2: from the algorithm, it sounded plausible
<ogra> could work if you abuse swap
<jdong> bob2: but somehow Linux isn't too thrilled when the root fs changes block devices :)
<bob2> plausible? how will you access bits on the partially converted filesystem?
<bob2> switching root fs block devices can be done with pivot_root
<jdong> bob2: you don't need to access them... you just need to convince all running apps to switch /bin to tmp/bin et all
<bob2> how simple!
<jdong> bob2: this was a year ago, when I barely started using Linux...
<jdong> bob2: you know, the newb's "linux can fly" outlook on the shiny new OS?
<zyga> which target CPU should ubuntu packages build for
<zyga> 486 or 686?
<jdong> zyga: 486
<jdong> zyga: though I personally advocate 686 in the near future :-/
<zyga> jdong: okay
<bob2> jdong: you have benchmarks showing it's an improvement?
<Kamion> 686 regresses AMD systems, I believe
* jdong calls up Gentoo friends
<Kamion> scientifically performed benchmarks would be better
<jdong> Kamion: thanks for clarifying that... I don't have any evidence that 686 runs better than 486... :-/
<Kamion> I believe elmo and lamont did some tests before warty
<Kamion> which led to the i386 archive event, because gcc had a bug that broke Via C3s with the optimisation flags we were using
<jdong> Kamion: why doesn't about:buildconfig show evidence of optimization for 486/pentium4?
<Kamion> if about:buildconfig is generated using the flags debian/rules or the Makefile thinks it's using, then it won't be accurate
<jdong> ah, ok
<Kamion> gcc is diverted on the buildds to a script that applies extra optimisations and calls gcc again
<Kamion> s/gcc again/the real gcc/
<Kamion> (archive event => wipe all the binaries in the archive and start again)
<lamont> jdong: in general, the only things that really do better on 686 than 486 are math and/or graphics-intense packages, which already tend to do runtime detection of CPU and run the right version of their code...
<lamont> gcc-4.0:        -mtune=pentium4 -march=i486
<lamont> gcc-4.0.force:  -pipe
<lamont> gcc-4.0.clear:
<lamont> are the flags we {default,force,clear}
* zyga has caused quite a discussion :)
<jdong> lamont: ok, so like mjpegtools should automatically use sse[1/2/3]  upon detecting its presence?
<lamont> jdong: most of them do - I haven't looked at many specific packages, other than just noticing such behavior in staring at build logs
<lamont> that is to say, if mjpegtools doesn't use them automatically, then one should benchmark the diff and see if it's worht turning on
<lamont> but, if turned on, it should be based on a runtime check, not hardcoded to either pentium4 or k7
<jbailey> jdong: FWIW, we (The Debign glibc crew) asked for a year or so for someone to provide us a benchmark showing that libc6-686 was worthwhile and finally just provided it so that we could move on and not have to get any more emails about it.
<jbailey> jdong: But in no case was someone able to provide a piece of software that made a noticable difference that didn't already have the magic in it for the optimisation.
<jdong> jbailey: ok, thanks
* jdong converted the wrong partition :)
<bob2> wasn't -686 eventually required for TLS, anyway?
<jbailey> Nope.
<jbailey> 486 and up for TLS
* ogra noted a mail on -users the other day where someone said -386 "feels" a lot faster for him
<jbailey> All you need is atomic operations.
<jbailey> And if you're really insane (like the hppa folks are) you can use lightweight syscalls to emulate it.
<mdz> ogra: you verified in /proc/mounts that the options took effect, yes?
<ogra> mdz, err... i'll veryify... 
<zyga> jbailey: ligthweigh syscalls?
<bob2> jbailey: so you get TLS with regular libc6?
<jbailey> zyga: I don't know all the details.  I was a big drunk when Carlos explained it to me, but I gather that instead of doing a full syscall transition, you hop into kernel mode, stop scheduling, do the bit that needs to be atomic, start it again and return to userspace.
<jbailey> bob2: Yup.
<bob2> oh, neat
* sivang wonders what is that TLS that's referred to.
<jbailey> bob2: In fact, on every release Ubuntu arch other than i386, there is only NPTL now.
<jbailey> sivang: Thread Local Storage.
<jdong> sivang: LOL
<sivang> TLS is also related to arch, IIRC
<bddebian> sivang: Transport Layer Security ;-P
<Kamion> sivang: I suspect you're thinking of tla
<jdong> sivang: lol, that's tla...
<jbailey> bob2: It comes from the parisc designers deciding that scalability was good, and that engineering details like atomic operations were implementation details that could be solved later.
<jdong> Tom Lord Arch
<bob2> jbailey: haha
<jbailey> bob2: Ask me over a drink sometime after the release. =)
<sivang> yep. Lucky me to have Kamion  here, who knows what I mean when even I don't really recall :)
* bob2 makes a note in his diary ;)
<Lathiat> mvo: hey
<Lathiat> mbi just updated bug 14006 with a patch (dodgy drawn arrows on notification popups)
<Lathiat> mvo: rather
<bob2> oh man
<bob2> go to bed
<Lathiat> mvo: its only for upwards pointing so far, but since thats the default and most common its the most annoying, if you could let us know if it works for you
<Lathiat> bob2: eh why? :)
<mvo> Lathiat: nice, thanks. I'll have a look soon
<Lathiat> mvo: upside down arrow windows are broken to start, their 2*ARROW_HEIGHT extra height
<Lathiat> mvo: (which would affect the calculation to stick the arrow there)
<mdz> Mithrandir: any luck with 15571?
<Lathiat> this bug has been *really* irritating me for weeks, finally pissed me off enough to go find it. :)
<Lathiat> now off to do a daily reinstall
<Lathiat> sicne my system is looking a little hosed
<herzi> seb128: ping
<seb128> herzi: pong
<herzi> seb128: can you please fix http://bugzilla.gnome.org/show_bug.cgi?id=317766 by patching the package? This bug renders criawips (broken) save code completely useless as it cannot even work if it was correct
<herzi> (this is libgsf-gnome-1)
<seb128> herzi: dholbach said he will
<herzi> okay
<seb128> herzi: BTW you can join #ubuntu-desktop for desktop stuff :)
<herzi> soo many chat rooms...
<seb128> herzi: here is fine too, don't worry :)
<ogra> mdz, now *that* was an intresting hint :)
<ogra> mdz, 192.168.0.2:/opt/ltsp/i386 / nfs rw,v3,rsize=32768,wsize=32768,hard,tcp,nolock,addr=192.168.0.2 0 0
<ogra> mdz, with: nfsmount -o nolock,rsize=8192,wsize=8192  ${roflag} ${NFSROOT} ${rootmnt}
<ogra> (was my last line i tested... i didnt change it back to 2048 )
<segfault> shouldn't bugzilla's 16386 follow 16568?
<segfault> well, i'll test it late.r
<ogra> jbailey, any idea to the above ? 
<mdz> ogra: unpack the initramfs and make sure your change took effect
<mdz> ogra: you remembered to chroot dpkg-reconfigure and to ltsp-update-kernels?
<ogra> yup
<ogra> err, chroot dpkg-reconfigure ?
<mdz> ogra: yes
<ogra> hrm...
<mdz> sudo vi /opt/ltsp/i386/usr/share/initramfs-tools/nfs; sudo chroot /opt/ltsp/i386 dpkg-reconfigure linux-image-2.6.12-9-386; sudo ltsp-update-kernels
<ogra> damned...
<jdong> before I waste 6 hours, can anyone speculate if OOo 1.1.5 will backport to Hoary cleanly?
<ogra> i reconfigued the server kernel
* ogra bangs head against the wall
<jdong> the odt support is enough of an incentive
<mdz> is Dennis Kaarsemaker here?
<mdz> ogra: do you know his nick?
<Nafallo> mdz: Seveas 
<mdz> Nafallo: thanks
<ogra> mdz, DapperDrake currently :)
<Seveas> mdz?
<ogra> normally Seveas 
<Seveas> ogra, no that's my logging thing
<ogra> oh
<mdz> Seveas: regarding bug #16743, if you are closing a bug imported from Debian which can't apply to Ubuntu, use the NOTWARTY resolution
<mdz> Seveas: I've added documentation to HelpingWithBugs now
<Seveas> mdz, ok
<Seveas> I'll re-read that page
<Seveas> mdz, that page states 'fundamentally does not apply' is a version difference fundamentally enough?
<mdz> Seveas: it depends on the circumstances
<mdz> if the bug has already been fixed in Debian, such that it will be imported as part of the normal merge process, it's OK to close it NOTWARTY
<mdz> or if it isn't critical for  Ubuntu (such that we'll just wait for Debian to fix it)
<mdz> if you're unsure, just add your analysis as a comment and I'll see it and act appropriately
<Seveas> take http://bugzilla.ubuntu.com/show_bug.cgi?id=16858 as example
<Seveas> If I find out that at works on Ubuntu and this bug does not occur, that would be a NOTWARTY? 
<Seveas> hmm, bad example, the bug is useless :)
<jbailey> ogra: I don't know the NFS stuff at all, but you can add 'break' to the kernel command line and call the pieces yourself by hand if that would save you time.
<ogra> jbailey, i made a mistake with the regenerations.. dont worry....
* ogra reboots to ltsp
<jdong> uhh, is there any good reason why launchpad needs newer bonobo than Hoary?
<jdong> seems to compile cleanly :-/
<jdong> dpkg-checkbuilddeps: Unmet build dependencies: libbonoboui2-dev (>= 2.10.1-0ubuntu2) libgtk2.0-dev (>= 2.8.2)
<jdong> hoary bonobo 2.8.1-1ubuntu1,  libgtk2.0-dev 2.6.4-0ubuntu3
<seb128> jdong: to annoy backporters I guess :p
<jdong> seb128: thanks :-/
<jdong> can we get that changed so that Backports team can resolve outstanding abiword and gaim vulnerabilities?.....
<mjg59> mdz: Around?
<jdong> grumble... and we're under all kinds of freezes now, aren't we... grumble
<seb128> jdong: I've other stuff on my list for the moment but I'll have a look later
<mdz> mjg59: yuep
<mdz> yep
<jdong> seb128: thanks; it was mdz's recommendation to get launchpad integration for Hoary
<jdong> well, I'm going outside for a while... bbl
<mdz> Seveas: not necessarily; the bug could be unreproducible for other reasons
<ogra> mdz, no change with 192.168.0.2:/opt/ltsp/i386 / nfs rw,v3,rsize=2048,wsize=2048,hard,tcp,nolock,addr=192.168.0.2 0 0
<mdz> Seveas: 16743 is a good example; the bug is specific to Debian's binary build and is completely irrelevant to Ubuntu
<Seveas> ok mdz, thanks for the info
<Seveas> I have 50 bugs more to visit on todays list :)
<sivang> jdong|away: what are you trying to get lpi for?
<mdz> Seveas: another common case is "fake" bugs which are filed in debbugs to prevent a package from moving into testing; we don't care about those generally
<mjg59> mdz: Can we pull radeontool and smartdimmer into main?
<mjg59> (And, uh, ship)
<mdz> sivang: rhythmbox
<sivang> mdz: for breezy?
<ogra> sivang, backports
<sivang> ogra: ah
<ogra> sivang, more stuff will follow
<mdz> mjg59: through the usual review process, yes (assuming you didn't write them)
<mdz> re: ship, assuming they're tiny
<sivang> ogra: I see, well, I would have been able to help, but only laptop is here with breezy on it
<ogra> sivang, use a hoary pbuilder ;)
<sivang> ogra: right, but on this slow laptop machine....:-(
<sivang> ogra: even testing minor fixes takes ages on the build cycle
<ogra> mdz, what really bothers me on the above line is the rw... shouldnt that be ro ? 
<mdz> ogra: it's not particularly important
<mjg59> mdz: size 8916 and 16188 respectively
<ogra> true, but as i see the options in pxelinux.cfg/default it should be ro...
<ogra> so these options aren't regarded as well
<mdz> Seveas: also, when fixing the Package field, remember to use " Reassign bug to owner and QA contact of selected component " so that those fields are updated as well
<Seveas> mdz, yes, i did that for all of them afaik
<Seveas> maybe in the beginning I missed a few
<mdz> yes, 16773
<Seveas> sorry
<jdong|away> sivang: so is there any importance in the version deps of lpi?
<sivang> jdong|away: I suspect not, you might try to fetch the src pkg, change the dependencies (and the corrosponding configure lines) and rebuild it
<sivang> jdong|away: the bonobo code just wraps the main l-i.c code for bonobo ui support.
<jdong|away> sivang: it builds clean with dpkg-buildpackage -d :)
<jdong|away> sivang: but due to Backports policy the source package MUST build cleanly to be in backports :)
<ogra> mdz, does the original ltsp use v2 or v3 ?
<mdz> ogra: it uses the kernel default
<ogra> hmm
<mdz> I think
<mdz> ogra: ask jammcq or someone else on #ltsp
<ogra>  /join #ltsp
<ogra> grmpf
<Seveas> mdke, it seems that that function does not work on unconfirmed bugs
<Seveas> mdz*
<Kamion> Seveas: always works for me
<dholbach> brb
<Seveas> eg #16859
<Kamion> I uncheck the "mark as NEW" checkbox; the wrong one always gets bogusly set
<Seveas> yes, I do that too
<Seveas> but after hitting commit and returning to the bug, it's still set to the debzilla@ubuntu
<Seveas> that's why i've missed a lot
<Kamion> Seveas: that has nothing to do with the unconfirmed state; acpi just doesn't have any other default assignee
<Kamion> lots of packages don't
<Seveas> right, ok
<Seveas> that explain
<Seveas> merci
<Kamion> pas de problme
<Kamion> hm, "de rien" would be more idiomatic - oh well
<ogra> Kamion, and you even missed seb128 to impess him :)
<ogra> *impress
<seb128> what?
<jdong> sivang: so can you remove the version deps on the two libs in the next lpi?
<seb128> jdong: I said I'll have a look
<seb128> jdong: no need to ask to somebody else
<jdong> seb128: k, thanks... forgot you were going to :)
<Kamion> 22:24 < Seveas> merci
<Kamion> 22:24 < Kamion> pas de problme
<Kamion> 22:24 < Kamion> hm, "de rien" would be more idiomatic - oh well
<Kamion> seb128: ^-- (what ogra was talking about)
<seb128> ah ah, thanks :)
<ogra> heh
<jdong> Kamion: wow, aren't we all French oriented recently....
<jdong> not just on #ubuntu-devel.. on #ubuntuforums there were grammar lessons in French, too...
<ogra> mdz, 16786 was imported from debian, right ? 
<mdke> aptop
<mdke>  [22:32:53]  < Simira> mjg59: testing right now. Things are getting good for HP, at least.
<mdke> argh
<Simira> :-)
* mdke falls into hole in the ground
<blueyed> I've noticed a difference in the Makefile generated by dpkg-buildpackage and using debuild (which should also use dpkg-buildpackage). With using debuild, it uses a wrong kde_htmldir setting of "${datadir}/doc/HTML". Using dpkg-buildpackage alone it uses /usr/share/doc/kde/HTML (which is right). Is this a known problem?
<Kamion> debuild sanitises the environment; perhaps the package build was inadvertently relying on some environment variable you have set
<Kamion> dpkg-buildpackage and debuild are both several steps away from anything that touches Makefiles directly
<blueyed> Kamion: I've set kde_htmldir=/usr/share/doc/kde/HTML in /etc/profile. Seems like using dpkg-buildpackage seems to honor that, not debuild.
<ajmitch> hm, no pitti
<Kamion> blueyed: debuild is, if anything, more correct. packages should never ever rely on things you've set in your environment.
<mdz> ogra: bugs imported from Debian have an alias starting with 'deb'
<ajmitch> Kamion: chances of getting a new yada in main is approximately nil, right?
<ajmitch> phpmyadmin was synced for a security fix, but the new source build-deps on new yada :-/
<ogra> mdz, yes, i just saw the screenshot on the bug :/ very strange sice i have tested xinerama with lots of people now... for all it seemed to work :/
* ogra wonders why he suddenly has a printer icon in the sytem tray...
<Kamion> ajmitch: I think changes to obscure packaging helper tools that roughly nobody understands and that could make everything that uses them FTBFS are pretty risky
<ogra> i dont even have a printer configured or attached here
<jdong> ogra: (1) print job not finished (2) I've hacked into your computer and am putting printer icons on all X sessions :)
<Kamion> ajmitch: would much rather undo whatever packaging change in phpmyadmin made it build-dep on new yada
<ajmitch> Kamion: yeah, I saw the discussion on dh_make. I'll try it with the older yada & we might have to live with the postrm bug it says it fixes
<ogra> jdong, the latter rather...
* jdong puts nmap away
<ogra> jdong, i have no printer configured here...
<Kamion> ajmitch: completely repackaging it with dh_make would be unwise; you'd have to live with the enormous merge job forever
<jdong> ogra: did you send a print job of some sort to a virtual printer of CUPS?
<ogra> and apparently i cant get rid of the icon grrr
<Kamion> unless you can persuade the Debian maintainer to switch, which is unlikely considering that he's the yada maintainer
<jdong> lol
* jdong 's AMD64 churning away at OOo 1.1.5
<ajmitch> Kamion: I wasn't suggesting doing that, I was referring to somone requesting a dh_make sync :)
<Kamion> ajmitch: oh, right
* ogra reboots for another ltsp test
* ajmitch is not nearly *that* crazy :)
<Kamion> ajmitch: dh_make is somewhat different because packages don't build-depend on it; it's only run by hand
<Kamion> which makes it safer in some ways, but also much harder to effectively test
<ajmitch> yep
<ajmitch> I used to use it at one point
<Kamion> ajmitch: isn't yada one of those helper packages that fills in new build-depends on the current version of itself, or something ghastly like that? you might find that rebuilding the source on breezy, ignoring build-depends the first time, makes it lower the build-dependency ...
<ajmitch> Kamion: all I know is that it's ghastly
<Kamion> the postrm bug fix is certainly not release-critical in any way
<ajmitch> I hope it doesn't rewrite build-depends
<jbailey> yada is one of those things that makes people feel okay when they read the source to cdbs. =0
<ajmitch> jbailey: oh dear
<ajmitch> phpmyadmin is universe anyway (surprisingly)
<ajmitch> so it's not going to block anything
<jdong> ajmitch: great excuse :)
<ajmitch> jdong: ?
<Kamion> doesn't surprise me - I'm sure php used to be blacklisted from main in the warty days
<jdong> ajmitch: am I to expect breezy-updates to be in good use for this release season?
<ajmitch> jdong: depends on what is allowed in
<jdong> There are times where known bugs in various programs really tick me off
<jdong> i.e. Warty Nautilus FTP
<jdong> ajmitch: what kind of stuff is _supposed_ to be let into *-updates?
<jdong> maybe I'm just misunderstanding the purpose of that channel
<ajmitch> jdong: I don't know, I don't set that policy :)
<ajmitch> as far as I know it's just critical & security fixes
<jdong> I'd like to see errata updates for Ubuntu stable releases....
<jdong> ajmitch: does the default FTP client screwing up all binary files it touches not quality as critical?
<jdong> (FYI gftp is in universe, apart from ncftp there are no other Main FTP clients)
<ogra> bah, i still have a printer in my tray after reboot
#ubuntu-devel 2005-10-09
<ogra> PITTI !!!
<jdong> lol
<ajmitch> jdong: it may qualify 
<jdong> ajmitch: (it's 12 months overdue :) )
<Nafallo> jdong: ehm? what's happened to lftp? ;-)
<ajmitch> jdong: complaining to me doesn't get it much faster though ;)
<jdong> ajmitch: the developer response was "live with it...." no updates to stable releases...
<jdong> lol
<jdong> well, ajmitch, I'd think you have greater influence on internal policy than me....
<ajmitch> jdong: not much more
<jdong> I am a mere mortal who breaks others' ubuntu systems :)
<jdong> speaking of that, anyone object to OOo 1.1.5 for Hoary?
<jdong> adds ODT support; huge incentive
<tseng> breezy is in 10 days
<tseng> fwiw
<robertj^> updates scares me
<jdong> I just walked a guy through upgrading hoary->breezy... dunno how well it'd go
<robertj^> I just don't grok it at all
<jdong> but I did a server from Warty->Breezy, and it worked great
* jdong assumes everyone's overjoyed with OOo backported; fires off e-mail to elmo ;)
<robertj^> jdong: I think 1.1.5 is great for hoary
<jdong> initial testing shows that nothing appears to break...
<jdong> only time and 20,000 angry users will tell....
<robertj^> jdong: its good practice for dapper though
<robertj^> people will be backportinng things to dapper for a looong time
<jdong> (and a couple incensed devs complaining about me not being on IRC, too)
<jdong> robertj^: absolutely. It'll be great to have this Backports stuff 100% smoothed out by Dappper
<tseng> 1 : to apply or offer incense to
<tseng> 2 : to perfume with incense
<jdong> brb, having multiple users complain about X failures.... gonna check myself
* tseng boggles
<jdong> tseng: when fire issues from the eyes, ears, or mouth of an animal
<jdong> lol
<jdong> or indignant: angered at something unjust or wrong; "an indignant denial"; "incensed at the judges' unfairness"; "a look of outraged disbelief"; "umbrageous at the loss of their territory" 
<jdong> but that last one sounded so good
<Kamion> jdong: I think the FTP client problem you cite above is a perfectly reasonable candidate for warty-updates; somebody just needs to do the work
<jdong> Kamion: ok; bugzilla entries have been filed, but I think they were marked INVALID
<jdong> months back
<ploum> has someone ever set up a planet here ?
<ploum> I can afford to set mine with the latest nightly :-(
<ploum> ERROR:root:Update failed for <http://zefredz.frimouvy.org/rss.php> (Error: 404) 
<ploum> for each feed
<Nafallo> ploum: dude... the planet maintainers live here.
<ploum> Nafallo, it's why I ask here ;-)
<robertj^> jdong: the real tough issue is do you recommend users to upgrade from OpenOffice 2.0 to 2.5 in dapper
<ploum> so jdub, if you have time to waste, can you tell me if the nightly of planet is broken ? (it's really time to waste, you must have important things to do, I understand)
<jdong> robertj^: I think that has to be the case.... Ubuntu has to get the separation of end-user apps from the core system like this
<jdong> robertj^: most Windows users find the "distribution" model unappealing
<jdong> but I can usually convince them otherwise when showing them the upgrade ease :)
<ploum> ok, forget it ! it was on my side
<lamont> smurf: ping
<smurf> lamont: *yawn* 
<lamont> smurf: why does keyboard-chooser.udeb fail when there's no keyboard plugged into the machine???? huh? huh?
<smurf> lamont: umm... good question. I suggest that I'll try to answer that after I've gotten some sleep. ;-)
<lamont> thanks
<smurf> lamont: Is there a bug for that problem someplace?
<lamont> Just encountered it (headless box), I can certainly file one.
<Kamion> I haven't seen such a bug
<Kamion> although I've been running into a few annoying problems with kbd-chooser, mostly related to i18n I think - that won't be the case here
<smurf> I freely admit I haven't tried to install from a headless box like, umm, ever
<jdong> out of curiousity, is /var/lib/dpkg/* repairable?
<jdong> I've seen XFS systems where those files got corrupted
<jdong> dpkg doesn't work too well without it ;)
<Kamion> smurf: I think the if chain at the end of keymap_ask() is just missing a case for kbd-chooser/no-keyboard
<jdong> I think RPM has a command to rebuild the db
<Nafallo> jdong: heard about the thing commonly called backup? :-)
<jdong> Nafallo: this particular server admin didn't think anything important was in /var....
<smurf> Kamion: Thanks; I'll look into it tomorrow (meaning, as it's 00:50 right now, "after sleeping")
<jdong> Nafallo: I don't know how he kept his job
<Kamion> smurf: sure
<azeem> jdong: you can usually recover available by running apt-cache dumpavail > /var/lib/dpkg/available, IME
<Nafallo> :-P
<Kamion> there are backups of old /var/lib/dpkg/status in /var/backups/
<Kamion> the rest isn't terribly recoverable
<jdong> Kamion: does azeem's commands have any value?
<jdong> (wow my grammar sucks today)
<Kamion> jdong: yes, although 'dselect update' is simpler
<Kamion> (and equivalent)
<jdong> ok; but the status file can't be rebuilt?
<Kamion> no, the status file contains most of dpkg's brain
<Kamion> it's theoretically possible to guess at some of it, but I'm not sure anyone's actually done it, and at best it would only work on systems that are otherwise in a completely sane state
<Kamion> which seems a bit optimistic :-0
<Kamion> :-)
<Nafallo> hehe
<Kamion> diversions and statoverride would be hard to rebuild too (you'd have to effectively reinstall all packages for the first, which would be hard without existing diversion state, and the second is sysadmin-provided information)
<azeem> TIMTOWTDI
<dholbach> hey azeem 
<Kamion> /var/lib/dpkg/info/ could be rebuilt by downloading all installed and removed-but-not-purged packages and unpacking their control areas, assuming you knew which packages were installed and removed-but-not-purged
<jdong> k, thanks guys
<jdong> that clears it up
<Kamion> basically, back up /var/lib/dpkg/
<jdong> exactly
* jdong informs sysadmin he's lost his job
<Kamion> jdong: (azeem's a long-time Debian developer BTW)
<jdong> Kamion: ok. I'm not too familiar with much of the dev community around here... keep me posted :) I'm new and still a stranger
* dholbach hates mailman-malone interaction passionately
<mdz> Seveas: btw, essentially every bug which has ever been filed against 'acpi' is wrongly assigned
<lifeless> yeouch
<mdz> Seveas: and belongs either to 'linux', 'acpi-support' or 'UNKNOWN'
<Seveas> mdz, ah ok
<mdz> the 'acpi' package just contains a trivial command-line tool; it has nothing to do with actually implementing the ACPI spec (that's done by the kernel) or dealing with events (acpi-support and acpid)
<Seveas> Thanks for pointing all these things out, I hope I'll make less mistakes in the future
<mdz> Seveas: these are minor things; you've been very helpful so far
<lifeless> mdz: what *should* go on acpi ?
<mdz> lifeless: bugs in /usr/bin/acpi
<mdz> which is the only purpose of that package
<Seveas> mdz, if minor things occur in large numbers they get very annoying :) 
<mdz> Seveas: similar for 'kernel-package' vs. 'linux', but I see you already know that
<Seveas> yep
<mdz> lifeless: which are so exceedingly rare as to be irrelevant in the face of the time we spend fixing it, so I'm considering just deleting that component
<mdz> I don't think that's reasonable for kernel-package, though
<mdz> we occasionally get real kernel-package bug reports, especially from debian
<lifeless> mdz: yeah. I was going down the path of 'if no report is ever on acpi, why do we have acpi listed'
<lifeless> mdz: it might not be a bad idea to nuke it and feed acpi bugs to acpi-support *even if that is technically wrong*
<infinity> Yeah, kernel-package has plenty of real bugs.
<mdz> lifeless: removing acpi would probably just cause all the kernel-side acpi bugs to end up on acpi-support
<infinity> And I still have no idea how all the linux-image bugs land there.
<mdz> infinity: people type 'kernel' into the selector
<infinity> (Why don't we have a component just called "kernel"?
<infinity> )
<lifeless> mdz: thats what I'm saying. Point is that users don't know enough to make that choice anyway
<mdz> lifeless: it's also a PITA to clean up all the old bugs which were closed without being reassigned away from 'acpi' (which bugzilla requires before it could be deleted)
<mdz> lifeless: acpi-support isn't all that much better than acpi as a wrong destination
<mdz> lifeless: certainly worse for mjg59, and not really better for me
<lifeless> mdz: k, was just a thought.
<mdz> perhaps we should rename acpi to acpi-the-silly-command-line-tool
<mdz> infinity: I was thinking about creating one, actually
<mdz> but it would mean that you'd have to search both to find kernel bugs
<mdz> the whole point of 'linux' is to collect all of them
<lifeless> I wonder if bugzilla could be fooled into aliasing them
<mdz> that's closer to what we'd want
<infinity> Yeah, that's kinda what I meant.
<infinity> But I dunno if bugzilla supports aliases.
<Seveas> hmm, continuing the triage on malone -- how can i close bugs there?
<dholbach> good night pals, i'm off to bed
<Seveas> 'night
<dholbach> night Seveas 
<Kamion> lifeless: I think the company line is that the project to fix bugzilla to be usable is called 'malone'
* Kamion wonders why rsync decided to choose now to resync TheOpenCD from scratch
<whiprush> jdub: ping
<Seveas> Kamion, in its current state malone is far less usable than bugzilla
<Kamion> Seveas: there was a certain amount of irony inherent in my statement
<Seveas> Kamion, ah, did not get that :)
<Kamion> it probably only came across if you've heard me talk about malone before
<Seveas> hehe
<Kamion> but still, that *is* the Canonical line, ultimately - Malone is what we'll be using long-term
<Kamion> so we all hope it'll get fixed :)
<Seveas> let's hope that term is lnog enough
<Seveas> I really like the previous - next buttons in bugzilla combined with the outrageously detailed searches that are possible
<Kamion> there aren't many things I like about bugzilla either
<Kamion> I might like the outrageously detailed search facility better if it didn't take the page an eon to load
* lamont -> home
<Nafallo> wow
<lamont> Kamion:  that's because the package list is > 1MB
<Nafallo> could we have a purple desktop in dapper+1 please :-)
<bddebian> With Pink Polka-dots?
<Seveas> yeah!
<Seveas> and bright lightblue/green/yellow squares 
<Seveas> Psychobuntu :)
<Nafallo> we should have all squares in diffrent colors on all windows :-)
<Nafallo> like: what colors are my firefox today?
<Seveas> There's a random-firefox-name extension
<mpt> infinity, Malone has aliases, though I'm dubious about the usefulness-to-clutter factor
<Nafallo> hmm, maybe I should install that on my girlfriends machine ;-)
<infinity> mpt : For obvious things like "kernel/linux", which we get a LOT of bug reports on, it makes sense.  FOr others, probably not so much worth the clutter.
<mpt> Kamion, part of my brief when I designed Bugzilla's outrageously detailed search facility was that I wasn't allowed to remove any of the outrageous details
<ogra> mdz, jbailey, YAY
<ogra> mdz, jbailey, -o retrans=10 seems to be the solution for #12942
<jbailey> ogra: Lovely.
<ogra> jbailey, thanks for the help :)
<mdz> ogra: what does that do?
<jbailey> ogra: Glad I could help. =)
<ogra> it retries 10 times instead of 3 times
<ogra> (...to mount)
<ajmitch> you need that many retries? worrying
<jbailey> ajmitch: The timeout seems particularily small.
<mdz> that doesn't make much sense to me; it never says that it gives up
<mdz> it just keeps retrying but never works
<mpt> Seveas, IMO the biggest problems with Malone are (1a) too many clicks to do anything to a bug report, (1b) you can't do multiple things to a bug report at once, (2) search is crippled, (3) the one-bug-in-many-places idea isn't obvious enough. Would that match your experience?
<mdz> ogra: do you still get the same messages?
<ajmitch> jbailey: it must be rather small
<ogra> mdz, i booted 5 times with a freshly rebooted server, all first attempts worked
<ogra> mdz, works just fine now
<jbailey> ajmitch: timeo is "7", no idea what unit that is.
<mdz> ogra: you don't even get a single 'not responding' message?
<ogra> not on the client
<Seveas> mpt, it matches it exactly
<mdz> that is weird enough to make me skeptical that it really avoids the problem
<ogra> i didnt run a tcpdump or anything, i'll look deeper tomorrow
<Kamion> mpt: (1c) it's confusing to see how to do anything to a bug report
<Seveas> that too
<Kamion> oh, and the display is *so* sparse I keep wondering if I'm missing stuff
<jbailey> ogra, mdz: Do you want something in initramfs for now?  I need to do an upload with jfs included anyway, so it would be nice to include this.
<mdz> jbailey,ogra: let's get confirmation from some users that it fixes the problem
<Kamion> in particular I keep looking in the wrong place to find who reported the bug
<mdz> get some instructions into bugzilla and ask for testing
<ogra> jbailey, i'd say go ahead, but if mdz has objections lets wait 
<mdz> it's a pretty safe change, so I think we can afford to wait a day or so to get confirmation
<ogra> yup
<mpt> Kamion: yeah, sabdfl is pretty fond of putting things in little blue boxes
<jbailey> mpt: I think my biggest problem is that the links at the top are context sensitive and I don't expect that.
<Kamion> mpt: I don't mind it being on the left-hand side, but in this case I think it could stand to be duplicated. I don't really understand why the report is treated fundamentally differently from comments; I would prefer if they all appeared in the same style (and thus with the commenter at the top right of the text of the initial report)
<mpt> Seveas: good, then at least I know I'm on the right track ... Over the next couple of weeks we're going to pull stuff (like making attachments, and subscribing) into the bug page to reduce the number of clicks
<Seveas> mpt, awesome
<Kamion> at the moment "assigned to" appears roughly to the top right of the initial report, quite close to the relative position of the commenter's name to a comment, which is very confusing indeed
<mpt> Kamion, agreed
<mdz> jbailey: timeo is in tenths of seconds
<mdz> so 0.7
<mdz> and the default for retrans is 5
<mdz> so 3.5 seconds
<mdz> that is pretty short
<ogra> mdz, its 3 in my source here
<ogra> (retrans)
<mdz> ./nfs/inode.c:          timeparms.to_retries = 5;
<jbailey> mdz: Default retrans for klibc's nfsmount is 3
<ogra> mdz, klibc
<mdz> uuarrghhh
<ogra> and timeo is 7
<ogra> i'll play with timeo tomorrow if you see a need for that
<ogra> and leave retrans at 3
<mdz> I can believe that we might hit the timeout sometimes
<mdz> but I don't understand why it doesn't fail
<mdz> it acts as if it is continuing to retry forever
<mdz> ogra: let's use the same defaults that the kernel does
<ogra> ok
<ogra> so retrans=5 then
<mdz> timeo=7 and retrans=5
<ogra> i guess setting that in klibc directly would be better than using a commandline option every time :)
<mdz> The -o retrans option allows designation of the number of timeouts allowed before the client gives up, and displays the Server not responding message. The default value is 3 attempts. Once the client displays this message, it will continue to try to send the request, but only once before displaying the error message if another timeout occurs. When the client reestablishes contact, it will fall back to using the correct retrans val
<mdz> ue, and will display the Server OK message.
<mdz> the confusing thing is that that never happens in our case
<mdz> so I don't see why increasing the timeout should change that
<mdz> or the number of retransmissions
<ogra> i never saw more than one message...
<ogra> the above suggests i should see more
<mdz> I have seen it repeat
<ogra> hmm...
<ogra> in which timeframe ? 
<Riddell> are the build daemons running today?
<ogra> i normally shut down the client after a minute or two
<ogra> Riddell, see topic... :) 
<ogra> i was hit by it too today, all uploads need approval :)
<Riddell> ogra: ah
<Kamion> mdz: btw, approval baton is yours, I'm well bored of it today
<mdz> Kamion: we need an archive admin list
<mdz> which gets mail when things land in the queue
* ogra guesses Kamion knows the gnome packages as well as seb today :)
<ogra> brb
<Kamion> Riddell: I've largely been avoiding KDE approvals because I don't know the standing policy on new upstream versions there
<Kamion> at least not well enough to want to enforce it
<mdz> Kamion: Riddell and I discussed via email; I've taken care of the pending uploads
<Kamion> ok, thanks
<ogra> mdz, 5 works too.. below it times out for me
<ogra> (i.e. 4) 
<mdz> so weird
<ogra> but if 5 is the default forthe kernel it sounds reasonable to use that
<mdz> maybe using a lower value triggers a bug somewhere
<mdz> ogra,jbailey: let's go ahead and set retrans=5 in initramfs-tools
<ogra> hmm, that might be... or the description is simply wrong
<ogra> i'd rather set it to 5 in klbc
<ogra> *klibc
<ogra> since its the default in the kernel anyway as you say
<ogra> so the default values should match
<jbailey> mdz: 'kay.  I will make a variable for options, set it to that by default and allow it to be overwridden in the initramfs.conf
<jbailey> Mmm..  Overwridden must be the intersection of overwritten and overridden, I guess.
<wasabi> Looks like in 2.6.12-9 the mppe module isn't audoloading right anymore
<crimsun> mppe?
<wasabi> ppp encryption stuff for MS VPNs
<crimsun> oh, it must be external
<wasabi> hmm?
<crimsun> I couldn't see anything from modinfo
<wasabi> /lib/modules/2.6.12-9-k7/kernel/drivers/net/ppp_mppe_mppc.ko
<crimsun> oh, I used ''modinfo mppe''
<wasabi> FOr whatever reason, it was being loaded on demand in 2.6.12-8
<crimsun> that would explain that
<oxez> is it me or the channel is -t, anyone can change topic?
<daniels> it's not just you
<oxez> okay
<tritium> hi daniels.  Good to see you
<daniels> tritium: yo
<bddebian> daniels: Would you mind looking at a patch for xfonts-terminus for me?
<daniels> bddebian: sure
<bddebian> daniels: Thx.  It works but I suppose I should probably do a proper patch?  http://www2.bddebian.com:8000/packages/ubuntu/xfonts-terminus/xfonts-terminus_4.12-2ubuntu2.debdiff
<daniels> bddebian: *shrug*, looks okay to me
<Kamion> so is evolution meant to provide evolution.desktop as well as evolution-2.4.desktop, or should I fix the default panel setup?
<Kamion> seems that evolution only provided evolution-2.2.desktop in hoary ...
<infinity> bddebian : "proper patch"?
<bddebian> daniels: You don't think I need to do a proper debian/rules patching for the Makefile and such?
<daniels> bddebian: why bother?
<infinity> bddebian : Is there a patch system in the package already?
<bddebian> daniels: That was my question but dholbach felt I should "do it right" :-)
<daniels> bddebian: often the overhead of adding dpatch and the huge drift (and antagonism) that results is far worse
<infinity> bddebian : If not, adding one increases the complexity of our diff against Debian, which is counter-productive.
<daniels> bddebian: tbh I wouldn't be adding any patch systems unless I had a huge unmanageable diff
<bddebian> infinity: No there isn't :-(
<ajmitch> especially for a small change
<infinity> bddebian : Right, then don't add one.  PLEASE.
<bddebian> Grrr.. :-)
<daniels> i don't think this counts as either huge or unmanageable
<infinity> bddebian : It just makes syncs harder, not easier.
<bddebian> OK, someone wanna upload it? ;-)
<daniels> it's a main package?
<bddebian> Aye :-(
<daniels> Kamion: approval?
<ajmitch> universe binary, main source
<bddebian> Malone bug
<Kamion> daniels: I'm nearly passing out, ask mdz
<daniels> Kamion: 'kay
<daniels> mdz: ^^
<bddebian> I think scribus needs a fixed .desktop file too but it's main also :-(
<bddebian> You folks just need to get ajmitch his main upload rights and I'll make him my bitch for any main fixes
* bddebian ducks
<infinity> bddebian : What's the point of changing the documentation of "default build locations" in that patch?
<bddebian> infinity: It's not necessary, it was just an anal thing :-)
<infinity> bddebian : (which is inaccurate anyway, since you didn't actually change those strings to match your changes to the Makefile)
<ajmitch> bddebian: hardly likely :)
<bddebian> I didn't?
<infinity> bddebian : s/local/misc/
<bddebian> ajmitch: What, that you'll ever get main? :-)
<bddebian> infinity: Didn't I make it /misc?
<infinity> bddebian : Not in the docs.
<bddebian> Oh must have been an oversight on a subsequent revision :-(
<ajmitch> bddebian: no, that's expected, I mean the uploading
<bddebian> ajmitch: ;-P
<bddebian> ajmitch: Don't feel bad, I still don't have a working @ubuntu.com e-mail :-)
<fabbione> morning
<sabdfl> mdz: ping
<crimsun> morning pitti 
<crimsun> pitti: when I plug in a usb sound device, a popup appears, but it refers to System> Preferences> Audio. Shouldn't that be Sound instead?
<vuntz> Kamion: "so is evolution meant to provide evolution.desktop as well as evolution-2.4.desktop, or should I fix the default panel setup?"
<pitti> Hi all
<vuntz> Kamion: it should provide it. But it doesn't right now
<vuntz> Kamion: it will in the future, though
<pitti> crimsun: right, it should
<pitti> crimsun: I'll upload a new version, thanks for spotting
<crimsun> pitti: thank you :-)
<fabbione> daniels: ping?
<ajmitch> hi pitti 
<pitti> Kamion/mdz: approval for uploading a new control-center which fixes the menu name pointer in the audio popup? (s/Sound/Audio/)
<pitti> Hi ajmitch 
<ajmitch> pitti: your phpmyadmin sync last week didn't quite work :)
<pitti> ajmitch: why, didn't it build?
<ajmitch> pitti: no, it needed a newer yada than was in main
<ajmitch> builds ok without it, so I set the build-dep back 
<fabbione> mdz, Kamion, whoever can answer: permission to upload mysql-dfsg-4.1 to fix 16708. One line change. simple and clear
<pitti> oh, thanks
* fabbione uploads and will wait to be larted later
<pitti> Kamion: permission to upload  http://www.rafb.net/paste/results/TqQt0d66.html ? (trivial build-time change only)
<fabbione> hey pitti
<pitti> Hi fabbione 
<fabbione> pitti: any news about that patch?
<fabbione> (kernel)
<pitti> fabbione: Linus produced a "totally untested patch" which is currently discussed
<fabbione> ok
<pitti> fabbione: this is pretty messy
<fabbione> yeah i can imagine
<smurf> pitti: Since when is Linus' posting totally untested patches news? ;-)
<Mithrandir> mdz: given that I can't reproduce it on any system I have access to, no.
<mdz> Mithrandir: neither can I, so we need to debug it by proxy with the people who can
<mjg59> mdz: sleep is broken in acpi-support 0.42, fixed in 0.43 (though that's not built yet)
<mdz> pitti: translated string?
<mdz> mjg59: I just approved it about 30 seconds ago
<pitti> mdz: no, the bubble is not translated
<mdz> pitti: ok then
<pitti> mdz: (it should be in the future, though)
<mdz> infinity,fabbione: uploads approved
<fabbione> mdz: ok done..
<fabbione> mdz: i am looking at that mkdirhier
<fabbione> but that's a pain to do.. it needs a NEW + an xorg upload
<pitti> mdz: permission for http://www.rafb.net/paste/results/TqQt0d66.html  ?
<fabbione> not sure it's worth it
<lifeless> daniels: ping
<lifeless> I just resumed...
<mdz> daniels: what is the story with all these xkb bugs?
<mjg59> mdz: Ta
<lifeless> daniels: and X was hung - showed my screen, with the shapes of the major windows (panel, xterm) in background-colour, but no content
<mdz> pitti: ok
<pitti> mdz: thanks
<mjg59> lifeless: From RAM or from disk?
<lifeless> daniels: I switched to console, and ps fux showed me a bash -c 'xscreen-saver-command -deactivate' process that was hung
<lifeless> thats from resume.sh I presume
<lifeless> mjg59: mem
<mjg59> lifeless: Ah. Now that's interesting.
<lifeless> daniels: so I killed that.
<lifeless> daniels: then there was a xscreensaver-command -throttle, I killed that too
<lifeless> no joy
<lifeless> so I killed xscreensaver
<lifeless> which made everything work again, except my mouse cursor was missing
<lifeless> I did a short suspend-mem, resume cycle
<lifeless> and it came good.
<mjg59> infinity: Win.
<lifeless> mjg59: yes, it is interesting.
<mjg59> infinity: Now we just need to figure out what state xscreensaver is in
<pitti> infinity: what's the status of tbird? pushing this into breezy becomes really hard, I assume
<mjg59> For some reason, this seems to happen when people StR for long periods of time but not short ones
<infinity> pitti : It's the next on my list after a binutils upload.
<infinity> pitti : asack rolled an orig and pushed it into sid over the weekend.
<lifeless> mjg59: yes, I had just done a 15 minute suspend
<pitti> infinity: can we still put it into breezy?
<mdz> mjg59: which one of the changes in 0.43 unbreaks sleep?
<mjg59> mdz: The fix in sleep.sh
<infinity> pitti : Should be able to.
<mjg59> mdz: Which is the "Fix Radeon backlight tweak support"
<infinity> pitti : It'll get more testing in breezy in 9 days than it'll get in the other dists, and we're backporting sources... So... <shrug>... I'll review the diff first, of course (coming up later today)
<pitti> infinity: ok, thanks
<tritium> mjg59, I can also confirm it occurs when hibernating for long periods
<mjg59> lifeless: How long had you slept for?
<mjg59> When it broke?
<mjg59> 15 minutes?
<pitti> infinity: JFYI, http://tinyurl.com/davmq could interest you (full set of bugs fixed for 1.0.7)
<lifeless> mjg59: yes
<infinity> pitti : It will fascinate me endlessly.
<mjg59> lifeless: Ok, cool. So the problem is almost certainly when you've slept long enough that xscreensaver activates itself during resume
<mjg59> And then gets miserably confused
<mjg59> Go xscreensaver
<pitti> infinity: I meant, for reviewing the diff :)
<infinity> (I know)
<lifeless> other data points
<lifeless> xscreensaver was not using up lots of cpu
<lifeless> (I checked via top)
<lifeless> I did not strace.
<lifeless> I will do that next time
<mjg59> Ok
<mjg59> I'll try to duplicate now
<mjg59> Oh hnngh I need to do a pile of installs
<pitti> fabbione: will you or BenC convert the kernel to the new reboot notification?
<infinity> mdz : While this testbuild is running, can I get pre-emptive approval to upload a binutils that A) make binutils-static stop depending on binutils, and B) produces a binutils-static-udeb.udeb?
<fabbione> pitti: nobody.. kernel is in strict security only mode
<pitti> fabbione: ouch
<infinity> Uhm, somebody really should.
<pitti> fabbione: the current notice so much sucks
<infinity> The current notification is B-R-O-K-E-N, and the unified thing was done for just such reasons.
<fabbione> pitti: ask mdz.. in anycase that would be BenC
<pitti> fabbione: ok, I will
<fabbione> infinity: isn't a bit too late to change stuff around?
<infinity> It's never too late, if it's done very carefully.
<pitti> fabbione: it's really trivial, just call an u-n script and be done
<infinity> Very.
<fabbione> that requires a lot of changes around.. 
<fabbione> from kernel-package to modify postinst
<fabbione> to the kernel to remove the old notification system
<fabbione> again.. i have no problems to do it.. given that mdz approves it
<fabbione> or BenC wants to do it
<mdz> infinity: it is a bit late for binutils-static-udeb
<mdz> the installer needs to be frozen pretty solid
<infinity> mdz : Erm?  Kamion requested it, otherwise nic-restricted-modules is useless.
<mdz> infinity: yes, much as has been the case for the past few months
<pitti> mdz: what do you think about dropping the current kernel update notification and use the new generic reboot notice?
<mdz> pitti: I think it would have been a good idea last week
<mdz> when we discussed it
<pitti> mdz: ok
<infinity> mdz : Right, well should we just drop nic-r-m for now, then?  That solves me a hassle or two. :)
* infinity notes that the addition of the udeb is a low-impact change, USING it in the installer, however, may not be...
<fabbione> AH AH!!!!
<infinity> So, I could upload static-udeb, but we could just not use it until the dapper cycle opens.
<pitti> Hi dholbach 
<fabbione> mdz: 16812 is easy to fix.. but it needs a xorg upload...
<dholbach> pitti: hi martin
<mjg59> infinity: That loses us madwifi support in the installer, right?
<mdz> infinity: we have bigger fish to fry; if we're not gonig to use it, then it can wait
<dholbach> morning everybody
<fabbione> mdz: i just figured that there is a shell implementation of mkdirhier
<infinity> mdz : True, except I just did it.  Meh.
<infinity> mjg59 : Yes.
<mdz> mjg59: yes, which we resolved a few months ago that we could live with (which is why no one has been working on it)
<mjg59> Ok
<fabbione> mdz: so that would fit perfectly in xutils (no need of a new package)...
<fabbione> mdz: but it's sort of a hack.. it should really be in its own package
<mdz> fabbione: ok
<fabbione> mdz: what would you prefer?
<infinity> mdz : Apparently, not everyone got that memo, as Kamion has had me fixing the nic-r-m udeb and getting a binutils-static-udeb.  Oh well.
<mdz> fabbione: I don't agree that every trivial program originating from X needs its own source package
<mdz> infinity: he knows better than to push something like that in this week
<fabbione> well xutils is now a dummy package.. so adding stuff back to it is a hack
<infinity> mdz : May have been a product of sleep deprivation, who knows.
<fabbione> mdz: i would personally prefer to add a mkdirhier package (arch all) and make xutils Depends: on it
<mdz> infinity: there is no possible way it can be properly tested in time for the release
<fabbione> mdz: but yeah a source package for 20 lines bash script is excessive
<infinity> mdz : So, I'll back out the udeb addition for now, upload a binutils that fixes the stupid dependency issue, and drop nic-r-m from lrm?
<mdz> infinity: I see no reason to drop nic-r-m
<infinity> mdz : Well, if it never makes it anywhere near the installation media, it's okay.  I assume we can just blacklist it?
<bob2> fabbione: mkdir -p?
<fabbione> bob2: almost..
<mdz> infinity: if it's already there, it's clearly not causing any harm
<infinity> mdz : It's useless (and broken/bloated) right now.
<infinity> I can unbloat it, but the intention of doing so was so that it would get used.
<infinity> <shrug>
<infinity> (dropping it is much easier than fixing it, that was the only reason I suggested it)
<daniels> mdz: which ones?
<infinity> Oh that's a shame, I even got the udeb creation right on the first shot, too.
* infinity moves on to working on thunderbird instead.
<jdub> GOOD MORNING FREEDOM LOVERS!
<pitti> Hi jdub 
<fabbione> daniels: yo
<pitti> mdz: permission to upload the fix for #16918?
<bob2> fsvo morning
<daniels> fabbione: sup
<pitti> Hi JaneW 
<pitti> mdz: well, thinking about it, it's a feature, so we should better disable it at all for Breezy
<jdub> jsgotangco: what's your bugzilla email?
<jsgotangco> jdub, jgotangco@gmail.com
<fabbione> daniels: 16812 <-
<fabbione> daniels: i am working on this.. right now.. patch on the way in a few secs
<jdub> what does 'gelera' mean?
<bob2> glarea?
<jdub> jsgotangco: ah! was looking for jsg :)
<jdub> bob2: no, in spanish or portuguese or something
<jdub> jsgotangco: you now have ALMIGHT EDITBUGS
<jdub> ALMIGHTY COMPLETE WORDS
<jsgotangco> jdub, gyahhhhh
<daniels> fabbione: okay
<jsgotangco> jdub, thanks
<daniels> tbh I never saw the point of mkdirhier
<robitaille> jdub,   the fridge needs e-cards like Mandriva :)  http://club.mandriva.com/xwiki/bin/view/Main/ECards
<bob2> daniels: HP-UX 0.5's mkdir didn't have -p
<robitaille> then you can spam all your friends with Ubuntu announcements...
<jsgotangco> ECards? Like "Happy Birthday from the Fridge?"
<daniels> bob2: we're using mkdir -p in several places for 7.0, so it's obviously somewhat portable
<bob2> hah
<robitaille> jsgotangco,  its personalized.  A coworker sent one to me earlier as joke to tell me about the latest Mandriva version to try to bring me back
<jdub> robitaille: heh, fear ;-)
<daniels> hell, I think mkdir -p is even specified by POSIX
<daniels> x is moving up in the world now.  requiring both C89 (changed late last year) *and* POSIX.
<jdub> whoa!
<jdub> #14502 :-)
<Lathiat> hrm, is there any reason wpasupplicant is not in main?
<moyogo> who should I contact to ask about the ttf-ubuntu-title font, I'd like to know if I can improve it (add characters)?
<jdub> moyogo: andy fitzsimon
<moyogo> jdub: thanks
<jdub> moyogo: note that the font will be updated soon with vastly improved quality (but not more characters)
<jdub> oh man, sabdfl on slashdot
<moyogo> jdub: I really like the font, and would like to either improve or be able to fork it into an OpenType font
<daniels> mdz: #15372, #16907 and #16910?
<robitaille> jdub, it seems the wiki survived the slashdot.  I was really afraid some people would start editing his wiki entry just for the "fun" of it.
<jdub> heh
<jsgotangco> heh
<jdub> the "need login to edit" thing keeps out stupid people *and* spam ;-)
<ajmitch> it could be worse :)
<fabbione> daniels: do we still check the MANIFEST at build time?
<jdub> "Ubuntu might be popular within its own community, but the distro won't go mainstream until its image matures past high school sophomore."
<fabbione> daniels: btw.. i don't see the need of it either.. let's just fix it and get over it
<jdub> YES! :)
<jdub> rock!
<jdub> all these people who think 'dapper' means gay
<jdub> man
<daniels> fabbione: eh, if you want.  i think it's crack though, since it literally jsust is mkdir -p.
<jdub> everybody knows it means 'metrosexual'!
<daniels> jdub: it means 'wearing a salmon pink polo shirt with the collar turned up'
<fabbione> daniels: yes i know.. i could see that.. but apparently a bunch of old Makefile still uses it
<daniels> fabbione: and yes, we still check the MANIFEST
<fabbione> daniels: ok
<daniels> mdz: 15387 has svu and I rather bamboozled.  given that I'm the only one who's worked on XKB code for some years, and sergey's basically the only one working on layouts upstream ...
<daniels> mdz: to be honest, I don't think we should bother shipping mkdirhier; let it be, and if they're building on non-POSIX systems, their problem.
<mdz> daniels: finishing up a phone call, one moment
<\sh> "Backgrounder: I'm 32 and counting, " *lol* what should I say ... I'm 34 and count down?
<JaneW> hi pitti (delayed)
* JaneW turns mute off ;)
<mdz> daniels: generally speaking, all of the x-keyboard-related bugs I've seen go by on ubuntu-bugs.  I've seen my-layout-reverts-to-us, error-activating-xkb-configuration and x-keyboard-vs.-gnome-keyboard bugs recently
<daniels> mdz: if 15387 needs fixing, I need latitude to spend a fair amount of time on it; this requires plunging deeper into XKB code than I'm comfortable doing on distro time.
<daniels> mdz: there's one x-keyboard-vs-gnome-keyboard bug that I'm looking at today, and is harmless; the first two, see above
<mdz> daniels: it's a regression from hoary, and you and seb128 said it was a serious one
<pitti> daniels: the gnome keyboard dialog: do you mean fixing the nodeadkeys issue?
<daniels> mdz: ime, almost every 'can't activate keyboard layout' bug is 'ralt kicks to level3 vs alts toggle layouts'
<daniels> pitti: and the lv3:lwin_switch issue, yeah
<daniels> mdz: right, but again, I'd like explicit permission to go chasing it as it's a deep-voodoo-XKB bug
<\sh> JaneW: good to see u...I 
<mdz> daniels: what are the odds that spending one day on it would net results?
<daniels> mdz: 40-50%
<\sh> JaneW: I wanted to ask you if you can put at least 2 or 3 kg of biltong in your luggage and take it to UBZ? the costs are mine so u'll get the money back :)
<daniels> that probability rises with two days, but I'm not sure
<daniels> it's a scary frigging bug
<mdz> RC is due in two days
<mdz> the bug is less than 3 weeks old; if it's so severe, why didn't anyone notice it earlier?
<dholbach> morning mvo
<daniels> whether it simply lurked until then or no-one picked it up is unknown
<mvo> hey dholbach 
<mdz> daniels: you meant 15372 rather than 15387, right?
<daniels> given that neither of the relevant code or layouts have changed
<daniels> mdz: yeha
<mdz> yes 16907 was one of the ones I was concerned about.you're sure it's really 15372?
<JaneW> \sh: er I can try I am already a pack horse for the company and have LOADS of printed goods to haul....
<daniels> layouts = [de  deadacute,de    de] 
<daniels> options = [grp grp:alts_toggle] 
<daniels> so, yes
<JaneW> \sh: can you check if Cananda has rules about that? US and Australia wouldn't allow it in....
<\sh> JaneW: ah well...don't tell anybody...but nobody is looking into the big bags...we "smuggled" at least 40kg of all good ZA stuff to germany ,->
<JaneW> \sh: yeah, but I LOOK guilty even when I am not ;)
<\sh> JaneW: it's not allowed normally without permission
<jsgotangco> JaneW, biltong courier hehe
<JaneW> \sh: I thought I was going to be arrested for taking a muffin into Oz.
<\sh> JaneW: hmmm...well...give it mark then...he can say it's food from space ,-)
<fabbione> ahahha
<daniels> we have good muffins here, why on earth would you need to smuggle them?
<jsgotangco> lol
<JaneW> daniels: didn't want to waste a perfectly good SA one ;)
* \sh don't need muffins.../me needs pure dried tasty game flesh ;)
<\sh> s/don't/doesn't/
<JaneW> \sh: lemme check my luggage allowance if it's 20kgs I might not make it, if it's 35kgs - np... ok?
<jsgotangco> jdub, do you know where the ubuntu font andyfitz made can be downloaded from?
<JaneW> \sh: I suspect it's 20kgs though :(((
<\sh> JaneW: yeah...I was too late with this request I think...who else comes from ZA to UBZ? 
<mdz> daniels: also #15414
<jsgotangco> \sh,  probably adi attar
<mdz> daniels: 16628 was marked pendingupload last week; where did the upload go?
<jdub> jsgotangco: apt-get install ttf-ubuntu-title :-)
<jdub> jsgotangco: but there's a better version coming
<daniels> mdz: it's more complex than I hoped.
<jsgotangco> jdub, thanks =)
<daniels> long story short, I'm having fun with PCI subsystem IDs
<schimmi> hmm, acpi does crazy thinks since last update this morning
<mdz> PENDINGUPLOAD means "I've fixed it and just need to upload the new version"
<crimsun> schimmi: make sure you're current. acpi-support -43 is supposed to fix a few things.
<Keybuk> jdub: help!
<mdz> mjg59: what's the master bug# for the sleep.sh thing?
<Keybuk> jdub: you have an X1 right?
<jsgotangco> schimmi, -43 was uploaded a few hours ago
<daniels> Keybuk: X300
<schimmi> crimsun: no, I am on 42.....
<Keybuk> should be close enough, I hope
<Keybuk> jdub: can you do lspci | grep IDE and let me know what's in it
<mdz> 16958 looks like it
<crimsun> schimmi: 43 is available as of 15 minutes ago
<schimmi> ic
<schimmi> brb
<jdub> Keybuk: X300, lifeless has an X1
<jdub> 0000:00:1f.1 IDE interface: Intel Corp. 82801DBM (ICH4) Ultra ATA Storage Controller (rev 01)
<jdub> ^ but that's what's in the X300
<Keybuk> jdub: ok, what's in /proc/ide -- anything besides "drivers" ?
<jdub> hda ide0
<Keybuk> hmm,ok
<mjg59> mdz: Yup
<mdz> daniels: if you're using PENDINGUPLOAD to mean fixed-upstream, we should create some other way to represent that
<daniels> mdz: it hasn't been fixed-upstream
* dholbach hopes that Malone will make this easier
<mdz> daniels: http://bugzilla.ubuntu.com/show_bug.cgi?id=11807
<daniels> mdz: pendingupload in that case was, well, I had packages, and they were ready to upload
<mdz> daniels: 16899 is another of the xkb issues I was concerned about
<fabbione> Keybuk: nice screenshot :)
<pitti> mdz: can I fix the pmount manpage to correct an inconsistent description? (#16843)
<Keybuk> mdz: so, how would you like ntpdate, nfs, pppoe, etc. fixed for breezy?
<mdz> Keybuk: the way which can't possibly introduce regressions
<Keybuk> the only real way to fix it is to rewrite /etc/network/interfaces for people so all interfaces are "auto" and not "hotplug"
<mdz> pitti: yes
<Keybuk> which will increase the boot time by about a minute or more for people on laptops
<mdz> I have a laptop and use auto without a minute increase in boot time
<Keybuk> on both the wired and wireless interfaces?
<daniels> mdz: i've needinfo'd 16899
<mdz> we needn't use it auto on _all_ interfaces, ssurely
<Keybuk> how do you pick which to change, and which not to change?
<pitti> Keybuk: without knowing the context, changing hotplug to auto seems utterly wrong
<mdz> Keybuk: go back to what we were doing in hoary, where we didn't have this problem?
<Keybuk> we had this same problem in hoary
<Keybuk> a few of the bug numbers are that old
<Keybuk> fresh installs of hoary had the bug (upgrades from warty didn't, just as they won't in breezy)
<Keybuk> I think we're just getting more new bugs because more people are installing fresh rather than upgrading
<mdz> I've clobbered all my fresh hoary installs, but I thought we used auto
<Keybuk> hoary used hotplug, I'm sure of it
<Keybuk> it's an installer thing, the bit that writes the initial network-interfaces
<mdz> if it isn't a regression, then we live with it
<Keybuk> I can't remember which bit that is this morning though <g>
* Keybuk is still learning d-i
<mdz> it would be netcfg, presumably
<Keybuk> that's the chicken; I was looking for net-config, net-detect, et. al
<Keybuk> yup, we wrote mapping hotplug in hoary too
* Keybuk could put an opportunistic sleep 5 in the boot sequence <g>
<Keybuk> that'd make most of the symptoms go away :D
<dholbach> good morning seb128 :)
<seb128> hey dholbach 
<pitti> hi seb128 
<bob2> ajmitch: hm, mcs is complaining about NUnut.Framework not existing, but it appears in the GAC.
<Lathiat> hrm, gnome-volume-manager setting shows "Burn a CD or DVD when a blank disc is inserted" as off in my fresh install
<Keybuk> heh, also in hoary we started portmap by default
<Keybuk> which may have added a useful extra couple of tenths to the boot sequence
<fabbione> daniels: http://people.ubuntu.com/~fabbione/xorg.diff <- you might want to add the proper C/R with the old xutils package because i don't remember when it was splitted out
<seb128> hey pitti 
<pitti> Lathiat: with a fresh profile?
<Keybuk> mdz: how about we do this ... when the first hotplug network interface starts configuring, touch a "doing hotplug" file ... then when the first one finishes, remove that file
<Lathiat> pitti: yes
<Keybuk> and in the mainline boot sequence, in S:S41hotplug-net, if that file exists, wait for it to go away
<daniels> fabbione: eh, why don't we just do it in another source package or so?
<Keybuk> that won't get the "two minute" problem because one will finish quickly
<Keybuk> but it will take the symptoms away for now
<mdz> Keybuk: sleep 5 isn't entirely insane
<fabbione> daniels: a source package for a 20 line shell script seems a bit excessive to me when we are so close to release.. it will need seeding and stuff..
<fabbione> daniels: this way it will be just a NEW
<seb128> pitti: is that known: http://people.ubuntu.com/~seb128/languagepack.png ?
<daniels> fabbione: isn't it built from the .c in the monolith?
<seb128> pitti: the title of the note is the start of the text
<fabbione> mdz: 5 secs is not always enough
<pitti> Lathiat: darn, right. I'll ask mdz whether I can fix this, it is a regression
<fabbione> daniels: not the shell script
<fabbione> daniels: there are both shell and .c implementation.. i think we can rely on the shell one :)
<Keybuk> mdz: yes, this will work, I shall add this "wait for the first hotplugging interface to finish" thing to hotplug
<pitti> seb128: I'll ask mvo about the correct format
<mdz> Keybuk: so long as it fails open if the file doesn't go away after some reasonable time
<pitti> mdz: can I fix the g-v-m default settings for auto burning? This worked some weeks ago, and it's only a s/false/true/ in the gconf schema
<seb128> pitti: k
<Keybuk> mdz: yeah, will put a maximum wait time in there, where it'll carry on after
<seb128> pitti: debian/patches/92_ubuntu-new_audio_notification.patch ... is there some text to translate here?
<pitti> seb128: you can translate it in Rosetta
<pitti> seb128: I'll do the same for German
<seb128> nice
<seb128> thanks
<pitti> seb128: thanks to gnome.mk intltool love :-)
<mvo> pitti: please use the description field only. the "name" field is no longer displayed. sorry
<pitti> mvo: ouch
<pitti> mvo: that's a really bad bug, we have fully translated name fields
<pitti> mvo: so where does the header stop and the text begin?
<mvo> pitti: can't we just move them down a bit?
<pitti> mvo: and why is Name not displayed?
<pitti> mvo: of course I can adapt the langpack note, but we also have to fix the kernel's and maybe the reboot note?
<mvo> pitti: it was (ab)used as a kind of summary and not as a name 
<mvo> pitti: the kernel (hopefully) does use the generic reboot notification now?
<pitti> mvo: if it was never intended to be displayed, why it is translatable?
<fabbione> mvo: no and it won't
<pitti> mvo: no, it doesn't
<mvo> fabbione: why not?
<fabbione> mvo: too intrusive change at this point in time
<pitti> fabbione: is there a nonintrusive way to disable it completely?
<pitti> fabbione: it is utterly broken for months
<fabbione> pitti: nope..
<pitti> darn
<fabbione> it requires quite some love in debian/rules
<mvo> pitti: ok, that changes the "display name" buisness of course :/
<mvo> pitti: I'll fix it then
<fabbione> i mean.. it can be done. but it's like a few hours of work to ensure we don't break anything
<pitti> mvo: that means, Name-* becomes the header again, and Description the pure text?
<fabbione> brb
<pitti> fabbione: it takes hours to remove/disable the notice creation?
<mvo> pitti: yes, looks like there is no other way (given that the kernel notification won't change)
<pitti> mvo: I don't understand why it was changed in the first place, was there a special reason?
<mvo> pitti: as I said, it was used as a summary and that dosn't looks right
<mvo> pitti: but yeah, not a big issue
<pitti> who is our bugzilla master?
<Kamion> mdz: damnit, sorry, I got you to build the wrong tocd thing - you can tell I was tired
<Kamion> mdz: I *have* to have either a reduced nic-restricted-modules or no nic-restricted-modules, regardless of whether it actually works. The current incredibly bloated one is causing other bugs, like us not being able to live up to our stated memory requirements.
<Kamion> I've been trying to get it fixed for ages
<infinity> Kamion : I'll fix it if that's required, but if we're not shipping static-udeb (and making it work), it's much less effort to just drop it.
<pitti> Kamion: can I upload http://www.rafb.net/paste/results/8ooPPC76.html ? It's a regression that was introduced a few weeks ago (wrong configuration default)
<Kamion> mdz: ?
<Kamion> dropping it is going to get me plenty of hatemail
<infinity> Kamion : If we're not using it, dropping it or fixing it amount to the same thing, no?
<Kamion> pitti: just upload things - they end up in the approvals queue for us
<infinity> Kamion : And apparently, not using it is what we're doing.
<pitti> Kamion: ah, I see
<Kamion> infinity: with respect I think that's a mistake that we'll regret
<janimo> infinity,Kamion is the large restricted modules udeb problem solved?
<Kamion> janimo: oh for goodness' sake, we're *discussing* that right now
<janimo> I have just logged in sorry
<Kamion> sorry, you only joined in the middle of it, I know
<fabbione> pitti: yes.. the changes in debian/rules are quite simple.. it takes hours to do test builds 
<Kamion> I'd like to see the l-r-m udeb fix uploaded just so that at least we can argue about it with it in the approvals queue where we can assess the riskiness more accurately
<infinity> Kamion : Alright.  I'll hold off on the matching binutils until I'm told to send that along too.
<infinity> Kamion : Or, should I upload that too, and let you and mdz argue about whether to reject or accept it?
<Kamion> *sigh* I'll drop the priority of nic-restricted-modules for now, so that at least it doesn't break the installer quite so badly
<Kamion> it'll still be bloating installation media by 4MB or whatever unless unseeded, though
<Keybuk> right, let's reboot to test this
<daniels> mdz: so, in summary, I'd like to leave mkdirhier alone
<Keybuk> excellent, worked perfectly
* Keybuk drop kicks that into the archive
<daniels> Kamion: sorry to bug you, but is %% a sensible thing to be using in maintainer scripts
<Treenaks> daniels: if you're writing .spec files ;)
<daniels> heh
* dholbach <- dogwalk
<daniels> daniels@ephemera:~% FOO=xfooxbarx
<daniels> daniels@ephemera:~% echo ${FOO%%x}
<daniels> xfooxbar
<`anthony> I'm confused - all of a sudden, ethereal and tethereal won't start, I get Could not set capabilities: Operation not permitted
<daniels> (FOO is really emo)
<`anthony> this is after doing a dist-upgrade of breezy
<daniels> (but less emo after that substitution
<Kamion> daniels: it's portable shell, yes
<`anthony> this is as root or a normal user.
<daniels> Kamion: thanks
<Kamion> daniels: although a bit pointless in the example you give there, since it's identical to %
<Kamion> (%% is longest-possible-match)
<`anthony> hm - sorry, I was wrong, it's only when run as root I get that error.
<fabbione> `anthony: can you show me lsmod please?
<fabbione> use pastebin or whatever
<fabbione> no flood here
<`anthony> fabbione: sure
<`anthony> http://pastebin.com/382440
<fabbione> when did you upgrade to breezy?
<`anthony> couple of weeks ago.
<fabbione> or better.. when was the last upgrade?
<fabbione> ok it has been fixed already
<`anthony> dist-upgrade? a couple of hours ago.
<fabbione> short version: you need to modprobe capabilities
<fabbione> long version: it has been fixed in initramfs
<daniels> the short version was longer than the long version
<fabbione> so you need to regenerate the initramfs (if there was no kernel upgrade) and reboot into the new one
<`anthony> fabbione: Ok. I rebooted after the upgrade, do I need to do anything else?
<`anthony> there was a kernel upgrade
<`anthony> gonna try another reboot.
<`anthony> back in a couple
<fabbione> no wait
<fabbione> do this:
<fabbione> modprobe capability
<fabbione> mkinitramfs -o /boot/initrd.img-`uname -r`
<`anthony> ok. That makes it work.
<fabbione> (as root)
<fabbione> and try to reboot
<`anthony> hang on - I'm running 2.6.12-8-686. I coulda sworn there was a newer kernel in the last upgrade.
<fabbione> there is
<fabbione> 2.6.12-9
<`anthony> what the heck.
<fabbione> so perhaps you didn't boot in the new one
* `anthony scratches head.
<fabbione> :)
<`anthony> right. but I don't understand - I don't recall seeing multiple kernels in boot screen.
* `anthony kicks computer. 
<fabbione> check again.. it must be there
<`anthony> stupid computer.
<fabbione> or you didn't upgrade properly
<`anthony> yep. it's there.
<`anthony> gonna reboot again.
<`anthony> and punch grub in the head if that doesn't work.
<`anthony> back in a couple
<`anthony> ok. beats me why rebooting last time defaulted to the old kernel, and this time to the new.
<`anthony> maybe it's random selection of kernels in grub. I didn't hit any keys at all last time. Oh well. Going to file it under either "cosmic rays" or "user is stupid".
<bob2> you might have been drunk?
<`anthony> I wish.
<HrdwrBob> little from column a...
<`anthony> yeah, that's probably more like it.
<fabbione> bbl
<`anthony> ta for the help
<daniels> pitti: ping
<lamont> seb128: why does gnome-session hate ia64?
<seb128> lamont: [   ]  gnome-session_2.12.0-0ubuntu1_20050906-1214-ia64-successful.gz   ?
<seb128> lamont: what does it do ?
<lamont> segv
<seb128> utch
<seb128> got a backtrace ?
<daniels> pitti: if you've still got that crazy mac with the lv3:lwin_switch and nodeadkeys, could you please try an upgrade with p.u.c/~daniels/xserver-xorg.config?
<lamont> seb128: would love to know how to get one
<seb128> when it crash, do you get this bug-buddy dialog to send a bug upstream?
<seb128> it has the backtrace
<seb128> other way ... start another wm, let's say wmaker and run gnome-session under gdm from here
<seb128> gdb
<lamont> pitti: and I need to squeeze about 2 MB from the livecd ISO on ia64...  got any hated-languages?  (all the others are oversize for 650MB media, ia64 is oversize for 700MB)
<lamont> ignore the current image, that was an attempt at things by dropping a kernel - not a really good option
<lamont> well, clicking 'inform developers' is singularly unhelpful
* lamont tries the wmaker approach
<mvo> infinity: when update-notifier went mad, what operations did you perform? a normal upgrade? do you have a log by any chance what applications got upgraded then? I assume you can't reproduce it?
<lamont> seb128: what's the smallest wm I can grab?
<talios> anyone here know anything about ubuntu's squeak packages?  I see the inisqueak script mentioned in squeaks manpage, and an inisqueak manpage, but sign of the actual script, bug with the package maybe?
<lamont> actually, that should work.
<zyga> mvo: hello :)
<mvo> hi zyga 
<lamont> seb128: any cmdline args to gnome-session?
<seb128> lamont: wmaker is quite small
<seb128> no
<lamont> Program received signal SIGSEGV, Segmentation fault.
<lamont> [Switching to Thread 2305843009251442688 (LWP 5455)] 
<lamont> 0x2000000001256c20 in free () from /lib/libc.so.6.1
<lamont> #0  0x2000000001256c20 in free () from /lib/libc.so.6.1
<lamont> #1  0x2000000000234690 in IceFreeListenObjs () from /usr/lib/libICE.so.6
<lamont> #2  0x400000000001b960 in clean_ice ()
<lamont> after several ICE errors earlier
<lamont> _IceTransTransNoListen: unable to find transport: tcp
<lamont> _IceTransmkdir: ERROR: euid != 0,directory /dev/X will not be created.
<lamont> _IceTransmkdir: ERROR: Cannot create /dev/X
<lamont> _IceTransPTSOpenServer: mkdir(/dev/X) failed, errno = 13
<lamont> _IceTransOpen: transport open failed for pts/bld-27:
<lamont> ...
<seb128> lamont: seems to not be a GNOME issue ...
<lamont> other than to the end user... :-(
<lamont> but yeah.
<fabbione> DOH!
<fabbione>  /dev/X ???
<jmg> hey guys, i need to file a bug due to state of suspend on my laptop... but not sure if i should be filing under acpi or under klaptop
<fabbione> acpi-support
<fabbione> use keyword laptop
<jmg> bugzilla?
<jmg> or malone?
<carlos> pitti, hi, around?
<ploum> Hello
<pitti> lamont: I didn't care for the ia64 image yet, since there were no images I could base size calculations on
<pitti> Hi carlos 
<slomo> seb128: is it a known problem that evolution-alarm-notify crashes on gnome startup?
<lamont> pitti: ah, makes sense
<Kamion> jmg: bugzilla
<seb128> slomo: no
<pitti> lamont: I have a clever script that makes determining the fitting set of langpacks easy
<jmg> Kamion: thx
<slomo> seb128: fine, i'll file a bugreport then ;)
<carlos> pitti, I'm going to prepare a language pack all days this week so you can choose whatever you want to generate the latest language pack. Is that ok for you?
<ploum> I've two soundard (one onboard and another). The only way I've found to use the other one was to blacklist the onboard module (intel8x0) in hotplug conf.
<seb128> slomo: with a backtrace please or it's useless
<ploum> seems very unfriendly
<pitti> daniels: you mean just upgrade the current breezy xorg to that versoin, or upgrade hoary to it?
<slomo> seb128: sure
<carlos> pitti, btw, we had a problem with control-center that should be fixed today, that's why it's a bit outdated
<pitti> carlos: that's great
<ploum> against wich package must  I report a bug ?
<seb128> thanks
<carlos> pitti, the others should already be up to date
<pitti> carlos: what about evolution-2.4?
<pitti> carlos: from the Friday tarball I removed c-c and evo
<seb128> ploum: the sound capplet has a soundcard selector
<pitti> carlos: the others were fine
<fabbione> jmg: bugzilla
<carlos> pitti, evolution is being imported atm, will be available with the language packs tomorrow
<ploum> seb128 : "changer le priphrique" ?
<carlos> after  breezy release, I will move the language pack generation to production so we don't need to wait for the staging sync
<seb128> ploum: gnome-sound-properties ... try to find it on the screen
<seb128> ploum: there is no that many option on this capplet :)
<ploum> aaaah! 
<lamont> daniels: ping
<ploum> I didn't see this ...
<ploum> ok, I'm lame
<seb128> :)
<ploum> thanks ;-)
<seb128> np
<lamont> daniels: wth is _IceTransTransNoListen defined?
<daniels> lamont: by /usr/include/X11/Xtrans/transport.c probably, because of the absence of TRANS_SERVER
<daniels> pitti: either
<pitti> daniels: ok, I'll reconstruct the broken xorg.conf and upgrade
<lamont> daniels: source package?
<daniels> lamont: xtrans-dev
<daniels> lamont: probably source package xtrans
<slomo> seb128: we won't get abiword 2.4 for breezy?
<daniels> pitti: you need to reconstruct the broken debconf answers ;)
<lamont> ok
<daniels> lamont: basically, it'll be getting /dev/X instead of /tmp/.ICE-unix because of a lack of ... maybe ISC
<daniels> i can't remember which
<lamont> ISC?
<pitti> daniels: not sure what you mean, but I didn't see/change any debconf answers
<lamont> daniels: wth does this mean: _IceTransTransNoListen: unable to find transport: tcp
<daniels> lamont: that it wasn't built with -DTCPCONN, and rightfully so.  don't worry about it
<daniels> pitti: hm
<pitti> daniels: ok, my xorg.conf now matches /var/lib/xfree86/xorg.conf.md5sum
<pitti> daniels: i. e. I have the exact same state as after the upgrade
<lamont> daniels: let me rephrase that... I'm trying to figure out why we segv in IceFreeListenObjs
<daniels> lamont: libice6-dbg might be useful there, I guess ...
<daniels> lamont: the PTS errors will beharmless, don't worry about them
<pitti> daniels: ah, there's no debs, but a script - I just execute it with sudo?
<daniels> lamont: for _IceTrans* functions, strip the IceTrans and then grep for it over /usr/include/X11/Xtrans
<daniels> lamont: xtrans is god's punishment for touching yourself at night.
<daniels> pitti: ah, don't worry about it, think I've got it figured out here
<lamont> well, that was diff.  now we die in strlen()
* lamont fetches libc6.1-dbg too
<pitti> Kamion: can you sync packages from Debian? I need some universe syncs for security updates
<lamont> heh... maybe if I logged in first
<lamont>   network_id = 0x49a90 <Address 0x49a90 out of bounds>, 
<lamont> neato
<lamont> daniels: do I care about this? ** (gnome-session:5244): WARNING **: Unable to lock ICE authority file: /home/lamont/.ICEauthority
<daniels> yeah, probably
<daniels> sounds like libICE is completely broken on your platform
<Kamion> pitti: yes
<smurf> lamont: I've updated kbd-chooser, please test
<lamont> smurf: that'll have to be once I get to work...  in about 4-6 hours
<pitti> Kamion: can you please sync gtkdiskfree 1.9.3-4sarge1, and apachetop 0.12.5-1sarge1 or 0.12.5-5 ?
<Kamion> smurf: kbd-chooser takes a while to propagate to anywhere people can usefully test it, because it's in initrds
<lamont> daniels: is this normal?
<lamont> _IceTransOpen: transport open failed for pts/bld-27:
<lamont> _IceTransMakeAllCOTSServerListeners: failed to open listener for pts
<lamont> _IceTransISCOpenServer: Protocol is not supported by a ISC connection
<lamont> the last ICE printf is:
<pitti> Hey haggai
<lamont> _IceTransMakeAllCOTSServerListeners: failed to open listener for sco
<smurf> Kamion: He can build his own ;-)
<Kamion> pitti: done
<lamont> Kamion: so does kbd-chooser then require a d-i daily, or just a CD crank?
<pitti> Kamion: thanks; dia sync would also be nice; no big changes between -11 (breezy) and -14 in Debian, and -15 has a security fix
<Kamion> lamont: d-i daily
<pitti> Kamion: however, I can also backport the patch easily
<daniels> lamont: don't worry about those
<lamont> Kamion: if I cron one of those for an hour or so from now on hppa, could you crank it through while I sleep?
<Kamion> pitti: dia's in main; please backport
<Kamion> lamont: yes
<pitti> Kamion: alright
<lamont> daniels: ok, then what routine do I want look at for who's assigning listenObjs[] ->network_id?
<lamont> oh feh./
<lamont> actually, keyboard-chooser made it through before evo.
<zyga> hi
<zyga> there is an issue with our ruby version
<zyga> we ship 1.8.2-9 which claims to be 1.8.3 (it has many patches)
<zyga> that version doesn't work with alexandria 0.6.1 (internal ruby errors)
<zyga> I did a debdiff of ruby as suggested on #u-motu
<zyga> it's over 4 megs long unfortunatly
<zyga> debdiff from our version to debian's unstable 1.8.3-1
<slomo> zyga: maybe apply the patches from our version and diff against that
<zyga> the debdiff is here: http://www.suxx.pl/ubuntu/ruby.debdiff
<ploum> http://bugzilla.ubuntu.com/show_bug.cgi?id=16964 : I'm not sure I understand what this bug means. It's me or there's no bug at all ?
<zyga> slomo: I'm not good at this stuff yet really
<lamont>   network_id = 0x49a90 <Address 0x49a90 out of bounds>, 
<lamont> interesting...
<lamont> becuase 0x6000000000049a90 contains "unix/bld-27:/tmp/.ICE-unix/5248"
* lamont whaps daniels
<lamont> or maybe just xorg
<lamont> daniels: guesses on who's casting pointers through 32bit ints?
<seb128> ploum: you may want to /j #ubuntu-desktop
<lamont> ../../src/listenwk.c:84: warning: implicit declaration of function '_IceTransGetMyNetworkId'
<lamont> I wonder if that would do it, eh?
<lamont> daniels: you have time to deal with all of the implict defs found in people.ubuntu.com/~lamont/buildLogs/libi/libice/1\:6.3.5-3/libice_1\:6.3.5-3_20050601-0420-ia64-successful.gz ??
<lamont> ../../src/listenwk.c:84: warning: cast to pointer from integer of different size
<lamont> that's the real fatality
<daniels> wonder why that's not defined
<lamont> only 20 lines of 'implicit definition of...' crap
<daniels> lamont: edit that file, add #define ICE_t and #define TRANS_SERVER before the Xtrans.h include; does that help?
<daniels> lamont: you may also need TRANS_CLIENT and/or TRANS_REOPEN
<daniels> though why this doesn't also fail on amd64 is beyond me
<lamont> because the upper 32 bits on amd64 pointers tend to be zer0
<daniels> lamont: you may also want to do the same with src/misc.c
<daniels> and src/listen.c
<daniels> and src/connect.c
<mjg59> Grngk.
<mjg59> Right.
<mjg59> DAILY INSTALL TIME
<lamont> accept, connect, listen, listenwk, misc, shutdown
<lamont> #define ICE_t
<lamont> #define TRANS_SERVER
<lamont> #define TRANS_CLIENT
<lamont> #define TRANS_OPEN
<lamont> any reason not to do all 4 in each of the files?
* lamont will get the "you're dead, mmmk?" script and run it over the ia64 log files once he gets to work
<daniels> REOPEN, not OPEN
<daniels> you can do all four, but finding the most minimal set needed would be most useful for me
<lamont> sigh, ok
<haggai> pitti: hiya
<lamont> ../../src/authutil.c:58: warning: function declaration isn't a prototype
* lamont notes that we are no longer in the 1980's
<daniels> lamont: yes we are.
<daniels> lamont: we're now requiring C89 instead of K&R.  so yeah, in the 80s, albeit just.
<lamont> daniels: people.ubuntu.com/~lamont/libice.diff
<lamont> seems to be minimal or near minimal
<mvo> pitti: update-notifier fixed to display the langpack notifications again correctly
<lamont> daniels: you want the privilege of uploading, or shall I?
<daniels> lamont: rockin, seems sensible to me
<daniels> lamont: all yours if you want it
<lamont> Kamion: please to approve the libice upload, it lets windowing work on ia64, by fixing missing implicit defs.  kthxbye
* lamont will do it
<lamont> gonna call it -4 though, not -3.1... K?
<Kamion> noted
<daniels> Kamion: it's the right fix
<Kamion> diff looks suitably non-intrusive if you (plural) can confirm it doesn't make the header files do other wacky things
<daniels> i'll commit it upstream in a sec; ice would be the only libxtrans-using module I haven't fixed it for already
<daniels> Kamion: i'm willing to assert that it doesn't
<Kamion> ok, thanks
<Kamion> go ahead thn
<Kamion> then
<Kamion> what does '#define ICE_t' do anyway?
<daniels> Kamion: based on past experience.  admittedly my recollection may be a little hazy, since every time I have to do anything with xtrans, there's usually an empty bottle of vodka in the recycling bin the next day, but yeah.
<Kamion> other than being a bad joke
<daniels> Kamion: xtrans is polymorphic code based on #defines
<daniels> Kamion: so you have common functions which change their name based on #define foo_t (X11_t, XSERV_t, FONT_t, FS_t, ICE_t)
<Kamion> that's a nasty abuse of _t
<Kamion> (which at least C99 reserves for the implementation, BTW, and C89 might do as well ...)
<daniels> /usr/include/X11/Xtrans contains a bunch of files which change like such (and expose varying functionality based on other #defines)
<Kamion> but obviously not something fixable for breezy ;)
<daniels> xtrans is a nasty abuse of fucking *everything*
<daniels> seriously.  #include'ing C files, which change function names based on some #define.
<daniels> it needs to go completely, not just lose the _t.
<daniels> but yeah, as I said, C89 was only made a requirement early this year or late last year or something.  i think xtrans predates it.
<daniels> at a time where you wanted to switch between unix sockets and decnet.
<daniels> if it explains anything, the same dude who wrote xtrans also wrote the current X module loader.
<lamont> Uploading via ftp libice_6.3.5-4_source.changes: done.
<lamont> Kamion: but X is part of the implementation... :-)
<Kamion> actually I wonder if I'm wrong about _t; I can find a statement that int*_t and uint*_t are reserved
<lamont> the problem with C's reserved namespace is that it doesn't say what the middle layers may use...
* lamont only knew about leading _
<lamont> but must go back to bed now...
<lamont> Kamion: tomorrow I'll make a pass through the rest of the log files looking for known-fatal ones...  Then run in circles and scream and shout
<Kamion> yeah, looks like I'm wrong
<daniels> lamont: it's only Xtrans that has this particular pathological evil, so just check everything that reverse build-deps on that
<daniels> i'm pretty sure libx11, xserver-xorg/xorg-server, libfs, libxfont, are okay
<lamont> daniels: only Xtrans has implicit deps?  I don't think so.
<lamont> er, defs
<daniels> lamont: well, only Xtrans has them, and then has some murderously bad casting around, within X
<daniels> leading _ is reserved?
<lamont> there are _LOTS_ of packages that have implicit defs of various things, from strcpy to xtrans...
<lamont> daniels: per the ANSI spec, yes.
<daniels> christ
<daniels> well there goes half the archive
<lamont> iz reserved "for the implementation"
<daniels> that's stupid
<Kamion> it's not quite that
<lamont> no, that's why the ansi namespace guarantees (with a few documented exceptions) that the user can have any name he wants, unless it begins with _: namespace purity
<Kamion> -- All identifiers that begin with an underscore and either an uppercase letter or another underscore are always reserved for any use.
<Kamion> -- All identifiers that begin with an underscore are always reserved for use as identifiers with file scope in both the ordinary and tag name spaces.
<lamont> the part the spec forgot was to declare (1) what is/is not "implementation", and (2) what do all the middleware libraries do?
<Kamion> (C99 7.1.3)
<daniels> oh, C99.  i won't have to worry about that for ten years yet.
<Kamion> I very much doubt that's new in C99
<daniels> hm.
<lamont> X libs fall squarely into the "we're not part of user space, but we're not part of implementation either, what the hell do we do for our namespace?" camp
<lamont> which means that they pick _$mumble and pray
<Kamion> I don't see it in the foreword
<lamont> it's part of the original ansi defn
<Kamion> (list of major changes from C89)
<lamont> late 80's would be about right for my recollection of the screaming time.
<Kamion> surely X has a perfectly good X* namespace
<lamont> (somewhere 85-95 ish...)
<lamont> Kamion: well, but what about internal, non-static names?
<Kamion> as long as each middleware library declares what namespace it uses, there's no problem, surely; if you're using that library, you know about it
<lamont> the API is pretty much X*, and the users tend to avoid X* accordingly, but...
<Kamion> or should
<lamont> right
<Kamion> lamont: XInternalFoo?
<Kamion> or XIntFoo or whatever
<lamont> XDontCallMeFoo
<Kamion> XDontCallMeShirley
<lamont> heh
* lamont goes back to bed.  for an hour or so anyway
* Mithrandir wishes infinity had a link with a little bit less latency.
<daniels> Mithrandir: ?
<lamont> Mithrandir: so does infinity
<daniels> we use _foo for internal stuff
<daniels> like _IceFoo, which is internal API that libSM uses
<daniels> WAY TO GO GUYS
<lamont> daniels: right.  THat'd be a violation of spec, in the purist sense.
<daniels> even better is the prototype of same in the libSM source, with a comment above saying 'this is libICE private API'
<lamont> Kamion: the issue comes down to how good the lib is at being pedantic about namespace.
<lamont> most aren't.
<Mithrandir> daniels: I'm trying to fix mysql by (ab)using lucifer.  It gives me flashbacks to 1200/75.
<daniels> Mithrandir: the link has been doing weird things lately.  i was getting thirty-second burstlag to my desktop earlier.
<Kamion> AFAIK _[a-z] .* is fine for identifiers in function, block, or function prototype scope
* lamont ran NFS over a 2400 baud link once. don't.
<daniels> i think we're 1500/256 at the moment
<Mithrandir> daniels: it's working fine, it's just that it's a long way from where I'm sitting.
<Mithrandir> daniels: and that 1500/256 is kbit/sec, I was talking bit/sec. :-P
<daniels> heh
<daniels> Mithrandir: think you've got crap latency, eh?
* Diziet is lost in a twisty maze of string classes, all different.
<Treenaks> daniels: you're just on the wrong side of the planet
<Kamion> ah, but function prototype scope only covers formal arguments, not the function identifier itself
<Treenaks> daniels: latency-wise
<daniels> Mithrandir: i just started a xorg source upload and now I'm off to have dinner.  cheers.
<Kamion> lamont: even glibc only started getting much more pedantic about it relatively recently
<Mithrandir> daniels: doesn't seem to affect me.  Have a nice dinner.
* lamont really really sleeps
* fabbione is tempted to test an insane install test
<fabbione> Kamion: how would you feel about 2x256MB USB keys in RAID1 for /boot + / and the rest on a 20GB USb disk?
* fabbione is trying to reuse all the hw that lays around the house
<Kamion> fabbione: *shrug* if you can get grub to boot off that, more power to you :)
<fabbione> Kamion: ehehe let's try :)
<fabbione> but it should. d-i sees the disks as SCSI
<Kamion> BTW, if #16094 rings a bell with anyone, I'd be interested
<Kamion> oh, wow, major partitioning speedup by fixing partconf/find-partitions to ignore read-only devices
<Diziet> I thought _... identifiers were only reserved if they had external linkage.  BICBW about  static int _zonk;
<daniels> the reply that says 'info@shipit.ubuntu.com, try that, it works perfectly for me!' is pure gold.
<infinity> mvo : <poke>
<fabbione> Kamion: *perhaps* he needs to remove the old md superblock.
<Kamion> Diziet: C99 says "identifiers with external linkage" elsewhere in the same section but only "identifiers" for the _[a-z] .* case
<Kamion> I don't know about C89
<fabbione> Kamion: old super blocks might confuse stuff around.. specially if they don't change position for a different partition size
<infinity> mvo : When update-notifier went nuts, I hadn't done anything previously.. It just... Went nuts... And after a reboot, no, I can't reproduce it.
<Kamion> fabbione: how does one most easily remove the old superblock?
<fabbione> Kamion: sec.. i need to look that up
<fabbione> mdadm --zero-superblock <pathtodevice>
<fabbione> but that needs to be done with all the raids turned off
<fabbione> otherwise they get rewritten
<Kamion> turned off as in not assembled yet, or turned off as in mdadm --stop?
<fabbione> mdadm --stop will do
<Kamion> if they're not assembled yet then I'd've thought /dev/md/0 etc. wouldn't mean anyway
<Kamion> s/anyway/anything/
<fabbione> if they are not assembled is ok too
<fabbione> but if they get started for some reasons, you need to stop them first
<fabbione> done that, zero the superblocks
<fabbione> recreate/start again the raids
<Kamion> if they aren't assembled, what device do you use? the underlying physical volumes?
<fabbione> you need to use the real partition/hd
<Kamion> ok
<fabbione> you never use /dev/md
<mvo> infinity: oh well. not restarting dbus by any chance or something like this :) ?
<Kamion> fabbione: can you think of any way to test whether this is the problem, non-destructively?
<Mirv> mvo: did you write that get-18n script in language-selector?
<fabbione> Kamion: i am thinking...
<fabbione> i am not sure i understand 100% what he wants to achieve.. i know tht old md blocks are a pain..
<Kamion> I can imagine adding a partman commit script which zeros the superblocks of new RAID physical volumes before going into the RAID configuration screen; I think that's too risky for breezy though, because if done wrong it could lose data
<fabbione> Kamion: he wants to: raid the 2 6.4GB in a stripe and than raid1 with the 15G?
<Kamion> fabbione: I have no idea what he's trying to do; the relevant point seems to be that he created *new* RAID physical volumes and mdcfg didn't see them all
<fabbione> Kamion: no you really don't want to do that.. i might go there just to start again a raid :)
<fabbione> Kamion: it gives the feeling he is trying to do md partitioning, that's not exctly supported
<Kamion> fabbione: I think he's trying to have two RAID0 pairs, but not RAID those two pairs together, but use them as LVM PVs or something
<Diziet> Kamion: Did someone approve the metacity `new upstream' for the long titles crash ?  I'm not convinced that this is the right answer to this problem at this stage.
<infinity> mvo : Could have been an upgrade from several hours previous that I hadn't restarted/rebooted yet.  But I know I wasn't doing anything much at all when I started noticing the churn.
<jdub> mdz, jbailey: YOU POUR COLD WATER ON MY HEART (and rightly so) re: shutting up grub
<infinity> mvo : Even so, that's hardly "reasonable" behaviour.
<Kamion> fabbione: the problem he describes is not doing anything unsupported, regardless of whether he's trying to do anything unsupported later
<mvo> infinity: no, certainly not :/
<Kamion> Diziet: yes, I did; standing policy since warty is to take the newest GNOME upstream versions we can
<Kamion> I looked over the diff and it didn't seem insane, although I didn't test it
<Diziet> kamion: OK.  Hmmm.
<Kamion> Diziet: (hence why Sebastien and Daniel are busy uploading all of GNOME 2.12.1 at the moment)
<Diziet> I think I will change it in firefox anyway.
<fabbione> Kamion: ahhhh ok.. i think i understand what it is trying to do...
<fabbione> Kamion:  i will try to reproduce it later
<janimo> daniels, any idea what could make 'xset dmps force off' only dim the screen now, while about a week ago it turned it off? ati driver, X600 chip
<fabbione> i need to get some rest becuase headacke is showing up
<daniels> janimo: no idea, we haven't touched that code for ages -- try downgrading the kernel?
<janimo> daniels, ok thanks
<Kamion> fabbione: problem is the only machine I have with multiple disks is my server, which I'm not taking down for installer tests
<pitti> Hi seb128 
<fabbione> Kamion: yeah don't worry
<Kamion> I don't know if it's a multiple-disks thing, or maybe a SCSI thing
<fabbione> it can be reproduced on a one disk machine i think
<Kamion> oh, no, he's using IDE
<seb128> hey pitti 
<fabbione> it's just question of faking 4 partitions
<infinity> mvo ; Does a greek install tweak/mangle the console font in /etc/console-tools/config, or did you do so by hand?
<fabbione> and try to raid them as he sais
<Kamion> fabbione: I just tried that, and it worked fine
<Kamion> fabbione: faking how?
<fabbione> Kamion: i did several RAID installs.. never had a single problem
<Kamion> fabbione: I'm seriously wondering if it's a missing udevstart or something
<Kamion> but it doesn't seem to be all that racy
<mvo> infinity: I didn't tweaked anything by hand, it is/was a stock greek install 
<fabbione> Kamion: i think the problem is that the first time he did try to create some kind of very weird raid
<fabbione> Kamion: till he realized he couldn't do that
<fabbione> (note the select one/select 3 dance)
<infinity> mvo : And I broke it, somehow?  Hrm.
<fabbione> Kamion: our raid code is ok.. it's mostlikely a small bug where we allow mdcfg to run is non perfectly sane situation
<Kamion> fabbione: the select one / select three business was only because partman wasn't showing him all of his devices, AFAIK
<fabbione> Kamion: but you can land there doing messes like that
<infinity> mvo : Does /etc/init.d/console-screen.sh, run from the console on a running system, fix/change anything?
<Kamion> the procedure he described seems totally sane
<Kamion> in the *first* post, ignoring the later ones
<Kamion> certainly later on he seems to have tried to do odder stuff
<fabbione> I set up two RAID partitions (physical volume) on one large drive and one RAID
<fabbione> partition on each of two smaller drives.
<fabbione> this is non-sense to me
<fabbione> (first line)
<Kamion> it's not very conventional, but I can see no reason at all why partman doesn't support that
<fabbione> i did try that stuff for fun
<mvo> infinity: no, but I think (could be wrong though) that it used to fix vt2-6. vt1 used to work ok
<fabbione> now the point is:
<fabbione> you create hda1
<Kamion> all it's doing is creating the volumes, then doing /usr/lib/partconf/find-partitions --ignore-fstype a bit later
<fabbione> than you create md0 out of hdb1 + hdc1
<infinity> mvo : And now all 6 are broken?...
<infinity> mvo : That could be an artifact of you playing. :)
<Kamion> which should show up all of the volumes you just created
<fabbione> afaict he is trying to create /dev/md1 out of hda1 + md0
<mvo> infinity: yes, that was what I was thinking too. I'll do a reinstall now
<fabbione> that's not exactly a supported situation
<infinity> mvo : My (global) font gets set correctly here, I haven't test per-vc fonts, but I also didn't touch that part of the code, so I'll assume it still works.
<fabbione> because you need to mark /dev/md0 as raid disk
<fabbione> and iirc that's not something nice to do
<fabbione> but again i need to test it
<fabbione> i did it too long ago
<fabbione> when i was more insane than now
<infinity> mvo : If it still breaks, yell loudly in the bug, and I'll do a test install in Greek in some free space somewhere.
<Kamion> fabbione: not to start with, he isn't
<mvo> infinity: will you still be around in ~30-45min?
<infinity> mvo : Just need to download an ISO to play with.
<infinity> mvo : FSVO 'around', yeah.  I'll be in and out all night, working off and on.
<Kamion> fabbione: you seem to be trying to say RESOLVED/INVALID - I really don't think that's the case and I don't like dismissing this, because it feels like it could quite easily be a partman bug given the complexity of that code.
<fabbione> Kamion: i didn't say RESOLVED/INVALID
<fabbione> i said: I need to retest it
<Kamion> you're saying he's doing something wrong and unsupported
<Kamion> that's what RESOLVED/INVALID means
<fabbione> and "fabbione Kamion: our raid code is ok.. it's mostlikely a small bug where we allow mdcfg to run is non perfectly sane situation"
<Kamion> I'm not sure I believe your premise :-)
<Kamion> have you read all of partman-md and mdcfg? :)
<Kamion> they're pretty nasty as far as partman integration goes
<mvo> infinity: ok, I'll keep you updated, thanks
<fabbione> Kamion: no. i need to understand what he is trying to do first.
<fabbione> Kamion: and as i said i need to get some rest first because headacke is coming up..
<Kamion> fair enough
<Mirv> mvo: _if_ you happened to write the get-iso-codes-i18n, it should do some extra checking: currently, when the language and the country is called the same in Finnish, a wrong translation is put in the language; in Finnish, language names are written in lower case, and the script seemingly gets the country name instead
<fabbione> Kamion: i didn't close the bug or anything :) i find it diffcult to believe we have such a strange bug
<fabbione> given that i do test a lot of installs on RAID
<fabbione> but they are sane config
<fabbione> +s
<mvo> Mirv: could you please file a bug and (if possible) do a patch :))) ?
<Mirv> mvo: ok, I will try :)
<Kamion> fabbione: hmm, partconf checks for LVM before RAID; I wonder if that could be a problem
<Kamion> fabbione: the output of the commands I asked him for should help, anyway, I hope
<mvo> Mirv: thanks, I'm happy to help if you have any questions (just /msg me)
<hunger> I can no longer burn CDs with breezy. cdrecord assumes /dev/sg0 as the divice to use, while it is actually /dev/sg1 (sg0 belongs to /dev/sda I think, not /dev/scd0). Should I file a bug on cdrecord or udev for this?
<mvo> hunger: cdrecord should look for /dev/cdrw. do you have that?
<fabbione> Kamion: i doubt that could be the issue.. the problem is lower than LVM or RAID.. like not all partitions are tagged as RAID devices
<fabbione> or something
<hunger> mvo: Let me check...
<Kamion> fabbione: partconf is what reports that tagging
<fabbione> i really need to test it and read all the logs
<Kamion> fabbione: so if it says LVM, partman-md won't display the device
* fabbione does it know becayse he can feel Kamion is worried :)
<fabbione> Kamion: you can see tha LVM doesn't recognize any partition as sucj
<fabbione> such
<fabbione> (from the first log)
<hunger> mvo: /dev/cdrw is a link to /dev/scd0
<Kamion> fabbione: I can see that *parted* doesn't think that any partitions are flagged as LVM, but that's not necessarily exactly the same as what /usr/lib/partconf/find-partitions thinks
<hunger> mvo: Sorry for the delay... Im in the office and had to boot my private laptop:-)
<mvo> hunger: no problem. might be a hal problem then. <---- pitti ?
<hunger> mvo: Does cdrecord even look in hal?
<mvo> hunger: no, but the symlink is IIRC setup by it
<fabbione> Kamion: there is something i am not sure i understand.. in order to access the mdcfg menu, all the changes must be committed to the disks
<fabbione> Kamion: if so.. why do the old partitions still show up?
<Kamion> fabbione: old partitions?
<fabbione> http://bugzilla.ubuntu.com/attachment.cgi?id=4181 <-
<fabbione> at the end of the file
<Mirv> mvo: actually, I might have been wrong.. it might be that one translator has actually done the few incorrect translations there. hmmkay.
<fabbione> parted_server: Closing infifo and outfifo
<fabbione>  /lib/partman/choose_partition/60partition_tree/choices: paragraph: 1	32256-6399267839	6399235584	primary	unknown	/dev/ide/host0/bus0/target0/lun0/part1
<fabbione>  /lib/partman/choose_partition/60partition_tree/choices: paragraph: 2	6399267840-12395496959	5996229120	primary	unknown	/dev/ide/host0/bus0/target0/lun0/part2
<fabbione> and so on
<fabbione> they shouldn't be there at all
<mvo> Mirv: ok, fair enough
<Kamion> fabbione: why not?
<Kamion> fabbione: partman doesn't forget about the underlying volumes just because you've configured RAID on top of them
<Kamion> AFAIK, that's still what's on his disk
<fabbione> Kamion: IIRC when you enter the raid setup, you need to commit your changes first
<Kamion> yes
<fabbione> so once you commit the changes, the old partition table should be gone
<Kamion> in what way is that an "old" partition table?
<hunger> mvo: Changing the cdrw ling to /dev/sg1 does not work.
<fabbione> Kamion: i can guess that by the fact that it is the same discovered in the first log?
<Kamion> the log does not indicate him having changed that partition table in any way
<hunger> mvo: Debug output of K3B lists "BLAHDEVICE (/dev/scd0, /dev/sg1) at /media/cdrom0 [All kinds of formats] 
<hunger> mvo: Then cdrecord fails opening /dev/sg0.
<hunger> mvo: Looks like a cdrecord bug to me...
<Kamion> he's attempted to configure a RAID device using some of those partitions as physical volumes, but he hasn't done anything else to the physical partition table
<mvo> hunger: yeah, interessting
<Kamion> fabbione: parted_server looks at the partition type (for DOS partition tables, anyway) to determine whether a partition is an LVM physical volume or RAID or whatever
<Kamion> fabbione: partconf/find-partitions looks at /proc/lvm/VGs/*/LVs/* and /proc/mdstat instead
<Kamion> so it's possible for it to give different results
<fabbione> hmmm
<fabbione> crack
<hunger> mvo: I guess I'll file a bug on cdrecord...
<fabbione> i am trying to reproduce that thing
<mvo> hunger: could this be a k3b problem? cdrecord seems to be setup for /dev/cdrw, you can try with "cdrecord -toc" 
<Kamion> fabbione: oh, hmm, no, I'm looking at the wrong bit of code there
<Kamion> I was looking at the code which lists active LVM/RAID *logical* volumes
<hunger> mvo: cdrecord -toc tries to work with /dev/sg0
* pitti is amused to find *two* firefox icons in the panel after a fresh daily installation
<mvo> hunger: odd, because cdrtools (4:2.01+01a01-4ubuntu1) breezy; urgency=low
<mvo>   * Add 27_default_device.dpatch:
<mvo>   was supposed to fix that
<hunger> mvo: cdrw is a symlink to /dev/scd0 by default anyway... and thatis associated with /dev/sg1
<Kamion> oh, heck, partconf/find-partitions doesn't list LVM or RAID volumes any more
<Kamion> I must have broken that :(
<mvo> pitti: hal is supposed to setup /dev/cdrw, no?
<pitti> mvo: no, udev
<hunger> mvo: Maybe this is because I have a sda instead of a hda.
<fabbione> Kamion: ok.. now i have a spare disk with 4 partitions.. let see what is going to happen
<mvo> hunger: still, it should point to the correct cdrw device (I assume you have only one)?
<hunger> mvo: CDRW device as in /dev/scd* or /dev/sg*?
<hunger> mvo: It does point to the proper /dev/scd... (and yes, I only have one).
<mvo> hunger: hmmmmm ...
<smurf> hunger: is there a CDR_DEVICE entry in your /etc/default/cdrecord, and what does it say?
<fabbione> Kamion: ok.. i managed to get the error he mentions about "Earlier, I was seeing some sort of error reported where the partitioner could
<fabbione> not inform the kernel of the partition changes."
<fabbione> it seems like parted/partman or whatever is trying to tell that there is a partition (/dev/md0p1) on top of the raid
<fabbione> when there is none
<Kamion> yes, I just noticed that myself too
<Kamion> #16706
<Kamion> I think it's a separate bug, but probably implicated somehow
<hunger> smurf: 1,0,0
* Kamion reboots to try setting stuff up from scratch
<fabbione> Kamion: mostlikely 2
<fabbione> if not more
<fabbione> i wonder if this is realted to raid0 only
<Kamion> the message in question comes from parted/libparted/linux.c
<Kamion> no, #16706 was reported on RAID5
<fabbione> ok
<mvo> hunger: can you try seting it to /dev/cdrw?
<smurf> hunger: does replacing that with "CDR_DEVICE=/dev/cdrw" fix the problem?
<smurf> mvo: ;-)
<mvo> smurf: thanks! :)
<mvo> infinity: greek install looks great so far (I'm in stage2 currently)
<hunger> smurf: It complains about it not being intended to work and not being supported, but it does seem to work.
<hunger> smurf: Let me try burning something...
<mvo> hunger: cdrecord likes to whine
<smurf> hunger: that's not a problem with cdrecord, but with cdrecord's author. :-/
<hunger> smurf: Yeap... that guy is notorious for that, isen't he?
<fabbione> Kamion: nothing.. i can't reproduce the bug.. i can only get to the md error..
<Kamion> fabbione: ok, now I've got 'No unused partitions of the type "Linux RAID Autodetect" are available', which I'm guessing is a problem with unzeroed superblocks
<fabbione> Kamion: you did reboot the machine, without rebuilding the partition table, right?
<fabbione> so it's like an old raid setup laying there
<Kamion> fabbione: right
<Kamion> yep, looks similar to his report
<fabbione> ok.. yes than you are hitting the superblock thing
<fabbione> try to zero the blocks and reboot again
<fabbione> or make parted restart from scratch.. not sure which one is easier
<hunger> smurf/mvo: K3B ignores thase settings:-(
<fabbione> brb
<Kamion> have to mdadm --stop some things first
<mvo> infinity: you rock! greek install went fine and all vt's are setup correctly
<fabbione> re
<Kamion> mvo: are those base-config changes now obsolete? I'm afraid I got snowed under and haven't got round to them
<mvo> Kamion: looks like it, yes. the install looked good in stage2 (fonts setup correctly). after a reboot usplash/gdm came up with no problems and vt1-6 have correct fonts
<Kamion> mvo: cool - in that case I'll just revert all the changes I have in arch
<mvo> Kamion: let me check stage2 again to be absolutly sure please
<smurf> hunger: Settings => Configure k3b => Devices, does that look sane?
<hunger> smurf: Yeap. It is using /dev/scd0 there (which it considers to be (1,0,0).
<hunger> smurf: Which is what cdrecord -scanbus thinks it is, too.
<segfault> pitti: shouldn't update-notifier_0.38.11ubuntu1_translations.tar.gz include latest translations from rosetta?
<smurf> hunger: Hmmm. Does adding dev=/dev/cdrw (to ... => Programs => cdrecord) help?
<pitti> segfault: no, that's only the data from the source package
<Mithrandir> hmm, how does one disable inotify in the kernel?
<fabbione> Mithrandir: you can't
<segfault> pitti: ah, ok
<fabbione> you can recompile
<Mithrandir> fabbione: that really, really sucks.  15571.
<hunger> smurf: Nope.
<fabbione> Mithrandir: inotify doesn't use /dev/inotify anymore
<fabbione> the test program in the last comments is foobar
<Mithrandir> fabbione: yes, and? :-)  I want to have those users check if inotify is to blame.
<Mithrandir> I guess I should take concordia for a spin, without inotify.
<hunger> smurf: Oh, wait... it forgot my setting... retrying.
<hunger> smurf: Yeap, that works.
<pitti> fabbione: so the "noinotify" patch is gone?
<fabbione> Mithrandir: i doubt.. i can easily move over 40MB/sec...
<Mithrandir> fabbione: yes, but you don't have the same hardware as those users, do you?
<smurf> OK, it seems that something in your system gets confused about SCSI device order. Can you "cat /proc/scsi/scsi" and "ls -l /dev/sg*", and put that into a pastebin?
<fabbione> pitti: the noinotify patch was a local hack...
<fabbione> Mithrandir: inotify is hw independent
<fabbione> Mithrandir: it's a hook at VFS layer
<ogra> Mithrandir, we had another inotify test proggy on the "disappearing menu items" bug ... let me look up the bugnumber
<Mithrandir> fabbione: unless it tickles bugs in other drivers or something similar.
<fabbione> Mithrandir: i did check the code.. no it doesn't interact with drivers at all
<fabbione> it replaces some dnotify (fs) calls with generic ones
<ogra> Mithrandir, #14967 there was a link iirc
<fabbione> so that they can be diverted between dnotify and inotify
<Mithrandir> fabbione: do you have any other suggestion what it might be, then?
<fabbione> pitti: the noinotify/inotify patch was only a local hack (rejected upstream) to disable/enable it for our kernel
<pitti> fabbione: I see
<hunger> smurf: k3b runs cdrecord ... dev=1,0,0 ... dev=/dev/cdrw ... now. Lucky me that mine overrides the first one:-)
<fabbione> Mithrandir: it's a gnome bug!! :P
<Mithrandir> fabbione: sorry, I meant _useful_ suggestion. :-P
<fabbione> Mithrandir: one question would be why gamin is polling
<jbailey> Anyone here happen to use NIS on their network? =)
<fabbione> if it uses inotify, it should just sit and wait
<jbailey> I have a bug, and I'd really rather not setup NIS to test it. =)
<Mithrandir> jbailey: I have networks using NIS, yes.
<fabbione> jbailey: i am not going to answer to that
<Mithrandir> jbailey: #?
<fabbione> Mithrandir: wrong answer to jb! you win a mess
<Mithrandir> pft, setting up nis takes about two minutes anyway.
<jbailey> Mithrandir: http://bugzilla.ubuntu.com/show_bug.cgi?id=16893
<jbailey> (I'll even be nice and paste a clickable URL)
<jbailey> Mithrandir: Upstream closed a similar bug as WorksForMe
<smurf> hunger: Can you "cat /proc/scsi/scsi" and "ls -l /dev/sg*", and put that into a pastebin? (http://ubuntu.pastebin.com for instance)
<jbailey> Mithrandir: If you can reproduce it, there are a couple patches in CVS that might be candidates.
<Mithrandir> jbailey: that should be reproducable in a chroot?
<Mithrandir> jbailey: wfm
<jbailey> Mithrandir: I think so, yes.
<fabbione> Mithrandir: you can try to spin concordia and disable inotify, but note again what gamin is doing
<hunger> smurf: I can't... no net on the ubuntu box.
<hunger> smurf: The CDRW is scsi1, chan 0, id 0, lun 0 in /scsi (HD is scsi0, chan 0, id 0, lun 0) (both are SATA drives). 
<fabbione> Mithrandir: with the new inotify gamin should jsut wait for inotify to actually notify it of the changes
<fabbione> so that polling thing is suspicious
<hunger> smurf: sg0 is 21,0 (mayor,minor), sg1 is 21,1
<Mithrandir> seb128: do you have any idea on 15571 wrt fabbione's comments?
<Mithrandir> jbailey: so, works for me, can't reproduce.
<Mithrandir> jbailey: not even outside a chroot
<jbailey> Mithrandir: Thanks.  It's inherited from Debian, so I'll mark it NOTWARTY then.
<seb128> Mithrandir: what about it?
<jbailey> Might be another sideeffect of them using gcc-4 to compile instead.
<seb128> Mithrandir: current inotify doesn't use a /dev entry
<Mithrandir> seb128: any idea why gam_server is spinning rather than just sleeping in that case?
<seb128> it spins?
<Mithrandir> seb128: or is that an old trace?
<seb128> which one?
<Mithrandir> seb128: comment #7 in http://bugzilla.ubuntu.com/show_bug.cgi?id=15571
<fabbione> THANK YOU MOZILLA.. for crashing again and again.. and again.. and again
<seb128> Mithrandir: afaik gamin pool for non-existant files
<seb128> Mithrandir: not sure if inotify can put a monitor on non-created yet entries
<seb128> Mithrandir: ie: ~/.recently-used 
<Mithrandir> why shouldn't it?
<seb128> the panel monitor recently-used even if the file is not created yet
<seb128> Mithrandir: dunno how the linux inotify code work and what you can monitor, I just know than polling was used for non-created files
<seb128> by gamin
<jdub> http://fridge.ubuntu.com/node/5 <- that's the badger :-) :-) :-)
<jdub> oh
<jdub> http://fridge.ubuntu.com/taxonomy/term/1
<jdub> ^ see it there
<jsgotangco> taxonomy?
<jsgotangco> jdub: man that's they hype machine
<jdub> means categories, essentially
<jsgotangco> wow it has gloss terms
<jdub> that's how we did the sabdfl definition bit ni the faq story
* fabbione goes for a rest.. bb
<fabbione> +l
<fabbione> Mithrandir: another solution for the itontify bug.. reassign it to jdub.. he wanted that crack in
<mvo> Kamion: tty1-3 in stage2 are fine (I waited for gdm to start). tty4 after a fresh stage2 has no getty and some log/error messages left. is that known? tty5,6 have a getty but the console-font is set wrong. after a reboot vt1-6 are fine again 
<Kamion> mvo: tty4 known; tty5-6 are probably just not there when base-config starts (look at the initial inittab)
<Kamion> if you have any good ideas for fixing the tty4 thing, let me know, otherwise I'll probably leave it alone for breezy
<jsgotangco> jdub: the fridge calendar is awesome
<Kamion> we could work around tty5-6 by running console-screen.sh after telinit q, but I think that's a bit risky
<Kamion> (because init probably doesn't create the gettys synchronously)
<mvo> Kamion: it's not really a huge issue IMHO because vt1-3 are ok and a reboot fixes the problem anyway
<mvo> Kamion: just wanted to let you know about the current state :)
<Kamion> thanks
<mvo> np
<infinity> mvo : Rock, so it all works?
<mvo> infinity: yeah, looks perfect. no flicking when gdm starts, nice fonts on all terminals. looks like we are done there :)
* mvo is having lunch now
* infinity lets out a small cheer.
<kingos> anyone want to help me ? I am experiencing bug 13497 - amd64 system, dhcp3-client 3.0.2-1ubuntu6
<kingos> breezy
<maswan> how large are you planning the release set to be? 6 cd isos? dvd isos?
<ogra> maswan, do you plan to mirror edubuntu too ? we have 6 CDs and 6 DVDs now
<maswan> ogra: hmm. well, we might. :)
<ogra> maswan, just to inform you about the extra size :)
<ogra> s/size/space/
<maswan> ogra: ehm. it is there already. :)
<ogra> oh, including the DVD ?
<maswan> we mirror releases as provided by rsync from releases
<maswan> seems to be cd isos
<ogra> ah, k
<maswan> we are working on a full cdimage mirror too, but that is a bit of work to keep up to date
<maswan> ok, so, are you going to have live edubuntu isos too at release?
<Kamion> maswan: 6 CDs for each of Ubuntu and Kubuntu, 3 CDs for Edubuntu, some as-yet-unclear number of DVDs
<Kamion> maswan: edubuntu live> no
<ogra> maswan, next release probably
<Kamion> maswan: oh, plus source CDs
<Kamion> 4/5 per project
<acyr> anyone know if all xorg binaries in Hoary are moved to /usr/bin from /usr/X11R6/bin now?
<daniels> nope, they aren't
<daniels> Xorg, in particular, is still in X11Rfrigging6
<acyr> daniels: but in breezy they are in /usr correct?
<daniels> nope
<bddebian> Morning
<daniels> daniels@ephemera:~/canonical/xorg/app/imake/imake-7.0% ls /usr/X11R6/bin
<daniels> X  Xnest  Xorg  Xorg-debug  Xvfb  gtf  ioport  mmapr  mmapw
<daniels> the servers are all still there in breezy
<acyr> daniels: where would you recommend I drop the fglrx apps into?
<infinity>  /usr/bin
<daniels> yeah
<daniels> nothing should be in /usr/X11R6/bin at all
<daniels> particularly nothing new
<acyr> for both hoary and breezy that'd be cool?
<daniels> yah
<acyr> sweet.
<daniels> thanks for doing the packaging stuff, btw -- much appreciated
<acyr> np
<acyr> where can I get your package stuff from (or how can I pull from the repository)?
<daniels> you can just apt-get source linux-restricted-modules-2.6.12
<acyr> ah ya that's right, forgot it is hiding in the restricted-modules.  thanks
<daniels> no worries.  ignore all the lrm-manager, and split-module stuff.
<acyr> will do.  I just wannt make sure I get the paths etc right.
<daniels> yeah
<infinity> acyr : Easiest to grab the binary .debs and do "dpkg-deb -c foo.deb" and make sure yours matches.  Then if you make sure your dpkg-divert calls in the maintainer scripts match ours, you must have (basically) identical packages.
<acyr> infinity: thanks for the info, will do
<infinity> acyr : Do you require the user to have debhelper insalled, or do you do it with bare dpkg-dev (dpkg, dpkg-deb) calls?
<infinity> acyr : Oh, also, you're aware that on breezy, kernel modules need to be build with gcc-3.4, right?
<infinity> s/build/built/
<acyr> infinity: I am using debhelper.  I am not packaging binaries for the kernel modules currently, just make-kpkg/m-a compat source.
<infinity> Ahh, kay.
<acyr> joy, linux-restricted-modules source is only 73MB... 
<bddebian> Heh
<daniels> yeah, nvidia-legacy really screwed our day
<acyr> daniels: what happened?
<daniels> they don't support old cards with current releases anymore, so l-r-m has two versions of the nvidia driver now, for each of i386 and ia64
<acyr> oh, hehe
<pitti_live> Diziet: ping
<maswan> Kamion: Well, we are counting on a trivial ammount of source cd downloads :)
<maswan> Kamion: the reason I'm curious is for dimensioning offload hosts that need to keep all data in ram
<pitti_live> jdub: here?
<pitti_live> Kamion: did you recently try to shutdown a live CD on powerpc?
<pitti_live> Kamion: this hangs at "Shutting down LVM Volume Groups..."
<jdub> pitti_live: pong
<pitti_live> jdub: (just testing live CD): firefox still does not have a start page
<pitti_live> jdub: do we miss a new package in the live seed?
<pitti_live> jdub: AFAIR this file was moved to somewhere else
<jdub> pitti_live: it's now in ubuntu-docs
<jdub> pitti_live: changed too late for the livecd build, perhaps?
<jsgotangco> most likely
<pitti_live> jdub: current image has u-d 5.10-4
<jdub> jbailey: ?
<pitti_live> jdub: right, so tomorrow's image shuold have it
<jdub> sweet
<jsgotangco> we still need to beautify that page though its horrid
<pitti_live> jdub: odd though, it was uploaded two days ago...
<Treenaks> pitti_live: it got quite a bit larger
<Treenaks> (didn;t it?)
<jsgotangco> Treenaks: yes around 10MB im checking why
<jsgotangco> it seemed to have included some images that are not used
<Treenaks> jsgotangco: livecd space restrictions
<jsgotangco> oh so it exploded?
<Treenaks> jsgotangco: maybe
<Treenaks> jsgotangco: it could be why there is no startpage on the livecd
<jsgotangco> darn
<jdub> jordi: ping
<pitti> Kamion: darn, I just saw that breezy still has postgresql-common 25; it seems my sync request got lost in the IRC crowd; -27 has no new features, just bug fixes, can we please sync?
<jbailey> jdub: Yessir?
<jdub> jbailey: pitti was asking questions about the ubuntu-docs home page not on the livecd
<pitti> jbailey: it already resolved, the current live images still have version -4
<jbailey> Ah, excellent.
<jbailey> Already resolved good.
<jsgotangco> jbailey: except that ubuntu-docs is 10MB and it has images that seem to not been used :(
<jbailey> jsgotangco: I wasn't sure what was used or not, I can slim that down.
<bob2> does that have the corrected ubuntuguide thing?
<jsgotangco> bob2: yeah without the crack and the marillat stuff
<jordi> jdub: pong
<jdub> jordi: what is the language of mallorca's independence army (non-spanish)?
* pitti tests current amd64 install, bbl
<jordi> jdub: GUESS IT
<jdub> haha
<jdub> elite :-)
<jsgotangco> hah
<jdub> estic cercand meus pantalons!
<jdub> though google doesn't do catalan ;)
<Treenaks> jdub: may 5th, 2006 is next No Pants Day
<jdub> :-)
<jdub> oh
<jdub> i see what you mean
* jdub adds to the fridge calendar
<jdub> hrm
<Treenaks> jdub: link it to http://www.nopantsday.com/
<jdub> nopantsday.com has't been updated
<Treenaks> hm I see
<Treenaks> maybe the wikipedia page?
<jdub> should do a new poll
<jdub> anyone here subscribe to ubuntu-users via digest?
* jdub looks at the postgresql sycn
<jdub> Version: 27
<jdub>  postgresql-common (27) unstable; urgency=low
<jdub> oh
<jdub> postgresql-common, separate source
<jdub> weird
<jsgotangco> jdub: i do
<jdub> jsgotangco: do you like the pace of the digests?
<jdub> i've had requests that they be sent only once a day
<jsgotangco> twice a day isn't really that bad
<jdub> they're twice a day atm?
<jsgotangco> i rarely reply to digest anwyays
<jdub> mailman only has a "# of kb" setting
<jdub> which is frustrating
<jsgotangco> jdub: depends on the volume i guess
<jdub> i was thinking of cranking up the kb to something fairly huge
<jdub> and turning on the "send daily even if not big enough"
<jdub> option
<jsgotangco> you'll have a failry long digest if that's the case
<jsgotangco> 10 - 12 entries per digest is actually chewable
<Lathiat> digests are just for those who dont have mail filtering :)
<jsgotangco> Lathiat: oh ubuntu-users is just not my cup of tea really
<jsgotangco> especially if you have .* on the wiki
<jdub> that's a lot of tea
<jsgotangco> ok i gotta sleep good night
<mdke> Kamion, mdz, any indication on what to do about that string change proposal for ubuntu-docs?
<Kamion> I'll look at it in a bit; it turned from an easy decision into a hard one all of a sudden and I had other things to do
<mdke> Kamion, fair enough, thanks
<mdke> Kamion, shout if you want clarification on anything
<Nafallo> are there likely to be another kernel for breezy or should it be safe to dist-upgrade my server?
<pitti> Kamion: ping
<mdke> Nafallo, even if there is, it should be relatively safe
<Nafallo> yea, but I don't want to restart her if not needed :-P
<mdke> ah one of those eh
<Nafallo> it _is_ a server ;-)
<mjg59> Kamion: What time are the dailies built?
<Diziet> Damn, 16599 is still hanging around.  Anyone here know anything about why some font pfb might be missing on some user's system ?
<Kamion> pitti: yo. I hadn't seen the powerpc problem before. postgresql-common synced.
<Kamion> 21 8 * * *      for-project ubuntu cron.daily
<Kamion> 31 7 * * *      for-project ubuntu cron.daily-live
<Kamion> mjg59: ^-- those are the Ubuntu dailies, London time
<StR> Hi all!
<pitti> Kamion: thanks
<StR> where can I see why did you choose usplash instead of splashy?
<pitti> Kamion: I just installed amd64; I got the grub dialog that asked me to enter "/dev/hda" or "(hd0)" - is that really on purpose?
<mjg59> Kamion: Ok. So if I'm getting a train at 6am tomorrow, I might as well just go for what's there now?
<pitti> Kamion: AFAIR Hoary just asked me whether to install in the MBR, or didn't ask at all
<Kamion> pitti: it depends on the circumstances.
<pitti> Kamion: (it didn't find my already installed breezy system either, but that's already in bugzilla)
<Kamion> pitti: if there's an operating system on your disk that os-prober couldn't understand, grub-installer assumes that it must be too stupid to get the answer to the boot device question right for itself and asks you instead
<Kamion> pitti: bug#?
<pitti> Kamion: #12885
<pitti> Kamion: ah, so os-prober saw my other breezy system, didn't recognize it because it automatically mounted it to /media/hda2, and then grub-installer goes the safe way?
<Kamion> pitti: the automatic mounting under /media doesn't interfere; mounting outside /media might, those
<Kamion> s/those/though/
<pitti> Kamion: yes, I changed the mount point
<pitti> Kamion: ok, then it's not that critical
<Kamion> pitti: in #12885 you mounted it at /breezy32, which behaves differently
<pitti> Kamion: just checking whether this was a bug, but it seems to make sense
<Kamion> pitti: partman-target has a special case to avoid mounting subdirectories of /media while the installer is runnign
<pitti> Kamion: ok, that's fine then; thanks for the heads-up; I will do my next test-install without mounting the partition then
<Kamion> pitti: let me get this straight - are you still mounting it at /breezy32, or did you change to taking the installer's default of /media/hda2?
<Kamion> we could possibly be a bit more intelligent and only mount filesystems mounted at standard Unix paths for the duration of the installer
<pitti> Kamion: nope, I changed it to /breezyold this time
<pitti> Kamion: I didn't know about the /media special-case
<Kamion> ok, I'll try my suggested fix above in dapper, then
<spayne> why are so many packages come through each day?
<spayne> and what is up with lists.ubuntu.com?
<Kamion> spayne: because there's a lot to do
<Kamion> spayne: lists> jdub's looking at it
<spayne> is it just the archives?
<jdub> yes
<spayne> yo jdub btw
<jdub> yo
<mjg59> Kamion: Is anyone other than elmo able to do syncs?
<daniels> mdz?
<daniels> he has archive powahs, doesn't he
<Kamion> mjg59: mdz or me
<Kamion> mjg59: what's needed?
<mvo> Kamion: ok to upload http://paste.ubuntulinux.nl/2760? various fixes in update-notifier
<mvo> Kamion: I can do you a debdiff if you want too
<mjg59> Kamion: sdparm
<carlos> pitti, todays' language pack: http://mawson.ubuntu.com/~carlos/rosetta-breezy-2005-10-04.tar.gz
<Nafallo> mjg59: please tell me you are going to propose that for main? :-)
<mjg59> Nafallo: With luck
<pitti> carlos: so evolution and control-center are current now?
<carlos> pitti, I will try to automate it so you have it all days when you wake up
<pitti> carlos: that's nice, thanks
<carlos> pitti, evolution is current, control-center is not
<pitti> carlos: when is the tarball ready? I'd like to set up my own cronjob that merges the buildd output with yours
<carlos> pitti, I think production has control-center already but the mirror is done around 2:00 A.M. (in our time zone)
<carlos> pitti, hmm, not sure, I will launch it at 4:30 AM
<pitti> carlos: can you set up a symlink like rosetta-breezy-current.tar.gz?
<carlos> pitti, and it takes between 3-4 hours
<carlos> pitti, sure
<pitti> carlos: so a cronjob at 10:00 should be safe?
<carlos> pitti, yeah, I think so
<Kamion> mvo: please just upload stuff, providing that you believe they're sensible for this stage of the freeze; it's much easier to analyse/approve things once they're in the queue
<Kamion> it looks reasonably sensible if you've tested it
<Kamion> mjg59: we don't have sdparm in the archive at all?
<mjg59> Kamion: Yeah. It seems to have hit Debian after syncs were stopped.
<sivang> Hi all
<mvo> Kamion: thanks. I'll do more testing before the upload, but it's mostly obvious fixes
<mhz> Kamion: hi
<mhz> Kamion: will you be around in 4 hours?
<Kamion> mjg59: ok, syncing, will NEW it later
<mjg59> Kamion: Ta
<Kamion> mhz: no, we have a guest round for dinner tonight. Why?
<mhz> Kamion: ogra  suggested you may help me if I continue having TFTP problems (spent 19 hours already)
<ogra> Kamion, i dont know the url for the netboot install howto from the top of my head, i thought you would know it
<mhz> tftp to install unbuntu from a ubuntu server to a thin laptop that boots PXE ok
<Kamion> http://archive.ubuntu.com/ubuntu/dists/breezy/main/installer-i386/current/doc/manual/en/
<Kamion> TFTP stuff is chapter 4.5
<mhz> cool, i'll read it, thou I have read many howtos so far.
<mhz> Kamion: thx
<ogra> mhz, but thats the right one :)
<mhz> LOL
<mhz> I hope so, real badly
<mhz> because this is the laptop I'm gonna be using for Ubuntu/Edubuntu/Kubuntu presentations
<mhz> (and using the default MS200 really sucks)
* lamont__ test kbd-chooser headless
<mjg59> Kamion: Can I upload an acpi-support that fixes the sleep key whitelisting support, fixes resume when the machine is asleep for longer than a few minutes and doesn't print nasty errors on SATA machines?
<Kamion> mjg59: yes
<mjg59> Kamion: Thanks
<Kinnison> seeeeeeeeeeeeeeeeb!
<Kinnison> seb128: Unfortunately, my apps menu seems to be lacking in gedit goodness
<Kinnison> seb128: and the menu editor doesn't list it either
<mhz> Kamion: BTW, all this hours spent ONLY 'cos afaik, there's no way to boot from PCMCIA CD drive, or is there??
<Kinnison> seb128: which is odd, 'cos I have gedit open over |/_ there
<Kamion> mhz: depends on your hardware
<mjg59> mhz: You can only boot from a PCMCIA cdrom drive if your machine supports it
<lamont__> smurf: 
<mhz> bios level?
<lamont__> Oct  4 15:47:30 kbd-chooser[3361] : ERROR **: kbd-chooser: cannot open file No keyboard to configure
<lamont__> Oct  4 15:47:30 main-menu[2862] : WARNING **: Configuring 'kbd-chooser' failed with error code 1
<lamont__> Oct  4 15:47:30 main-menu[2862] : WARNING **: Menu item 'kbd-chooser' failed.
<ogra> mhz, thats a BIOS thing
<mhz> tsktsktsk! no bios option for that :(
<mhz> well, the positive side of this story is that I'll endup wikin a howto local netboot install from edubuntu onto thin laptops  :D
<Kinnison> seb128: keybuk told me to bug you :-)
<seb128> Kinnison: about what?
<seb128> oh
<mhz> Kamion: ogra: BTW, is it ok if I export this document to Moin wiki format?? or I'll be doubling efforts.
<seb128> Kinnison: do you have a /usr/share/applications/gedit.desktop ?
<smurf> lamont__: bah, I didn't get that this morning
<lamont__> smurf: moving the kbd-chooser inside the if makes things happier too.....
<ogra> mhz, ist fine, i dont think there is a wiki version of it yet... but make sure to keep it up to date
<Riddell> Kamion: can I upload a small amarok fix?  http://muse.19inch.net/~jr/tmp/amarok.diff
<Kinnison> seb128: yes
<jordi> jbailey: ping
<seb128> Kinnison: gnome-menu-spec-test | grep gedit ?
<Kinnison> no output
<Kamion> mhz: no, I'd really prefer you not to
<lamont__> smurf: let me push it back up to the top of the hill one more time, and see what I can see.
<jbailey> jordi: pong
<smurf> lamont__: sure
<seb128> Kinnison: ls ~/.local/share/applications/ | grep gedit 
<mhz> ogra: oh, then maybe it is not worth the try, because Moin does have version controling, when it is wiki work. I don't imagine how to uptodate with html files.
<mhz> Kamion: ok
<jordi> jbailey: how's glibc doing?
<jordi> jbailey: does your pending upload contain kurdish stuff?
<Kinnison> seb128: gedit.desktop and gedit-usercustom.desktop
<jbailey> jordi: good, yes.
<jbailey> jordi: It'll be cooked by the end of the day.
<jordi> jbailey: I mailed you a file, please check it matches what you have in your tree
<jbailey> jordi: Do you want me to use what your is?
<jbailey> jordi: (When did you learn to speak kurdish? *g*)
<Kamion> ogra: we'd never be able to keep it in sync properly
<seb128> Kinnison: I bet that this gedit.desktop has a NoDisplay=true
<jordi> jbailey: the Kurdish dude sent it, DUDE
<Kamion> Riddell: yes
<jordi> jbailey: I hope it will be the same as you have now, but just in case.
<Riddell> Kamion: thanks
<ogra> Kamion, ah, yes... thats why i notified mhz about that... 
<Kinnison> seb128: So it does. Now. (1) How did it get there, and (2) how is a normal user meant to fix this?
<lamont__> smurf: Your keyboard is: No keyboard to configure
<lamont__> highlighted selection is: Find your layout by pressing some keys
<lamont__> "select from a complete list" immediately fails
<seb128> Kinnison: (1) gnome-vfs/nautilus had a such bug, (2) that doesn't happen a lot and should not happen with current version ... for other people I guess bugzilla it
* smurf grumbles in kbd-chooser's direction
<Kinnison> seb128: right
<Kinnison> seb128: so I should just rm it?
<Kamion> smurf: the QUIT state goes into keymap_set()
<seb128> Kinnison: correct
<Kamion> smurf: perhaps you should just exit(0) or something
<lamont__>  ERROR **: kbd-chooser: cannot open file console-keymaps-none/keymap doesn't exist
* mhz days sleeps
<Kinnison> seb128: yay, you win a $beer
<seb128> Kinnison: cool :)
<lamont__> smurf: truthfully, this doesn't need to get fixed for breezy
<smurf> lamont__: it's still a bug. Bugs tend to annoy me on principle, especially when I test stuff (like this morning) and they *still* happen. :-/
<jdub> tseng: beagle 0.1.1 already - you rock!
<lamont__> smurf: true... not like anything needs that installer step to succeed though, and it seems to work just fine on head-ful systems
<lamont__> hence not really worth the risk to the release to do an upload of that right now.
<dholbach> hey carlos
<dholbach> carlos: how are you?
<smurf> lamont__: Well, I can put it onto my todo list, next to "tell the decision tree generator to use X keymaps instead of console ones" and "re-do the decision logic so that I can drop the 'do you have this key' dialogs" I already have for Dapper
<sivang> ploum: ping, re: 16931
<sivang> ploum: right click the workspaceswitcher applet, do you see there is no seperator between "Help" and "Get Help Online" ?
<pitti> daniels: still here?
<lamont__> thansk
<sivang> hey pitti 
<pitti> Hi sivang 
<segfault> is there any plan to release today a new langpack?
<daniels> pitti: mmm?
<bddebian> Anyone know/think that bringing in new libofx and aqbanking versions will break anything?
<pitti> daniels: https://launchpad.net/distros/ubuntu/breezy/+translations
<pitti> daniels: that should come close to what you asked for
<daniels> pitti: rockin', thanks
<fabbione> daniels: dude.. where is mkdirhier? ;)
<fabbione> daniels: i thought you were going to include it in the last xorg upload
<Kamion> Keybuk: re hotplug, isn't a minute and a half a bit long to wait for interfaces to come up?
<sivang> mjg59: ping
<Keybuk> Kamion: well, 60 seconds is the dhcp timeout
<mjg59> sivang: Hi
<Keybuk> and that wait is only *if* it really is trying to bring one up
<Kamion> oh
<Keybuk> the net.ifup timeout is 120 seconds
<Kamion> sucky
<sivang> mjg59: I'd like to ask some about another performance loss from latest upgrades, which wasn't before
<Keybuk> so I picked something half way between the two
<Keybuk> if you don't have any hotplug interfaces (ie. not present, or all auto) it won't wait at all
<mjg59> sivang: I'm not certain I'm the right person to be asking
<Keybuk> because the net.busy file it looks for is forced removed in S:S40hotplug and doesn't get created until a hotplug event is about to start
<Kamion> Keybuk: hm, right
<sivang> mjg59: last time I saw something like that it was related to "one channel for both hd and optical drive" on dell 
<Kamion> ok, approved, we'll see what happens
<sivang> mjg59: so I figured maybe it's related to the fact I am on a laptop
<mjg59> sivang: I have absolutely no idea what you're talking about, I'm afraid
<sivang> mjg59: can we take it private somewhere? (if you have the time, ofcourse)
<Keybuk> Kamion: I tested the bits thoroughly individually, and then started running it on my laptop (which has the ntpdate problem every time) and it does the right thing
<mjg59> sivang: No, if it's a development issue it belongs here. If it's not a development issue, I'm unsure why I'm the person to be talking to
<sivang> mjg59: k
<sivang> mjg59: but I suspect this is related to the fact I'm on a laptop, I don't feel this slow down on my desktop, but well, I can probably live with it.
<pitti> Kamion: does it still make sense to translate d-i parts in Rosetta?
<pitti> Kamion: quite few of the dialogs and strings are shown in English
<Kamion> pitti: I updated a number recently; we are now past the non-langpack translation deadline
<Kamion> pitti: any particular ones, in case I just missed the updates from Rosetta?
<pitti> Kamion: no, no particular ones; just my general impression
<Kamion> well, I need examples or I can't check :)
<mjg59> sivang: If you can narrow it down to a specific upgrade, that would be helpful
<Kamion> de: 940 translated messages, 26 fuzzy translations, 8 untranslated messages.
<Kamion> hmm
<seb128> Kamion: and for fr?
<sivang> mjg59: I'm afraid I can't, sorry for the lack of information.
<Kamion> fr: 971 translated messages, 1 fuzzy translation, 2 untranslated messages.
<seb128> thanks
<seb128> let me know if you plan another update, I'll translate those 3
<mdke> does anyone know what package the update-manager strings are in in rosetta?
<pitti> carlos: how can I become an official translator of something?
<Kamion> seb128: the fuzzy and one of the untranslated are bogus, not sure why
<Kamion> seb128: the other is in cdebconf
* Kamion beats up installer-po
<seb128> k, thanks
<pitti> carlos: I wanted to add some missing translations to gnome-volume-manager, but I can't
<Kamion> oh, I forgot to upload archive-copier
<pitti> smurf: can you register me as German translator?
<Keybuk> Kamion: no real progress on that cdrom-detect bug yet
<Keybuk> it looks like he has one of those weird IDE controllers that thinks it's SCSI
<mdke> anyone know? Is update-manager translatable via rosetta?
* bddebian has no clue as usual
<mvo> mdke: it should be, yes
<mdke> mvo, what package would it be in, do you know?
<Kamion> pitti: most of the visible German ones are probably in base-installer, which has no updates in Rosetta; I could probably backport them from Debian but it would take a while ...
<pitti> mvo: I didn't find a template
<mvo> mdke: oh, it should be update-manager. carlos, is it imported ?
<mdke> it's not there
<pitti> Kamion: well, never mind; no need to add something to your workload
<mvo> pitti, mdke: there was a problem some days ago with the import, maybe carlos knows more?
<Diziet> pitti: Yes, what did you want ?
<mdke> mvo, hope so. There is an update-notifier in hoary, but nothing in breezy
<pitti> Diziet: nevermind, I already found the reason (obsolete u-docs package on live CD caused missing ffox start page)
<mvo> mdke: both "update-manager" and "update-notifier" are not availabe? bad :/
<seb128> Kamion: cdebconf has 100% of fr translations according to rosetta 
<mdke> mvo, correct. jordi, any ideas?
<smurf> pitti: https://launchpad.net/people/ubuntu-l10n-de/ => "Join the team"
<pitti> smurf: I already did that
<pitti> smurf: but AFAICS you are the one to prod about ack'ing?
<jordi> (sorry, phone)
<smurf> pitti: Ah. in that case, (a) I didn't get an email from launchpad, (b) since a few days it doesn't show the list of proposed members any more
<mdke> k
<smurf> pitti: I'll ask on #launchpad what the problem is
<pitti> smurf: thanks
<smurf> pitti: what's your username there?
<Kamion> seb128: updated after the deadline
<mdke> smurf, https://launchpad.net/people/ubuntu-l10n-de/+members
<mdke> smurf, he's there :)
<pitti> smurf: well, I requested the addition in the moment I pinged you
<pitti> smurf: pitti
<seb128> Kamion: k
<smurf> mdke: ah, thanks
<mdke> that is a lot of members :)
<smurf> pitti: done
<pitti> smurf: thanks
<smurf> I seem to have had webcache problems, that list was cut off :-/
<pitti> mvo: update-notifier is at 100% German translation now :-)
<mvo> pitti: nice!
<mdke> pitti, how did you do that?
<mdke> we would love to have it translated in -it
<pitti> mdke: just added the rest to Rosetta
<mdke> pitti, you found the template for breezy?
<pitti> mdke: yes, it's not exactly hidden
<pitti> mdke: erm, notifier != manager
<mdke> pitti, well me and jordi can't see it
<mdke> search "update" on the page https://launchpad.net/distros/ubuntu/breezy/+lang/it
<mdz> morning
<mdz> Kamion: feel free to unseed nic-r-m
<Kamion> -msgstr "Tlcharger de quoi supporter votre langue?"
<Kamion> +msgstr "Tlcharger le support de language ?"
<Kamion> seb128: which is better? the former's yours, the latter's from Rosetta
<Kamion> mdz: ok
<pitti> Hi mdz 
<seb128> vuntz: opinion on that? :)
<seb128> hi mdz
<mdke> pitti, damn, you have it in german but we don't have it in italian :)
<mdz> mdke: has it already been translated, or not?  there seemed to be some disagreement
<mdz> jdub: what's up with the lists.u.c archives?  there's nothing for october
<sivang> hmm, I now wonder if what made my edimax card work is nic-r-m 
<mdke> mdz, you mean that string on ubuntu-docs?
<mdz> mdke: yes,  the one you asked me about
<mdke> or update-manager
<mdke> mdz, ok, the position is that the string as it currently is, has not been translated.
<jdub> mdz: checking into it tonight
<mdz> mdke: if it hasn't been translated, there's no reason not to change it
<mdke> mdz, cool. The further question, which Kamion raised, is what to change it to
<mdz> mdke: starter guide
<mdke> mdz, if we use Ubuntu FAQ Guide, it is possible that we can use the existing translation of the title of the guide to localise that string. if we use "starter guide" (better title), we won't be able to localise the string, unless it is put up for translation now/later
<seb128> Kamion: since vuntz doesn't reply, I would pick my version :)
<jdub> mako: ping
<Kamion> seb128: ok
<mdke> mdz, starter guide it is? i'm happy with that if you are
<Kamion> also Rosetta flattens non-breaking space 0xA0 to space 0x20 in French translations. grumble
<Riddell> infinity: are you able to grant documentation group SVN access?
<seb128> Kamion: all the unbreakable spaces?
<seb128> carlos: is that known?
<vuntz> seb128, Kamion: "Tlcharger le support pour votre langue"
<Kamion> seb128: obviously I haven't checked exhaustively, but it seems to - unless translators have been adding text to Rosetta without 0xA0
<seb128> Kamion: that's would not be a surprise, you have to use compose to do that and I'm not sure that a lot of people know that
<seb128> anyway
<Kamion> seb128: these ones should have been imported from the correct versions in the package, though
<seb128> Kamion: vuntz' version is nice, pick this one if you have not made the change yet
<Kamion> done
<seb128> Kamion: I'll ping carlos about that
<seb128> thanks
<lamont__> buildLogs/e/evolution-data-server/1.4.1-0ubuntu1/evolution-data-server_1.4.1-0ubuntu1_20051003-2247-ia64-successful.gz:Function `isodate_from_time_t' implicitly converted to pointer at e-cal-backend-http.c:877
<lamont__> buildLogs/g/gnome-media/2.12.O-0ubuntu1/gnome-media_2.12.O-0ubuntu1_20050905-0110-ia64-successful.gz:Function `gnome_vfs_mime_type_from_name' implicitly converted to pointer at audio-profile-choose.c:61
<lamont__> buildLogs/g/gnome-pilot/2.0.13-0ubuntu9/gnome-pilot_2.0.13-0ubuntu9_20050926-1010-ia64-successful.gz:Function `crypt' implicitly converted to pointer at gpilotd.c:541 Function `crypt' implicitly converted to pointer at make-password.c:76
* lamont__ grumbles at seb
<lamont__> seb128 even
<pitti> Kamion: btw, if you need a German example: the dialogs for entering user name and the first password are completely untranslated
<mdz> mdke: I think "FAQ Guide" is confusing
<seb128> lamont__: utch
<mdke> mdz, me too
<mpt> hurrah
<jordi> could very well be a mozilla bug too
<Kamion> pitti: no update available for pkgconf-shadow in Rosetta
<jordi> I remember mozilla broke non-breaking spaces in the past
<desrt> seb128; did you or davyd reply, yet, to my email?
<Kamion> pitti: if you translate it really quickly, I can update it
<Kamion> since apparently that's one I missed anyway
<lamont__> seb128: not that they _need_ to be fixed for release, but they are definitely bugs
<seb128> desrt: we spoke about it on IRC, he has the issue too and we didn't figure what's wrong
<pitti> Kamion: right; however, I wondered because it was fully translated in Hoary, and I didn't see obvious changes
<mdke> mdz, ok starter guide it is. We'll try and build the string into our rosetta template just in case there is a possibility of uploading language updates after release
<seb128> lamont__: right
<desrt> seb128; k.  just trying to figure out if i'm lost email (both of my mailservers in two separate countries went down simultaneously)
<Kamion> pitti: well, those dialogs all changed upstream
<pitti> ah, ok
<seb128> desrt: davyd replied that it works for him, I replied to that and we continued on IRC
<desrt> ah
<desrt> so i am missing mail :(
<desrt> thanks
<mdz> mjg59: I thought we got the ata passthrough patch in, which was what we needed for hdparm?
<mjg59> mdz: You said that it was too big
* jdub was able to do some ata passthrough bits on his server
<mdz>   * drivers-scsi-libata-passthrough: Support for ata passthrough with hdparm
<mdz>     and smartmon tools. (Closes: #14931)
<mjg59> Oh. Uhm.
<mdz> linux-source-2.6.12 (2.6.12-9.19) breezy; urgency=low
<mjg59> Right, sorry - I thought we'd agreed not to do that.
<mjg59> Do you want me to do a 0.45 with that enabled again?
<mdz> mjg59: hmm, good question
<mdz> having hdparm working again is one thing, and poking at it by default when we haven't been testing that is another
<mdz> is it easy for people to re-enable it if they have an SATA laptop?
<mjg59> At the moment they have to uncomment some lines in /etc/acpi/power.sh
<pitti> Kamion: I update them in Rosetta, it can't hurt anyway
<mdz> let's leave it, then. let them enable it if they want to find out whether it works
<mdz> I've approved 0.44
<ploum> sivang, re 16931 : yes, I see a separator between them
<pitti> Kamion: done
<Kamion> pitti: thanks
<sivang> ploum: on both top and bottom ?
<lamont__> mdz: speaking of kernels...
<ploum> sivang, well it's just like others apps
<mdz> Kamion: when do you plan to do the final d-i upload for RC?
<ploum> sivang, the only difference is that I have a "preference" at the top (on top of Help)
<mdz> we should start building RCCs no later than tomorrow afternoon
<Kamion> mdz: tomorrow morning
<sivang> ploum: and you have TWO seperators that distinguish the "Get help oneline" and "Translate this application" ?
<Kamion> updates today are only non-initrd and safe translation-only changes
<sivang> ploum: from the rest of the items on the context menu?
<Kamion> hmm, maybe s/and/or/ there would be clearer
<ploum> sivang : no
<Kamion> either not in the initrd, or translation-only
<ploum> sivang, I take a screenshot, it will be easier
<sivang> ploum: sure, thanks
* lamont__ notes that ppc is the slowest d-i architecture: debian-installer:       00:05:59 (341 entries, sigma 00:02:15)
<ploum> sivang, http://ploum.fritalk.com/multidesk.png
<sivang> ploum: dude, six desktops?  :)
<ploum> sivang, 8
<sivang> hmm, I should learn to count
<ploum> :p
<smurf> mdz: What's a RCC? Release Candidate Candidate?
<sivang> ploum: anyway, you were right. I wonder if this is some weird left over from me hacking on gnome-panle to include lpi
<ploum> sivang, you are welcome
<Keybuk> sivang: I have 12
<sivang> Keybuk: :)
<Keybuk> e.g. in http://www.netsplit.com/tmp/Screenshot.png
<jdub> Riddell: ping
<jdub> jordi: ping
<jdub> ogra: ping
<sivang> Keybuk: wow
<ogra> jdub, pong
<sivang> Keybuk: what's that packect.c file you are hacking on?
<Keybuk> part of the app in the top-right window
<Riddell> jdub: hi
<Keybuk> which is being debugged in the bottom-left
<Keybuk> uh, bottom right
* Keybuk /really/ can't do left and right
<sivang> Keybuk: what does it do?
<Keybuk> sivang: if the window at the top-right doesn't make sense on first sight, it's hard to explain :)
<Keybuk> it's a timing screen for an F1 race
<mjg59> seb128: I moved a file on a usb stick to trash. Opening the trash applet shows it, but the applet claims that there's no trash and I can't empty it
<Diziet> kamion/mdz: I would like to upload fontconfig to fix 16905 (wrong path for X11 fonts).  I trust that's OK ?
<Keybuk> and yes, I use emacs
<Diziet> I have done a test build, of course, and it works.
<mdz> Diziet: one-liner?
<sivang> Keybuk: that's ok, I like emacs very much. Although when in lack of resources and need of speed, I use vi :)
<jordi> jdub: pong
<mdz> or otherwise trivial pathname substitution?
<Keybuk> sivang: yeah, I use vi as an editor, emacs as an IDE
<seb128> mjg59: seems to be a notifu
<seb128> notification issue
<mdz> Diziet: if so, yes, if not , send a debdiff
<mjg59> seb128: Ok. I couldn't find a bug filed - shall I add one?
<Diziet> mdz: Yes.
<Diziet> I've looked at the debdiff myself.  I'll upload it now.
<seb128> mjg59: if you can get it on will yep
<seb128> mjg59: if that happened once and you have no gamin log or something like that's it's not really useful
<mdz> smurf: yes
<mjg59> seb128: Well, is it something that you're currently tracking?
<seb128> mjg59: no, we have no bug about that atm
<Nafallo> I just had a question from one of our users that has a webhotel. what is "server" and what is "client" for dapper. i.e. what parts have 3 years support?
<seb128> mjg59: is your system uptodate? gnomevfs/nautilus 2.12.1 are supposed to have some fix for that
<mjg59> seb128: Ah - it's from last week. I'll try an update.
<seb128> let me know if you still get that with the current versions
<jdub> mjg59: got my /msg?
<mako> jdub: oh oh
<mako> jdub: did i catch you?
<jdub> mako: oh!
<jdub> mako: just sent you email *right then*
<mako> does this pertain to your imminent arrival in my fair city?
<jdub> it does
<jdub> was just about to do hotel stuff when i saw your wiki update
<mako> jdub: need a place to crash?
<jdub> ja!
<mako> jdub: you have one
<jdub> yay!
<mako> bUT
* jdub packs vegemite
<mako> we should throw an ubuntu party
<mako> at my place
<jdub> yeah!
<jdub> though i won't be there for the 13th
<mako> if we use all rooms, its unlikely that my place will hold more than 40
<jdub> 7th-11th
<mako> we had 25 in the biggest room
<mako> it was tight but worked
<fabbione> hey mako
<jdub> mako: which night do you want to do the partay?
<mako> we get sabdl to buy a keg and we're set :)
<mako> fabbione: hey there :)
<mako> jdub: i'm hosting two others already.. i have three proper sleeping places including the couch
<mako> jdub: i might host one or two more on the floor if they have a sleeping bag
<mako> jdub: http://www.aceatrium.com
<mako> jdub: sorry http://www.acetarium.com
<jdub> heh
<infinity> Riddell : I dunno, are you?
<Riddell> infinity: ignore me
<mako> jdub: so.. what day do you think would be ideal?
<pitti> doko: ping
<mako> jdub: should i give luis a call? i already pinged him about it but he didn't get back to me yest
<jdub> mako: 8th or 9th
<jdub> mako: how about 8th for maximum not-at-work-tomorrow value?
<jdub> mako: ha ha ha re: cost benefit
<carlos> seb128, hi, I'm not aware of that problem...
<ivoks> pitti: hi you were right... gnome-cups-add hal://%h doesn't work :/
<sivang> ivoks: trying to fix cupsys bugs?
<ivoks> sivang: not really :)
<ivoks> sivang: but i was thinking about investigating that...
<pitti> sivang: that one was about g-v-m
<carlos> dholbach, pitti gnome-backgrounds is not generating the .pot file
<dholbach> carlos: oh, ok - same reason for gnome-mag?
<pitti> carlos, dholbach: cdbs gnome.mk's magic doesn't work for arch:all packages
<sivang> pitti: btw, mdz didn't agree for patching cupsys that late in the cycle, which is understood, so we probably need a BOF for that issue with cupsys and some more enhancments
<sivang> pitti: to have for dapper
<pitti> sivang: yes
<carlos> dholbach, gnome-mag has it, let me check why is not yet imported...
<ivoks> :/
<seb128> dholbach: you said it was yesterday no? (gnome-background)
<dholbach> seb128: yesterday i couldnt find the translations, yes
<seb128> dholbach: but you got a .pot after the build no? carlos said <carlos> dholbach, pitti gnome-backgrounds is not generating the .pot file
<Diziet> The usplash font is still the ugly one.
<carlos> seb128, gnome-background is not generating it so I don't get the .pot 
<dholbach> seb128: i think so, will re-check
<Diziet> And the firefox start page still has no css.
<dholbach> no... grmbl
<sivang> Diziet: so is the epiphany one
<Diziet> Isn't it the same page ?  `About Ubuntu'.
<sivang> Diziet: oops, right
<mdz> seb128: do you have the bug# for the boot-admin vs. menu.lst bug?  it wasn't in your changelog and dupes are still being reported
<seb128> mdz: #13584  #15638 
<mdz> 15638, thanks
<seb128> np
<pitti> seb128: librsvg2 builds fine with firefox-dev instead of mozilla-dev; would there be anything wrong about it?
<seb128> pitti: no, dholbach did that when syncing from Debian but we said than mozilla is main anyway so we didn't bother changing
<seb128> pitti: I've a pending upload with 2 patches, I can change that too if you want
<seb128> s/with/for/
<pitti> seb128: would be nice, but only if it is safe
<pitti> seb128: it is one of three packages that keep mozilla-browser in main
<seb128> pitti: are we moving it to universe before 5.10? what are the 2 other packages
<pitti> this got out of my attention unfortunately, so I fear we need to keep moz in main for breezy
<seb128> pitti: if we have to keep it for the 2 other, no point to do it now, I'll do when we open dapper
<pitti> but at least we should really, really kill it off for dapper
<seb128> yah
<seb128> yeah
<pitti> seb128: enigmail seems doable, OO.o is unknown
<pitti> seb128: ideally I'd like to drop the moz-dev dependency to mozilla
<pitti> seb128: and just add the required files from moz to m-dev
<pitti> seb128: so that OO.o can build without -browser
<pitti> oh, phone, cu later
<carlos> dholbach, the problem with gnome-mag is in my side, I will try to get it fixed today
<dholbach> carlos: thank you, i'll take care of gnome-backgrounds
<dholbach> thanks carlos, pitti, seb128 :)
<seb128> carlos: do you have gnome-applets now?
<carlos> seb128, it's being imported atm
<mdke> carlos, did you see the bitching about update-manager earlier? any idea about that?
<seb128> carlos: cool, it has been fixed today, just making sure :)
<carlos> seb128, thanks
<seb128> carlos: do you have a list of desktop packages to fix ?
<seb128> thank *you* :)
<carlos> nomeata, I don't (other than update-manager)
<carlos> fucked xchat...
<carlos> s/nomeata/no/
<carlos> mdke, let me check..
<seb128> cool, thanks
<carlos> seb128, about the non breakable spaces change... any URL from where I can check that?
<zyga> Kamion: hi
<seb128> carlos: ask Kamion, he pointed that
<zyga> Kamion: do you have a moment
<ogra> zyga, he left for the evening i think
<carlos> seb128, pitti, mdke update-manager is not generating the .pot file that's why It's not imported
<carlos> Kamion, ?
<carlos> oh
<carlos> ogra, ok
<zyga> ogra: too bad
<zyga> I wanted to talk with someone about ruby issue
<seb128> zyga: mail the list
<ogra> zyga, come on... he works more than 12h a day :) leave him a bit of spare time ;)
<zyga> ogra: yeah I know :)
<ogra> zyga, just do as seb128 suggested :)
<zyga> seb128: I'm not sure how to explain the problem - that's why I preferred to talk
<mdke> carlos, i think it is mvo's package
<mdke> maybe he can fix that
<zyga> carlos: hi
<zyga> carlos: I hacked update-manager a bit, can I help?
<carlos> mdke, I know, but mvo is not online and pitti and seb128 already fixed that kind of problems
<seb128> carlos: I'll have a look
<mdke> carlos, awesome if they can
<carlos> zyga, not sure, we need that the .pot file is generated on build time so the automatic bridge to Rosetta works
<carlos> seb128, thanks
<seb128> np
<zyga> carlos: just a moment, I'll have a look
<zyga> carlos: you are talking about dpkg-buildpackage 'build time' right?
<carlos> zyga, I suppose, pitti and seb128 know the details
<zyga> carlos: fixed
<zyga> carlos: the source currently in the repository has a one-line bug
<carlos> zyga, cool, thanks
<zyga> remove gnome-software-properties.desktop.in from po/POTFILES.in
<zyga> it's no longer used and it's causing the pot build to fail
<zyga> I cannot commit this, sorry :)
<zyga> a regular cd po && make update-po works then
<zyga> hmm....
<zyga> is mvo going to be here today?
<seb128> zyga: why do you need him right now?
<zyga> seb128: I've noticed that something strange happened to the source
<zyga> seb128: the issue with potfiles was already fixed
<seb128> zyga: ?
<zyga> (we fixed it before)
<seb128> what package?
<zyga> update-manager
<seb128> it doesn't update the potfile
<zyga> yes
<seb128> and the POTFILE list a file not shipped with the package
<seb128> but that can wait 1 hour
<seb128> please be patient
<schimmi> I wanna debug an acpi suspend problem. any pointer how to debug it if it just crashes on wakeup (no display, not net, no nothing, just running fan) ?
<seb128> mvo will fix it when he's around
<seb128> or I'll fix it after dinner if he's not here
<seb128> anyway time for dinner, bbl
<zyga> seb128: you mean POTFILE should be shipped?
<seb128> it is
<zyga> cheers seb128 
<seb128> the package has it
<carlos> seb128, having dinner now? so late??? you are not a real french :-P
<seb128> anyway, bbl
<seb128> carlos: ah ah
<zyga> I know - I don't understand ... nevermind
<carlos> seb128, pitti, mdke, going out to have dinner, if you need anything send me an email and I will take a look when I'm back
<carlos> later!
<dholbach> do we support jigit/jigdo at any rate?
<ogra> dholbach, nope
<ogra> dholbach, there was a mail from Kamion bout it iirc
<ogra> last week or so...
<dholbach> ogra: ok, because of #16763
<ogra> dholbach, the fix makes sense... though
<dholbach> ogra: yeah, but the pointing to a site is a bit problematic in our cas e:)
<dholbach> herzi: fixed libgsf should be in the archive soon
<ogra> dholbach, true...
<herzi> dholbach: great
<dholbach> ogra: i'll have a look out for that mail, thanks
<herzi> that you VERY much
<ogra> dholbach, :
<ogra> > Would it be possible to provide official jigdo templates for breezy
<ogra> > for dvds of universe and multiverse? I know a lot of people who would
<ogra> > really appreciate this.
<ogra> It's unlikely to happen officially (the cdimage machine is already quite
<ogra> busy, and jigdo-ing things takes ages), but I welcome efforts to do it
<ogra> unofficially.
<ogra> thats Kamions answer
<ogra> ;)
<dholbach> merci
<ogra> but its a bit odd that we have th ejigdo files on cdimage if we dont support it
<ogra> imho
<dholbach> yes
<dholbach> 250k :)
<Riddell> mdz, Kamion: can I upload a new kubuntu-docs, the version that's in there is horribly out of date
<mdz> Riddell: just doc updates?  will it break translations?
<Riddell> mdz: they arn't translated
<sivang> ploum: ping, still here?
<mdz> Riddell: if they are only docs and no code changes, and they aren't translated, then it's fine
<Riddell> mdz: yes, no code changes
<Riddell> except removing the user guide since that won't get finished in time
<hno73> mdz, Kamion: I'm uploading a new tarball that is exactly 100MB: OOo2, Firefox and Gaim
<hno73> I guess we could save another 10 MB by going with OOo 1.1.5
<hno73> which is the official stable release, but ...
<wasabi__> jbailey, ping
<ploum> sivang, yep
<wasabi__> having some pretty bad initramfs probs, hope something isn't broken. :0
<sivang> ploum: can you plesae open AisleRiot (GNOME game) and look up the lp items?
<ploum> sivang, no problem in aisleriot
<sivang> ploum: two seperators? :)
<ploum> no !
<sivang> ploum: can you put up a screenshot ?
<ploum> yep
<ploum> http://ploum.fritalk.com/aisleriot.png
<sivang> ploum: cool then, everything's fine.
<sivang> ploum: thanks
<ploum> sivang, you are welcome
<jbailey> wasabi: pong
<dholbach> mdz: were you presented with syncing "supah-powahs" too? i just remember that Colin got them in James' absence
<ogra> dholbach, mdz too (referring to Kamion)
<dholbach> ogra: merci
<dholbach> mdz: if you should find the time, if not it's not tragic, could you please sync gftp from sid? (we didn't make modifications, so that should be fine), rationale is the fixes listed on http://packages.debian.org/changelogs/pool/main/g/gftp/gftp_2.0.18-10/changelog
<thesaltydog> dholbach, http://packages.debian.org/changelogs/pool/main/b/baobab/baobab_1.2.0-1/changelog.html
<Riddell> mdz: can I upload an updated kubuntu-meta?  it adds usplash artwork
<bddebian> Riddell: Got any thoughts on kmymoney2 and all the associated stuff (libaqbanking, libchipcard2, etc)
<bddebian> :)
<Riddell> bddebian: what's the question?
<Riddell> they had a new release didn't they
<bddebian> Riddell: There is a Malone bug to update the version
<bddebian> Same for gnucash
<bddebian> Both need newer libchipcard2, libaqbanking, etc
<Riddell> bddebian: anything else rdepend off those?
<bddebian> Oh yeah, they need newer libofx too :-)
<ogra> Riddell, you dont have the usplash in yet o_O 
<Riddell> ogra: why not?
<bddebian> Riddell: Not for libchipcard2
<Riddell> sorry, read that wrong
<ogra> Riddell, that was a question :)
<ogra> Riddell, in edubuntu its already there since some days
<ogra> i was just astonished :)
<bddebian> OMG, it's a never ending stream of updates... libaqbanking, libaqhbci, libofx, libchipcard2..
<Riddell> bddebian: sounding dangerous
<bddebian> Riddell: Nah, sounds "fun" ;-)
<mdke> i've just dist-upgraded to breezy and the language-selector is not present :/ any ideas what is wrong? shall i file a bug
<thesaltydog> mdke, install ubuntu-desktop
<mdke> hmm
<thesaltydog> mdke, I had the same problem
<mdke> the dist-upgrade didn't go well, there are some more things to install
<mdke> will do it now
<mdke> thanks thesaltydog 
<thesaltydog> mdke, yes. should be a guide somewhere. Why don't you work on it?
<ogra> mdke, always make sure the -desktop package is there if you upgrade between releases, it eases the pain ;)
<ogra> eases == solves most of the issues
<mdke> ogra, yeah... although that shouldn't be
<thesaltydog> ogra, it looks like dist-upgrading to breezy the -desktop package disappears..
<mdke> yeah i'm pretty sure I had -desktop installed
<ogra> mdke, sure it should and its stated in every upgrade notes since warty
<thesaltydog> ogra, c'mon, don't joke...
<mdke> ogra, well as Kamion said once, it shouldn't be necessary to have -desktop to have a clean upgrade
<ogra> thesaltydog, maybe because some pre depnds are not ready yet
<mdke> but anyway, I had -desktop installed yesterday
<mdke> thesaltydog, is there a bug open about this?
<mpt> mdke: there is a BoF proposed about it
<thesaltydog> mdke, I'm not sure it is a real bug.. maybe a lack of documentation
<ogra> mdke, if you want all the new and shiny stuff, you'll need it... lang-selector wanst there in hoary... -desktop cares for it
<thesaltydog> mdke, you need also to install gnome localization packages
<mdke> ogra, i repeat, for the 3rd time, that I had -desktop installed before the upgrade started
<thesaltydog> the language-pack has been splitted
<ogra> mdke, indeed its shouldnt matter for a simple package upgrade 
<mdke> thesaltydog, yeah that is documented
<ogra> mdke, and i repeat the second time that some pre dependencys might be broken currently... 
<thesaltydog> what can I say for the 4th time?? :-)
<ogra> thesaltydog, be creative ;)
<mdke> oh well
<mdke> dist-upgrade is a nightmare at the moment
<mdke> hopefully it will be better for the RC
<ogra> mdke, if you watched the upgrade (i usually dont) you would have seen what made it disappear
<mdke> ogra, yeah i didn't have time to follow it
<mdke> oh well, if it is a bug then i guess the reports will come in
<thesaltydog> ogra it should be a way that warns user if -minimal , -base or -desktop metapackages are removed or going to be removed..
<ogra> mdke, to be safe in such cases, dont dist-upgrade, just upgrade ;)
<mdke> ogra, from hoary to breezy I shouldn't dist-upgrade???
<ogra> thesaltydog, apt does that, but you need to attend the upgrade
<ogra> mdke, not if something might be in a broken state
<ogra> i'm always careful with dist-upgrades...
<mdke> hmm
<mdke> i understood to upgrade to a new version of Ubuntu I needed to dist-upgrade
<ogra> dist-upgrade means apt is allowed to remove stuff to fullfill dependencys
<ogra> upgrade only upgrades
<thesaltydog> ogra, no, I mean one of your beautiful graphical fireworks... Thos that even my mother will understand...
<zyga> hmm
<zyga> why did we get radeontool?
<ogra> mdke, think about the case where ooo is broken but -desktop depends on a certain minimal version thats not in the archive... it will simply uninstall -desktop becaue it cant fulfill the dep...
<ogra> mdke, if you run upgrade instead of dist-upgrade, it just wont upgrade -desktop but leave it in place
<thesaltydog> ogra, in these case, a small flashing icon on the taskbar saying "wooops.. you don't have u-d installed!"
<ogra> thesaltydog, the pc couldalso do some explosion sounds indeed...
<thesaltydog> whay not? Maybe some smoke from the fan..
<ogra> but the simple solution is not to blindly dist-upgrade during development releases ;) 
<mdke> ogra, i dunno much about it, i was just dist-upgrading to breezy as thousands will do in a couple of days
<thesaltydog> oliver, once you told me "make it simpler!" remember? 
<ogra> mdke, for RC all will be fine
<jbailey> Am I the only one annoyed by the slow fade-in, fade-out of the screesaver? 
<ogra> jbailey, yes
<thesaltydog> you really believe that my mom will look at the thousands lines during such a dist-upgrade?
<bddebian> jbailey: Nope ;-)
<pitti> seb128, carlos: ah, update-manager does not use cdbs, nor gnome.mk, I fix the package to produce a pot
<ogra> jbailey, but you can adjust it :) suggest a better default value
<zyga> jbailey: it's nince IMHO
<jbailey> ogra: Adjust it?  Last I checked, there were no adjustments to the screensaver.  Is that new?
<mdke> jbailey, i like it too >_<
<jbailey> 'kay, I'll suck it up and deal then.
<seb128> pitti: mvo is already on it
<mvo> pitti: let me fix it please, there is another small issue pending
<pitti> mvo: ah, so much the better :)
<seb128> pitti: you should be on #ubuntu-desktop, you miss desktop discussions :)
<pitti> seb128: I can't follow more than two channels
<zyga> jbailey: you can patch it to provide an adjustment control 
* zyga hides
<zyga> mvo: hey
<\sh> TB meeting started 7 mins ago?
<seb128> pitti: k
<jbailey> zyga: Nah, I'll just disabled the screensaver.
<zyga> mvo: there is one useless file in POTFILES.in, gnome-software-properties.desktop.in
<zyga> mvo: it's no longer there
<pitti> seb128: I'll join though, maybe my highlights catch some interesting things :-)
<jbailey> zyga: It's not like it serves much purpsoe other than mesmerising me anyway. =)
<ogra> jbailey, its there since warty
<zyga> jbailey: I'd rather like an ability to disable 'login as someone else' button
<ogra> jbailey, you can even switch it off
<zyga> heh 
<zyga> hello ubuntu ;)
<wasabi__> okay evms still no worky
<wasabi__> I am at a loss why not. =(
<jbailey> ogra: It somehow seems worse now.  I have a memory that I could the shift key and start typing in my window right away.  Now it winds up feellike like I break my train of thought wondering why my machine is broken.
<pitti> Kamion: here?
<jbailey> ogra: No worries.  If I'm the only one who's having issues, I'll cope. =)
<ogra> jbailey, feel free to suggest a better value ... 
<wasabi__> jbailey, initramfs starts, md loads, lvm fails to load, evms loads but detects no devices.
<wasabi__> Not quite sure waht's up.
<seb128> pitti: cool, thanks :)
<jbailey> ogra: I have no idea how to discover that value. =(  I freely acknowledge that my use cases are not that common
<jbailey> ogra: I also admit that part of the reason I never used Windows XP is because all the menus faded in.
<ogra> jbailey, in the screensaver settings panel
<ogra> jbailey, extended options
<bddebian> jbailey: Now THAT, I know you can switch off ;-P
<jbailey> ogra: I found it slow and disturbing and it was easier to wind the drive and reinstall than figure out wher eto change it. =)
<zyga> jbailey: you can turn off the fade
<jbailey> ogra: Nice, I see it.  Thanks!
<zyga> jbailey: check advanced options in the screeen saver prefs
<ogra> jbailey, all i want is to make you happy, but i need the value you like for that ;)
<bddebian> :)
<jbailey> "Fondu au noir lors du verrouillage" =)
<wasabi__> Hmmm. =(
* zyga never really knew why something that doesn't fit in a 800x600 dialog window should be placed in 'advanced' when it's really basic stuff 
<jbailey> ogra: The only thing I can suggest is faster than I think, but slow enough for the eye to catch, and I have no idea what that value is. 
<jbailey> wasabi__: Mmm
<jbailey> wasabi__: Are you at a shell prompt, then?
<ogra> jbailey, check if 1sec serves you
<wasabi__> well, i was. not anymore.
<ogra> i can adjust it in the next upload
<wasabi__> live cd
<wasabi__> The funny thing is, at the prompt, I can run evms_activate
<wasabi__> but it detects nothing
<wasabi__> the lvm scripts (when run manually) do properly detect and create /dev/mapper/vg0-root
<jbailey> ogra: Oh.  I see is.  It fading away the screen saver for 1 second and then fading in the desktop for 1 second now?
<wasabi__> but evms_activate doesn't see anything
<jbailey> If that was 2 before, no wonder I was getting frustrated.
<wasabi__> guess I can mount /dev/mapper/vg0-root
<ogra> jbailey, yes, thats wha the spinbutton is for
<jbailey> wasabi__: Hmm
<wasabi__> It might just be an evms bug.
<wasabi__> But if so, it's pretty bad. =(
<jbailey> wasabi__: Are you just looking for lvm volumes managed through evms?
<wasabi__> No. evms has two components. The mapper which can map anything to a name in /dev/evms and the management interface.
<wasabi__> /dev/evms/root is my root, which is mapped to /dev/mapper/vg0-root.
<wasabi__> It's plain ol' LVM beyond that
<wasabi__> I'll brb, going to try to mount root with pure LVM.
<jbailey> wasabi__: Can you see if I included the lvm2 module in there?
<wasabi__> oh, you did.
<wasabi__> lvm works.
<jbailey> No, I mean for evms.
<wasabi__> oh?
<wasabi__> there's such a thing?
<jbailey> In the initramfs look in /lib/evms/2.5.2/*.so
<wasabi__> (is there a way to mount an initramfs???)
<jbailey> wasabi__: mkdir /tmp/foo; cd /tmp/foo; zcat /boot/initrd.img | cpio -i
<wasabi__> doh.
<wasabi__> root@ubuntu:/initramfs/lib/evms/2.5.2# ls
<wasabi__> disk-1.2.10.so  dos-1.1.13.so  lvm2-1.0.2.so  multipath-1.0.2.so
<jbailey> AH, so much for that theory.
<jbailey> I remember not including md because it was huge.
<wasabi__> Hmm. Shouldn't matter though, should it?
<wasabi__> I do use md.
<wasabi__> But evms should't be aware of it really... should it?
<wasabi__> And this is a recent problem.
<jbailey> Right.  That's only if you want evms_activate to assemble your md volumes for you.
<jbailey> wasabi__: Let's check the obious.  The /dev/hd* exists, right?
<wasabi__> yes.
<wasabi__> I'll brb
<mpt> sivang: I don't suppose you want to know that those lpi menu separators are in the wrong place anyway ... ;-)
<sivang> mpt: actually I do, we should fix everything there for dapper :) we shold sit on a beer in UBZ
<mpt> that sounds painful
<mpt> but we can certainly sit in close proximity to a beer :-)
<jbailey> mpt: The trick is to sit *around* the beer.
<jbailey> mpt: It's best done my consuming it.
<jbailey> s/my/by/
<mpt> jbailey: around it like a cat?
<mpt> sivang: https://wiki.ubuntu.com/LaunchpadIntegration?action=AttachFile&do=get&target=app-help-menu.jpg
<jbailey> mpt: I am a vegan, I do not consume cat.
<bddebian> no comment
<mpt> picky
<sivang> mpt: LOLOLO
<wasabi_> root=/dev/mapper/vg0-root works
<wasabi_> hmm kernels are still being built with gcc 3.4?
<bddebian> Yes
<eruin> seems acpi-support just started depending on radeontool from universe...?
<Riddell> seb128: any news on splitting gstreamer-misc?
<seb128> Riddell: I'll ping lool again, but that's really short from 5.10
<sivang> mpt: well, given that, jameh's was actually the one who implemented the layout eventually, and I was sure he was following the spec :-/
<sivang> mpt: sorry for not noting that early enough
<Seveas> mdz, just wanted to know whether you have more comments about my bug-triaging, I really appreciate all the guidance so far
<sivang> jbailey, mpt : in hebrew you say "sit on a beer" , and it's understood as sit around a beer :)
<mdz> Seveas: I haven't finished ubuntu-bugs yet today, but none so far. thanks for your help.
<sivang> tht's why I was consuded
<sivang> err, confused.
<ogra> "It seems that I can no longer activate the bug." i love my bug reporters :)
<Seveas> :)
* Seveas wants a shiny 'activate bug' button :)
* tseng pushes the activate bugs button
<ogra> *g*
<jbailey> I want molly guards for my activate bug buttons.
<gilligan_> hm.. is there a fix for the conflict between libmp4 and libmp4v2-0  ? breaks during unpack trying to overwrite  /usr/lib/libmp4v2.so.0.0.0 which is also in libmp4-0 .. ?
<mpt> <blink>BUG ACTIVATED, PLEASE STAND CLEAR</blink>
<Seveas> mpt, add that to malone and I'll kill you :p
<mpt> Seveas: It'll serve you right for using a browser that supports <blink>
<jdub> mpt: s/STAND CLEAR/WATCH YOUR FEET/
* ogra loves <blink> tags :)
<sivang> Seveas: what will the activate button will do/ :)
<tseng> mpt: put that in the malone stylesheet plzkthx
<mvo> mdz: permission to upload http://paste.ubuntulinux.nl/2766
<gilligan_> hrm.. that conflicting package is from marillat
<lamont__> gilligan_: if you're mixing repositories, you're on your own
<lamont__> (that is, not supported... and it's a #ubuntu question, to boot)
<gilligan_> yes and yes.. problem solved anyways - sorry
<lamont__> np
<wasabi_> uh oh.
<wasabi_> vmware breaks on 2.6.12-9
<gilligan_> lamont__: just checked again tho - if i am not completely mistaken the packages in question are all from official repositories -- not using any others currently
<lamont__> gilligan_: only archive.ubuntu.com?
<gilligan_> lamont__: right
<lamont__> sounds like time to visit bugzilla.ubuntu.com
<gilligan_> libmp4v2-0 and libmp4-0
<gilligan_> first being from multiverse
* lamont__ -> home
<lamont__> so are smartdimmer and radeon tool supposed to be propogating from universe to main?>
<sivang> ah, finally
<sivang> irssi proxy rocks
<lamont__> sivang: you mean that's your fault, or somethign unrelated to my livecd woes?
<ajmitch> morning
* lamont__ really really gone
<sivang> lamont__: huh ?
<lamont__> sivang: just the timing of your comment... nm
<sivang> lamont__: lol
<sivang> lamont__: I guess that was my fault , then.
<lamont__> mjg59: what have you done to my livecd builds?  damn propogating crap...
<mdke> seb128, ping?
<mjg59> lamont: Mm?
<mdke> seb128, unping
<seb128> mdke: unpong
<mdke> :)
<os2mac> any of the laptop team folks around.
<jdong> building my own kernel... why shouldn't I compile it with GCC4?
<jdong> (or rather why's it compiled with GCC 3.x)
<ogra> jdong, make it compile with 4 :)
<os2mac> I have some questions/comments about the Dell Inspiron 8600 and Breezy that I would like to share with the Laptop team.
<os2mac> anyone around?
<jdong> ogra: u sure that's a good idea?
<jdong> os2mac: if it involves vbetool I was smacked down :)
<jdong> lol
<ogra> jdong, it doesnt compile afaik....
<jdong> oh?
<os2mac> it doesn't 
<os2mac> i was going to comment on how well it runs out of the box for my Inspiron 8600....
<mjg59> os2mac: ?
<os2mac> accept for the for wlan0
<mjg59> os2mac: Yeah, I'm interested to hear
<jdong> ogra: does "make deb" automagically work?
<jdong> ogra: or am I a lazy bum
<ogra> jdong, you dont use make deb with kernels ;) have a look at make-kpkg
<os2mac> so I was going to ask if you had any idea of ndiswrapper was going to be included by default on the next release.
<mjg59> os2mac: It's included by default
<os2mac> really?
<mjg59> Yes
<jdong> ogra: k, thanks.... any pointers on CONFIG_HZ?
<mjg59> ndiswrapper is in the kernel and ndiswrapper-utils is on the CD
<os2mac> I have had to download it, (at lease on the live version)
<mjg59> I've no idea about the live version
<ogra> jdong, no idea i havent compiled a kernel since i use ubuntu... o need for that
<ogra> *no
<jdong> lol, good one :)
<jdong> kernel devs care to explain what happened to dm_bbr?
<os2mac> question? is it included as a package or installed.
<os2mac> MJG:?
<mjg59> os2mac: Which? ndiswrapper-utils is included as a package on the install CD and is copied to the hard drive, but isn't actually installed
<os2mac> ahhh I see.
<os2mac> I am using the Dell wlan nic... the actuall chipset is Broadcom (the bcmwl5 driver) do you know if the broadcom linux driver is installed?
<jdong> ogra: does kernel-package do initramfs?
<ogra> jdong, nope, thats initramfs-tools
<jdong> ogra: so I have to manually mkinitramfs, right?
<ogra> nope...
<jdong> ogra: it ain't the automagic linux-image*'s, is it?
<ogra> its done by the linux-image package
<ogra> you can do mkinitramfs too indeed
<jdong> k
<jbailey> ogra: hmm?
<ogra> jbailey, you cant ? 
<jdong> ogra: I'm just aiming to build my own kernel; newest Linus tree with some performance patches....
<jdong> ogra: don't wanna lose too much Ubuntu Just Works-ness
<jdong> lol
<jbailey> ogra: No, just checking to see what you need.
<jbailey> ogra: Wondering if you're talking about the nfs bug. =)
<ogra> jbailey, nope, helping jdong 
<jdong> so if I don't use initramfs/mkinitramfs on this custom kernel, usplash will hate me, right?
<jbailey> 'k =)
<ogra> jdong, yup
<dholbach> brb
<jdong> ogra: so make-kpkg will just put the vmlinuz and modules in a deb package... everything else (initramfs generation) is up to me?
<carstenh> jbailey: ping
<jdong> ogra: most of the docs I've found are old-fashioned Debian-ness
<jbailey> Carsten!
<jbailey> carstenh: How's thing?
<ogra> jdong, not sure i didnt build a kernel since pre ubuntu time as i said... it used to work like that, yes
<jdong> ogra: ok, thanks... then I also presume these will keep Debian-style kernel names instead of linux-*
<ogra> jdong, i guess its patched for ubuntu... but thats only a guess
<jdong> hmm
<jdong> jbailey: you seem to have done work on kernel-package... can you shed some light on (1) initramfs and (2) naming?
<jbailey> I'm reasonably familiar with initramfs-tools.
<jbailey> I have only light exposure to kernel-package.
<jbailey> What do you need?
<jdong> jbailey:  	kernel-package 	 (9.001ubuntu2) 	breezy; 	urgency=low      * Use initramfs-tools instead of initrd-tools.  -- Jeff Bailey  <jbailey@ubuntu.com>Wed, 10 Aug 2005 04:57:37 -0400 
<jdong> explain....
<jdong> so does the --initrd flag now do initramfs
<jdong> or is there an entirely new option
#ubuntu-devel 2006-10-02
<jdub> fabbione: will edgy have a supported sparc release?
<ajmitch> morning jdub 
<_ion> or m68k?
<siretart> god praise backups!
<ajmitch> siretart: what did you destroy?
<siretart> ajmitch: my desktop workstation by trying to upgrade to edgy
<ajmitch> ouch
<siretart> ajmitch: /sbin/discover decided to hang in state D :/ as well as mdadm
<siretart> while trying to restore my backups, I fell over #63398 (and filed it afterwards)
<siretart> bug 63398
<Ubugtu> Malone bug 63398 in Ubuntu "[regression]  live cd doesn't support lvm/md (software raid) devices" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63398
<ajmitch> hm, serious
* ajmitch needs access to lvm+raid for those times he breaks things
<siretart> oh, it's quite handy
<siretart> espc. when the desktop cd can actually access them in case of emergency and for restore purposes. 
<siretart> I'm a bit angry about myself for giving my last dapper desktop cd away only a few hours before :/
<siretart> so I had to redownload it
<HrdwrBoB_> ajmitch: just get some old disks and stick them in an md/lvm setup
<ajmitch> HrdwrBoB_: that'
<ajmitch> that's fine
<ajmitch> assuming that there are some old disks around
<ajmitch> but the bug should still be fixed if possible
<max_> how ready is edgy?
<HrdwrBoB_> as ready as pie
<gnomefreak> pie before you place in oven :)
<Weirdbro> You devs going to go along with the Debian Firefox renaming?
<fabbione> jdub: yes
<fabbione> morning btw
<fabbione> ajmitch: why is f-spot not built on sparc?
<fabbione> isn't f-spot mono stuff?
<ajmitch> yes, it is
<ajmitch> it's Arch: any, so I'll check it out
* ajmitch guesses it or mono were blavklisted on sparc at some point
<ajmitch> infinity: are you able to check if that's the case?
<fabbione>  edgy sparc   Successfully built
<fabbione> ^^ mono
<ajmitch> no good reason why f-spot shouldn't build then
<fabbione> infinity: ^^
<elmo> I suspect launchpad is still using an ancient copy of P-a-s - they've had a lot of issues re-implementing P-a-s support, not sure if they're resolved yet or not
<fabbione> elmo: ok thanks..
<ajmitch> right
<jdub> fabbione: rock :-)
<fabbione> jdub: of course we are talking about -server only
<fabbione> not desktop yet
<User75> Hi, I need help, I want to change the data of some UDP packet passing through my linux router
<desrt> wow.
<Lathiat> heh
<ajmitch> impressive patience
<jdub> fabbione: ah
<fabbione> jdub: assuming that for edgy+1 i will have more time and sparc/desktop gears, i might be able to get it done in the next 6 months
<fabbione> but it's an assumption
<wasabi> Hmm. WHat is to be expected out of Normal User interaction with our LP bugs?
<wasabi> From a customer/non-customer service POV.
<infinity> elmo: I have P-a-s auto-updating now, actually, but that doesn't mean f-spot isn't still blacklisted in Debian.  We'll see.
<infinity> ajmitch: I'll look into it.
<infinity> elmo: Yeah, actually, looks like P-a-s being implemented correctly finally is the cause of the problem, since Debian's P-a-s still exclused sparc from mono stuff.
* infinity fixes.
<joejaxx> whould anyone mind explaining to me in privmsg how to generate the cd isos from seeds? there seems to not be any documentation on the process
<fabbione> infinity: that's because Debian rejected our mono/sparc patches waiting for an upstream release
<fabbione> but we know we work there 
<infinity> Oh, feh.  So the fact that I just updated Debian's P-a-s to allow mono on sparc is wrong?  Great.
<infinity> I guess I might have to fork/branch P-a-s at some point, if they won't take those patches.
<infinity> Anyhow, it works for now.
<infinity> ajmitch: It'll build when OOo and gcc-snapshot stop plugging up the buildds.
<fabbione> infinity: afaik the new mono upstream release has sparc
<fabbione> not sure if the debian/mono maintainer did care to tell buildd admins to update Pas
<fabbione> just let it there and see what happens :)
<pitti> Good morning
<Hobbsee> hey pitti 
<ajmitch> infinity: thanks for that
<ajmitch> morning pitti 
<pitti> hey Hobbsee 
<pitti> moin ajmitch 
<Chipzz> wth is P-a-s? :P
<fabbione> Chipzz: a file that tells the buildd that package foo should build or not on a certain architecture
<fabbione> pitti: bug #62972
<Ubugtu> Malone bug 62972 in linux-source-2.6.17 "leaves core files behind after calling crashdump-helper" [High,Fix committed]  http://launchpad.net/bugs/62972
<pitti> fabbione: I saw BenC's upload
<fabbione> pitti: kernel side has been done by Ben with 10.25
<fabbione> ok
<pitti> fabbione: and that I have to clean up in apport now
<pitti> fabbione: thanks
<fabbione> pitti: perfect
<pitti> fabbione: strange, it's nontrivial to unlink a file in the kernel?
<fabbione> pitti: so it seems.. i didn't check code or anything.. just going trough the bug list for release
<pitti> ok, fine; I adapted the bug accordingly
* pitti reboots, brb
<Chipzz> fabbione: oh, I was thinking some kind of abbrevation like g-p-m or stuff like that
<ajmitch> Chipzz: yes, packages-arch-specific
<froud> I see that the Server Install CD installs kernel -server, but the Server installation from the Alternate CD does not, instead it installs -386. Is there a reasoning for this?
<Fujitsu> froud, the server CD is for installing servers. The alternate CD isn't.
<infinity> froud: No room on the alternate CD for extra kernels, and we expect people to do server installs form the server CD.
<infinity> froud: That installation method on the alternate CD will be renamed to something like "minimal" (undecided currently) for edgy to reflect the fact that it's not "the server install"
<NthDegree> infinity: uh it's called a "Command line install" AFAIK on the new edgy Alternate CDs
<infinity> Man, I could work nearly fulltime on queue/new alone some days..
<Fujitsu> NthDegree, yes, it was renamed a couple of days back.
<infinity> NthDegree: Ahh, yes.  Though there was still some contention about that. :)
<infinity> NthDegree: It may stick, though.
<NthDegree> I like it personally
<NthDegree> and the CD was the 1st one that actually worked in ages
<infinity> Well, anything's better than "server", which doesn't do what people expect.
<NthDegree> people think RHEL when they hear "server" and Linux
<NthDegree> so they assume they get a GUI too :|
<tfheen> infinity: did you look at http://librarian.launchpad.net/4565707/buildlog_ubuntu-edgy-i386.xffm-proc_4.5.0-0ubuntu1_FAILEDTOBUILD.txt.gz ?
<infinity> tfheen: Cute.
<tfheen> it works in a normal system here, so I'm at a bit of a loss to understand what's happening
<infinity> tfheen: Err, wait.  procps isn't {Build-,}Essential.
<infinity> tfheen: Just a missing build-dep.
<infinity> tfheen: (Or need to preseed configure with /bin/ps, if it's not actually going to use it, but just wants to know you have it)
* infinity notes that sparc succeeded, and goes to clean out the sparc chroot a bit.
<froud> Fujitsu: infinity: "Command Line Install"is about as misleading as "Install Text Mode". Alternate CD should provide basic installation of server (sans LAMP) and text mode should provide user ability to install with desktop or without. The OEM installation should enable preseed possabilities for desktop and server. Just a thought
<infinity> Ugh, apt's autoremove does some Very Bad Things in the face of transitional packages.
<infinity> I wonder if there's a way around that at all...
<infinity> The following packages were automatically installed and are no longer required:
<infinity>   upstart-compat-sysv pkgbinarymangler startup-tasks system-services upstart
<infinity> All obviously BS.
<Fujitsu> What? You don't need those. They're not system critical at all.
<fabbione> infinity: isn't that in buildd chroot?
<infinity> Actually, I'm curious how upstart got in that list, since it wasn't the product of a transitional package update...
<fabbione> infinity: if so why would you need upstart?
<infinity> fabbione: sysvinit used to be Essential: Yes.  If upstart isn't, I can remove it, and will.
<infinity> Perhaps apt's trying to be smart there.
<infinity> It's is clearly wrong about pkgbinarymangler, however, which was installed as a result of a transition from pkgstriptranslations.
<infinity> Oh well.
<fabbione> i thought upstart was Essential: yes ?
<infinity> Doesn't appear to be.
<infinity> It was made Essential, then that was reverted, I guess.
* infinity removes.
<infinity> Hrm, but sysv-rc kinda wants /sbin/runlevel, and that is Essential: Yes, so I suspect a missing dep here...
<tfheen> infinity: it's priority: required, though
<tfheen> but that might not count?
<infinity> tfheen: Doesn't matter.
<infinity> tfheen: Lots of stuff is required that isn't build-essential.
<tfheen> 'k
<tfheen> Toadstool: ^^^
<infinity> tfheen: Anyhow, looking at what configure does with it (checks for valid switches to ps, etc), the build-dep would be needed, since it'll actually use it.
<tfheen> infinity: yeah, hence why I didn't just say "oh, just preseed it"
<fabbione> "Applications can not close shared connections.  Please fix this in your app.  Ignoring close request and continuing."
<fabbione> ^^ who the hell is spawning this message?
<fabbione> (when playing dvd with xine)
<pitti> fabbione: could be dbus
<pitti> fabbione: yup, confirmed, that string is in libdbus
<fabbione> hmmm
<fabbione> so why didn't we see this before and it is coming out all of a sudden?
<dholbach> good morning
<Treenaks> hi
<Burgundavia> mvo: you up yet?
<mvo> Burgundavia: yes, hello
<Burgundavia> mvo: does the language support tool still ask users to reload the language pack info?
<infinity> mvo: So, is there anything magical we can do to make transitional packages not completely confuse apt's autoremove DB?
<dholbach> good morning tkamppeter
<dholbach> hey infinity
<mvo> Burgundavia: yes it does
<infinity> mvo: Take the classic case where fileutils depended on coreutils, if you removed fileutils, you'd then end up with apt helpfully telling you that coreutils was no longer useful. :)
<Burgundavia> mvo: perfect, thanks
<infinity> mvo: A contrived example, sure.  I just saw it with pkgstriptranslations->pkgbinarymangler, and it annoyed me. :)
<infinity> mvo: I also saw it with upstart and friends, and I'm not sure why there.  I think perhaps because it was Essential:yes for a while, so technically "auto-installed", then stopped being Essential, so was deemed expendable.
<mvo> infinity: you would have to use "apt-mark unmarkauto pkgbinarymangler" (or synaptics gui). currently apt has no idea about transition packages unfortunately
<mvo> infinity: essential packages are automatically considered manual installed (wanted) :)
<tkamppeter> dholbach, good morning
<mvo> infinity: but upstart depends on ubuntu-minimal, so apt shouldn't think it can remove it
<infinity> mvo: Are they?  Then how the heck did I get "upstart-compat-sysv pkgbinarymangler startup-tasks system-services upstart" in my removal list?
<infinity> mvo: buildd chroots don't have ubuntu-minimal installed. :)
<mvo> infinity: heh :) that would explain this one
<infinity> mvo: What I was guessing was that, for the few days that upstart was Essential, I upgraded, which forced installation, but also marked it auto.  Internally, apt ignores that auto (because it's essential), but when we demoted them, it started paying attention again.  Sound about right?
<dholbach> ogra: new gnome-power-manager!
<infinity> mvo: If that's what happened, I can live with that, cause it was a mistake for us to mark it Essential in the first place, and in general, demoting something from Essential should make it removeable.
<infinity> mvo: It just seemed kinda weird. :)
<mvo> infinity: yeah, that totally makes sense :)
<mvo> infinity: just use apt-mark to get rid of it then
* Keybuk wonders how you run a program with a controlling tty
<tkamppeter> pitti, doko_: biff
<pitti> hi tkamppeter 
<doko_> tkamppeter: can do. will take 12h anyway until it hits the archive
<tkamppeter> hi pitti
<fabbione> mvo: ping?
<mvo> fabbione: pong
<tkamppeter> doko_: OK, go ahead.
<Keybuk> pitti: around for a moment?
<pitti> Keybuk: yes, I am
<Keybuk> you've dealt with a few of the daemons that needed a /proc/bus/usb -> /dev/bus/usb conversion
<Keybuk> can you remember off-hand which way they check?
<Keybuk> I've suddenly had a bad thought that something might check for /proc before /dev
<Keybuk> so when we enable usbfs again, they'll break because those devices can only be read by root
<pitti> Keybuk: can't say in general, but for libgphoto in particular I made sure that it checks /dev first
<Keybuk> do you remember what cups does?
* pitti checks
<pitti> Keybuk: ah, cups uses /dev/usblp or /dev/usb/lp
<pitti> Keybuk: it doesn't use the raw devices at all
<Keybuk> cool
<pitti> tkamppeter, doko_: I'll test the new foomatic-db-engine and upload
<pitti> tkamppeter: interesting, since a few days, cups autodetects a 'HP Fax' device for me, although I don't have anything resembling such a thing
<pitti> tkamppeter, doko_: uploaded; works great
<StevenK> Kamion: Connected from the new place?
<Kamion> StevenK: not quite yet - working from iwj's today
<Kamion> should be connected by tomorrow
<StevenK> Ah
<StevenK> But you've been kicked out of the old place?
<Kamion> not quite that either, but I've moved all the computers
* StevenK shakes his head.
<StevenK> Moving is complicated enough, but that seems *too* complicated. :-)
<Kamion> it's got to be done at some point
<tfheen> hi Colin
<StevenK> Kamion: I went through the moving fun one year ago, and I don't want to again for quite some time.
<Kamion> tfheen: mind if I upload the pending casper stuff?
<tfheen> Kamion: please.  I'm fighting with the expenses system.
<doko_> iwj_: fontconfig ping (about the rendering for the UI fonts in firefox and openoffice.org)
<iwj_> doko_: Err, hello.
<iwj_> But I'm afraid I don't know what you're referring to ...
<doko_> iwj_: can you see the difference in how the UI elements are rendered in gedit/gnome-terminal and firefox/OOo?
<iwj_> I can see a difference which I think is to do with kerning.
<iwj_> Hmm, also, the firefox one is a touch smaller.
<iwj_> Is that what you mean ?
<doko_> do you have a gnome desktop running?
<iwj_> Not normally :-) but I will have one in just a moment ...
<ogra> dholbach, i was fearing you would say that today :)
<doko_> iwj: http://librarian.launchpad.net/4542766/Screenshot.png
<dholbach> ogra: "fear" - it's not that bad, is it?
<iwj_> It doesn't look quite the same here, but I can still see a difference.
<ogra> dholbach, nah ... :)
<Kamion> I much prefer the OOo rendering in that screenshot
<doko_> seb128: does gnome uses it's own pango settings for the kerning/rendering? ^^^
<_ion> keybuk: Re: the OpenOffice discussion at ubuntu-devel@, IMO even WYSIWYG is a feature that has better alternatives. :-)
<seb128> doko_: it uses what you configure with gnome-font-properties
<iwj_> doko_: What exactly is your complaint/question/opinion/... ?
<minghua> doko_: that looks just like the difference between autohinting and bytecode-hinting to me
<tkamppeter> pitti, the auto-detection of a fax device comes from HPLIP 1.6.7, this bug is fixed in 1.6.9. They have fixed it after my upstream bug report and I have already tested on Mandriva that it is fixed now.
<minghua> doko_: my debian unstable has the same problem (since OO.o 2.0rc3 I think)
<tkamppeter> Currently I am waiting for Debian picking up HPLIP 1.6.9.
<pitti> tkamppeter: ah, good to know
<pitti> tkamppeter: is mdz fine with 1.6.9 for edgy?
<minghua> doko_: if you turn off the bytecode hinting and turn on autohint I believe OO.o and abiword will look the same
<tkamppeter> pitti, I did not post an UVF ER yet.
<doko_> minghua: will have to check ...
<tkamppeter> pitti, but there is already a Ubuntu bug report about this: bug 62506
<Ubugtu> Malone bug 62506 in gnome-cups-manager "Incorrectly Detects HP Fax device" [Medium,Needs info]  http://launchpad.net/bugs/62506
<pitti> ah, nice
<minghua> doko_: you know how to do it, right?  if ubuntu's fontconfig is the same as debian's, dpkg-reconfigure fontconfig-config should do it
<dholbach> TheMuso: Hey Luke, did you notice festival spinning CPU like mad in edgy recently?
<tkamppeter> pitti, perhaps we must overgo Debian here, as they seem not to be much interested in HPLIP 1.6.9. They have still only 1.6.7.
<pitti> tkamppeter: I don't see a problem with that
<doko_> minghua: hmm, doesn't make a difference
<minghua> doko_: hmm, strange
<minghua> but beta's hinting is strange
<RicardoPerez> pitti: ping
<pitti> hi RicardoPerez 
<RicardoPerez> pitti: hi! i have a question... mmmm....
<slomo> doko, doko_: shall we upgrade pysupport to 0.5.2 for edgy? a user had a problem with dbus-python which disappeared after upgrading pysupport and from the changelog it looks rather sane
<minghua> there is also bug #60760 about hinting
<Ubugtu> Malone bug 60760 in freetype "turning off autohinting has no effect" [Undecided,Unconfirmed]  http://launchpad.net/bugs/60760
<RicardoPerez> pitti: what is the package (or Rosetta's template) which contains the volume & drive names?
<doko_> slomo: yes please
<pitti> RicardoPerez: 'contains'?
<RicardoPerez> pitti: the volumes that appears in Places->Computer
<pitti> RicardoPerez: that's gnome-vfs2
<slomo> doko_: ok, i'll care for it, thanks :)
<minghua> doko_: sorry I don't have edgy to test, but that screenshot looks exactly the same at my unstable (I also use arial as interface font there)
<RicardoPerez> pitti: mmmmm I can't find that template in Rosetta...
<pitti> carlos: ^ ?
<RicardoPerez> pitti: can you send me the link?
<minghua> s/at/as/
<pitti> RicardoPerez: https://launchpad.net/distros/ubuntu/edgy/+source/gnome-vfs2/+translations
<pitti> carlos: (nevermind)
<doko_> minghua: we use DejaVu, not Arial, but both are ttf fonts
<minghua> doko_: Is that screenshot DejaVu extra light?
<RicardoPerez> pitti: oh, great, thanks! it's related to bug 62502
<Ubugtu> Malone bug 62502 in hal "[Edgy]  Volume names appears untranslated" [Undecided,Unconfirmed]  http://launchpad.net/bugs/62502
<minghua> doko: that screenshot definitely is not dejavu sans (regular)
<carlos> pitti: ok
<RicardoPerez> pitti: the volumes appears untranslated, but the gnome-vfs2 template is fully translated in Rosetta
<doko_> minghua: fc-match show DejaVu-Sans for Sans
<pitti> RicardoPerez: did you try the current daily edgy langpacks?
<pitti> RicardoPerez: please check the mo files in them
<minghua> doko_: for the machine that took the screenshot http://librarian.launchpad.net/4542766/Screenshot.png ?
<RicardoPerez> yes, I just installed it, but doesn't works...
<RicardoPerez> pitti: yes, the .mo file contains the translation, as I said in the bugreport
<minghua> doko_: then I have no idea, it looks just like Arial to me.  if you want, I can even show screenshots
<pitti> RicardoPerez: hm, then this must be a bug in gnome-vfs2 itself
<RicardoPerez> pitti: then I'll change the bugreport from hal to gnome-vfs2, is right?
<pitti> RicardoPerez: right, I just did that
<RicardoPerez> pitti: oh, great :)
* pitti takes the bug
<minghua> doko_: maybe gnome-font-settting is different?
<RicardoPerez> pitti: thanks
<minghua> doko_: I found another way to test the hinting: use the gnome "desktop -> preference -> font" dialog, go to "details", and try different choices in the hinting section, which gives quite different effects
<minghua> doko_: and the change is instant, also I believe OO.o is not affected by this gnome setting
<doko_> minghua: right, but firefox is affected as well (therefore the question to iwj_ about our change/hack to fontconfig/pango)
<iwj> doko_: What question ?
<iwj> I mean, what is your question/comment/complaint/... ?
<minghua> doko_: I see.
<minghua> iwj: maybe you can look at bug #60760, too?  I suspect it's related to doko's question
<Ubugtu> Malone bug 60760 in freetype "turning off autohinting has no effect" [Undecided,Unconfirmed]  http://launchpad.net/bugs/60760
<minghua> iwj: the problem in 60760 is a user sees font rendering changes after upgrading to edgy
* iwj looks.
<minghua> iwj: and ignore my comments there, it may be off-base
<iwj> They upgrade and the behaviour of the software changes.  That doesn't seem to me a sufficient condition for a bug ...
<minghua> iwj: sorry, i meant they upgrade from pre-beta to beta
<minghua> iwj: it's just some people prefer bytecode hinting to freetype autohinting
<minghua> iwj: and according to the user, bytecode hinting is now not available in edgy beta
<minghua> iwj: that sound a bug to me
<iwj> Err, yes, probably.  Has anyone debugged it properly ?
<iwj> It's definitely nothing to do with the firefox/fontconfig/pango FC_ANY_METRICS patches.
<minghua> iwj: not as far as I know.  and I don't have time to debug it now, sorry
<iwj> Right.
<Riddell> carlos: is it possible to put kcmlocale near the top of items to be translated?  it's needed to be able to select the language in kde's system settings
<carlos> Riddell: sure, we can raise its priority
<carlos> Riddell: edgy and dapper ? or just edgy?
<Keybuk> I've worked out why my computer every now and then says "And we're going to interview Bob Plums..."
<Keybuk> it's not some random ogg buffer problem, or sound card driver bug
<zul> eh?
<Keybuk> it's nautilus
<pepsiman> Keybuk: lugradio
<Keybuk> if you point the mouse at a sound file, it starts playing it
<jdub> Keybuk: hover sample?
<Keybuk> and there's a sound file on my desktop
<jdub> yeah
<infinity> Oh, that's just wrong.
<Keybuk> and if I switch desktops, sometimes the mouse briefly hovers over it on the way between them :)
<infinity> Hover sample for audio is just plain dumb.
<Keybuk> pepsiman: aye, it's the episode I was in, innit
<pepsiman> Keybuk: :)
<_ion> I like the feature.
<Keybuk> I like the feature so much, I'm about to write a patch disabling it, and upload it without telling seb :)
<Riddell> carlos: both would be nice
<carlos> Riddell: done for Edgy and Dapper, it has the same priority as kdelibs
<Riddell> carlos: you should have all needed .desktop translation files now, some I've renamed to be the same as upstream
<_ion> keybuk: Why not just change the setting? ;-)
<pepsiman> carlos: Where do manpages, doc and help translations done in Rosetta end up?  They're not in the langpacks
<Keybuk> _ion: "the setting" ?
<_ion> keybuk: The setting.
<Keybuk> what's the setting?
<_ion> The "Preview sound files" setting in nautilus preferences.
<carlos> Riddell: ok, I will rename the ones we already imported and import the new ones. Thank you!
<_ion> (surprisingly)
<infinity> Nautilus properties -> Preview.
* Keybuk can't see anything in the right mouse properties thing
<infinity> But having it on by default still feels wrong to me.
<Keybuk> uh
<Keybuk> how do I get to the nautilus preferences?
<infinity> Keybuk: open a nautilus window, Edit->Preferences.
<Keybuk> it's not in my Preferences Menu
<Keybuk> gah
<Keybuk> that's broken
<infinity> Keybuk: Say, Places->Home, for instance.
<carlos> pepsiman: atm they stay in Rosetta, I got already the approve to stop importing them into Rosetta until we have an automatic way to publish them in Ubuntu like we do with language packs
<Keybuk> you should be able to change the desktop preferences without opening some random indow
<carlos> pepsiman: so I'm going to hide them from the UI so people don't expend time on them
<_ion> keybuk: Something opened from the context menu of a directory would be a wrong place to put program's global preferences into.
<Keybuk> _ion: agree, it should be under System->Preferences
<infinity> System->Preferences->File Manager would be nice, yeah.
<Keybuk> didn't we used to have that?
<infinity> No idea.
* Keybuk bets jdub removed it in one of his culls
<minghua> well, I have a desktop->preference->file management on debian
<infinity> Could have been cleaned out due to someone's fascist "you can get there from elsewhere, and that menu is cluttered" thing.
<pepsiman> carlos: I see, that's a shame, when translating them into en_GB I get to proofread them
<infinity> minghua: Guess that answers that.
<Keybuk> the same facism that leaves dozens of users hunting for the button on the login screen that accepts their username
<infinity> Yeah, File Management is there in the Menu Editor, it's just invisible by default.
<minghua> yeah, I remember now, ubuntu hides all nautilus entries in the menu
<minghua> also the applications->system tools->file brower one
<Kamion> ogra: have you seen this "Applications can not close shared connections" error from 'gnome-screensaver-command --poke'?
<Keybuk> Kamion: I've seen that
<minghua> which means it's very hard to get a browser nautilus window
<ogra> Kamion, nope ...
<ogra> sounds like a dbus message
<Kamion> it is
<carlos> pepsiman: Well, with every Ubuntu release, we get something else implemented to add support for this kind of things so I hope it will not take too much time until we implement something to support documentation in a way quite similar as language packs
<Kamion> just running 'gnome-screensaver-command --poke' from a terminal reproduces it for me, but this is a live CD from late last week
<Keybuk> Kamion: someone was talking about that earlier
<Keybuk> (as in the actual bug cause)
<Kamion> carlos: decent man page translation is going to have to wait for groff Unicode support to be finished up
<seb128> infinity: why do you need it, nautilus preferences are available from any nautilus window
<infinity> seb128: How many poeple know what that means?
<infinity> seb128: If your desktop is doing weird things (say, playing sounds when you hover over stuff), is it intuitive to open your "home folder" to fix it?
<seb128> opening preferences of the program you use is common behaviour?
<infinity> seb128: It may be to you and I, cause we know that it's "all nautilus", but "normal users" would have no clue.
<seb128> you want gedit preferences to the panel menu too? :p
<carlos> Kamion: well, anyway, we are not able to ship them as part of language packs so it's not an issue right now
<infinity> seb128: I only care about gedit preferences when I'm running gedit, it doesn't affect my "desktop", which users don't really assign an application to.
<seb128> infinity: I doubt people will go to system, preferences, file browser to change that anyway
<minghua> seb128: I think a lot of users don't realize their desktop is a part of nautilus
<infinity> seb128: I dare you to find 1 out of 10 non-nerd users who know that their desktop is a nautilus window.
<seb128> I've missed the start of the conversation
<Keybuk> seb128: I just tried to
<seb128> I didn't know it was about the desktop :p
<Keybuk> my desktop was behaving oddly
<Keybuk> and I _know_ that it's nautilus
<seb128> if sound preview is confusing maybe it should be off by default
<Keybuk> it never occurred to me to open a nautilus window to change how the desktop behaved
<infinity> seb128: Oh, I think it should be off by default, but that's orthoganal to the "how do I make my desktop behave differently when I don't know it's nautilus" thing.
<seb128> it never occured to me that you had to change the way the desktop behaves
<seb128> that's about the only setting for the desktop
<infinity> Alternately, adding "Preferences" (or even "Nautilus Preferences", as a bit of education that the desktop is nautilus) exclusively to the Desktop context menu, but not to any other folders, might be nice.
<Keybuk> seb128: single vs. double-click too
<seb128> Keybuk: that's not desktop specific though
<Keybuk> neither is hover-sound-preview
<pepsiman> carlos: Is bug 62668 a rosetta problem?
<Ubugtu> Malone bug 62668 in language-pack-gnome-es "[Edgy]  Some strings can't be translated" [Undecided,Confirmed]  http://launchpad.net/bugs/62668
<seb128> right
<Keybuk> but it DOES change the way the desktop behaves
<Keybuk> and it's totally non-obvious to open a file manager window to change that
<seb128> it would be misleading to call that "desktop preferences"
<Keybuk> System -> Preferences -> Icon Behaviour
<infinity> seb128: No, hence my suggestion of "Nautilus Preferences", but only on the desktop context menu, not for any other folders.
<seb128> context menu is not discoverable
<minghua> I like infinity's idea
<infinity> seb128: For other folders, it's obvious you're in a nautilus window, and you can get at Edit->Preferences, but not on the desktop.
<seb128> right
<seb128> then we need a simplier dialog with those preferences
<seb128> I don't think the nautilus preferences one is good to expose to the menu
<carlos> pepsiman: yes, it is, but I just fixed it. Thanks for noting it to me
<seb128> with the list of columns, etc
<infinity> Well, "Preview Preferences" could open the Nautilus pref window, but paged to the Preview page.
<infinity> I tend to think it's good education to clue people in to the fact that Nautilus==Desktop==FileManager, but in a friendly way.
<seb128> right, but Scott just mentionned the "simple/double click" is useful too
<infinity> Reusing the same dialog, but paging to a different page by default helps that.
<infinity> Microsoft tends to do that all over Windows, to clue you in that "Time and Date" and "International Settings" and such are all tied together, etc.
<infinity> Just page to the one they asked for, but you start to get the idea that, hey, all these pages might relate.
<seb128> anyway I've no strong opinion about it
<seb128> we masked it because the preferences menu is already too long
<infinity> I have no really strong opinion about the solution, just that the current situation is suboptimal. :)
<seb128> and we estimated few people want to go there change something
<infinity> And turning off audio preview by default may also be sane.
<seb128> and it's available from somewhere else
<infinity> Anything that makes a computer act haunted freaks out my mom.
<infinity> And me.
<infinity> And Keybuk.
<seb128> what, audio preview?
<seb128> we have that since warty
<seb128> I don't think anybody complained before now
<infinity> I don't keep audio on my desktop, which is why I've never noticed.
<seb128> it's weird you are freaking now :p
<infinity> "Close a window, and have your computer sing to you cause your moise pointer is in the wrong place" is freaky.
<infinity> mouse, too.
<jdub> it's been in nautilus since < 1.0
<Keybuk> I don't think it's bad in nautilus windows
<Keybuk> it's just downright silly on the desktop
<Keybuk> because your mouse will cross or hover over audio as part of its normal business
<infinity> But there's no pref to differentiate the two, so... <shrug>
<infinity> jdub: Old features can still be wrong.  Y'know, like modal editors. :)
<seb128> what an idea to put audio on your desktop :p
<Keybuk> non-spatial file manager
<Keybuk> seb128: why not?  I stick anything I download or don't really intend to keep forever on my desktop
<Kamion> and our browser will download stuff to the desktop by default, so ...
<seb128> Keybuk: no reason, was sort of a non-funny joke :p
<pepsiman> Kamion: but lugradio is a podcast, use a podcast app to download it
<infinity> The French excel at those.
<seb128> I've some video on my desktop myself ;)
<Keybuk> pepsiman: ITYM "zunecast"
<Kamion> pepsiman: that's not really the point anyway
* seb128 slaps infinity
<dholbach> New:  Ubuntu 6.10  "without Media Player^W^WAudio Preview" edition
<Keybuk> seb128: your response was a bit of an LP-esque "your use case is meaningless to us"
<seb128> I think we should just turn off audio preview by default
<seb128> it requires mpg123 and ogg123 to work anyway
<seb128> which means it doesn't work by default
<seb128> it's broken on non-local locations
<minghua> maybe that's why nobody complained
<minghua> because it never worked :-P
<seb128> and it seems to be annoying rather useful for people who get it working ;)
<infinity> Yeah, my "mom" wouldn't have CLI audio players installed.
<infinity> That does kill the scary for "average users", but also makes the feature nearly useless.
<ogra> Kamion, there is a change mentioned in src/gs-listener-dbus.c in the gnome-screensaver changelog ... lets wait for the 2.16.1 tarball and see if it fixes the issue
<Kamion> ogra: thanks
* tfheen writes down a note to self: "Slip in .foo.wav on Adam's machine.  Make sure file contains ghost noises"
<infinity> tfheen: Hidden files don't show up on the desktop, therefor can't be hovered over. :P
<tfheen> infinity: darn!
<tfheen> :-)
* Hobbsee tickles tfheen 
* Hobbsee runs away very quickly
* tfheen goes to grab some food, but stumples as he's tickled.
<tfheen> bad Hobbsee!
<slomo> ogra: which issue with g-s and dbus?
* tfheen orders his cat to chase Hobbsee while he finds food
<ogra> slomo, _dbus_warn ("Applications can not close shared connections.  Please fix this in your app.  Ignoring close request and continuing.");
<ogra> thats triggered by gnome-screensaver-command --poke
<slomo> ogra: ah... does it break something? it shouldn't anymore with latest dbus but the older versions just closed the shared connection and that could break afaik
<ogra> dunno if it breaks something, Kamion just reported there is that message
<Kamion> it doesn't break anything AFAIK, but I've had people getting confused by it in ubiquity bug reports
<Kamion> (because ubiquity periodically runs the above)
<ogra> will also get noisy in .xsession-errors
<ogra> slomo, if its a dbus issue, could we make it more silent ? 
<ogra> ("Please fix this in your app" does rather sound like its g-s-s' fault)
<slomo> ogra: it's an application bug about which dbus now warns and makes it not break anymore... i would prefer to just fix g-s instead of making the warning go away
<ogra> right
<ogra> so i'm waiting for the new g-s-s tarball ...
<_ion> All of https://launchpad.net/distros/ubuntu/+source/preload/+bugs would be fixed by syncing to the Debian version of preload.
<_ion> Ubuntu has 0.4-1, Debian has 0.4-3
<slomo> ogra: you mean version 1.41 of gs-listener-dbus.c? i don't think this will fix it
<pitti> _ion: changelog looks nice, I filed a sync request
<elmo> ehm
<elmo> does dapper not have the "resize my windows partition to free up some space" option or am I being really stupid?
<ogra> slomo, hmm ...
<_ion> pitti: Thanks.
<elmo> or is it only available on the alternate installer?
<pitti> elmo: it should have it, but at least I do not always get that option
<slomo> ogra: fix would/could be just removing the dbus_connect_close() at the end of gnome-screensaver-command.c... if necessary the connection to the socket should be closed automatically by the application terminating
<_ion> Bug #62827 still applies to dapper, though. The attached patch probably applies cleanly to the dapper version as well.
<Ubugtu> Malone bug 62827 in preload "parses /proc/N/maps incorrectly, renders whole program nonfunctional" [Undecided,Confirmed]  http://launchpad.net/bugs/62827
<ogra> slomo, ok, i'll try that ... 
<elmo> pitti: meh, ok, I'll try edgy beta
<Keybuk> oh, what a shame, preload doesn't work
* Keybuk wipes a solitary tear
<elmo> Team CD: /dev/cciss/c0d0p2     1.1T 1004G   82G  93% /
<elmo> kamion/tfheen: ---^
* infinity deletes his pr0n from lithium.
<tfheen> elmo: ack, thanks.
<slomo> ogra: otherwise there was a recent commit in dbus cvs to fix some aspects of handling shared connections... not sure what exactly is the effect of that change
<tfheen> infinity: oh, so I don't need to nuke that full-tree hardlink tree I have lying about then? :-P
<infinity> tfheen: Heh, you do that too, eh? :)
<ogra> well, if dropping dbus_connect_close() doesnt break anything its an easy fix
<infinity> tfheen: Last time elmo screamed, a hardlink tree was my "pr0n", yes.
<tfheen> given that nothing seems to have blown up badly after beta went out, I presume it should be safe to rm the hardlink tree.
<infinity> tfheen: Your turn. :)
* tfheen goes scrounging for his laptop
<slomo> ogra: if possible i would like to get dbus 1.0rc2 aka 0.94 or even 1.0 into edgy
<ogra> ah, sounds cool ... but i'll also have to get g-s-s 2.16.1 in ;)
<ogra> so doing that minor change to the package while building it isnt a biggie
<Spads> mdke: ping
<Tonio_> mdz: ping ?
<HiddenWolf> jsDgx2Daishei3
<HiddenWolf> sorry
<elmo> Kamion: ping?
<ogra> HiddenWolf, i hope that was only your IRC pw :)
<HiddenWolf> ogra: *sigh*
<elmo> Kamion: this laptop seems to be insistent on using 'New York' for a timezone - I select London, hit Forward, get 'US Keyboard'.  Click back, it's still on London, but the timer's going and when it finishes, it resets to New York
<elmo> known bug? (this is with edgy beta)
<tfheen> elmo: the US keyboard thing is known, yes.
<elmo> tfheen: if I select UK, and go back, it still flicks back to New York
<HiddenWolf> ogra: no, that was me thinking I had locked my session, like always, and typing my password blind. 
<HiddenWolf> ogra: which is now changed, obviously. :)
<elmo> tfheen: should I bother to look any further, or just suck up the US timezone and move on?
<tfheen> elmo: it sounds like a bug, I guess Colin would like to see a bug about it.
<elmo> tfheen: k, thx
<seb128> ogra, slomo:
<seb128> " mccann * gnome-screensaver/ (ChangeLog src/gnome-screensaver-command.c): 
<seb128>  * src/gnome-screensaver-command.c (main):
<seb128>  Don't close a shared bus connection."
<ogra> oh !
<ogra> seb128, thanks ! :)
<Treenaks> oh, so _that_ was complaining in xine-ui!
<seb128> np ;)
<slomo> seb128: thanks :)
<elmo> whine
<elmo> edgy beta doesn't have a "resize my windows partition" option either
<Riddell> Kamion: bzr branch at http://kubuntu.org/~jriddell/bzr/ubiquity/ubuntu/ adds the ensureItemVisible fix
<pitti> Keybuk: in case it helps your morale: the same way that you now get all boot problems filed against upstart, I get a lot of program crashes filed against apport :/
<ogra> dholbach, how do you set the X cursor theme in ubuntu-artwork, do you ship an /usr/X11R6/lib/X11/icons/default/index.theme ?
<Keybuk> pitti: heh
<Keybuk> *hugs*
<tfheen> pitti: "apport made this program crash"?
<pitti> 'don't shoot the messenger'
<pitti> tfheen: yeah, it's eeeevil
<ogra> oh, thats not its intention ? 
<tfheen> ogra: I'm sure I get more crashes now than before. Must blame apport for them
<tfheen> ;-)
<ogra> right 
<Mirv> sorry, urgent need! is there someone else than newz2000 that can admin ubuntu-xx servers?
<pitti> but it's simple - sudo killall apport-random-kill-daemon
<Mirv> something wrong, I can't upload a PHP file put it got deleted to 0 bytes -> nothing works on the site
<seb128> ogra: cat /var/lib/dpkg/info/human-theme.postinst
<seb128> ogra: it's an alternative
<ogra> ah, cool, thanks ... my bandwith is eaten by other stuff else i'd have pulled -artwork already and looked myself
<seb128> ogra: human-theme is the package you want
<Mirv> disk quota is exceeded. anyone?
<Mirv> or is there any other way to contact anyone at Canonical?
<ogra> seb128, ok
<seb128> Mirv: what machine is that?
<seb128> Mirv: maybe ping elmo
<Mirv> 69.60.114.112 , ubuntu-fi.org
<Mirv> or actually forum.ubuntu-fi.org's account. 
<Mirv> ok it's either newz2000 or smurf, neither of which are around
<Mirv> by deleting the file I was able to bring the forum up, albeit with an ugly mix of the default theme and the ubuntu theme
<Mirv> (I tried uploading a new version of the SMF theme php file)
<Kamion> elmo: yeah, it's a bug, don't think I had a report about it before
<Mirv> ok, I grabbed newz2000 <5 seconds after him logging on. problem solved.
<Kamion> Riddell: thanks, will merge
<Kamion> elmo: if you show me /var/log/partman (or /var/log/installer/partman if you've rebooted), then I can diagnose why it isn't giving you the resize option
<bddebian> Howdy folks
<Kamion> elmo: timezone> I just tried one approach to fixing it, but unfortunately that broke other things - I'll keep trying
<elmo> Kamion: ok, will get you installer when I get networking
<elmo> s/installer/logs/
<elmo> Kamion: shall I put it in a bug?  (if not: http://people.ubuntu.com/~james/tmp/partman )
<Kamion> elmo: in that case, it's only arguably a bug
<Kamion> elmo: you have three primary partitions, and no extended partition
<elmo> Kamion: so resizing would be excessively non-trivial?
<Kamion> elmo: partman always wants to create / as a primary partition (which is a known issue, but I believe it's required on some older BIOSes)
<pitti> iwj: \o/ I finally released the firefox/breezy update from hell
<elmo> ah I see
<Kamion> elmo: then it also needs a partition for swap - which adds up to 4 primary + 1 extended
<Kamion> which is over the limit
<Kamion> summary: the PC partition table format sucks walruses through a leaky oil pipeline
<elmo> Kamion: ho hum - what's the easiest way forward in terms of non-destructively getting Ubuntu onto a machine with this kind of brain damaged partition layout then? 
<iwj> pitti: Yay!  Thank god for that.  etc.
<iwj> Thanks for your effort and forbearance.
<pitti> iwj: thanks for porting and crash fixing :)
<Kamion> elmo: partition manually and put everything in logical partitions; your BIOS probably isn't actually stupid enough to care about that, it's just that I know that there are some that do care
<Kamion> (e.g. seb128's laptop gets upset about not having an active partition, and I'm willing to bet that that BIOS check doesn't look at logical partitions)
<Riddell> mvo: any way of finding out why something is kept back during a dist-upgrade?
<dholbach> ogra: ubuntu-artwork is split up
<dholbach> ogra: ubuntu-theme ships it and sets it in .postinst (iirc)
<ogra> dholbach, yes, i noticed ... 
<ogra> i didnt know its an alternative ...
<ogra> i like alternatives, very cool :)
<dholbach> ogra: that's something Jeff and Nathaniel set up in the early days - I never changed it
<ogra> i never had to care for it until now :)
<ogra> btw, g-p-m uploaded
<smurf> Mirv: you want newz2000 -- I have no access to that box
<dholbach> ogra: nice
<mvo> Riddell: run it with "-o Debug::pkgProblemResolver=true" 
<Keybuk> foo2zjs: /etc/udev/rules.d/11-hplj10xx.rules
<Keybuk> where did that come from?!
<tepsipakki> pitti: Hi, do you plan to backport the fix for #44196 to dapper?
<pitti> tepsipakki: if you think it's appropriate, please add a dapper task
<Seveas> Kamion, which sourcepackage should bug 62950 be assigned to?
<Ubugtu> Malone bug 62950 in Ubuntu "Isolinux error message refers to non-existant CD2, needs changing" [Undecided,Unconfirmed]  http://launchpad.net/bugs/62950
<tepsipakki> pitti: from "backport fix to releases"?
<seb128> doko, doko_: around?
<seb128> doko, doko_:do you have any idea on
<seb128> $ python2.5 -c "import gobject"
<seb128> Traceback (most recent call last):
<seb128>   File "<string>", line 1, in <module>
<seb128> ImportError: No module named gobject
<seb128> $ dpkg -L python-gobject | grep so
<seb128> /usr/lib/python-support/python-gobject/python2.5/gtk-2.0/gobject/_gobject.so
<seb128> /usr/lib/python-support/python-gobject/python2.4/gtk-2.0/gobject/_gobject.so
<doko_> seb128: interesting
<seb128> doko_: that's breaking gnome-python and pygtk builds because they try doing a 2.5 build and chock on it
<slomo> seb128: at least for me it has the wrong sys.path with python2.5
<seb128> slomo: what do you mean?
<slomo> seb128: for 2.4 sys.path contains "/var/lib/python-support/python2.4/gtk-2.0", for 2.5 it doesn't contain the 2.5 variant of this
<slomo> seb128: >>> import sys
<slomo> >>> sys.path.append("/var/lib/python-support/python2.5/gtk-2.0")
<slomo> >>> sys.path.append("/usr/lib/python2.5/site-packages/gtk-2.0")
<slomo> >>> import gobject
<seb128> ah, k
<doko_> seb128: should be fixed with the sync which slome requested
<slomo> seb128: can you please retry with latest python-support from debian? it has a ton of bugfixes
<seb128> slomo: I trust doko on it, will wait for the sync
<Kamion> Seveas: syslinux
<seb128> did you get the UVF approval?
<slomo> seb128: bug #63527  (no uvf approval yet)
<Ubugtu> Malone bug 63527 in python-support "UVF exception & sync request: python-support 0.5.2 from debian/unstable (main)" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63527
<Seveas> Kamion, merci
<seb128> Kamion: maybe you can approval that sync which unbreaks python modules using python-support now? ;)
<Seveas> Kamion, also, I'd appreciate it if you could look at bug 63043 -- I marked 2 similar bugs as duplicates of the old hw-detect bug but that may have been incorrect
<Ubugtu> Malone bug 63043 in ubiquity "ubiquity HwDetect failed with code 10" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63043
<seb128> doko_, slomo: no, doesn't fix it ... or do I need to rebuild pygobject then?
<seb128> it adds /var/lib/python-support/python2.5 to sys.path with it
<seb128> but the .so is to /usr/lib/python-support/python-gobject/python2.5
<seb128> and the .py to /usr/share/python-support/python-gobject
<seb128> hum
<doko_> seb128: reinstalling python-gobject?
<seb128> doko_: k, fix it
<seb128> that's going to be fun
<seb128> like we are going to ask users to reinstall their package?
<doko_> seb128: no, I'll have to go over the list, after the new one is synced
<seb128> ok
* seb128 hugs doko_
<seb128> gnome-python split is blocked on that now
* keescook waves hello
<Toadstool> tfheen, infinity: thanks for the explanations about xffm-proc build failure :)
<tucoz> I have written a bug report that is targeted towards the 2.6.17-10 kernel. However, malone can not find this package, so the package is unknown at the moment although i think i know what package it is.
<dholbach> heya keescook
<keescook> hi dholbach!
<dholbach> how's it going?
<elmo> Kamion: cute - when I create a logical partition, the "Resize partition #1" option appears
<keescook> goin' good.  having fun with security patches, played a little with apport too
<dholbach> keescook: rock on! :-)
<tucoz> I wonder if i should leave it as unknown or what package i should select so that the bug report ends up in the right place.
<Toadstool> infinity: hmm, by the way, how are we, poor MOTUs, supposed to test a package build when even a pbuilder created with --variant=buildd includes packages not installed on an actual buildd? ;)
<pitti> hi keescook 
<keescook> hi pitti, just reading through your emails now.  :)
<Seveas> !sdfsgda
<Seveas> (oops, wrong channel)
<doko_> Kamion, infinity: please process in NEW: openoffice.org (and with lower priority all the *-java packages, plus hsqldb and bsh)
<jdong> slomo: poke
<slomo> jdong: yes?
<jdong> bug 62323 , is the library safe to backport, compatibility wise?
<Ubugtu> Malone bug 62323 in dapper-backports "[dapper]  libsgutils1-dev should depend on libsgutils1" [Undecided,Unconfirmed]  http://launchpad.net/bugs/62323
<Riddell> mvo_: fancy helping me debug some upgrade issues?
<slomo> jdong: imho yes... and would be nice to backport this, there are a lot people that have problems compiling banshee from source because of this bug
<slomo> jdong: but i didn't test building it in dapper. both versions are compatible though
<jdong> slomo: yeah, I have a prevu user experiencing problem with banshee backporting
<jdong> slomo: I'll test building now
<slomo> jdong: you want to backport banshee? good luck... will be hard without backporting complete mono ;) and there is already an inofficial repository containing everything... and it looks fairly sane
<jdong> slomo: no, I'm not trying to backport banshee.... users are :)
<jdong> slomo: what do you think happens when I give them an auto-backporting tool :D
<slomo> jdong: they will update to edgy without even knowing it? ;)
<jdong> slomo: the 3rd question I got was if it was possible to backport gnome 2.16 :D
<slomo> jdong: "deb http://apebox.org/badgerexplosion ./" <--- give this to users wanting to backport banshee... everything is in there at least for x86
<jdong> k, will do
<slomo> what was your answer? s/dapper/edgy/ in sources.list and dist-upgrade? :)
<jdong> slomo: my answer was that he'd save time by just upgrading to edgy; by the time he gets all the dependencies, he'll basically have a 75% edgy box 
<mdz> Tonio_: yes?
<slomo> jdong: i remember you working on the azureus package... are you familiar with java packaging in general?
<jdong> slomo: not at all. I suck at java packaging ,and packaging in general :)
<slomo> ok :(
<jdong> eventually I gave up on azureus, too
<jdong> didn't know if it was my fault or GCJ's, but fedora's sources simply don't compile on ubuntu's java stack
<slomo> did you talk to doko about it?
<jdong> slomo: no, I gave the package back to bddebian and ran in the opposite direction
<jdong> we need eclipse 3.2 before we can even consider azureus 2.5.0.0 though
<jdong> and that's plenty to keep doko occupied :)
<jdong> besides, who needs azureus with a properly working ktorrent anyway
* jdong puts on flamesuit
<bddebian> jdong: Well I certainly don't need it ;-P
<jordi> Riddell: ping
<Riddell> hi jordi 
<gnomefreak> doko_: can you ping me when you get a minute please
<doko_> gnomefreak: no. just start typing
<gnomefreak> oh ok
<gnomefreak> take a look at bug 45705 is it safe to close? 
<Ubugtu> Malone bug 45705 in ia32-libs "Error in Dist-upgrade on Dapper" [High,Confirmed]  http://launchpad.net/bugs/45705
<gnomefreak> come to think about it dholbach asked about that on another bug this morning
<Kamion> Seveas: yes, that was incorrect, it's a different exit code
<gnomefreak> i was under the impression that is too dangerous to update on a stable system
<doko_> gnomefreak: look, who's the assignee and ask him. maybe it should be closed, because it was only a problem in dapper, and not one with the upgrade from earlier releases
<gnomefreak> k
<elmo> hmm, a package diff between default dapper install and default edgy install is fascinating
<Kamion> slomo,doko_: can you identify the exact fix in the python-support changelog that fixes bug 59775?
<Ubugtu> Malone bug 59775 in dbus-python "dbus-python is broken" [Undecided,Fix released]  http://launchpad.net/bugs/59775
<Kamion> elmo: yeah, gparted is like that
<slomo> Kamion: i can't... i never had the problem myself but the user said that upgrading fixed it for him
<Kamion> that's not very acceptable for a UVF exception
<slomo> apart from that upgrading fixed the python-gobject breakage seb128 saw earlier today
<Kamion> I need to be sure that that change is required, and that it's not some other mystical voodoo that fixed the problem
<seb128> a python-support fix is required for sure
<Kamion> WHICH python-support fix?
<Kamion> there's a changelog in the UVF exception request bug - if somebody can point me to the lines of the changelog describing the fix, that would help me
<seb128> dunno, doko said it's fixed by one of the new versions from Debian, looking at it
<Kamion> doko_: help :)
<seb128> Kamion: might be http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=383799
<Ubugtu> Debian bug 383799 in bittornado "ImportError: No module named BitTornado" [Serious,Closed]  
<seb128> "   * update-python-modules: check for .path presence when checking for
<seb128>      newly installed python versions, otherwise stuff might not be
<seb128>      compiled for it (closes: #383799, medium-urgency fix)."
<seb128> from the changelog
<Kamion> ok, that looks plausible, thanks
<seb128> np
<doko_> Kamion: and we need a rebuild (done with the sync as well) to add python2.5 support (didn't look at it)
<doko_> Kamion: can I bribe you with CD space, if you process openoffice.org in NEW? ;)
<Kamion> doko_: there are several dependency generation fixes in that python-support changelog; after the new python-support is available, could you please scan through the archive for breakage due to that and upload anything that needs to be fixed?
<Kamion> doko_: give me a minute dude, I was away for the last hour doing urgent bank stuff
<Kamion> I've only been back for <10 minutes
<doko_> Kamion: yes, already said to seb128, that I will do it
<doko_> Kamion (didn't realize that you were away)
<doko_> Riddell: ping
<Riddell> hi doko_ 
<Kamion> doko_: OOo accepted
<doko_> Kamion: thanks :)
<ogra> Kamion, remind me, why did we default to a fixed hostname in edubuntu ?
<doko_> Kamion: you just got 17MB on the CD
<ogra> doko_, ??
<ogra> doko_, you are joking, right ? you dont introduce 17MB extra on the CDs after beta
<slomo> i guess he means -17MB 
<ogra> i hope so :)
<_ion> Does anybody really use the Windows software on the Live-CDs? :-)
<ogra> windows users ?
<Kamion> ogra: I honestly can't say I remember any more
<_ion> Nah, they either download newer versions of the software, or burn whatsitsname... OpenCD?
<Kamion> _ion: yes - it's a fantastic easy first step for new users
<Kamion> _ion: Eben Moglen will enthuse about this approach if you let him - he had great success converting several people to free software using it
<_ion> Perhaps someone could do some evil hack to make e.g. Linux and Windows versions of Firefox and OOo on the Live-CD use the same data files. ;-)
<Kamion> you get them using the Windows software first, then you say "hey, if you liked that, just boot from the CD and try out the rest"
<ogra> Kamion, it somehow appears silly to me ... we should probably change it ... veven though i'm sure it was my decision ...
<Kamion> ogra: it'd be worth searching through IRC logs to find out the reason first
<Kamion> ogra: FWIW I made the change on 2005-07-29
<Kamion> doko_: thanks!
<Kamion> doko_: the -gcj variants seem larger than the non-gcj variants, as a general rule ... do the -gcj variants end up on the CD?
<doko_> Kamion: no
<Kamion> ok
<doko_> Kamion: if they are found, they are used (native code), if not, the code is interpreted
<Kamion> doko_: ok, processed all the GCJ stuff
<doko_> great!
<jdong> doko_: is eclipse 3.2 planned for edgy or edgy+1?
<doko_> jdong: there's nothing planned; doing eclipse in my free time.
<jdong> doko_: ok, just curious
<sivang> re all
<Riddell> tfheen: the accessiblity changes in kubuntu beta don't seem to work, is there a way to debug that at all?
<Tonio_> mdz: just wanted to know if the informations on bug bugs 62544 are enough or if you need more ?
<Ubugtu> Malone bug 62544 in kaffeine "0.8.1 -> 0.8.2 UVF Exception Request" [Undecided,Unconfirmed]  http://launchpad.net/bugs/62544
<mdz> Tonio_: I received your email and will review it with the other freeze exceptions in my queue
<Tonio_> mdz: thanks
<LaserJock> mdz: is it possible to remove the latest version of a package from edgy Universe, or do you have to upload a new package over it?
<heno> Riddell: Kamion said there was a small bug in the a11y scripts. I guess the fix is on its way
<Riddell> heno: so it doesn't work for ubuntu either?
<heno> Riddell: correct
<Riddell> heno: ok, makes it nicer for me :)
<pitti> BenC: new kernel&apport combo works nicely now :)
<mjg59> Who's supposed to be looking after gnome-power-manager at the moment?
<bluefoxicy> png_pov.cpp:(.text+0x358f): undefined reference to `png_write_finish_row'
<bluefoxicy> hrm.... why is that symbol not in libpng12?  ... ah well.
<kristog> mjg59: ?
<mjg59> kristog: Who's supposed to be dealing with gnome-power-manager bugs at the moment?
<kristog> whoa 130 bugs, debian only 14.
<mjg59> Right
<Kamion> heno: I uploaded the fix this morning
<heno> Kamion: cool, I'll give it a test 
<_ion> mjg59: Hi
<dholbach> hey _ion!!!
<_ion> Hi dholbach 
<dholbach> _ion: how are you! good to see you again!
<_ion> dholbach: Good to see you. :-) I've managed to debug a problem with loudmouth a bit. Seems like it doesn't support STARTTLS at all. My jabber server requires using it, and loudmouth crashes when connecting. I haven't yet been able to fix the crash.
<_ion> dholbach: I.e. both telepathy-gabble and gossip crash.
<dholbach> _ion: urg
* jdong|laptop drools over squashfs 3.1's multithreaded capability
<dholbach> _ion: would you please file a bug with debug backtrace in LP for that?
<jdong|laptop> there's probably not a chance that we can get squash 3.1 in edgy, right?
<dholbach> _ion: I'm happy to forward it to the (somewhat obscure) upstream bug tracker
<_ion> dholbach: Yeah, i'm going to file the bug. I've thought i'd submit a patch that fixes the problem at the same time, but i haven't been able to fix it yet. I'll probably file the bug today anyway.
<dholbach> _ion: thanks a lot for that
<_ion> dholbach: There's some strange stuff going on with function callbacks. :-)
<ogra> jdong|laptop, i wouldnt oppose a gcompris backport ... if it builds and doesnt crash 
<seb128> mjg59: no real maintainer, ogra is doing updates usually, I don't think he looks at bugs for it though
<seb128> jdong: you are doing backports? Any reason there is rhythmbox 0.9.5 bakports for dapper done?
<ogra> well, roughly ... as time permits ... i'd appreciate to give away maintenance to someone who can put in more time 
<ogra> mjg59, ^^
<_ion> mjg59: Have you noticed this patch? https://launchpad.net/distros/ubuntu/+source/usplash/+bug/62865/comments/1
<Ubugtu> Malone bug 62865 in usplash "1024x768 with nVidia GeForce4 Ti 4800 SE: "screen init failed"" [Undecided,Unconfirmed]  
<kristog> seb128: ogra mjg59 i will take a look on gpm bugs.
<ogra> kristog, very much appreciated ... if we ever meet remind me to pay you a barrel of beer ;)
<kristog> ogra: ahahah thank you :)
<seb128> kristog: thank you, you rock!
<jdong> ogra / seb128: ok, I'll look at those two backports soon
<seb128> jdong: thank you
* jdong has been somewhat swamped recently... sorry for any backlog
<seb128> np, we know "too much too do" feeling too ;)
<ogra> right, totally ... :)
<seb128> s/too do/to do
<seb128> any, dinner time
<jdong>  -> Considering  libnautilus-burn-dev (>= 2.15.3)
<seb128> bbl
<pitti> seb128: enjoy
<seb128> jdong: hum, k, better to close the backport task opened for some time then
<jdong> k
<seb128> bah, new n-c-b is not required
<seb128> the Build-Depends has been bumped to catch a soname change I think
<seb128> I'll have a look after dinner
<jdong> I'll leave the ticket open then
* jdong grabs lunch
<pitti> slomo: liferea approved
<slomo> pitti: woohoo :)
<pitti> imbrandon, Riddell, seb128, Tonio_: FYI, I'm processing MIR now and approved some (not yet finished)
<pitti> please tell me if you need something urgently, I won't process the whole queue
<BenC> pitti: good news (re apport+kernel)
<pitti> BenC: interesting that unlink() was the culprit...
<slomo> pitti: now what's the process to get it into main but not installed by default? asking an archive admin or is there something else now?
<pitti> slomo: it needs to be seeded to 'supported'
<pitti> slomo: once that happened, anastacia will demand promotion, and the archive guys will do it
<BenC> pitti: vfs_unlink() in the kernel was just not being nice
<slomo> pitti: ok, thanks :) is there a FF exception or something needed at this point?
<BenC> pitti: so I tried to use sys_unlink() (which is the userspace syscall function for unlink()), but it didn't want to actually unlink the files
<pitti> slomo: not FF, but I'm not sure whether mdz is happy with new main packages at this point; better ask him
<pitti> BenC: I think I got it pretty solid now in apport, but of course I can't guarantee that cores are deleted in all circumstances
<slomo> mdz: are you fine with adding liferea to the supported seed for edgy? or better wait for next release?
<pitti> BenC: like, if apport itself segfaults (happened recently with python-apt, for example)
<BenC> pitti: in those cases, it may be nice to keep the core around any way to help reproduce the apport bug
<seb128> pitti: meanwhile would be nice
<pitti> seb128: already done
<seb128> cool
* seb128 hugs pitti
<siretart> pitti: do you know why cryptsetup isn't in main?
<siretart> I wonder why I don't find any report or request about it
<pitti> siretart: mainly because noone bothered hard enough to ask for it
<siretart> ah
<slomo> siretart: i want it in main ;) but it currently breaks very bad with upstart (at least for me)
<Tonio_> pitti: hehe, thanks, good to ear this :)
<siretart> slomo: I see it the other way round: upstart breaks cryptsetup very hard. it doesn't give the cryptsetup init script a controlling tty
<Tonio_> pitti: urgency for kubuntu is digikam, but it requires 2 libs to be approved aswell...
<pitti> Tonio_: all done
<slomo> siretart: or that... but keybuk said it's cryptsetup bug and i didn't look too hard yet because of no time ;)
<Tonio_> pitti: fabulous !
<siretart> slomo: well. he is obviously a bit biased, no? ;)
<slomo> siretart: if you want to fix the part that does it wrong you'll get a beer from me when we meet some day ;)
<siretart> slomo: its quite hard to input a passphrase without an tty, no?
<slomo> well, i trusted him :P
<pitti> slomo, siretart: oh, you didn't meet so far?
<siretart> no only irc so far
* pitti drank beer with both of you so far
<slomo> siretart: it gets an tty according to Keybuk
<siretart> oh
<mjg59> _ion: Yeah, I've been ill
<mjg59> I'll get to it
<siretart> hm. I'm just on my 2nd try to upgrade my workstation to edgy. lets see if it succeeds today
<slomo> siretart: or at least should.... it should be called with < /dev/console > /dev/console but iirc the init script does this already
<mjg59> seb128: That's rather less than ideal
<seb128> mjg59: right, the issue is that everybody from the team is already overloaded so nobody is wanting to step for it
<_ion> mjg59: Sad to hear it. :-( I hope you get well soon.
<mjg59> seb128: At the moment there are several regressions over dapper
<_ion> The fsck script contains something like 'exec </dev/console >/dev/console 2>&1' IIRC
<mjg59> I don't have time to do anything about it right now
<_ion> Oh, i missed slomo's last line.
<slomo> _ion: cryptsetup's init script has this too
<seb128> mjg59: if you find regressions mark them as high importance, we will try to have a look to them before edgy
<siretart> if I understood Keybook correctly, cryptsetup requires a controlling tty. I don't think these redirections do support them
<siretart> I was told today by a collegue that cryptsetup was broken with sysvinit too: he got asked his passphrase, but every letter he typed was echoed on the console
<siretart> didn't get to check that yet
<slomo> if we want it in main this definitely has to be fixed first though ;)
<slomo> siretart: i had the echo-passphrase-to-console bug in the past too... but this happened only short before upstart broke it completely ;)
<Ng> mjg59: about?
<Ng> mjg59: a while back I mentioned having to enable the softled option for the atheros in my X40 and you suggested filing it as a bug, but I forgot which package you suggested filing it against
<elmo> deskbar applet == teh buggy
<mjg59> Ng: linux-restricted-modules
<Ng> k
<Kamion> linux-restricted-modules-2.6.15 or linux-restricted-modules-2.6.17, in fact
<Kamion> I doubt Malone knows about linux-restricted-modules as such ...
<froud> how is a modules update performed if modules-update is meant to be obsolete ... although it is still installed and works in dapper
<froud> is there an alternative?
<Ng> Kamion: technically the bug applies to both, since I had to do this in dapper too, but presumably it's not likely to be fixed there? ;)
<Kamion> Ng: doesn't sound serious enough, at a first hearing
<Ng> Kamion: I have absolutely nothing by way of a case for it for dapper, it's just an LED blinkying or not :)
<jdong> !seen keybuk
<jdong> *grumble*
<siretart> ah, hi jdong 
<Kamion> Ng: thought not :)
<siretart> jdong: I've seen that you tried backporting libxine, did you also compile the extracodecs package?
<jdong> siretart: yes, both do backport cleanly
<jdong> siretart: I was talking to slomo about it yesterday, and he wants it to build against internal ffmpeg though
<siretart> oh
<jdong> he said that dapper's ffmpeg is too old, and he'd rather use the internal ffmpeg
<siretart> well, this is indeed a valid point
<slomo> siretart: because the ffmpeg in dapper is fairly old and i expect regressions
<siretart> right
<siretart> jdong: do backports build in dapper or in dapper-backports chroots?
<jdong> siretart: dapper-backports
<jdong> backports do build against themselves correctly
<siretart> slomo: in this case, how about backporting ffmeg as well?
<slomo> siretart: shouldn't break anything directly... but maybe stuff can't be rebuild anymore against newer ffmpeg
<slomo> has to be tested
<siretart> slomo: stuff in dapper or in dapper-backports?
<slomo> both
<siretart> slomo: stuff in dapper doesn't matter, imo. stuff in dapper-backports is indeed a valid point. but I don't think we have anything else backported which b-d on ffmpeg. I may be wrong, of course
<jdong> slomo: so libavcodec isn't necessarily compatible with dapper's version?
<slomo> jdong: yes but that doesn't matter much, we linked statically in dapper
<jdong> slomo: oh, ok
<slomo> can only happen that stuff from dapper is not buildable anymore with the backported ffmpeg
<jdong> that seems like it's not the end of the world :)
<siretart> jdong: remember, ffmpeg is always a royal pain in the ass :/
<jdong> siretart: yeah, I'm noticing that
<jdong> I'm sending an ffmpeg through pbuilder right now
<jdong> it looks like it'll do fine
<keescook> joy, I've been working on ffmpeg/xine-lib security patches too.
<jdong> testing it is another story though :D
<siretart> great. 2nd. upgrade to edgy, now to screen remains black after booting the new kernel
<siretart> any ideas or pointer how to debug?
<jdong> siretart: take off quiet?
<jdong> keescook: oh boy... fun... that shouldn't be affected by dapper-backports work though
<jdong> keescook: dapper-backports (i'd expect) has a much narrower audience than dapper-update/dapper-security
<keescook> jdong: yup, I agree.
<keescook> just figured I'd raise my hand and share the ffmpeg pain with you
<jdong> i386/dsputil_mmx.c:630: error: can't find a register in class 'GENERAL_REGS' while reloading 'asm'
<jdong> it doesn't look like ffmpeg will build with dapper's gcc?
<slomo> jdong: -fomit-frame-pointer fixes this on x86 ;)
<slomo> or newer gcc
<jdong> slomo: oh. but I can't frickin fomit-frame-pointer backports packages :D
<siretart> jdong: interesting. without splash and quiet, now I noticed that linux-restricted-modules. in fact, there are many package upgrades missing.. hmmm. anyway, good tip
<jdong> siretart: hmm, did you pull in ubuntu-desktop?
<siretart> jdong: I trusted update-manager to do its job. previously, ubuntu-desktop was installed
<jdong> ah, ok
<jdong> siretart: I just got word back from jenda that update-manager worked like a charm for him
<siretart> jdong: I made good experiences with update-manager until this upgrade
<jdong> hmm, maybe update-manager bug then...
<siretart> already filed as bug #63617
<Ubugtu> Malone bug 63617 in upgrade-system "crash while removing packages" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63617
<smurf> Kamion: ping
<siretart> which package is responsible for breaking my /etc/fstab by trying to mount my filesystems via UUID?
<Kamion> smurf: hi
<smurf> siretart: why is that broken?
<Kamion> volumeid
<Kamion> (source package udev)
<siretart> smurf: mount -a; \n result: mount: special device /dev/disk/by-uuid/9c9cfasdfa-waef-d234-235 does not exist
<Kamion> that's the default in edgy though, and it works for most people, so your claim is a bit too broad ...
<siretart> hrmpf
<Kamion> "w" doesn't sound like a character that should be in a UUID
<siretart> I cheated
<Kamion> in fact that UUID is entirely broken
<smurf> Kamion: I'm just installing the beta from the alternate CD and note that the "no support for your language on the CD. do you want to download?" question shows up very late.
<slomo> siretart: is this your encrypted partition?
<smurf> Kamion: if I were a sysadmin, I'd have wandered off by now, and would be rather annoyed upon coming back that the installation hasn't progressed much ... might it be possible to ask that somewhat earlier?
<Kamion> smurf: no later than in dapper ...
<smurf> Kamion: I didn't try that in dapper ;-)
<siretart> I don't have X on that machine yet
<siretart> slomo: no, I have only cryptoswap on that machine
<slomo> siretart: ok, no idea then
<siretart> Kamion: well, the special thing I use here is lvm on software raid
<Kamion> smurf: tricky - the obvious place would be a base-installer hook, but I don't think those get to talk to debconf
<Kamion> siretart: IIRC that's fixed in current udev, so a dapper->edgy upgrade won't suffer this problem
<Kamion> udev (093-0ubuntu16) edgy; urgency=low
<Kamion>   * Don't convert software RAID (/dev/md[0-9] *) devices to UUID as there's
<Kamion>     something nasty in that woodshed.  Ubuntu: #62476.
<Kamion>  -- Scott James Remnant <scott@ubuntu.com>  Tue, 26 Sep 2006 17:17:05 +0100
<siretart> interestingly, it works for /, but not for other filesystems on that vg
<JB[away] > hey guys, when does you want to fix the mod_proxy bug -> https://launchpad.net/distros/ubuntu/+source/apache2/+bug/62820 ???
<Ubugtu> Malone bug 62820 in apache2 "RPC over HTTP" [Undecided,Unconfirmed]  
<siretart> Kamion: I upgraded from dapper 15min ago. so I can confirm that bug is not fixed
<smurf> Kamion: OK -- I translate your answer to "we should think about that after Edgy".
<Kamion> siretart: ok, file a bug on udev then, attaching /etc/fstab.pre-uuid
<cbx33> is there news on MV
<smurf> Kamion: ... alternately, is there a reason why somebody might answer "no" to that question? Otherwise we could just prioritize it away
<Kamion> smurf: yeah, I can't think of an easy way to do it unfortunately without shunting questions around to packages where they don't belong
<zul> cbx33: heh good im not the only wondering
<Kamion> smurf: absolutely - downloading language-support-* takes a lot of bandwidth
<Kamion> smurf: I added that question because I was fed up of having to wait for language-support-ja or whatever to download during tests
<cbx33> zul, heheh
<Kamion> and it seemed likely that people doing a custom install might not necessarily care about input methods
<smurf> Kamion: fair enough
<JB[away] > hihoooo :)
<siretart> Kamion: filed as bug #63626
<Ubugtu> Malone bug 63626 in udev "udev did convert my lvm on raid filesystems in /etc/fstab" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63626
<Kamion> followed up
<Kamion> JB[away] : if nobody's answering, it's because nobody here knows about / is interested in your bug
<Kamion> JB[away] : perhaps a mailing list post would be more fruitful
<JB[away] > :(
<JB[away] > but it is important
<Kamion> Many bugs are important, but we have limited resources.
<Kamion> That sounds like the sort of bug we generally rely on upstream to fix.
<JB[away] > sure, but i thought that ubuntu dapper is very stable
<Kamion> Yes, it doesn't change much :-)
<JB[away] > but have a important bug :(
<Kamion> If there is a *known* patch for this issue, then it can be backported
<Kamion> but the patch needs to be identified
<JB[away] > apache havent relaesed e patch
<JB[away] > :(
<JB[away] > they fixed the bug on the version 2.0.56 without a patch
<pitti> JB[away] : then it's a matter of finding the patch in their cvs
<Kamion> Apache use revision control; there's no need for them to release individual patches when anyone can extract them from the revision control system
* Kamion goes off for the evening
<Kamion> night all
<kristog> night
<zul> later Kamion 
<pitti> bye Kamion 
<JB[away] > pitti i have speak with the apache developer
<JB[away] > and a patch would't released
<pitti> JB[away] : well, if they fixed the bug upstream, they must have a patch :)
<pitti> JB[away] : it's just not separately distributed/announced
<JB[away] > sure why not?
<JB[away] > apache fixed it on 2.0.56
<JB[away] > but my distri (ubuntu) have only 2.0.55
<zul> then its just a matter of finding the fix
<JB[away] > i cant find :(
<pitti> also, for edgy, requesting an UVF exception for apache2 sounds generally reasonable
<pitti> their stable branches have a good reputation
<JB[away] > http://issues.apache.org/bugzilla/attachment.cgi?id=16744
<JB[away] > is this the patch?
<pitti> looks very much like it
<JB[away] > and now?
<pitti> please add a comment to the ubuntu bug with the link to the bug
<pitti> s/bug/patch/
<JB[away] > https://launchpad.net/distros/ubuntu/+source/apache2/+bug/62820
<JB[away] > :)
<Ubugtu> Malone bug 62820 in apache2 "RPC over HTTP" [Undecided,Unconfirmed]  
<tfheen> Riddell: break=casper-bottom and step through 30accessibility by hand?
<JB[away] > duoble post @ pitti ? :)
<pitti> JB[away] : no, a link to the upstream patch is prefered to an attachment
<JB[away] > oo sorry, 
<pitti> JB[away] : alright, I marked the bug appropriately, will get fixed for edgy
<JB[away] > for edgy?
<JB[away] > i need them for dapper :(
<pitti> that's considerably more effort: https://wiki.ubuntu.com/StableReleaseUpdates
<pitti> and I don't have the time to pursue that
<pitti> and it's not the kind of bug we fix in stable releases
<JB[away] > i cant use so ubuntu on my server
<gnomefreak> infinity: if you are here, i would like to know if ia32-lib was fixed with breezy > dapper upgrade
<JB[away] > ok i degraded to debian sarge, the apache works fine
<froud> I read somewhere that Ubuntu Kernels provide modules to support IPSec out the box. Is this so?
<joejaxx> JB[away] : do you know how is responsible for the generation of the ubuntu cd images?
<joejaxx> or froud*
<JB[away] > no
<mc44> joejaxx, you probably want tfheen
<mc44> joejaxx, if you mean the live cds
<joejaxx> mc44: thank you 
<tfheen> joejaxx: hmm?
<joejaxx> tfheen: may i pm you?
<tfheen> joejaxx: sure.
<_ion> froud: The problem with IPsec is different implementations being bug-incompatible with each other. I'd recommend openvpn. (Offtopic, sorry.)
<froud> _ion: openvpn and openswan in universe. Regardless of which solution, shouldn't Ubuntu kernels ship with support for IPSec, I mean it is IETF and practically the defacto std.
<sivang> pitti: you have an idea how to workaround the fact that under a chroot, programs cannot access mount points etc? have youever run into this?
<sivang> pitti: (I need to be able to install DB2 under a chroot, but installer failes when attempting to access physical mount points)
<pitti> sivang: bind mounts usually help
<sivang> pitti: but /home is already bind mounted
<sivang> pitti: do you like bind mount /dev/sda1 to somewhere ?
<pitti> sivang: do you want to access physical device nodes or mount points? /dev/sda1 is not a mount point :)
<sivang> pitti: i would say mount points
<sivang> :-)
<seb128> ogra: new gnome-screensaver 2.16.1 available
<sivang> pitti: I should probably mount bind /
<pitti> sivang: you most probably do not want that...
<sivang> pitti: but then I wouldn't it be actually putting stuff into / of my non chroot environment, making the chroot useless?
<sivang> pitti: right then
#ubuntu-devel 2006-10-03
<joejaxx> Kamion: may i pm you?
<sivang> night all
<Viper550> I ported Dapper's Usplash to Edgy
<leonel> ei ei  Egdy with  gnome  2.16.1 ??   
<leonel> Nice !
<leonel> just updated and came gnome-applets 2.16.1
<leonel> thanks  guys really  great Job
<kinema> I'm looking for documentation and/or specifications on how deb package repositories are formatted.
<kinema> Directory hierarchies, packages.gz, etc...
<kinema> never mind.. i just found the repository howto at debian
<fabbione> morning
<Hobbsee> hey fabbione 
<fabbione> hey Hobbsee 
<jdong> holy crap the git tree looks busy :)
<jdong> am I reading correctly that edgy will have HT off by default, can be enabled via ht=on?
<fabbione> jdong: it has been like that since hoary or breezy
<fabbione> jdong: that's to circumvent an hw security flow in ht design
<jdong> fabbione: oh, ok
<fabbione> jdong: we can't fix it, but we can leave the option to the users
<fabbione> neither upstream is interested in working around a hw bug
<jdong> fabbione: thanks for the info... yeah I remember reading about that somewhere
<BlingBonk] > Anyone Heard of Richard Stallman
<fabbione> no problem
* jdong thinks it should be mentioned in the release notes though
<jdong> just as a thought
<fabbione> jdong: no, it's something that has been there forever
<fabbione> pointless
<jdong> ok
<fabbione> tfheen: ping?
<tfheen> fabbione: hello
<fabbione> heyya
<fabbione> tfheen: http://people.ubuntu.com/~fabbione/xorg.debdiff <-
<tfheen> fabbione: uh, that looks bogus.
<fabbione> ?
<tfheen> hmm, no
<tfheen> sorry, mea culpa.
<tfheen> ok, go ahead.
<fabbione> ok thanks
<Burgundavia> ajmitch: krb5-auth-dialog <-- this SoC work?
<ajmitch> Burgundavia: that's RH code
<ajmitch> I have to resubmit other code to NEW
<fabbione> tfheen: http://people.ubuntu.com/~fabbione/xserver-xorg-video-ati.debdiff <- the debdiff looks huge because i did fix some packaging errors but the real changes are much more contained.
<tfheen> fabbione: you're aware that we're not in "everything must be reviewed before upload" mode just yet?  I don't know that code well enough to judge, so if you want a second pair of eyes, better to ask rodarvus
<fabbione> tfheen: yes i am aware.. i am confident about the changes. i just wanted to make sure changes were not too intrusive
<tfheen> fabbione: that's hard to say when I don't know the code base. :-)
<fabbione> fair enough :)
<sivang> morning
<Keybuk> elmo: ping
<Keybuk> uhh
<Keybuk> what the fuck is up with the wiki?
<Keybuk> I just edited a page, and it errored, and then DELETED the page
<Burgundavia> Keybuk: welcome to the wiki
<Treenaks> moin + disk full?
<Burgundavia> luckily the page history is still there, and can be restored
<Keybuk> how?
<Burgundavia> the get info linki
<ajmitch> some crazy people subscribe to the whole wiki, too
<Burgundavia> however, you cannot restore the page until the saving bug is fixed
<Keybuk> Burgundavia: "Missing 'current' file" when I try that
<Burgundavia> Keybuk: you can view the old revision there
<Seveas> Keybuk, grab a large heavy object and chase the canonical sysadmins
<Burgundavia> Seveas: indeed. He works for the people AND is in the same country
<Keybuk> and I know where they live
<Seveas> someone should warn them for an incoming keybuk
<sivang> "One guided Keybuk coming at 12:00 O'clock. His considered armed and dangerous"
* Seveas enters the nuclear bunker
<Treenaks> Seveas: what? a bunker made out of enriched uranium? :P
<sivang> hehe
<robban> Any date when an official cd will be released with this fix? https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.15/+bug/57265
<Ubugtu> Malone bug 57265 in linux-source-2.6.15 "Return value of slave_configure in scsi_scan.c is ignored" [Undecided,Fix committed]  
<Keybuk> syndicate scott# modprobe nvidia
<Keybuk> Not loading nvidia module; not used in /etc/X11/xorg.conf
<Keybuk> \o/
<Keybuk> mjg59: ^
<seb128> Keybuk: hi. could you sync pilot-link (bug #63654), it's required to fix the ftbfs on evolution? 
<Ubugtu> Malone bug 63654 in pilot-link "Please sync pilot-link (main) from unstable" [Undecided,Confirmed]  http://launchpad.net/bugs/63654
<Keybuk> seb128: yeah, it's archive day today
<Keybuk> just fixing up this first
<seb128> ok :)
<mjg59> Keybuk: Thanks!
<Treenaks> hmm.. LaptopTestingTeam has vanished from the wiki
<Treenaks> Burgundavia?
<Keybuk> mjg59: 
<Keybuk> install if cat /etc/X11/xorg.conf 2>/dev/null | tr A-Z a-z | sed -n -e '/^[ \t] *section[ \t] *"device"/,/^[ \t] *endsection/{/^[ \t] *driver[ \t] */{s/^[ \t] *driver[ \t] *"*//;s/"*[ \t] *$//;p}}' | grep -q -w nvidia; then modprobe --ignore-install -Qb  nvidia; else echo "Not loading nvidia module; not used in /etc/X11/xorg.conf" 1>&2; fi
<mjg59> Keybuk: Needs te same for nvidia-legacy
<Keybuk> mjg59: I did
<mjg59> But other than that, hurrah
<mjg59> Rock
<mjg59> And fglrx?
<Keybuk> we could do fglrx
<_ion> Doesn't \s work as [ \t]  in sed? I might remember wrong.
<Keybuk> _ion: no
<_ion> Ok.
<Keybuk> and that isn't a useless-use-of-cat-award either
<Keybuk> cat is used so I can capture and hide the "file not found" message, without losing any parsing error messages
<_ion> mjg59: Feeling better now?
<Kamion> _ion: no, [[:space:] ]  does though
<_ion> kamion: Yep. :-)
<Keybuk> Kamion: that took longer to type :p
<Kamion> robban: not at present, since a fixed package hasn't even been uploaded yet
<mjg59> _ion: Somewhat
<Kamion> robban: we have no schedule for a second point release of dapper at present
<mjg59> Lots of real world work to do, but I'll try to take a look at usplash
<Keybuk> Kamion: it also only obeys the first use of [[:space:] ] 
<Kamion> Keybuk: huh?
<Keybuk> if you do ^[[:space:] ] *section[[:space:] ] *
<Keybuk> it won't expand the second one
<Kamion> seriously? that's a rather crap bug
<Keybuk> something to do with "performance reasons"
<mjg59> _ion: Which bug number has your patch?
<mjg59> I'll try to fit that in today
<_ion> https://launchpad.net/distros/ubuntu/+source/usplash/+bug/62865/comments/1
<Ubugtu> Malone bug 62865 in usplash "1024x768 with nVidia GeForce4 Ti 4800 SE: "screen init failed"" [Undecided,Unconfirmed]  
<mjg59> Kamion: Having thought about things, it might be the case that we want usplash's resolution algorithm to be dependent on whether the machine is a laptop or not
<mjg59> Kamion: vesa sometimes uses different timings to X. If we use the X modes on machines with analogue outputs, there's more of a chance of us going outside the monitor's frequency range
<Kamion> we need to order things such that usplash is configured after X anyway, so I'm not too bothered about the exact details of what usplash.postinst does
<Kamion> I'll try to sort that out this week
<Keybuk> mjg59: what's the fglrx source package, module name and X driver name?
<mjg59> Keybuk: xorg-driver-fglrx, fglrx, fglrx
<Burgundavia> Treenaks: the wiki is currently having major issues
<Treenaks> Burgundavia: quite..
<Keybuk> mjg59: which source does the module come in?
<mjg59> Keybuk: linux-restricted-modules
<Keybuk> it doesn't have an equivalent of nvidia-kernel-common ?
<mjg59> No
<Keybuk> ok
<Keybuk> I guess you can only install the X driver once :)
<seaLne> has anyone seen this:
<seaLne> apt-get: error while loading shared libraries: /usr/lib/libstdc++.so.6: invalid ELF header
<seaLne> it nly happened on one of my machines, dist-upgrade failed and reruning gives that
<mjg59> seaLne: What does file /usr/lib/libstdc++.so.6 say?
<seaLne> symbolic link to `libstdc++.so.6.0.8'
<mjg59> seaLne: And file /usr/lib/libstdc++.so.6.0.8?
<seaLne> and its data
<mjg59> Your libstdc++ is corrupt somehow
<seaLne> yeah different md5sum
<seaLne> any suggestions?
<mjg59> Reinstall it
<ajmitch> & run fsck when you can
<seaLne> http://rafb.net/paste/results/izapeC23.html
<_ion> Your HDD seems seriously corrupted.
<seaLne> ok, if its just my problem thats good
<Keybuk> ah, this must be some new definition of "good" I wasn't previously aware of
<seaLne> bad for me good for everyone else :-/
* Keybuk starts l-r-m building on his laptop
<Keybuk> this should save on heating bills
* _ion recently built l-r-m to test the new nvidia beta driver.
<_ion> It was too buggy. :-)
<robban> Kamion: Ok, thanks
<minghua> Keybuk: does debian-change-only syncs (no new upstream tarball) requires UVF too now?
<minghua> I was looking at bug 62824
<Ubugtu> Malone bug 62824 in mayavi "[Sync Request]  mayavi 1.5-4 from Debian unstable (main)" [Wishlist,Rejected]  http://launchpad.net/bugs/62824
<Keybuk> no
<Keybuk> I may not have had my glasses on there :)
<minghua> Keybuk: thanks
<ajmitch> how can I make initramfs a bit more verbose on boot so I can see where it is dying?
<Tonio_> Keybuk: hi ! I was searching for someone who could promote a few packages to main...
<Tonio_> Keybuk: they all have been accepted by pitti already
<Keybuk> Tonio_: are they seeded?
<Tonio_> Keybuk: yes
<Keybuk> which packages?
<Keybuk> ajmitch: remove "quiet"
<Tonio_> Keybuk: digikam is seeded, the 2 other packages are dependancies
<Tonio_> Keybuk: source packages are : digikam, dcraw, libkexif
<Keybuk> Tonio_: ok, they'll be done today then
<ajmitch> Keybuk: already removed
<Tonio_> same for binaries
<ajmitch> not booting with usplash, so I don't think I'm running into the nvidia bug there
<Tonio_> Keybuk: source package digikam also produces binary "showphoto", but this one can stay in universe
<ajmitch> I'll try with another kernel
<Tonio_> Keybuk: thanks!
<olemke> seaLne, have you just tried rebooting and see if the problem goes away? I had exactly the same problem with some of the edgy kernels, random libraries were corrupted, but were fine again after a reboot.
<seb128> ogra: are you going the fix the "opengl screensavers should be used only on boxes with graphical acceleration available" issue for edgy?
* mneptok jumps up and down on ogra
<seaLne> olemke: yeah i rebooted but still the same problem, running badblocks to see if there is actually a disk problem
<olemke> seaLne, ok, then it might be really a hardware problem :-(
<ajmitch> hm, might have just been the xen kernel I was using, something else to complain to zul_ about :)
<seaLne> olemke: few week old disk... *shrug*
<elmo> ok, wiki should be back now - no data or changes were lost, but RecentChanges for the last 10 hours is missing - the history on individual pages is still retained though
<ajmitch> thanks, elmo 
<Kamion> BenC: uh - there's no linux-restricted-modules-2.6.17-10-powerpc64-smp, so should linux-restricted-modules-powerpc64-smp maybe be removed again?
<doko_> Keybuk: bug 50811, which ones?
<Ubugtu> Malone bug 50811 in libservlet2.4-java "Broken Dependancy" [Undecided,Rejected]  http://launchpad.net/bugs/50811
<Keybuk> the change to use java-gcj-compat ?
<Kamion> doko_: https://launchpad.net/people/doko/+packages lists a number of build failures under "Uploaded packages", which appear to be part of what's causing openoffice.org-gcj to be uninstallable. Could you look at those?
<Keybuk> you didn't respond when asked
<Kamion> libxalan2-java, libxerces2-java, bsh are the ones I noticed
<doko_> Keybuk: you did?
<doko_> Kamion: will do, although it's bank holiday
<Keybuk> doko: you're subscribed to that bug, and there's a comment asking for your opinion
<Kamion> doko_: whenever it's convenient
<doko_> Keybuk: so dholbach's "go ahead" was not good enough? anyway, I'll look at it
<Keybuk> doko: no
<minghua> doko_, Keybuk: I think you guys misunderstood each other.  Keybuk is rejecting because it can't be synced, as we need -3ubuntu1 instead of -3 to keep ubuntu changes, right?
<Keybuk> minghua: right
<seb128> any reason beagle binary is to universe?
<Keybuk> from my reading of the report, it needs to be merged, and not sync'd
<Keybuk> and dholbach merely approved that
<seb128> beagle-dev and src package are to main
<Keybuk> seb128: it's in anastacia output, so I'm gonna look at it in a bit
<mneptok> oh, duh. the Germans are all off today.
<Kamion> seb128: I just promoted it about two minutes before you said that :)
<seb128> Kamion: thank you
<Kamion> (was cleaning up CD uninstallables)
<tseng> Kamion rules
<seb128> could somebody give a retry to nautilus and yelp builds then? ;)
<seb128> they failed because beagle-dev was not uninstallable (it Depends on beagle)
<tseng> (we still cant find the DD to tell us why he did so)
<tseng> it was never that way before
<tseng> if we can revert it beagle binary could be demoted if that was intentional
<ogra> seb128, i'll surely look into it, but i cant promise it will be non intrusive enough to enter edgy
<ogra> mneptok, ouch, my back
<Keybuk> slomo or siretart: around?
<sivang> mneptok: sent
<sivang> mneptok: hope it's understandable and readable :-)
* Kamion makes another effort to figure out why anastacia wants to promote type-handling
<siretart> Keybuk: yes, (sort of)
<Kamion> Keybuk: did you promote jack-audio-connection-kit and friends?
<Kamion> or did you fix whatever was pulling them in?
<Keybuk> Kamion: neither
<Kamion> must've gone away by itself
<Keybuk> siretart: network-manager-pptp is in NEW
<Keybuk> does this have a freeze exception?
<Kamion> Keybuk: didn't the first upload predate the freeze?
<Kamion>   102437 | S- | network-manager-pptp | 0.6.3+cvs20060819-0u | two days
<Kamion>   101122 | S- | network-manager-pptp | 0.6.3+cvs20060819-0u | five days
<Keybuk> Kamion: it was after the mail went out
<Kamion> ah, didn't check that closely
<Keybuk> several hours after
<siretart> Keybuk: I don't remember a malone bug about it. who uploaded it?
<mjg59> Ngh.
<Keybuk> siretart: nobody I've heard of
<siretart> hm
<mjg59> Has the network-manager "Create network" feature ever worked?
<Kamion> oh, heh, I think type-handling is a subtle germinate bug to do with % (whole-source) processing
<mjg59> Because it really doesn't seem to now
<giftnudel> mjg59: yes, it does
<Keybuk> mjg59: yes
<giftnudel> well, it did
<Keybuk> but that doesn't do what you think
<Keybuk> that creates an ad-hoc network with that name
<tepsipakki> would it be possible for the dapper-backports -changes to contain the changelog compared to the previous version?
<giftnudel> Keybuk: yes, I have done this before
<Keybuk> siretart: Craig Box
<tepsipakki> now the changelogs are useless, since they only have "automated backport upload..". Where to file a bug?
<giftnudel> ubuntu-meta?
<mjg59> Keybuk: Yes, that's what I'd expected
<mjg59> Instead, I got it appearing to attempt to DHCP
<Keybuk> mjg59: oh, then yes, it seems to work
<Keybuk> yeah it does that
<Keybuk> and when the dhcp fails, it falls back to a link-local
<mjg59> And finally timing out and dropping back to there being no network
<Keybuk> oh
<Kamion> giftnudel: no, ubuntu-meta is almost never the right place
<Keybuk> it's entirely possible all that is broken in Ubuntu :)
<mjg59> Keybuk: Heh
<Kamion> tepsipakki: file it without a source package and subscribe ubuntu-archive - it's a script that we haven't got round to getting into soyuz yet
<mjg59> Keybuk: It'd be good if someone else could give it a quick check, and make sure it's not just me
<giftnudel> Kamion: well, I thought for such stuff not belonging to a package
<Kamion> giftnudel: no
<tepsipakki> Kamion: ok, will do
<Kamion> giftnudel: if it doesn't belong to a source package, don't enter a source package at all
<giftnudel> oh, ok
<Kamion> giftnudel: otherwise the few things that really do belong to ubuntu-meta get buried in crap
<giftnudel> right, that shows Ubuntu, correct?
<Kamion> yes
<Keybuk> mjg59: the only laptop I have here is this one
<Keybuk> (in a working state, that is)
<giftnudel> Kamion: well, I forgot you can file a bug without a package, thanks
<ajmitch> Keybuk: first nm-pptp upload predated the freeze by several hours
<siretart> Keybuk: never heared about him as well
<Keybuk> ajmitch: it still appears to post-date it for me
<ajmitch> Keybuk: at least I recall uploading it in the morning before the freeze was announced
<Keybuk> oh hmm
<Keybuk> maybe you're right
<Keybuk> ajmitch: gktools rejected; copying, the source files, and debian/copyright disagree
<StevenK> Nice!
<ajmitch> hm
<ajmitch> I thought I'd checked that one over 
* ajmitch kicks self
<ajmitch> Keybuk: just the missing LGPL eggtryicon.*?
<Keybuk> ajmitch: COPYING is GPL
<Keybuk> source is LGPL
<Keybuk> this requires upstream intervention
<StevenK> And debian/copyright says MIT? :-P
<ajmitch> I must have been blind there
<ajmitch> I'll try & track them down
* Keybuk blinks
<Keybuk> I like this one
<Keybuk> the author has pasted their standard GPL preamble at the top of every source file
<Keybuk> including those copied from gettext
<herzi> tfheen: are you at work today?
<tfheen> herzi: yes
<ogra> herzi, we didnt unite with norway yet so there is no bank holiday :)
<simira> germans...
<ogra> heh
<ajmitch> we'll see if the gktools author responds..
<ogra> simira, it would gain you an extra fee day ;)
<ogra> *free
<sivang> mneptok: did my email reach you ?
<Keybuk> lfittl: ping?
<herzi> tfheen: can you take a look at the casper bug report on launchpad then, please?
<tfheen> herzi: which bug?
<herzi> the one i asked you about on sunday
<lfittl> Keybuk: pong
<herzi> https://launchpad.net/distros/ubuntu/+source/casper/+bug/63277
<Ubugtu> Malone bug 63277 in casper "Doesn't work from USB devices" [Undecided,Unconfirmed]  
<Keybuk> lfittl: I'm rejecting glest and glest-data I'm afraid
<tfheen> herzi: have you tried with today's daily?
<Keybuk> glest is GPL 2, but glest-data has no permission for modification
<Keybuk> so glest-data could go into multiverse
<Keybuk> but the strict dependency between the two implies a GPL violation to me
<lfittl> Keybuk: hmm
<Keybuk> if it were a suggests, and glest could function without the data, then I wouldn't have a problem
<lfittl> Keybuk: and how about putting glest into multiverse as well?
<lfittl> Keybuk: GPL violation also applies to art and code?
<Keybuk> lfittl: like I said, the fact there's a dependency there implies a GPL violation to me
<Keybuk> the two aren't functionally different entities
<Keybuk> so shipping them together means that the data must be GPL also, under the terms of the GPL
<lfittl> Keybuk: ok, thats unfortunate, will try to contact upstream about that, thanks
<Keybuk> if the data could be replaced, or glest could work without it, then I would agree that they were different things
<lfittl> yep, understood
<mneptok> sivang: it did, thanks.
<mneptok> sivang: i will pass along the action items
<Keybuk> I'm erring on a slightly strict side of "intent of the licence" rather than "letter of the licence"
* mneptok tootles off for home
<herzi> tfheen: no, not yet
<herzi> tfheen: is that supposed to be fixed?
<lfittl> Keybuk: what would be your proposed solution for upstream? release the art under a different license?
<Keybuk> lfittl: release the art under a licence that permits modification
<Keybuk> and GPL compatible, obviously
<tfheen> herzi: yes
<Keybuk> given their current text of the art licence permits more free distribution than the GPL allows, I suggest MIT
<Keybuk> or just GPL the artwork
<lfittl> k, and if they don't want to do that, we need at least some sample art that has a gpl compatible license
<Keybuk> then they should release the source under a different (or dual) licence, such that we are permitted to distribute it with the artwork
<Hobbsee> Keybuk: @ https://launchpad.net/distros/ubuntu/+source/gaim-librvp/+bug/63684  <-- remove the one that's in the archive.
<Ubugtu> Malone bug 63684 in gaim-librvp "Please remove gaim-librvp from the archive" [Undecided,Confirmed]  
<Keybuk> Hobbsee: which one is in the archive?
<Hobbsee> 0.8-1
<Keybuk> BZZZT
<Keybuk> incorrect answer
<Hobbsee> the version for 2.x hasnt been written yet :P
<Keybuk> 0.9-1 is in the archive
<Keybuk> it just hasn't built
<Hobbsee> right, so my system....
<Hobbsee> ah.  i checked that originally
<Hobbsee> just cheated and ran apt-cache policy to check
<Hobbsee> indeed, you're right.
<Keybuk> lfittl: ironically, it's distribution that's the problem -- if we didn't attempt to distribute the artwork at all, and it was up to the user to download it an put it in the right place, then I wouldn't be concerned either
<Keybuk> because then we're not violating the GPL by forcing GPL and non-free packages together
<Keybuk> we're just shipping an incomplete (but free) source :)
<lfittl> heh, I always hate license problems ;)
<BenC> Kamion: There should be. The last lrm upload I did enabled it
<ajmitch> Keybuk: well, I got a quick reply on the gktools issue :)
<Kamion> BenC: ah, it failed to build: http://librarian.launchpad.net/4625766/buildlog_ubuntu-edgy-powerpc.linux-restricted-modules-2.6.17_2.6.17.5-8_FAILEDTOBUILD.txt.gz
<BenC> Kamion: Ok, I'll fix that and reupload
<Kamion> thanks
<ogra> hmm
<BenC> no madwifi for ppc64
* StevenK idly wonders how much hard drive space the librarian has kicking around.
<ogra> am i supposed to have the ppc *and* the ppc64 linux-image on the powerpc CD 
<shawarma> Does anyone know where pitti is?
<ajmitch> shawarma: holiday in .de today
<BenC> ogra: Yeah, it can dual boot
<Kamion> ogra: yes
<shawarma> ajmitch: so back tomorrow?
<ajmitch> shawarma: I'd presume so, I can't be certain though :)
<shawarma> ajmitch: Ok, that's fine. thanks.
<ajmitch> sigh, trying to convince an upstream of licensing problems is tedious
<tseng> ajmitch: i hope it isnt RML
<ajmitch> nope
<ajmitch> damn, should have plugged the laptop in
<tseng> you mentioned to me missing gpl header, i told him in person
<tseng> he was not thrilled
<tseng> heh
<ajmitch> g-p-m didn't warn me of battery going flat
<tseng> is there any way to turn off the beep, tw
<tseng> btw
<ajmitch> what beep?
<gnomefreak> Kamion: when you get a sec. with livecd installer grub gets put on MBR correct? I always get an error 15 file not found after grub comes up i choose ubuntu. this is dual boot with win 2k pro and edgy
<tfheen> anybody got an idea about https://launchpad.net/distros/ubuntu/+source/casper/+bug/63398 ?  It's clearly not a casper bug.  I could just say "mdadm and lvm2 were removed on purpose, rejected"
<Ubugtu> Malone bug 63398 in casper "[regression]  live cd doesn't support lvm/md (software raid) devices" [Undecided,Unconfirmed]  
<Kamion> gnomefreak: yes, it goes on the MBR. I think you might need somebody who can cope with grub better than I can
<gnomefreak> Kamion: ok ty
<Kamion> gnomefreak: could be it's pointing at the wrong device or something
<gnomefreak> ill look into it i have to set edgy up on other pc this week so i will see if it happens on that one too. i didnt know if this was a bug that was known. i couldnt locate any on LP about it
<bddebian> Howdy folks
<seb128> hi bddebian
<Keybuk> hmm
<bddebian> Hello seb128
<Keybuk> when a printer doesn't actually print anything
<Keybuk> that means it's broken?
<seb128> Keybuk, infinity: could you give a build retry to nautilus, yelp, evolution ?
<bddebian> Keybuk: Won't print a test page from itself?
<Keybuk> bddebian: it prints it
<Keybuk> but doesn't actually put any ink on the paper
<bddebian> Change the toner/ink? ;-)
<imbrandon> could be a dry inkwell
<Keybuk> seb128: edgy?
<Keybuk> bddebian: done that
<bddebian> Keybuk: Is it a laser or ink jet?
<Keybuk> ink jet
<bddebian> Hmm
<bddebian> You pulled the little plastic strip off the cartridges?
* bddebian ducks
<Keybuk> there wasn't one
<bddebian> Sorry, does it have a head cleaning option, or can you see any gunk built up on the head?
<imbrandon> yea thats what i was gonna say check the heads ( if its not one that has new heads on the ink carts )
<seb128> Keybuk: yep
<Keybuk> bddebian: from fixyourownprinter.com, it seems it's a common problem with this printer model
<Keybuk> and it's a hardware failure
<bddebian> Joy
<Keybuk> doko: libjfreechart-java will need a rebuild?
<Keybuk> likewise libjcommon-java
<Keybuk> Tonio_: ping
<moi1392> hello, I have a feature request for ubuntu and want to submit it here before launchpad to be sure it make sense
<seb128> moi1392: hi
<moi1392> seb128: :) hello
<moi1392> it's about xorg, I frequetly see on forum poeple that configure bad xorg and then it fail to load ! it's specially critical with newbies because the only way for them is to reinstall all the system !
<seb128> what do you suggest to solve that?
<moi1392> I wonder if it's a good idea to have a static second config file (for example /usr/share/X11/xorg.conf) that is set at the installation time and never change, then, if xorg fail to load with /etc/X11/xorg.conf, it could try with that more failsafe config file
<moi1392> it's a low term and low cost solution, but could really help many poeple !!
<Amaranth> I wonder though, how someone would manage to break xorg in a stable release but not know how to fix it.
<moi1392> I don't know anything about X development, but i'm sure it not that hard to implement
<moi1392> Amaranth: many poeple try to change their xorg.conf option for some (not alays good) reason and then the server fail to load
<tepsipakki> the static file would not work if the user changed the adapter
<tepsipakki> ..which uses different driver
<Amaranth> the real solution is adapter and monitor autodetection
<seb128> moi1392: users should not touch something like that if they don't know what they are doing
<moi1392> tepsipakki: we could use the vesa driver for example, it's a "failsafe" solution only
<Amaranth> tepsipakki: not really, vesa would still work
<tepsipakki> of course
<Amaranth> But if you switch PCI slots it'll probably fail
<moi1392> seb128: i'm agree, but users touch it !
<seb128> moi1392: and they learn to not touch it again then :p
<pepsiman> monitor autodetection doesn't work when the monitor is off
<Amaranth> I meant monitor hotplug
<Tonio_> Keybuk: pong
<pepsiman> Amaranth: now that would be cool
<Amaranth> it's possible, apparently it was demoed at GUADEC
<Amaranth> anyway, time to go
<moi1392> seb128: yes, but the first time, the X fail to load and the user is angry against ubnutu and not against itself because he broke it !
<tepsipakki> maybe the error message should say something about a mirror ;)
<Keybuk> Tonio_: digikam moved to main for you
<Tonio_> Keybuk: great, and same for its 2 deps I assume ?
<seb128> moi1392: not a lot we can do against people blaming somebody else when they break something
<Kamion> moi1392: at present, there's no one xorg.conf file that would work properly for everyone
<Keybuk> yup
<moi1392> seb128: yes, we can work to avoid that think to be broken *so easyly* (ok, actually, not that so easyly...)
<Kamion> moi1392: X upstream is working on full autodetection, so that under normal circumstances you won't need xorg.conf at all
<Tonio_> Keybuk: okay thanks, I'm updating kubuntu-desktop
<Kamion> moi1392: that will solve this problem much better
<moi1392> Kamion: I know that, but my idea is only a low term solution, and since *it looks* (may be i'm wrong here..) easy to implement, it could be a good idea
<Kamion> doesn't sound trivial to implement to me
<Kamion> if you want to prove me wrong by means of a patch, you're welcome ;)
<moi1392> Kamion: if I remember well, you can give the xorg config file at a parameter to /usr/bin/X, so if it fail to load, simply retry with a parameter :)
<Kamion> but at present I doubt there's an xorg.conf which will work on all hardware, which brings you back to autodetection, which brings you back to files that people sometimes need to edit and will sometimes screw up
<Kamion> moi1392: doesn't really help, see above
<moi1392> Kamion: I take a look at this later today :)
<Kamion> ultimately, if people are going to go and edit system files by hand, there's only so far you can go to protect them
<Kamion> because you'll find that somebody will write a howto that tells people to edit your next layer of protection
<Kamion> and then you need a third layer
<Kamion> and it all gets totally mad
<Keybuk> Kamion: odd, ubuntu-desktop depends on libgnome2-perl, which depends libgtk2-perl, which depends libcairo-perl, which is in universe
<Keybuk> how do the CDs build?
<Keybuk> ah
<Keybuk> it's a build dep
<Keybuk> sorry
<moi1392> Kamion: agree with that ! but again, it's a short term solution that can prevent some poeple saying aroud "ubuntu is bad, I just miss to change something, or try to install some driver and it doesn't work anymore..."
<Kamion> moi1392: short-term solutions that invent extra files that we then have to carry around for ever, upgrade, etc. are often worse than no solutions, I'm afraid
<Kamion> one has to be careful about which hacks one decides to introduce ...
<moi1392> Kamion: I have no good answer to that :/ you take a point.
<Kamion> moi1392: a better answer might be a way to get to a safe mode from a boot option, like we already have on the live CD
<Kamion> though we already have "recovery mode" which is single-user, so the wording would be difficult at the grub menu
<Keybuk> it'd make sense to merge the two anyway
<Keybuk> single-user could still be an X server
<Kamion> what, have sulogin ask "do you want to continue booting to X?" or something?
<Keybuk> or just not bother with sulogin at all?
<Keybuk> and just leave that there for people who know about kernel command-line options
<Kamion> bit concerned that we'd be breaking some recovery cases where you do need sulogin
<thom> yeah, that sounds like a really bad idea tbh
<Kamion> we shouldn't call it "single-user" if it starts X
<Keybuk> which need sulogin?
<Kamion> if rc2 is fucked
<Keybuk> we don't call it "single-user", we call it "recovery mode"
<Kamion> 14:36 < Keybuk> single-user could still be an X server
<Keybuk> sorry, I meant the grub option
<Kamion> ok
<Kamion> yeah, don't massively object to tat
<Kamion> that
<thom> right
* Keybuk guesses elmo cares about nagios-plugins
<elmo> hmm, what now?
<Keybuk> oh, just demoting nagios to universe ;)
<Keybuk> (actually, I'm not, I promoted its deps -- they were split from a package that was previously in main)
<elmo> I'd be surprised if nagios was ever in main
<elmo> it's not something I can imagine pitti endorsing without violence involved
<Kamion>     nagios | 2:1.3-0+pre6 |         hoary | source
<Keybuk> it has the comment "# SECURITAH REVIEW" next to it
<Keybuk> I'm entirely happy to put it in universe
<elmo> I'm easy, I think we should, if only because it's superseded by nagios2
<elmo> btw - what's the best way for someone as lazy as me to get xvnc4viewer into main?
<elmo> xvncviewer is buggy to the point of unsuability
<Keybuk> oh, well then
<StevenK> elmo: Hack the xfree86 source of the bastard so it builds?
<StevenK> s/of/out of/
<StevenK> That was the situation last I looked at it, if I recall.
<elmo> StevenK: xvncviewer has the same problem?
<StevenK> elmo: Graah. My memory isn't quite that good.
<StevenK> IOW, I'm not sure.
* StevenK wonders if he's awake to look now.
<seb128> infinity: do you know why http://people.ubuntu.com/~pitti/ddebs/pool/main/e/evolution-exchange/ has no i386 version? the package has built on i386 before amd64
<sebest> anybody knows why /proc/net/dev is not updated in real time on ubuntu, it seesm to be updated every 1/2 seconds
<Keybuk> is it updated in real time on any other distrbution?
<StevenK> elmo: Can I suggest you bug pitti? He was the one that pointed out that vnc{,4} still contained Xfree86 code in the source tree, and he may know what it will take to get the damn thing promoted.
<elmo> StevenK: yeah, will, do thanks
<StevenK> elmo: No problem.
<sebest> Keybuk, yes it seems
<sebest> Keybuk, when i do this : for i in `seq 1 1000` ; do cat /proc/net/dev | grep eth0; done
<sebest> on my custom kernel i have a different value on each line
<sebest> on ubuntu, i have 5 different lines
<Keybuk> *shrug* could be caused by anything
<sebest> Keybuk, it seems to be kernel related?
<sebest> and it gives bad behaviour with tools like  nload
<Keybuk> it would definitely be kernel related ;)
<sebest> the graphics of nload are flawed becuase of this
<sebest> because it computes the difference every 500ms, so it gives 0 
<sebest> 1/2 of the time
<sebest> Keybuk, first i thought it could be controlled throught sysctl, but i didn't find anything related to this
<seb128> herzi: does adblocker has an UI now?
<seb128> herzi: and why is it not built by default by upstream?
<herzi> it is built
<seb128> no it's not
<herzi> but it should be enabled in the user config by default
<seb128> or it would be shipped with the package
<seb128> ah
<herzi> sorry
<herzi> today is bug-day for me
<seb128> herzi: I didn't really get your blog on "Ubuntu is like WIndows" BTW
<seb128> herzi: I didn't have to reinstall any of my Ubuntu (out of my desktop because services-admin trashed /etc/rc.d) and I upgrade from version to version
<elmo> someone remind me of the shell idiom to iterate over lines in a file?
<StevenK> for i in $(cat file) ; do echo $i ; done  ?
<elmo> i.e. like for i in <blah>; do <blah> done, but line splitting, not word splitting
<StevenK> Ah
<kristog> while read line ?
<_ion> while read ...; do ... ; done <file
<_ion> That doesn't read the whole file to memory.
<elmo> thanks
<herzi> seb128: yes, updating works
<herzi> but if i update for some releases
<herzi> and then reinstall
<herzi> there's a feelable difference
<seb128> herzi: there should not
<herzi> i have had missing splash screens for breezy, missing upstart for edgy
<herzi> i often feel surprised when setting up new ubuntu versions (as i did this weekend on the laptop as a result of the broken HD)
<Kamion> elmo: IFS='
<Kamion> '
<herzi> surprised in the positive sense
<Kamion> with that literal line-break in there
<Kamion> you'll want to save IFS first and restore it afterwards
<herzi> but then this is also negative because IMHO it should not differ and show all the beauty also when upgrading
<Kamion> elmo: while read works too, and may be easier (lighter on memory too, as _ion said), although it has the disadvantage that any variables you set inside the loop won't be preserved outside the loop because the loop body becomes a subshell
<Kamion> herzi: such things are possible, but we do want to hear about them in the form of bug reports
<herzi> Kamion: the problem is that you don't expect me to have two installations and always compare them
<herzi> so i don't recognize them always in the moment they appear
<herzi> (the missing splash screen was something I realized with dapper, so it was already skipping a whole release)
<_ion> foo | while read x; do foo=42; done; echo $foo  nothing
<seb128> herzi: usually things like that happens when you remove ubuntu-desktop at some point
<_ion> while read x; do foo=42; done < bar; echo $foo  42
<seb128> herzi: because the ubuntu-* make sure you have things like upstart or new splash installed on upgrade otherwise
<_ion> kamion: 
<seb128> herzi: using the dist-upgrader is also a good idea, dunno if you did so, because it has some magic and does smarts things on upgrade
<herzi> seb128: i usually dist-upgrade after modifying the sources.list to play with eg. edgy right now
<seb128> herzi: with ubuntu-* installed before dist-upgrade?
<herzi> so the dist-upgrader won't notice
<herzi> it should
<herzi> but i'm not completely sure
<seb128> herzi: right, my point is that you can't blame Ubuntu do make good upgrades if you don't use the tools that are available for that
<seb128> herzi: update-manager makes sure you have ubuntu-desktop installed I think, it installs it if required and remove it after upgrade or something like that I think (mvo knows that better)
<herzi> i'm using update-manager
<seb128> s/do make good upgrades/to not make good upgrades
<herzi> seb128: of course
<seb128> herzi: update-manager -c -d I mean (the "upgrade to next major version" mode)
<seb128> which has the smart logic I was speaking about
<herzi> ahja, good to know
<herzi> is there a wiki page about that?
<Kamion> _ion: right, true, I'm normally using the former form so I forgot the distinction
<seb128> herzi: http://daniel.holba.ch/blog/?p=14
* seb128 goes for some fresh air, bbl
<ne78> will edgy be relased without rubygems ? That's a blocking issue for rails developper wanting to use rails. The root of the problem seems to be debian not accepting gems (altought they accept python easy_install/cpan/rpm/tar)
<ne78> s/wanting to use rails/wanting to use ubuntu/
<Kamion> Do you have a reference to this alleged Debian problem?
<Kamion> The only upstream source package format accepted by either Debian or Ubuntu is .tar.gz, but it's not uncommon for maintainers to repack whatever upstream happens to ship in the form of a .tar.gz.
<Kamion> In the case of CPAN, they ship .tar.gz source. Source RPMs get repacked. Python source is normally .tar.gz, I believe.
<Kamion> Neither Debian nor Ubuntu is likely to accept foreign *binary* packages in the near future.
<StevenK> Kamion: I think the point is that with Perl, you can use CPAN to install stuff that isn't in Debian. With Ruby/Gems, you can't, since Debian doesn't provide gems.
<Kamion> Is gems the toolset used to install native Ruby packages?
<StevenK> Yup
<StevenK> gems install rails, etc
<Kamion> Then I want a reference to this Debian issue that ne78 mentions.
<StevenK> There's a bug filed, I know. 
* StevenK thinks.
<Kamion> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=334962 is the only one I can find
<Ubugtu> Debian bug 334962 in ruby1.8 "ruby1.8: 1.8.3 breaks RubyGems" [Important,Open]  
<StevenK> That's not it, I just found it.
<Kamion> ah, I see http://pkg-ruby-extras.alioth.debian.org/rubygems.html
* pitti waves
<pitti> slomo: hi
<slomo> hi pitti :)
<Hobbsee> hey pitti 
<tkamppeter> Hi, piiti, did you celebrate the reunification of Germany?
<Kamion> but that says that a rubygems package will be made available
<Kamion> Perhaps one of the MOTUs who knows about ruby should go and talk to the Debian pkg-ruby-extras team and find out whether rubygems is in a state where it can be incorporated
<Kamion> lucas is our normal point of contact there
<ne78> launchpad has https://launchpad.net/distros/ubuntu/+source/rails/+bug/34840 about it
<Ubugtu> Malone bug 34840 in rails "Rails needs gems" [Medium,Rejected]  
<slomo> pitti: did you get my /query?
<tkamppeter> pitti, Mike Sweet has fixed bug 57445, can you package CUPS again, and also for bug 63707?
<Ubugtu> Malone bug 57445 in cupsys "Printing not possible with line break or mis-interpreted encoding in job title" [Undecided,Fix committed]  http://launchpad.net/bugs/57445
<Ubugtu> Malone bug 63707 in cupsys "[edgy]  Error printing HTTP / IPP device-uri" [Medium,Confirmed]  http://launchpad.net/bugs/63707
<Kamion> there's http://packages.debian.org/experimental/interpreters/rubygems
<Kamion> ne78: I suggest you talk to lucas and find out whether he thinks we can sync rubygems from Debian experimental
<ne78> Kamion: that would be great
<ne78> Kamion: who is lucas ?
<StevenK> Kamion: But for Edgy+1, I suspect
<elmo> how the heck do release critical bugs work in malone these days?
<Kamion> ne78: Lucas Nussbaum; he's involved both with Ubuntu and with the Debian pkg-ruby-extras team, I believe. I've commented on the bug you mentioned with a question.
<Kamion> StevenK: If it's vaguely workable and doesn't interfere with ruby, it could be pulled in for edgy
<ne78> Kamion: ok thanks
<Kamion> elmo: set milestone ubuntu-6.10, set appropriate importance
<elmo> Kamion: how do you see milestones in the normal "I'm looking at a bug" page though?
<Tonio_> Kamion, Keybuk, mdz : I just noticed kmplayer-konq-plugins went back to universe, which is an issue still we have it in kubuntu seeds... Is there a reason for this ?
<ne78> StevenK: it doesn't interfer with ruby, it's a optional component without any reverse depends
<pitti> slomo: hi, yes, it took several minutes for my IRC connection to settle
<pitti> hi tkamppeter 
<Kamion> elmo: I don't think you can, without clicking on the fiddle-with-bug-status expander
<Kamion> elmo: we use https://launchpad.net/distros/ubuntu/+milestone/ubuntu-6.10
<pitti> tkamppeter: marked bugs accordingly, will fix tomorrow (I have to care for an urgent issue right now)
<elmo> Kamion: _classy_
<Kamion> elmo: the way it lists all the fixed bugs is particularly good
<Keybuk> Tonio_: it wasn't seeded
<Kamion> desktop: * kmplayer-konq-plugins # more stable than kaffeine
<Kamion> Keybuk: was too
<Riddell> yes, it's in our desktop seed
<Tonio_> Keybuk: afaik it is...
<Keybuk> then it wouldn't have been in the list of things to demote
<Keybuk> so wouldn't have been demoted?
<Kamion> Keybuk: well, it appears to be in the list of things to *promote* now
<Kamion> Keybuk: I think you demoted all of kmplayer source by mistake rather than just some binaries, or something like that
<Keybuk> could have done if it looked like all of kmplayer went into universe
<Keybuk> germinate hasn't settled yet anyway
<Keybuk> will leave it another publisher run and look what needs fixing then
<elmo> Kamion: I think even better is how the sorting ... doesn't
<Kamion> mdz: re bug 61514, would you cry very much if I just nuked the time remaining altogether? With it being rather unreliable due to CD read speeds, I kind of feel like just the percentage ought to be enough
<Ubugtu> Malone bug 61514 in ubiquity "Time remaining display should be less granular" [Low,Confirmed]  http://launchpad.net/bugs/61514
<Kamion> elmo: definitely
<elmo> anyway, would someone (esp. a {ba,}sh fanatic) like to look at 63740 and a) confirm it, b) set it to RC?  if we're going to have ndiswrapper in main, it shouldn't be entirely broken
<Kamion> oh my, and it doesn't even skip duplicates
<tkamppeter> pitti, have seen your comments on the bug reports. Thanks in advance.
<StevenK> bug 63740
<Ubugtu> Malone bug 63740 in ndiswrapper "ndiswrapper wrapper (sic) uses bashisms" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63740
* StevenK is lazy
<pitti> my pleasure :)
<mdz> Kamion: I would not cry if we disabled it for now and did it properly for edgy+1
<Kamion> elmo: I'll just fix it, how about that ...
<elmo> Kamion: giggle, that works too
<Kamion> mdz: I'll take that as a "yes" - I'd rather fix it once while I'm there
<Keybuk> could you fix it to actually work while you're in there
<Keybuk> and generate correct modprobe alias lines?
<Keybuk> so it'll get automatically loaded
<elmo> it worked for me just now - apart from the auto loading part
<elmo> well, once I installed ndis 1.8
<elmo> that's probably another bug
<elmo> well it is - there's several open about it already
<Kamion> Keybuk: why don't you do it then - I have no idea beyond the obvious shell bug
<Kamion> [^...]  -> [!...]  in debian/ndiswrapper and debian/rules
<Keybuk> because I don't know my way around the windows inf files well enough to do it properly
<Keybuk> I've been bugging upstream on/off about it for the best part of a year
<Kamion> in that case, I'll just fix elmo's bug
<Keybuk> I was more arguing for demoting it to universe since it doesn't actually work properly anyway
<BenC> pitti: oooh...I found something you might like for edgy+1
<Kamion> Keybuk: can't say I care
<pitti> BenC: ooh, a surprise??? :)
<BenC> pitti: corename in 2.6.19 kernel (maybe 2.6.18 supports it too) will support pipes, so you can do "| /usr/bin/apport" :)
<pitti> BenC: \o/
<pitti> BenC: well, that still doesn't completely replace our interface since we need the signal number
<BenC> means it can support core's in chroots and such
<pitti> BenC: but maybe the signal number can be extracted from the core
<BenC> pitti: right, but I can build on this functionality now that it's there
<pitti> yeah, that rocks
<BenC> we can revisit this in mountain view
<BenC> I'll have installable kernels for edgy+1 before then
<Keybuk> ya know ... I really prefer the dapper usplash to edgy
<gnomefreak> it feels more complete to me
<gnomefreak> but edgys isnt too bad
<pitti> 'more complete' in the sense that it actually works, yes :)
<Keybuk> the progress bar is far too thin and mean, and having it bunched up at the top of the screen just looks bad
<pitti> </whine>, sorry
<gnomefreak> lol pitti 
<mantiena> Hi all
<gnomefreak> pitti: mine works fine
<heno> Keybuk: agree, why is it so thin and bright?
<sivang> re
<mantiena> maybe somebody knows when language-packs will be updated ?
<elmo> Kamion: thanks (ndiswrapper)
<Kamion> np
<seb128> "Proposal: NetworkManager for GNOME 2.18."
<seb128> interesting
<seb128> let's see how the discussion is going to turn ;)
<slomo> don't think it will be included... it's not really mature enough imho ;)
<seb128> slomo: RedHat and Novell seem to think it is, that will count for something
<Burgwork> slomo, nor do I
<Burgwork> slomo, I wonder if I shoudl start the discussion of with a discussion of why I think it is not mature
<seb128> Burgwork: you think the linux stack behind it is not ready or do you think n-m is not?
<Keybuk> the lack of support for common networking cases is the worrying thing for me
<Keybuk> e.g. static networks
<seb128> it just ignores those for the moment no?
<Burgwork> seb128, n-m
<Keybuk> right, there's no way to set up a static network with NM
<Burgwork> which is tons of fun
<seb128> should not be too hard to fix
<Keybuk> "hard to fix" ?
<Keybuk> well, first you'd have to write a GUI for configuring static networks
<seb128> "use n-m for non-static and keep using what we have for static" would work for now
<Keybuk> that's what we do
<Keybuk> but this to me is a reason not to make it part of GNOME by default
<seb128> right, expected that we don't do n-m
<Keybuk> it's just not complete enough
<seb128> excepted
<seb128> right
<seb128> is somebody working on that part?
<Keybuk> not that I know of
<seb128> I mean if they started working on it 2.18 can be realistic
<Burgwork> Keybuk, what about the atheros issue?
<Keybuk> "the atheros issue" ?
<Burgwork> the fun interaction between n-m and those cards
<jdong> Burgwork: I have an atheros and it appears to work fine with nm
<jdong> two atheroses, actually
<jdong> what interaction is it?
<Keybuk> Burgwork: works for me
<Burgwork> I have had a few issues, but I should probably test nm, given the last one I tested was a few months ago
<jdong> the only issue I can _think_ of is that the available networks list might not refresh properly once you are connected to a network
<doko_> Kamion: all -java binaries built on all archs (db4.4 still in NEW)
<Kamion> doko_: thanks; db4.4 accepted
<Fibbs> Hi folks
<Fibbs> Can someone here explain me what to do to get ubuntu edgy beta to run as a DomU in xen? I have the problem that xen is complaining about the glibc (tls nonsegneg) also after moving /lib/tls away.
<Fibbs> On some distributions there are methods to configure glibc with some config file but i did not find nothing about this
<lotusleaf> Fibbs: have you tried #ubuntu+1
<zul> or #ubuntu-xen
<Fibbs> zul: oh, didn't know that there was a ubuntu-xen channel
<Fibbs> great...
<Fibbs> lotusleaf: What does #ubuntu+1 threat about?
<lotusleaf> Fibbs: see topic here re: support issues and /join #ubuntu+1 for Edgy support and #ubuntu-xen which may help your particular issue
<mantiena> who is responsible for language-packs generation ?
<seb128> mantiena: pitti and carlos and launchpad
<mantiena> seb128, thans
<seb128> np
<seb128> usually better to ask your question
<seb128> easier to give an appropriate reply
<mantiena> pitti, maybe you know when language-packs will be updated ?  ;)
<pitti> mantiena: I'll care for it tomorrow
<pitti> mantiena: we have a new stable release updates process, so I'll just upload them to dapper-proposed for now
<pitti> and to dapper-updates a week after
<mantiena> pitti, I'm asking about language-packs for egdy :)
<pitti> mantiena: ah; well, I'll have them uploaded tomorrow, too
<pitti> mantiena: our normal schedule is 'first Monday in the month', but I was too busy yesterday
<mantiena> ;)
<mantiena> pitti, thanks for info
<jdong> is it a known issue that fglrx isn't modprobing by default anymore?
<jdong> I know there was a recent l-r-m upload that was supposed to make fglrx modprobe by default....
<jdong> if it's used in xorg.conf
<tucoz> hi, i have filed a bugreport and chose the linux-source package. However, this is wrong and i can not change this. Should i close the bugreport, or leave it open even though it is for the wrong package?
<seb128> tucoz: how can't you change it?
<tucoz> I want to change it to xorg-driver-fglrx , but launchpad doesn't find that. And if i wipe out the package text, nothing gets changed.
<tucoz> I figured it was better to have nothing, than the wrong target
<Kamion> tucoz: you need to use a source package name - try 'linux-restricted-modules-2.6.17' (for edgy, or ...-2.6.15 for dapper)
<Kamion> $ apt-cache showsrc xorg-driver-fglrx | head -n1
<Kamion> Package: linux-restricted-modules-2.6.17
<pitti> mantiena: hm, wait - we just recently updated edgy langpacks for the beta, I don't think another update is justified yet; do you see a particular reason to do it now?
<tucoz> ah. so that is how it works. Thank you
<pitti> mantiena: (I'm only concerned about dapper right now, it does need an update)
<jdong> baah... keybuk... you broke my fglrx.ko... :)
<jdong> "   * Don't allow the fglrx module to be loaded if it's not used in xorg.conf"
<jdong> ^^ apparently it doesn't load it even IF it's in xorg.conf :D ^^
<_ion> That's a feature.
<jdong> LOL
<jdong> _ion: are you auditioning to be RMS or something?
<_ion> How did you guess? :-)
<jdong> well, it's indirectly causing bug 63558 too
<Ubugtu> Malone bug 63558 in usplash "Latest usplash leaves my consoles corrupted" [Low,Confirmed]  http://launchpad.net/bugs/63558
<jdong> so I guess that's a feature, too :D
<_ion> I don't have a long enough beard, though.
<jdong> grr... fglrx should really TELL me when its kernel module is not found
<jdong> nvidia does that... (by... bombing out and displaying GDM's BSOD)
<jdong> that way I won't file erroneous bugs on usplash
<mantiena> pitti, yes, I see the reason for updating edgy langpacks at least one time before edgy release candidate :) Now langpacks are more than week old and people are translating, for example I've translated gnome-app-install for edgy 3 days ago :)
<pitti> mantiena: oh, of course we'll update them again for the RC
<pitti> mantiena: but translators should use my daily generated updates for testing
<mantiena> pitti, where ?
<pitti> mantiena: deb http://people.ubuntu.com/~pitti/langpacks/daily/edgy ./
<pitti> mantiena: likewise for s/edgy/dapper-updates/ etc.
<pitti> hi sabdfl
<mantiena> pitti, thanks
<sabdfl> hi efters
<tfheen> hello Mark
<abattoir> Kamion: hi, w.r.t bug 62777 , the fix has not yet been uploaded right?
<Ubugtu> Malone bug 62777 in ubuntu-cdimage "kubuntu installs oem-config-gtk" [Undecided,Fix released]  http://launchpad.net/bugs/62777
<jdong> lol, efters.... gotta remember that one :)
<Kamion> abattoir: I've deployed the fix on the cdimage build machine, but I only committed the corresponding oem-config fix to bzr a few minutes ago
<Kamion> so no, not yet uploaded
<Kamion> I was going to hoover up a few other bugs first
* jdong waves at sabdfl, too
<Kamion> abattoir: I've pushed the branch with the fix, though
<abattoir> Kamion: ok, because i tested 1003 build, doesnt seem to install oem-config at all, i'll try installing again
<Kamion> sounds slightly different, perhaps; /var/log/syslog (or /var/log/installer/syslog after reboot) might be interesting
<sabdfl> hey jdong, how's the backport scene?
<abattoir> Kamion: ok, i'll check that if installation fails again(oem user is created, btw)
<jdong> sabdfl: pretty good, pretty good. finally dapper-backports is working as expected :)
<sabdfl> are you guys basically running it from start to finish?
<jdong> sabdfl: yeah; it's primarily me dealing with the requests, testing the packages, and approving the packages...
<Kamion> abattoir: nod, thanks
<jdong> it's been slightly overwhelming these past few weeks though, still catching up :)
<abattoir> Kamion: thank you ;)
<sabdfl> broad shoulders!
<jdong> yeah
<jdong> I'll also have to try to find the time to go through the MOTU process... more and more I'm finding the need to patch into universe, and I feel kind of bad for nagging folks in #ubuntu-motu to do my dirty work :)
<Riddell> Gloubiboulga: did anyone make a xubuntu usplash?
<Gloubiboulga> Riddell, yes jmak did
<Riddell> Gloubiboulga: great
<t0mmY-> hi there, having trouble with ubiquity, stalls at the time/date setup, anyone have any ideas? thank you.
<jdong> t0mmY-: this is primarily a development channel.... have you tried the other channels of support first?
<jdong> (#ubuntu, #ubuntu+1 if it's Edgy, etc)
<t0mmY-> or at least is there any other ways installing ubuntu edgy with out having to download the alternate cd?
<t0mmY-> jdong, no i have not, sorry, saw the NO support message a little bit to late. :)
<t0mmY-> how about the alternate installer thing? ideas?
<jdong> t0mmY-: make sure it's not a bad burn. do a media check. from the livecd, the only supported installer is ubiquity
<jdong> t0mmY-: else, go for an alternate cd
<Kamion> wait please
<t0mmY-> have done a media check, its ok, so..
<Kamion> let me dig up that bug and find out if it would be useful to have somebody to talk to in real-time who's experiencing it
* Kamion <- ubiquity maintainer
<t0mmY-> okei, nice :)
<jdong> no, Kamion <- installer god :)
<t0mmY-> hehe
<Kamion> t0mmY-: is this the edgy beta?
<t0mmY-> yeah, downloaded the iso today..
<Kamion> t0mmY-: Ubuntu, Kubuntu ...?
<dholbach> bug 62752?
<Ubugtu> Malone bug 62752 in ubiquity "timezone selection in ubiquity hangs, when just proceeding and clicking next" [High,Needs info]  http://launchpad.net/bugs/62752
<t0mmY-> ubuntu
<t0mmY-> okei..
<Kamion> dholbach: thanks, that's the one I was looking for
<t0mmY-> hehe
<dholbach> de rien :)
<rod_> is there some minimal boot cd / floppies to install ubuntu?
<Kamion> t0mmY-: could you start the installer with 'sudo env UBIQUITY_DEBUG=1 ubiquity 2>/tmp/ubiquity.log', reproduce the hang, and attach /tmp/ubiquity.log and /var/log/syslog to bug 62572, please?
<Ubugtu> Malone bug 62572 in totem "totem-gstreamer-firefox-plugin is obsolete and should be removed" [Low,Fix released]  http://launchpad.net/bugs/62572
<Kamion> t0mmY-: er, bug 62752 I mean
<Ubugtu> Malone bug 62752 in ubiquity "timezone selection in ubiquity hangs, when just proceeding and clicking next" [High,Needs info]  http://launchpad.net/bugs/62752
<Kamion> rod_: http://archive.ubuntu.com/ubuntu/dists/edgy/main/installer-i386/current/images/netboot/mini.iso (similar for dapper) is the smallest I support
<Kamion> rod_: that's 8.5MB, downloads the rest from the network
<rod_> awesome, tx Kamion 
<Kamion> haven't been able to cram the kernel onto a floppy, I'm afraid
<jdong> lol
<Kamion> well, it's not laughable, it was possible with 2.4
<Kamion> but we've never had Ubuntu install floppies because we started out with 2.6, and AFAIK nobody's ever managed to get d-i floppies working with 2.6
<rod_> Kamion, heh ^^   It's mostly that I dont want to download first knot1, then knot2, then beta....    Now I can just do clean installs this way
<Kamion> you do need to remember to refresh that install image every so often
<rod_> or whenever when edgy is out, get the latest versions instead of first the stock versions and later download all the mass updates
<Kamion> it'll break whenever the kernel ABI changes, which is relatively often in a development cycle
<rod_> hmm did you just say it uses a 2.4 kenel/
<jdong> Kamion: I haven't used any 2.6-based distros that support floppy kernels at all
<t0mmY-> Kamion, i have now uploaded them too bug 62752
<jdong> Kamion: so I don't think it's a ubuntu or d-i specific problem
<Ubugtu> Malone bug 62752 in ubiquity "timezone selection in ubiquity hangs, when just proceeding and clicking next" [High,Needs info]  http://launchpad.net/bugs/62752
<Kamion> rod_: no, 2.6
<jdong> Kamion: IIRC knoppix still supports like 2 or 3 floppy boots... they split up their images in some way
<Kamion> rod_: we were discussing something else
<jdong> maybe it's just kernel then initrd.gz
<rod_> Kamion, sry, i read it wrong with my lousy english
<jdong> maybe theirs can split that way easily
<rod_> Kamion, since i think you make these iso's... Would you like any feedback after the installation using this iso?
<Kamion> well, the d-i floppy scheme is a boot floppy with kernel, root floppy with initrd, possibly driver floppies
<doko_> Kamion: all CD images are 17MB smaller now. OOo still works; please keep about 4MB free (would like to know from heno, if the -hicontrast icons should be included again)
<Kamion> rod_: bug reports on anything that goes wrong are always good
<Kamion> doko_: great, thanks!
<Kamion> noted
<Kamion> doko_: if you could let me know if you hear that -hicontrast isn't needed, that would be good
<doko_> ok
<Kamion> t0mmY-: oh, I see, it's line-wrapping
<Kamion> see the end of http://librarian.launchpad.net/4643437/syslog - that's wacky
<Kamion> t0mmY-: thanks, that's perfect, I should be able to take it from here
<t0mmY-> Kamion, Alright, what do you suggest for me to do in the mean time? Download alternate cd thingy ? :)
<Kamion> t0mmY-: yep
<jdong> t0mmY-: wait for the next ubiquity, then apt-get update from the livecd? :)
<jdong> if your RAM permits
<t0mmY-> jdong, will that take long? hehe, probably.. or..??
<t0mmY-> i can install applications..
<jdong> t0mmY-: that's a question to ask kamion :)
<t0mmY-> jdong, i knwo..
<jdong> t0mmY-: just enough ram to do an apt-get update and apt-get install ubiquity
<jdong> shouldn't need any more than 512
<jdong> at the most
<t0mmY-> Kamion, long before new package?
<jdong> your sources.list on the livecd needs to reference archive.ubuntu.com though; I expect you know how to change that if it doesn't?
<t0mmY-> jdong, got 1gb at the moment.. so i am good.. :)
<Kamion> well, it's annoying that I can't reproduce the bug, but maybe a day
<Kamion> jdong: that's the default
<t0mmY-> jdong, yeah..
<jdong> Kamion: ok, good to know
<Kamion> t0mmY-: subscribe to that bug and you'll get a mail when it's fixed
<t0mmY-> Kamion, any more information i might provide to help you solve this?
<t0mmY-> Kamion, will do..
<Kamion> t0mmY-: dunno yet :-) my test rig's busy with something else right now, and I'm in a meeting, so I haven't dived in and analysed it in full
<t0mmY-> Kamion, alright, the alternate cd will be downloaded in about 20 minutes so, if you need something before that just ask. :)
<jdong> slomo: any reason why our x264 hasn't been updated since july?
<slomo> jdong: ENOTIME
<slomo> no other reason :)
<jdong> slomo: would we have a chance of UVF'ing that? :D
<slomo> no idea what has changed
<slomo> maybe :)
* jdong has no idea what's changed either, from the ABI perspective
<jdong> from the improvement side, doom9 is raving over newer releases though
* jdong tests building a new x264...
<jdong> slomo: are there any valuable ubuntu chances?
<jdong> changes*
<jdong> to the package
<slomo> look at the package, i can't remember anymore ;)
<slomo> but iirc no
<jdong> doesn't look like it
* jdong starts a pbuilder on debian-marillat package
<jdong> now, the moment of truth.... :)
<jdong> slomo: do we have anything that builds against x264 that I need to check for breakage?
<jdong> I'm testing the obvious mencoder
<jdong> but the media players all decode with libavcodec
<jdong> how do I query for what source packages build-dep on libx264-dev?
<slomo> grep-dctrl on Sources
<jdong> ah, that's a wonderful idea
<slomo> i don't know another way :)
<jdong> slomo: only avidemux and mplayer... I'll test both
<jdong> slomo: the marillat package builds fine in edgy, x264 cmdline works
<jdong> mplayer rebuilt cleanly, too
<jdong> I'm testing it now
<slomo> file an UVF exception later with everything needed
<jdong> slomo: I will
* _ion laughed at the checklist examples. https://lists.ubuntu.com/archives/ubuntu-devel/2006-October/021452.html
<jdong> LOL
<mc44> _ion, another fun thread that wont die :)
<_ion> Yeah. :-)
<Kamion> aha
* Kamion unbreaks oem-config
<jdong> slomo: avidemux needs a simple patch to work around an API change
<jdong> is that still ok?
<jdong> slomo: I'm working out exactly what that "simple patch" is right now :D
<slomo> maybe
<slomo> sorry, i'm busy currently :(
<jdong> slomo: I'll attach the patch to the UVF ticket then. it's a simple two-liner
<sivang> jdong: where do you file he UVF expection tickets? 
<jdong> sivang: launchpad?
<jdong> under the source package
<sivang> jdong: ah, so it's bug reports :-)
<sivang> jdong: sure, just got confused over the "ticket" term
<jdong> sivang: ticket, bug, same thing :)
<jdong> right now, it's just me talking to myself and motu-media getting spammed :D
<jdong> slomo: I've completed the UVFe, assigned it to ubuntu-motu-uvf as I'm supposed to
<jdong> enjoy :)
<_ion> The new community wallpapers are nice.
<tseng> _ion: link?
<_ion> Well, apt-get install_or_source edgy-community-wallpapers :-)
<_ion> Blubuntu, Peace and Tropic being the new ones.
* sivang hopes the firefox bug that prevents from adding book marks will get fixed soon. same for the constant popping window asking if to restore sessions if if it did not crash before.
<Ingmar^> was there any recent change to the xv extension that would cause me to have dropped frames in all video players I installed (vlc, kaffeine & mplayer ) ??
<Ingmar^> evening all :-)
* jdong has no idea...
<jdong> but what video card?
#ubuntu-devel 2006-10-04
<Ingmar^> ati radeon
<Ingmar^> xserver-xorg-video-ati got an update yesterday, but downgrading & restarting my xserver didn't solve it
<Ingmar^> got any idea how I can  
<Ingmar^> got any idea how I can narrow the problem down & find what's wrong ?
<jdub> fabbione: ping
<jdub> with the latest kernel/initramfs combination, myu machine stops booting aafter fsck
<jdub> it boots going back to -9-generic and its old initramfs (haven't tried rebuilding it though, will do now)
<elmo> ehm, dumb question, but how in edgy are you meant to tell firefox to handle file types differently, e.g. not use totem to play video?
<_ion> Edit  Preferences  Content  File Types: Manage  for each format you don't want a plugin to be used, Change Action and select what suits you best.
<_ion> The MediaPlayerConnectivity extension > the Totem plugin. :-)
<elmo> I don't have a MediaPlayerConnectivity extension?  that dialogue you showed me only lists flash as a Download Action I can change
<_ion> Just choose e.g. Save to disk.
<elmo> that's the point dude - I don't get that option in edgy anymore
<_ion> Oh... Worksforme.
<_ion> Unless there has been a Firefox update during the last 4 hours or so.
<jdub> (from above) seems okay after redoing the initramfs for -10-generic
<jdub> i wonder what was out of sync
<jdub> during upgrade
<_ion> Did you backup the faulty initramfs? Do a diff.
<wasabi_> Hmm. I guess it works right, but getting an expense form in .xls is silly. ;)
<simpla> hi guys
<simpla> I have a question on development on ubuntu, can I ask that here?  Or is this channel for development of ubuntu?
<zul> development of ubuntu
<simpla> ok, is there a channel for development on ubuntu?
<zul> i dont think so at least i dont know of one
<simpla> ok thanks
<Fade> development on ubuntu isn't any different than development on any given *nix platform.
<Fade> too fast. ;)
<zul> heh come to the dark side have we kylem 
<kylem> ? i parted a while ago to reclaim some much needed irc tabs.
<zul> ah
<PorkkroP> Hello =>
<fabbione> morning
<fabbione> Treenaks: you around?
<Treenaks> fabbione: yes
<fabbione> Treenaks: yo dude.. i was looking into my irclogs to dig out how to run compiz, but i think they have been lost somehow
<fabbione> Treenaks: mind to give me again the cmd line you use?
<Treenaks> compiz --strict-binding --indirect-rendering gconf
<Treenaks> and gnome-window-decorator --replace
<Treenaks> (compiz might need --replace too)
<Treenaks> and I don't know if 'gconf' is still possible in current edgy
<Treenaks> Also, I saw a git commit (23a6f97e08fd49e1cae03cd97cae67a5f06b7634) in xf86-video-ati that might finally fix bug 20283 \o/
<Ubugtu> Malone bug 20283 in xserver-xorg-driver-ati "[fgl v5000]  really bad sync" [Unknown,Needs info]  http://launchpad.net/bugs/20283
<fabbione> Treenaks: i think i pulled that in yesterday in ubuntu3 (edgy)
<Treenaks> fabbione: it's 11 hours old..
<fabbione> but i can't access gitweb on freedesktop for some reasons
<Treenaks> ""
<Treenaks> "FP timing regs required for both internal and external TMDS"
<fabbione> upstream didn't push that one to me
<Treenaks> so how do I test? get a clean copy from git, an put in a debian/ dir, or get the package, and just apply the single patch from git?
<fabbione> Treenaks: can you actually access the commitdiff on gitweb?
<Treenaks> fabbione: yes
<fabbione> it hangs here
<fabbione> waiting for..
<Treenaks> strange..
<fabbione> it's a network problem or so it seems...
<bronson> Is it possible for mere mortals to download a package from Revu?
<bronson> I need http://revu.tauware.de/details.py?upid=3297 but I can't figure out where the .deb is.
<ajmitch> bronson: revu generally only has source packages
<bronson> source is fine -- I don't mind building it.  All I can find is the individual files that I'd have to wget -r to build.  :)
<ajmitch> .dsc, .diff.gz, .orig.tar.gz
<ajmitch> so the first 3 on the page
<bronson> ok.  ajmitch, thanks.
<dholbach> good morning - HAPPY HUG DAY!
<tfheen> hello Daniel
<Hobbsee_> hey dholbach 
<dholbach> hey Tollef, Sarah!
<tfheen> 'morning Sarah
<Hobbsee> :)
<pitti> Good morning
<bronson> Trying out my new network-manager-openvpn package...
<fabbione> Treenaks: that commit won't work in edgy tree and doesn't fix that bug
<fabbione> Treenaks: and the fix is post-super-patch-of-death-after-release.. that means chances that it applies are < 0
<tepsipakki> before I file a wishlist bug, why is /etc/mtab a file and not a link to /proc/mounts? Surely /proc is always present on ubuntu..
<tfheen> because mtab includes more information than /proc/mounts
<tepsipakki> tfheen: seems to be the other way around here
<tfheen> /etc/mtab:/home/tfheen/live/iso/casper/filesystem.squashfs /mnt squashfs rw,loop=/dev/loop0 0 0
<tfheen> /proc/mounts:/dev/loop0 /mnt squashfs ro 0 0
<tepsipakki> ok, loop-fs..
<tepsipakki> but is that fixable?
<tfheen> probably
<tfheen> but it's not fixed
<bronson> ajmitch: that worked great.  thanks for the hint.
<tepsipakki> tfheen: that's true ;)
<tepsipakki> tfheen: now that we are at it, do you know why /proc/mounts lists tmpfs's twice?
<tfheen> tepsipakki: it doesn't for me
<tepsipakki> oh..
<tfheen> : tfheen@golem ~/live/chroot > grep volatile /proc/mounts
<tfheen> tmpfs /lib/modules/2.6.17-10-generic/volatile tmpfs rw 0 0
<tepsipakki> ah
<tepsipakki> that's an exception, yes
<tepsipakki> but /var/run etc
<tepsipakki> actually three times here
<tfheen> they're probably mounted more than once, then
<tepsipakki> duh
<sivang> morning
<jdub> Keybuk: your website is timing out for me
<Keybuk> whew, anastacia is looking somewhat sassier this morning
<Keybuk> jdub: blame thom
<jdub> well, /blog/ actually
<jdub> www appears to be fine
<Keybuk> works for me
<jdub> oh, but it has moved to blog.
<jdub> and now i don't get dns for it
<Keybuk> no, it hasn't moved to blog.
<Keybuk> clear your cache
<Keybuk> that was a temporary thing
<Keybuk> mozilla is "helpfully" caching the bogus redirect
<jdub> you should fix the link on the front page
<Kamion> Keybuk: anastacia> nice
<jdub> mmm, /blog/ is still taking time
<Keybuk> jdub: ah, well spotted
<Keybuk> taking time => ruby on rails is teh suck
<tfheen> is there a way to list the bugs for a package which are targetted to a particular milestone?
<pitti> tfheen: yes; display the package's bug page -> advanced search -> tick the release
<Keybuk> Kamion: btw, always meant to ask ... there's no way to completely fulfill jessica's wishes and assign priority on a per-arch basis?
<tepsipakki> how come there are no xfonts-*-transcoded -packages?
<tfheen> pitti: oh, point.
<Kamion> Keybuk: correct, unfortunately
<Keybuk> *nods* I tend to just make sure i386/amd64 are right
<Kamion> yeah, that's reasonable
<fabbione> Kamion: hey dude.. when you have 10 spare minutes would you mind to help me with a bug in debconf usage?
<Kamion> actually I think with soyuz you probably can do per-arch priorities
<Kamion> but it's not exactly heavily tested
<Kamion> change-override.py has an -a option
<Kamion> fabbione: sure, now's fine
<fabbione> Kamion: ok great! can you grab redhat-cluster-suite from edgy?
<fabbione> the 2 scripts are cman.config and cman.preinst
<fabbione> i wrote them based on your input
<Kamion> 2.20061002-0ubuntu1 OK?
<fabbione> yeps
<fabbione> for some reasons that i can't understand when i do dapper -> edgy upgrades, no matter what i answer it fails
<Kamion> ok, got them
<Kamion> fails how?
<fabbione> if i just dpkg -i cman it works
<Keybuk> Kamion: it does?  it's not in --help
<fabbione> it hits one of the "exit 1"
<Kamion> Keybuk: oh, maybe it doesn't then
<Kamion> obviously I'm mad
<fabbione> dpkg: error processing /var/cache/apt/archives/cman_2.20061002-0ubuntu1_i386.deb (--unpack):
<fabbione>  subprocess pre-installation script returned error exit status 1
<fabbione> (that was from running apt-get install cman
<Keybuk> Kamion: then what does that make the rest of us? :)
<Kamion> fabbione: can you run it with DEBCONF_DEBUG=developer and put the output somewhere for me please?
<fabbione> Kamion: sure...
<fabbione> http://people.ubuntu.com/~fabbione/debconf.output
<tepsipakki> so, there was the bug #39560 already filed
<Ubugtu> Malone bug 39560 in xfonts-core "The xfonts-*-transcoded packages are missing from Breezy onwards" [Medium,Confirmed]  http://launchpad.net/bugs/39560
<fabbione> Kamion: i can see now where it hits the exit 1
<fabbione> but i am not sure why we did it that way
<Kamion> oh, your error is in assuming that db_input critical failing means that we're noninteractive
<Kamion> it might equally mean that the .config is being run second time round
<Kamion> fabbione: I suggest just moving lines 13 to 19 of the .config (db_input to db_fset) inside the 'if [ "$RET" = false ] ' block just above
<Kamion> you don't need to bother asking the question if seen_in_2.0_upgrade is true (i.e. .config being run second time round)
<fabbione> ok!
* fabbione tests
* Keybuk was having a rising panic reading iwj's dpkg changelog ... until I noticed the "dpkg-source" bit
<tfheen> Kamion: did you just upload a new casper or just commit?
<fabbione> Kamion: thanks
<Kamion> tfheen: upload
<tfheen> Kamion: ok.
<Kamion> wanted to fix that KDE bug
<Kamion> sorry if I got in your way
<tfheen> you did, but that's ok.
<Kamion> Riddell: is there a reason qt3-designer isn't in main?
<AnAnt> I got a problem in Edgy, I upgraded from Dapper to Edgy, now whenever I boot the laptop when connected to LAN, I first get an IP address, then when the boot completes I lose that address, so I have to unplug & plug again to fix that , why is that happening ?
<AnAnt> note: i got whereami & ifplugd installed
<AnAnt> oh btw, there is a bug I think in the Ubuntu Help documents
<AnAnt> I mean the System documentation
<AnAnt> sometimes it misses some words
<AnAnt> for example in the Adding Extra repositories page: in step 1 it says "Open ."
<AnAnt> that seems to be something wrong !
<Keybuk> meh
<Keybuk> does anyone know how to either
<Keybuk> a) make sed case-insensitive
<Keybuk> b) lower-case something without using tr
<pitti> Keybuk: use s/foo/bar/i ?
<pitti> that replaces foo, Foo, or FOO with 'bar'
<Keybuk> pitti: that doesn't work for /.../ though
<Kamion> use sed's y/// command?
<Keybuk> Kamion: doesn't accept ranges
<Kamion> Keybuk: there's a GNU extension /.../I
<Kamion> for case-insenstivity
<Keybuk> I guess we can rely on those
<pitti> Keybuk: echo 'Hello' | sed -r '/hello/I d' works fine
<Keybuk> don't need the -r ?
<pitti> yes, true
<pitti> autofinger...
<agutierr> hello all: I have a problem using  preseeds: process is fine before unpacking language-pack-en: then the installation process becomes slow, and do nothing... I dont know what is wrong. Someone has used an automated install with ubuntu ? Thanks!
<tepsipakki> agutierr: it is generating locales, so it takes time
<agutierr> the installer log shows: Generation complete
<agutierr> but nothing happers
<agutierr> happens
<tepsipakki> on edgy?
<agutierr> dapper
<tepsipakki> how long have you waited?
<tepsipakki> have you checked what processes are running?
<agutierr> Umm
<agutierr> let me a moment
<agutierr> well
<agutierr> generation is complete
<agutierr> now the problem is
<agutierr> the package isntallation is sooo slow
<agutierr> now its installating xresprobe
<agutierr> but... every package takes about 5 minutes
<agutierr> it isnt usual I think
<tepsipakki> does the machine have enough RAM?
<agutierr> 512 M
<tepsipakki> (just guessing here)
<tepsipakki> ok, plenty
<agutierr> previously
<agutierr> i use a debian preseed
<agutierr> it works fine
<tepsipakki> I have ~220 dappers running and havent seen similar
<Keybuk> sweeeet
<Keybuk> C-A-F1, then C-A-D twice very quickly ... :)
<agutierr> Umm
<agutierr> For what ?
<AlinuxOS> Hello, how can I report a bug for Debian if I use Ubuntu ?
<agutierr> my preseed file is: http://paste.uni.cc/10557
<pitti> AlinuxOS: http://www.debian.org/Bugs/Reporting
<pitti> AlinuxOS: in short, install Debian's reportbug and use that
<AlinuxOS> pitti, ;) thank yuu and good morning!
<pitti> AlinuxOS: Good morning, pal :)
<AlinuxOS> I have reportbug package installed
<AlinuxOS> is it useful ?
<siretart> AlinuxOS: yes. just be sure to use the '--bts debian' option.
<seb128> hum
<seb128> pitti: do you know if that might be an apport bug
<seb128> most of the gaim crash bugs look like
<seb128> " Program terminated with signal 6, Aborted.
<seb128>  #0  0x00002baaa029747b in *__GI_raise () from /lib/libc.so.6
<seb128>  #0  0x00002baaa029747b in *__GI_raise () from /lib/libc.so.6
<seb128>  No locals.
<seb128>  #1  0x00002baaa0298da0 in *__GI_abort () from /lib/libc.so.6
<seb128>  No locals.
<seb128>  #2  0x00000000004c0afc in main ()
<seb128>  No symbol table info available."
<AlinuxOS> I so I launch it "reportbug --bts" <---that's ok I think.
<pitti> seb128: well, ATM we catch SIGABRT
<pitti> seb128: I agree that this stack trace is useless, though; gaim seems to have its own signal handler?
<seb128> that's possible, looking
<seb128> pitti: right, they have
<pitti> seb128: and if it catches a SEGV, it calls abort?
<pitti> seb128: probably priting something to stderr before
<seb128> 	case SIGSEGV:
<seb128> 		fprintf(stderr, "%s", segfault_message);
<seb128> 		abort();
<seb128> 		break;
<pitti> ok, that would spoil the apport report
<seb128> k
<seb128> so should I just patch that out?
<pitti> seb128: I think we should prefer proper apport reports over stderr messages, yes
<seb128> doing that
<pitti> seb128: so a mini-patch which just disables the sigaction() call for SIGSEGV etc.?
<seb128> that explain all the useless bt we get ;)
* pitti hugs seb128, master of all bugs
<seb128> just dropping the 
<seb128> "		fprintf(stderr, "%s", segfault_message);
<seb128> 		abort();"
<seb128> should be enough no?
<pitti> seb128: no, then you won't get any crash report at all
<lifeless> have to drop the handler
<lifeless> if you catch the exception, you have to processit
<pitti> seb128: and if you catch a SIGSEGV in gaim, then you need to abort the program anyway
<pitti> it's pretty dangerous to continue the program after a segv
<lifeless> unless you are a VM
<pitti> seb128: the safest thing would be to not catch it at all
<lifeless> if you are a VM, then segv is sometimes /used/ :(
<seb128> static int catch_sig_list[]  = {
<seb128> 	SIGSEGV,
<seb128> 	SIGHUP,
<seb128> 	SIGINT,
<seb128> 	SIGTERM,
<seb128> 	SIGQUIT,
<seb128> 	SIGCHLD,
<seb128> 	-1
<seb128> };
<seb128> I'll just drop SIGSEGV from that list then
<pitti> seb128: right
<pitti> seb128: so it doesn't intercept SIGFPE, SIGBUS, and friends. good
<Keybuk> pitti: it's not _that_ dangerous
<pitti> Keybuk: well, true, s/dangerous/fragile/
<Keybuk> not even fragile
<pitti> if you examine the situatioon properly, you can probably handle it
<pitti> but not at all in a general catch-all segv handler
<Keybuk> usually one does something like siglongjmp to a known good point in the execution
<AlinuxOS> I've allredy filed a bug against console-setup in rosetta...is it enough for Debian ?
<Fujitsu> AlinuxOS, Malone is the Launchpad bug system, Rosetta just does translations...
<AlinuxOS> sorry
<AlinuxOS> malone :D
<AlinuxOS> yes
<AlinuxOS> I meant malone Fujitsu you've right :)
<Fujitsu> Good, I was hoping you hadn't found a way to use Rosetta to report a bug :S
<AlinuxOS> Fujitsu, no, just want to know If I report a bug in malone, is it assigned to Debian too ? Has Debian benefits or something ?
<tepsipakki> can backports add source packages?
<cbx33> seb128, did gconf update go ok?
<Fujitsu> AlinuxOS, no, you'd need to report it seperately in Debian.
<AlinuxOS> or should I use "reportbug --bts debian"
<tepsipakki> ie. if I'd like to have new versions of xfonts-{base,75dpi,100dpi} which all have their own source now
<seb128> cbx33: I got swaped with other issues, please stop pinging me every day, pressure is no fun, I'll do it when I've time, thank you
<seb128> swamped
<cbx33> sorry seb128, wasn't pressurising, just a casual enquiry as to gconf as a whoole
<cbx33> my apologies
<cbx33> I'll say no more
<seb128> yeah, people enquiring every day if they bug is fixed is not really useful :p
<seb128> np ;)
<seb128> s/they/their
<cbx33> point taken
<__keybuk> *sigh*
<__keybuk> why does X-Chat SEGV every time it's closed?
<lifeless> Keybuk: because it can ?
<AlinuxOS> mmm, I prefer malone then Debian reportbug :/
<Fujitsu> Keybuk, I noticed that too.... It's /really/ annoying. Any ideas why it does it?
<cbx33> who would I talk to about someone sponsoring a teamspeak server for a few hours so we cna have a collaborative sound session?
<highvoltage> cbx33: I thought anyone can create a room?
<cbx33> highvoltage: yes, but I need a nice high bandwidth server ;)
<cbx33> fast and speedy
<highvoltage> ah ok :)
<cbx33> since I don;t know how many people are going to want to participate
<cbx33> but I have several people interested already
* Keybuk wonders what happens with sysvinit if you press C-A-D while rc6 is running
<sivang> highvoltage, cbx33 : this is for mountain view?
<highvoltage> I think cbx33 wants to do this now.
<sivang> highvoltage: ah :)
<highvoltage> (or before MV, at least)
<cbx33> sivang: I was hoping to do it sometime next week
<cbx33> I have a server in the states but it's not the fastest ;)
<popey> cbx33: how much bandwidth do you think it would need?
<popey> I have a machine in the uk with some bandwidth
* ogra laughs about the recent debian-gtk-gnome ML discussion
<ogra> ...Option 4: use the Ubuntu logout dialog.
<ogra> http://www.manucornet.net/ubuntu/JPEG/Logout_dialog.png
<ogra> It has a poor UI, but with smaller icons and another ordering, we can make it something good...
<ogra> heh
<cbx33> popey: not sure.....I did it once and had a 1.5 hour conversation with someone else and the total bandwidth was 10Mb
<cbx33> :p
<cbx33> I'm thinking we'd have about 10 people or so
<cbx33> and the quality would be upped
<Kamion> AlinuxOS: there was already a commit to Debian's console-setup svn repository regarding Georgian fonts; I don't think another report is needed
<AlinuxOS> Kamion, I've done in both places...as some people said to me that I should file bug everywhere.
<Kamion> AlinuxOS: svn://svn.debian.org/svn/pkg-kbd/people/zinoviev/console-setup
<Kamion>   * New mini-font georgian16.bdf to be used for the Georgian letters in
<Kamion>     Fixed16, author: Gia Shervashidze.  Thanks to Vladimer Sichinava.
<cbx33> popey: what do you think?
<Kamion> like I say, no need for another bug
<AlinuxOS> hm Kamion , so why no one noticed me ? :(
<Kamion> AlinuxOS: because people are not omniscient :-)
<cbx33> is it a fast connection?
<Kamion> AlinuxOS: just leave it alone now, one notification is enough; I'll pull the fix into Ubuntu's console-setup
<AlinuxOS> Kamion, sorry me...just understand me (no communication, no feed back) so I bugging people like you :)
<AlinuxOS> If I only knew about it :(
<Kamion> AlinuxOS: yeah, Anton probably just forgot to mail you back
<Kamion> he's normally pretty good about that
<AlinuxOS> definitely yes.
<Keybuk> mjg59: around?
<Riddell> Kamion: re qt3-designer, no reason it's not in main, it just hasn't been seeded
<ogra> Kamion, there is either a bug in germinate or rather the liveFS build scripts or i'm seeding something wrong ... somehow the gcompris-sound packages end up on the ppc liveCD 
<cbx33> ogra: eeek
<ogra> (according to the .manifest file)
<ogra> i guess thast my 40MB oversizedness
<popey> hehe cbx33 have you seen 61530 :)
<popey> that's bug 61530
<Ubugtu> Malone bug 61530 in ubuntu-sounds "Shutdown sound is truncated" [Medium,Confirmed]  http://launchpad.net/bugs/61530
<cbx33> hahahahahaha
<popey> why don't you have a launchpad account?
<popey> silly rabbit
<cbx33> yeh the shutdown sound is getting dropped
<cbx33> of course I do silly rabbit
<popey> :)
<popey> and :( shutdown sound
<popey> what, completely dropped?
<cbx33> yup completely dropped
<cbx33> https://launchpad.net/people/petesavage
* popey registers savetheshutdownsound.org
<TheMuso> heh
<cbx33> heheh
<cbx33> frank suggested we just drop it completely as a lot of machine shutdown in a few seconds
<cbx33> and alsa is one of the first things to go :(
<popey> they do?
<popey> blimey
<cbx33> apparently
<cbx33> in edgy that is
<popey> it's not alphabetical is it?
<cbx33> hehe
<popey> make it zalsa :)
<popey> aaaanyway
<cbx33> I would have liked to keep it
<cbx33> and shorten it 
<popey> yeah, me too
<popey> right, going to shutdown and see how long it takes
<cbx33> well I have my new sound card now
<cbx33> so I'll make one up
<cbx33> and we'll see what frank thinks
<cbx33> ou have a fairly kickass machine don't you
<popey> ~20+ seconds :(
<popey> not today, today I'm on a 1.1GHz celery
<cbx33> ahhh
<popey> but yes, I do have a kick ass machine :)
<popey> http://gallery.popey.com/gallery/misc/DSC02495 :D
<cbx33> grr our DNS servers are still down I can't see it
* cbx33 saves for later
<cbx33> HAHAHA
<cbx33> what proc is in there?
<popey> Core 2 Duo 6700 2.66GHz
<popey> twin NVidia cards in SLI mode
<Kamion> ogra: it's another side-effect of arch-specific task headers not working yet
<Kamion> ogra: infinity's working on an apt-utils backport for drescher, after which I'll fix up cron.germinate
<Kamion> infinity: (how's that going?)
<cbx33> popey: nice
<ogra> Kamion, ok, thanks
<cbx33> mdz: I do have an LP account - I just subscribed
<cbx33> to that bug
<infinity> Kamion: Doing now, will hand it off to soyuz and the admin team before I head to bed.
<Kamion> cool, thanks
<infinity> Should cook it on mawson for at least a couple of days before we go break drescher, so I'd expect a rollout and invalidating the cache on drescher early next week (or the weekend, if we're lucky)
<infinity> Invalidating the cache will take like a day, so would be nice to do it on a weekend.
<ogra> infinity, we still need to talk about the ltsp tarball generation (sigh) can you dedicate some time for that tomorrow ?
<infinity> ogra: Sure thing.  My tomorrow, or yours?
<infinity> ogra: Like, give me an "in X hours" thing, or a UTC time. :)
<ogra> yours ?
<ogra> heh
<tfheen> ogra: how's your ltsp fix coming along?
<ogra> tfheen, which fix ? 
<tfheen> ogra: 62750
<tfheen> you're aware the RC is merely two weeks away, I presume
<Treenaks> fabbione: remember that X bug I told you about this morning? I got a reply (through upstream bugzilla).. I have to send my bios (and they're working on it)
<ogra> oh, thats fixed locally already i just need some other tweaks that should also go into the next upload
<fabbione> Treenaks: i know.. i reported to Ben and Dave directly on irc :)
* ogra sets the bug to "in progress"
<fabbione> Treenaks: but read about the patch.. it won't work on our ati driver
<tfheen> ogra: ok, good.
<ajmitch> tfheen: what package should I open a bug task on for the mono issues on the live cd?
<ajmitch> I've got it open against f-spot at the moment
<ogra> Keybuk, would you mind me fixing 62036 ?
<AnAnt> why doesn't edgy accept this redirection:  >&    ?
<ogra> (not sure if thats enough though)
<sivang> AnAnt: probably since it uses dash or so
<AnAnt> why doesn't edgy accept this redirection:  >&    from shell scripts ?
<sivang> AnAnt: the default is dash now which is a stricter POSIX shell, IIRC
<Treenaks> fabbione: ok, nice to know
<tseng> you shell scripts should have #!/bin/bash if they are going to be bash specific
<ogra> AnAnt, 2>&1 works fine here ...
<AnAnt> ogra: thanks
<ogra> even with dash
<AnAnt> ogra: I didn't but 2 & 1 before, thanks
<AnAnt> but that doesn't work fine !
<AnAnt> I don't get redirection !
<Kamion> AnAnt: see http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_07
<Kamion> 2>&1 not "2 & 1"
<AnAnt> Kamion: yes, I meant that I didn't put 2 nor 1 before
<Kamion> ">filename 2>&1" is the usual way to redirect both standard output and standard error to filename
<AnAnt> oh
<Kamion> (2>&1 redirects standard error to standard output)
<Kamion> the order is important
<AnAnt> k, it worked
<ogra> 2 & 1 would append 2 to the first command and background it and then try to execute 1 (which is no command)
<AnAnt> I used to do >& filename
<Kamion> yes, that's a bashism
<sivang> AnAnt: sart bash and try it , it will work again
<sivang> *start
<AnAnt> sivang: yeah, it worked, thanks
<Kamion> or just fix the script, it's usually not hard
<Kamion> and makes your script a lot more likely to be portable to other systems
<AnAnt> Kamion: did that 
<AnAnt> k, now something else, the networking
<Keybuk> ogra: I was holding off on that for some reason, but I've forgotten why -- so sure
<AnAnt> my laptop is connected to LAN, when I boot the laptop it gets an IP at the beginning, but for some reason, it loses that IP when the booting finishes
<ogra> Keybuk, do you think that suffices to get the right lenght of the progressbar ?
<Keybuk> ogra: that should fix it, yes
<ogra> ok
<Keybuk> assuming you call usplash start from that init script, it would kill usplash anyway :)
<Keybuk> so it certainly can't go further
<Keybuk> cbx33: I'd argue to get rid of the "startup" sound too ;)
<Keybuk> or, at least, change where it's played
<Keybuk> instead of being "music to listen to while you wait" have it as a "sound that alerts you that your machine is now ready"
<cbx33> Keybuk: I agree with you on the where
<cbx33> thought this isn't possible to be changed is it?
<cbx33> not now anyway
<Keybuk> not now
<cbx33> indeed
<infinity> Keybuk: What's the point of your fglrx.modprobe?
<infinity> Keybuk: If it's mean to prevent hotplug auto-loading, it probably belongs in lrm-common, not in xorg-driver-fglrx, if it's meant to prevent autoloading from the X driver, that makes no sense at all, since the driver will only try to load fglrx if it's in xorg.conf to start with.
<Keybuk> ah, I did ask whether there was a "common", but got a "no"
<Keybuk> should the nvidia equivalent be moved there too (from nvidia-kernel-common) ?
<infinity> Keybuk: Well, it clearly doesn't belong with the X driver, it belongs with the module.
<infinity> Keybuk: Yeah, there's already some nvidia modprobe stuff in lrm-common.
<infinity> Keybuk: Or.. Wait.. Is there?  No, my crazy nvidia hack is in nvidia-glx-legacy, for other sketchy reasons.
<infinity> Keybuk: May want to look at that to make sure yours isn't stepping on toes.
<infinity> Keybuk: Anyhow, again, is there really a point to all this?
<infinity> Keybuk: fglrx.ko doesn't autoload on my box unless I'm running the fglrx X driver.
<Keybuk> mjg59 whinged a lot
<infinity> It's only loaded by the X driver, not via hotpluggy stuff.
<Keybuk> ah, then it differs from the nvidia one, which is loaded by udev
<infinity> Well, fglrx.ko has no modalias or PCI IDs or anything.
<infinity> So, perhaps we should drop that hack altogether.
<gnomefreak> infinity: you got minute? bug 45705 was fixed wasnt it?
<Ubugtu> Malone bug 45705 in ia32-libs "Error in Dist-upgrade on Dapper" [High,Confirmed]  http://launchpad.net/bugs/45705
<Keybuk> yup, agree
<infinity> gnomefreak: Erk.  It might not have been, actually. :/
<gnomefreak> oh
<Keybuk> infinity: you want to drop it, or shall i?
<Kamion> cjwatson@drescher:~/germinate-test/ubuntu-misc$ egrep 'gcompris-sound-(de|en)' more-extra*
<Kamion> gcompris-sound-de/i386  Task  edubuntu-desktop
<Kamion> gcompris-sound-en/i386  Task  edubuntu-desktop
<Kamion> gcompris-sound-en/amd64  Task  edubuntu-desktop
<Kamion> that's more like it
<Kamion> now with any luck apt-ftparchive will understand that once it's upgraded
<infinity> Keybuk: You should look at nvidia-glx.postinst.in and see if your nvidia hack is going to wreak havoc with that.
<infinity> Keybuk: I can drop the fglrx thing in the upload I need to do right now, but first look at the nvidia thing and tell me if the world is going to explode.
<Keybuk> yup, the hack will break that entirely
<doko_> keescook, pitti: wrong upload queue for python2.4 hoary-security
<Keybuk> why the hell do you do that in postinst, instead of shipping a conffile?
<infinity> Keybuk: Because I want to remove it in prerm, even if the package isn't purged.
<pitti> doko_: yeah, I noticed, I uploded it into the correct queue afterwards
<infinity> Keybuk: Too many people remove without purging, which would cause module loading to just explode.
<doko_> pitti: thanks!
<Keybuk> hmm, so how do we attack this
<Keybuk> mjg59 doesn't want nvidia drivers loaded if the X server isn't going to be used
<Keybuk> the X server can't be trusted to auto-load the driver
<doko_> pitti: will you upload the package I prepared for dapper (the one with the extra fix)?
<infinity> Keybuk: The X driver WILL (and does) autoload the nvidia module.
<Keybuk> infinity: no, it doesn't
<Keybuk> it kernel panics, crashes the machine, etc.
<pitti> doko_: yes, that's what I did; thanks for preparing it
<infinity> Keybuk: If we remove the modalias from the kernel module (can we?), the problem goes away.
<Keybuk> it appears to be directly related to SLI
<infinity> Keybuk: Err, come again?  It always used to autoload it.
* infinity shrugs.
<Keybuk> if you have SLI, you get crashes, etc.
<infinity> Kay.  So it needs to be loaded by udev if you have SLI?  Cute.
<Keybuk> and given that I have that configuration, I'm not about to upload anything that breaks my X server ;)
<infinity> Looks like it's time for a little shell script instead of a hideous modprobe line.
<Keybuk> "little shell script" ?
<infinity> Something clever enough to detect A) if you're using the nvidia driver, and B) if it's legacy or non-legacy.
<infinity> Then use that as our install target.
<Keybuk> install that at S08?
<Keybuk> oh, I see
<Keybuk> sure, if you like
<infinity> Kay, I guess I'll just do that too in this upload.
<AnAnt> how can one do field splitting in dash ?
<infinity> AnAnt: read?
<infinity> (Or any of a dozen other tricks)
<Keybuk> infinity: be sure to put nvidia-kernel-common back to how it was?
<AnAnt> read ?
<infinity> Keybuk: Well, it might belong there anyway.  But whatever I do, I'll end up uploading both LRM and n-k-c, yeah.
<Keybuk> echo foo bar baz | read FOO BAR BAZ
<Keybuk> infinity: cool
<AnAnt> how can one do field splitting of a variable in dash ?
<Keybuk> echo $VAR | read FOO BAR BAZ
<Keybuk> anant: http://www.amazon.com/Portable-Shell-Programming-Extensive-Collection/dp/0134514947
<Kamion> Riddell: FYI I'm doing a keyboard variant selector for KDE ubiquity now
<Kamion> (hence fighting with qt3-designer)
<Riddell> Kamion: let me know if you want me to take over
<Kamion> I think I've got the hang of it, just fighting with the bizarre layout stuff
<Kamion> and its excessive application of fixed geometries
<Kamion> it's good for me to be able to do this stuff, anyway
* Keybuk wonders what happens if you press C-A-D while the machine is halting
* Fujitsu gets a feeling of deja vu.
<tfheen> Seveas: you've been doing a bit of usplash hacking, haven't you?
<Seveas> I have
<Seveas> but only the non-difficult parts
<simira> mvo: I dig update-manager!
<mvo> simira: hello! what do you mean exactly?
<Seveas> tfheen, for edgy+1 I have some more usplash plans
<cbx33> Seveas: cool
<tfheen> Seveas: I need somebody to bounce ideas off, basically, so if you have a bit of time?
<tfheen> Seveas: this is for casper; I'm trying to fix https://launchpad.net/distros/ubuntu/+source/casper/+bug/61535
<Ubugtu> Malone bug 61535 in casper "usplash progress reporting is not very accurate for casper" [Low,Confirmed]  
<tfheen> if I try to use PULSATE, that ends once I call log_end_msg
<tfheen> (which is done half a zillion times in casper)
<Seveas> hmm
<Seveas> log_end_msg calls PROGRESS?
<tfheen> log_end_msg calls update_progress which calls usplash_write "PROGRESS", yes.
<tfheen> also, it seems like it doesn't actually increase PROGRESS_STATE at all?
<Seveas> I'm not too familiar with what log_*_msg do currently
<Seveas> let's see
<tfheen> look in /usr/share/initramfs-tools/scripts/functions
<Seveas> ah, in initramfs log_*_msg is different than in /lib/lsbinit-functions?
<Seveas> :q
<tfheen> seems like it, yes.
<simira> mvo: it asked me if I wanted to do a dist-upgrade
<Seveas> tfheen, you might just want to disable the entire progress updating code in /usr/share/initramfs-tools/scripts/functions if you want to pulsate
<Seveas> init will reset the progressbar when it takes over
<tfheen> Seveas: does anything use pulsate ATM?
<Seveas> no
<Kamion> Riddell: is there a way to stop qt designer sticking fixed geometry properties all over the place? your .ui file only seems to have them at the very top level
<tfheen> any reason why we can't have PULSATE START and PULSATE STOP or something then?
<tfheen> hi Henrik
<Seveas> forcing people to be careful 
<kristog> hello 
<simira> hi heno, how's living in Norway?
<Riddell> Kamion: you place them roughly where you want them as fixed geometries then click the layout buttons to put them into horizonal/vercial/grid layouts
<heno> simira: Hei! Still a bit chaotic, but nice overall :)
<Kamion> Riddell: I think I'd broken the top grid layout by accident. It still wants to assign a fixed geometry to the topmost grid layout (the one with the WidgetStack, back, next, cancel, etc. in it), though
<Kamion> is there a way to say "just use the whole window"?
<simira> heno: yes, all that nice weather and stuff must feel comforting, almost like Bergen :p
<Riddell> Kamion: click on the widget background and click the grid layout button in the toolbar and it should put it into a layout again
<heno> heh, almost as nice ;)
<tfheen> Seveas: well, sure.. I wouldn't consider that a problem, though
<Kamion> oh I *see*
<Kamion> it didn't occur to me that clicking on the background would be useful
<Kamion> thanks
* heno goes to do some more RL admin, bbl
<Kamion> ah yes, that works a *lot* better
<Seveas> tfheen, making usplash ignore PROGRESS between PULSATE START and PULSATE STOP is trivially implemented though, I can do that in < 10 minutes -- but you may want to run that past mdz/mjg59, now that Ubuntu is rather deep frozen
<tfheen> Seveas: sure, it's not the implementation I'm asking about.  I can do that trivially myself.
<tfheen> Seveas: do you have another suggestion for how to fix it for the bug I mentioned?
<Seveas> semantically I would prefer that initramfs doesn't call PROGRESS if it doesn't want it to be displayed
<tfheen> Seveas: oh, true, but my scripts really just call log_msg_end, which they have to for the SUCCESS prompt to be displayed properly.
<Seveas> could this work:
<Seveas> #!/bin/sh
<Seveas> source initramfs-tools/scripts
<Seveas> update_progress() { }
<Seveas> (aka, turning that into a noop)
<tfheen> Seveas: yes, it's possible to work around it.
<sivang> cbx33: let me know if you managed to get a hold of pygi
<cbx33> ok
<tfheen> fabbione: uh, why is https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.17/+bug/62485 assigned to me?
<Ubugtu> Malone bug 62485 in linux-source-2.6.17 "[SPARC]  - Regression - Niagara does not reboot properly" [High,Confirmed]  
<ogra> tfheen, because that validates you to get some of this nice HW as well ;)
<tfheen> Kamion: does ubiquity currently mount the squashfs-es by itself?  I'm looking at fixing https://launchpad.net/distros/ubuntu/+bug/62756
<Ubugtu> Malone bug 62756 in Ubuntu "mono confused by the desktopCD" [High,Confirmed]  
<Kamion> tfheen: ye
<Kamion> yes
<Kamion> well, if they aren't already mounted
<tfheen> ok, goodie.  I'll just remove that code bit from casper, then
<keebler> What would the command be to install usplash-dev on dapper, other than make/make install? dpkg something, iirc.
<Kamion> Do any developers object to drescher (the archive publishing machine) being taken down for upgrade at some point on Friday? archive.ubuntu.com will remain available as usual, but there'll be a period when uploads won't be processed.
<keebler> Let me rephrase. I downloaded the Usplash-dev source from the FTP. I'm looking to build it on my system, but as I understand it, the conventional method of build won't work. Now I'm confused.
<keebler> I'm trying to "backport" it to Dapper, if possible. And mjg59 is afk or somesuch.
<Kamion> uh, if you're not familiar with dpkg, I'm not sure that backporting usplash is a good idea, to be honest ...
<Kamion> 'dpkg -i foo.deb' is the command to install a single .deb
<keebler> Kamion: You're probably right. But I'm trying to learn.
<Kamion> that won't process dependencies, unlike apt
<Kamion> or at least it won't go and fetch dependencies for you
<keebler> Kamion: Well, I'm not looking to install a deb.
<tfheen> Kamion: do we have any idea about how much downtime?  I'm fine with it.
<Kamion> keebler: sure you are
<keebler> Well.
<keebler> lol
<Kamion> keebler: you asked what the command would be to install usplash-dev; usplash-dev is a .deb
<keebler> Not a .deb, trying to build it from source.
<keebler> tar.gz
<Kamion> oh, dpkg-buildpackage -b
<keebler> Thats the one!
<Kamion> tfheen: couple of hours
<tfheen> Kamion: ok; I don't mind (with any of my hats)
<Kamion> well, an hour or two for the dapper upgrade, then about a day for apt-ftparchive to rebuild its cache
<keebler> mjg59: Told me, but I lost my last system after getting it to install/build. I'm currently reading the man page, but I was trying to take a shortcut by asking here.
<Kamion> that day will probably stretch over into the weekend
<tfheen> better then than closer to RC
<keebler> Well that rocked. usplash-test.sh (usplash-dev) worked pretty swell on Dapper.
<keebler> Or, atleast I think it did what it was supposed to. :) Mostly red and blue, with a progress bar in the middle and various numbers and gradients?
<Kamion> keebler: you'll probably want a theme as well
<Kamion> rather than the testcard - say usplash-theme-ubuntu
<bddebian> Howdy folks
<jdong> howdy, bddebian
<bddebian> Heya jdong
<infinity> mvo: clean targets that call configure are evil.
<ogra> ++
<ogra> gave me headdaches often enough ... and are used way to often in debian
<infinity> Well, I use it in Debian, but only in a semi-intelligent "if we're not unpatching, don't run configure" way, so it's skipped over on a pure source build.
<infinity> apt just unconditionally runs it on every clean, afaict.
<ogra> yep
<infinity> s/configure/autoconf/ rather.
<infinity> People running configure on clean should REALLY be shot.
<ogra> there are a lot of them ...
<mvo> infinity: apt?
<ogra> i guess you'd need a machine gun :)
<ogra> mvo, apt-get source -b
<infinity> mvo: apt runs autoconf on clean to get the version in the configure script.
<mvo> infinity: right
<infinity> mvo: Not a huge deal, just annoyed me briefly to have to wait for autoconf to get installed before doing a source build. :)
<mvo> infinity: I think apt should just get a build-system that is not so "special" ... 
* mvo puts it to his todo
<infinity> Err, it also doesn't build-dep on autoconf for that feature.
<infinity> Cute.
<Kamion> just to get the version? is that all?
<Kamion> I did this in ubiquity:
<Kamion> VERSION := $(shell dpkg-parsechangelog | awk '/^Version:/ { print $$2 }')
<Kamion> AC_VERSION := $(shell grep -w '^AC_INIT' configure.ac | cut -d' ' -f2 | \
<Kamion>                         sed 's/[] [,] //g')
<Kamion> ifneq ($(VERSION),$(AC_VERSION))
<Kamion> $(warning Version $(VERSION) in debian/changelog does not match $(AC_VERSION) in configure.ac!)
<Kamion> endif
<doko_> infinity: what happended to the gcc-snapshot build on floe(ia64)=
<doko_> s/=/?/
<infinity> doko_: Looks like floe's having problems with life.  I'll fix.
<janimo> seb128: hi, ping re python-gnome2
<seb128> janimo: I'm working on it for some days, python-support and random packages are broken making impossible to build python-gnome
<seb128> janimo: I've just sorted pyorbit and rebuilt python-gnome 5 min ago
<seb128> s/are/were rather
<janimo> seb128: ah ok, nice :)
<seb128> your patch had some issues, I've fixed them
<seb128> like your Conflicts,Replaces was on version 2.6.16
* janimo must have looked at the kernel version for too long before or something
<janimo> infinity, tfheen: hi, is anything using stacked filesystems on the liveCD ATM? I'd like to see if that can be used for xubuntu a11y
<infinity> janimo: No, there isn't currently.
<janimo> infinity: is the code done though? Is this a buildd side thing only?
<infinity> janimo: I failed to deliver it in time for beta, so now I'm running an internal "do I defer it, or try to convince people to let it in after the weekend" debate.
<infinity> janimo: The casper code is there and appears to work, the buildd side is buggy and not rolled out, and got side-tracked when I missed the beta deadline and had other pressing stuff to attend to all week.  It's a solid day of debugging and work to get it rolled out, I suspect.
<janimo> infinity: thanks. I'll have a look at the casper part, in case the buildd side will get done as I see no other way to optionally install a few packages on the liveCD depending on boot menu selection
<heno> rodarvus, fabbione: did either of you make changes in xorg relating to wacom tablets? I need some help with this gok bug: https://launchpad.net/distros/ubuntu/+source/gok/+bug/48074
<Ubugtu> Malone bug 48074 in gok "gok gives an X Window System error" [Medium,Confirmed]  
<Keybuk> janimo: you need to file MIRs for gxine and pyxfce
<Keybuk> seb128: likewise for meanwhile
<janimo> Keybuk:  I have
<janimo> Kemaybe not for pyxfce though
* janimo looks
<Keybuk> janimo: have you asked pitti to review them?
<seb128> Keybuk: pitti approved meanwhile on monday
<Keybuk> seb128: so he did, I ken't spel
<seb128> :)
<janimo> Keybuk: yup, he said he'd get around to it
<seb128> https://wiki.ubuntu.com/MainInclusionReportMeanwhile
<Keybuk> seb128: promoted
<seb128> thank you
<seb128> will gaim automatically retry?
<Keybuk> Riddell: kiosktool
<Keybuk> seb128: I thiiiink so
<infinity> seb128: Yes.
<seb128> cool
<Riddell> Keybuk: what about it?
<Keybuk> Riddell: you need an MIR for it
<Keybuk> or you need to remove it from your supported seed
<Riddell> Keybuk: ok, I'll remove it from the seeds for now, it still needs a root password
<Keybuk> okies
<jdong> Keybuk: your sed script for fglrx doesn't work
<Keybuk> jdong: ?
<jdong> jdong@jdong-laptop:~$ cat /etc/X11/xorg.conf 2>/dev/null | sed -n -e '/^[ \\t] *section[ \\t] *"device"/I,/^[ \\t] *endsection/I{/^[ \\t] *driver[ \\t] */I{s/^[ \\t] *driver[ \\t] *"*//I;s/"*[ \\t] *$//;p}}'
<jdong> jdong@jdong-laptop:~$                 
<jdong> Keybuk: it's not matching anything
<jdong> Keybuk: and my xorg.conf does use fglrx
<janimo> seb128: do you know if onboard is still in the plan? it's still in universe
<Keybuk> jdong: hmm
<Keybuk> you need to escape it
<Keybuk> modprobe drops one set of \s
<jdong> oh
<infinity> Being replaces in a few minutes anyway. :)
<jdong> let me take a look then
<Keybuk> quest scott% sh
<Keybuk> $ cat /etc/X11/xorg.conf 2>/dev/null | sed -n -e '/^[ \t] *section[ \t] *"device"/I,/^[ \t] *endsection/I{/^[ \t] *driver[ \t] */I{s/^[ \t] *driver[ \t] *"*//I;s/"*[ \t] *$//;p}}'
<Keybuk> nvidia
<Keybuk> -- 
<jdong> there, that works
<jdong> now, why didn't it work the last time I booted...
<jdong> AHA
<jdong> fglrx.dpkg-old
<jdong> stupid dpkg
<jdong> ok, rebooting, will come back to yell at you again if I don't get fglrx loaded :D
<janimo> Keybuk: removed python-xfce from seeds, as it's not needed by anything essentuial after all
<Kamion> jdong: is there something that doesn't ignore .dpkg-old?
<Kamion> damn, too late
<heno> pitti: about janimo's question, can you (or someone) review onboard?
<heno> https://wiki.ubuntu.com/MainInclusionReportOnBoard
<pitti> heno: ok, if it's urgent
<heno> pitti: it is rather yes, thanks
<pitti> heno: quality-wise you are happy?
<heno> pitti: I am. Less features but more stable than gok
<Keybuk> Kamion: yo
<Keybuk> installer seed
<jdong> Keybuk: k, works well, nvm
<Keybuk> why does the regex for the i386 kernel modules have .*-386-di in it
<Keybuk> when all the others just have .*-di ?
<pitti> heno: ok, deb and packaging looks fine, I'll approve
<heno> pitti: \o/ thanks!
<rodarvus> heno, I haven't made any changes related to wacom tablets
<Kamion> Keybuk: workaround for a germinate bug that was sucking -generic-di onto the seeds and I didn't know wy
<Kamion> why
<Kamion> at the time I did that, I didn't have time to investigate properly
<Keybuk> don't we WANT -generic-di in the seeds?
<Kamion> no
<Kamion> well, maybe soon :-)
<heno> rodarvus: ok, any idea how that config issue can be worked around?
<Keybuk> ext2-modules-2.6.17-10-generic-di | 2.6.17-10.26 | edgy/main/debian-installer | i386
<Keybuk> ^ so how come that's in main, and not in anastacia
<Keybuk> yet
<Kamion> but not right now - the default kernel for the alternate install CD is still -386
<Keybuk> cdrom-modules-2.6.17-10-generic-di | 2.6.17-10.26 | edgy/main/debian-installer | i386
<pitti> heno: doing p-virtkey now, too
<Kamion> please leave them in main
<Keybuk> ^ that _is_ in anastacia
<Keybuk> ?
<Kamion> I'll sort them out and figure out what crack germinate/anastacia are smoking soon
<Keybuk> ok
<rodarvus> heno, I wasn't here at the time wacom tablets started being automatically added to xorg.conf, but I'd say the fix is not to add them to *every* configuration, as its done currently
<Kamion> I don't know exactly what the problem is at the moment, and IIRC it's a bit confusing
<rodarvus> (I mean, this happened on dapper development cycle)
<Keybuk> I don't want to end up accidentally removing things next time there's an ABI dump ;)
<Kamion> just dump the whole kernel into main every time
<Keybuk> there'd be in the ultra-long-list that I never read <g.
<heno> rodarvus: ok, is that a change we can make now or is it too late
<Kamion> at the moment though, I'm trying to beat the string freeze with a few bits and pieces
<heno> I think it's the non-core pointer stuff they both do (gok and wacom) that causes the problem
<rodarvus> heno, not sure. I'll ask fabbione when he is around (I'm unaware of the implications touching this part of the config might have, and how many users it might affect)
<heno> rodarvus: ok, will do, thanks
<rodarvus> heno, I subscribed to this bug report, and will talk to fabbione about it - wacom tablets seem to be a source of problem to other users too
<dholbach> janimo, Gloubiboulga: did you think about having new gnumeric and new goffice?
<dholbach> janimo, Gloubiboulga: it seems to have lots of fixes
<pitti> Gloubiboulga, janimo: @ gxine MIR: can you please use the standard template in the future? this report is very short
<pitti> Gloubiboulga, janimo: gxine *did* have security issues in the past, too (the report claims not)
<janimo> pitti: ok, sorry about that
<heno> rodarvus: as does gok. I think we should remove it from main for Edgy+1
<janimo> dholbach: you mean a sync from debian? I'll have alook
<dholbach> janimo: not sure if debian has it already
<dholbach> I don't think so
<dholbach> it was just released or a day ago
<janimo> dholbach: hmm it needs an UVF exception I assume?
<janimo> even if its not on the ubuntu CD
<dholbach> I suppose so - is it on the xubuntu cd?
<janimo> it is, yes :)
<janimo> dholbach: just that I am entirely unfamiliar with gnumeric source and devs to asses if it's better to have this except by lookign at the changelog
<dholbach> janimo: and new goffice and gsf too
<janimo> but it;s a point release so I guess it ihas to be better :)
<dholbach> janimo: I just saw it on the ftp-release list and saw the list of things it fixes (from the news file)
<dholbach> just as a headsup :)
<pitti> janimo: what do you use right now as media player in xubuntu? (any chance we can drop a package in favor of gxine?)
<pitti> Keybuk: can you please approve the langpacks in dapper-proposed?
<janimo> pitti, it was xfmedia and is no longer in the seeds
<pitti> ah, nice
<janimo> dholbach: thanks ;)
<pitti> janimo: ok, approved; I'll process this dict-plugin now, then the queue is reasonably clean again
<janimo> seb128: are you going to look at python-gnome2-extras or should I make a patch for similar breaking out binaries?
<janimo> pitti: \o/
<seb128> janimo: I doubt we are going to split extras for edgy
<seb128> janimo: what to split will not be that easy to decide for it
<janimo> seb128: at least the gtkhtml2 part, it is needed by gnome-app-install. 
<seb128> not for edgy
<janimo> the main reason why I started the discussion
<Keybuk> pitti: do you have bugs for each, with debdiffs?
<janimo> gconf was worked around in u-m
<janimo> that is not possible with gtkhtml2
<janimo> not all the small bits, but this single gtkhtml2 so
<janimo> as simole as gconf and canvas
<pitti> Keybuk: mdz was fine to special-case them :)
<Keybuk> pitti: *shrug* I'm not going near them if they break the policy
<janimo> s/simole/simple/
<pitti> Keybuk: but he wanted to use the proposed->updates staging
<Keybuk> not unless you have signatures from mdz and sabdfl in triplicate :)
<seb128> janimo: I understand that you want to split gtkhtml2, we might want to split other parts too, needs some discussion
<janimo> seb128: so to not make it too compliated when we converge with debian when they split,
<janimo> we can just take a single package out whioch they will surely split as well
<seb128> I'll think about it later
<janimo> seb128: ok, I only said the single one to keep it as simple as possible
<janimo> seb128: ok, thanks
<seb128> np
<Keybuk> pitti: sorry to be silly; but there's a written policy, and threats of dire consequence to one's employment if it's not obeyed
<pitti> Keybuk: ok, can you then please approve cupsys (bug 54277) and hal (bug 56484) uploads?
<elmo> uploads and builds are going to be down for an hour or so while the ftp-master machine is upgraded
<elmo> apologies for the inconvenience
<Keybuk> pitti: err. in an hour, apparently ;)
<pitti> Keybuk: I can forward you mdz's mail about that topic, or do you want to ask him yourself?
<pitti> Keybuk: heh, ok :) bad timing
<Keybuk> pitti: I probably won't catch him this evening (gym day)
<Keybuk> I'll e-mail him for confirmation
<pitti> Keybuk: ok, thanks
<pitti> janimo: '#!/usr/bin/make -f\ninclude /usr/share/cdbs/1/class/xfce.mk' <= that's the whole debian/rules? remarkable :)
* dholbach hugs CDBS
<Keybuk> sfllaw: errr, ping
<jdong> dholbach: I put diffstats and changelogs on the wine uvf request
<dholbach> jdong: cool
<dholbach> jdong: it says so on http://wiki.ubuntu.com/MOTU/Processes/UVF - else it's always hard to judge
<jdong> dholbach: yeah, I noticed that document after filing that UVF
<dholbach> ok
<jdong> dholbach: my 2nd one (x264) was much more thorough :)
<janimo> pitti, yup I chuckled when I saw that as well :) (Gauvain packaged that one)
<bddebian> Gawd I hate my freakin' life somedays.. :'-(
<bddebian> Oops, wrong chan, sorry
<jdong> lol
<pitti> bddebian: indeed, in this channel it is required to be happy when writing 
<jdong> bddebian: stop trying to package azureus!
<bddebian> pitti: It's the second happiest place on earth? ;-)
<zul> pitti: heh like shiney happy people
<bddebian> jdong: Heh, I WISH that was what I was working on..
<seb128> what is the first one?
<bddebian> seb128: DisneyWorld, of course :-)
<heno> BenC: did you have to do a lot of code cleanup to get the speakup stuff into the kernel? (I'm trying to nudge the speakup people to try to get it into the default kernel)
<BenC> heno: Not really...I cleaned up the keyboard.c changes so it was a bit cleaner, but other than that, it was pretty straight forward
<heno> BenC:  Coding style was ok too?
<BenC> heno: I didn't really review it that much
<heno> ok, thanks
<BenC> but that's what the lkml is for...if they send a patch for inclusion, they'll get a lot of feedback
<BenC> just the little bit of code review I did found one bug with the locking of the prov file, I'm sure the lkml will find others, and generally improve the code
<BenC> *proc
<heno> BenC: yep, seems they did that got some constructive feedback but didn't take it very well and ran away
<heno> They might just need some guidance through that process
<BenC> heno: you have to have pretty tough skin to get through that process
<BenC> but it's worth it, if only for the code and the users of it
<heno> Yep, that's what I'll be telling them :)
<BenC> hell, I've been trying to get a single document in the kernel, not even code, and I've been in the process for months now
<BenC> mostly due to me not having time between edits, but still :)
<zul> heh excuses excuses :)
<zul> ..ill shut up and get back to what i was doing
<Chipzz> 17:33 <@Chipz> I go back upstairs, announce a reboot of defcon1 in 10 minutes, and do sleep 300 ; shutdown -r 0
<Chipzz> hrrrm
<Chipzz> wrong channel
<Ng> ok folks, uploads and builds should be going again, the ftp-master machine upgrade is done.
<thom> Chipzz: are we allowed to laugh at you for doing sleep... shutdown anyway?
<Chipzz> thom: you lack some mathematecial skills my dear friend ;)
<thom> well, no
<thom> you lack some manpage skills _and_ some mathematical skills
<Chipzz> thom: you obviously never read http://bofh.ntk.net/bastard.html
<Chipzz> which that was actually a parody of :P
<thom> parody is supposed to be funny. anyway, i still intend to laugh at you for using sleep then shutdown
<sfllaw> Keybuk: errr, pong?
<jdong> grr, how do I get pbuilder to do some make parallelism?
<Chipzz> thom: then again, it was torn out of context, and never intended to be pasted here
<jdong> I'd love for my second core to be doing some work
<Keybuk> sfllaw: you were inventing times for the team meeting?
<Chipzz> s/torn/ripped/
<sfllaw> Keybuk: I was?
<sfllaw> Oh, I misread the time, didn't I?
<sfllaw> Sorry.
<Keybuk> sfllaw: 19:00Z ?
<Keybuk> you mean 0700 UTC
<sfllaw> Well, 07:00Z is fine as well.
<Keybuk> (the Z is a curiously american thing that most people probably won't recognise, btw)
<popey> zulu?
<popey> I thought it was a Military thing
<sfllaw> Uhm, that's obviously me being super archaic by accident.
<sfllaw> I'll resend.
<Keybuk> I could be extremely pedantic at this point, and go on to point out that Zulu time, GMT and UTC are not the same thing
<Kamion_> http://wwp.greenwichmeantime.com/info/timezone.htm
<Keybuk> but I won't ;)
<Kamion_> I always assumed that zero => Z => Zulu, but evidently not
<sfllaw> Z is the zero time zone.
<sfllaw> Which is GMT.
<sfllaw> Which is UT1.
<Keybuk> no
<Keybuk> Z is UTC
<Keybuk> which is almost, but not quite, precisely the same as GMT
<Keybuk> they can be different by as much as 2-5 seconds
<infinity> Either way, Zulu isn't an "American thing".
<Keybuk> usually no more than 1-2s though
<sfllaw> Resent.
<infinity> It's used for military and aerospace all over the world.
<Kamion_> sfllaw: as the above link notes, it's a mapping of letters of the alphabet to zones, rather than z => zero
<Keybuk> infinity: either way, it's not that appropriate for a u-d-a mail ;)
<infinity> :)
<sfllaw> Kamion_: I think the timezones start from Z at Greenwich and are split in two by it.
<sfllaw> So it really is zero.
<heno> sfllaw: so east and west london are in separate time zones? :)
<Keybuk> When a positive leap second occurs, it is denoted as "23:59:60" in UTC
<Keybuk> ...interesting
<Keybuk> I wonder how many millions of lines of code fail to parse that? :)
<elmo> heno: next time I'm late to the office, that's so going to be my excuse
<elmo> "I had to cross a timezone to get here!!"
<popey> there was a leap second last new year
<popey> iirc
<sivang> heno: I have a certificate that I stood up on the 0 degree line :-)
<Keybuk> popey: there was
<Keybuk> UTC is now 0.4 seconds ahead of GMT
<Keybuk> or is it behind?
<popey> heh
<Keybuk> sivang: the 0 degree line goes through my dad's old house
<Kamion> elmo: how do you define "late to the office"? :-)
<Keybuk> Kamion: turning up on Tuesday morning, bright and fresh for work on Monday
<sivang> Keybuk: wow cool, I was really amazed by the green park straight off Greenwich pier and the excellent mushroom soup serving tea house in it's middle.
<Keybuk> there's a little statue on the south coast where the meridian enters the UK
<pitti> argh, whoever designed the banshee UI deserves a hit on the head
* HiddenWolf points pitti to rhythmbox
<pitti> HiddenWolf: that's what I'm using usually, I just installed banshee to debug an apport issue ;)
* HiddenWolf hugs pitti
<HiddenWolf> Good luck. :)
<fabbione> heno, rodarvus: no, i made no changes. the wacom stuff comes from mjg59 
* sivang searches for a photo on the line.
<Keybuk> sivang: og?
<Keybuk> of?
<rodarvus> fabbione, thanks for clearing this up
<rodarvus> mjg59, ping :)
<sivang> Keybukkyou know me, can't type and can barely walk :-)
<Keybuk> http://www.flickr.com/photos/leewalton/89309189/
<heno> mjg59: I know you would recommend people use dasher, but could you help us unbreak gok anyway? :)
<Kamion> ok, this should be a worthwhile ubiquity change, for those who watch its bug list
<Kamion> +  * Catch ENOENT, EIO, ENOTDIR, and EROFS while copying files, try to figure
<Kamion> +    out what filename they relate to, and display a useful error message
<Kamion> +    explaining that this is probably a CD or hard disk fault (as
<Kamion> +    appropriate) and how to deal with this. Closes about a million bugs.
<Kamion> won't catch all the weirdness, since after all ubiquity is running off the CD, but ...
<sivang> Keybuk: http://muse.19inch.net/~sivan/P1030888.JPG my gf standing next to the line, better put her's photo then my fat self :-)
<Keybuk> of course, the absolute best thing about the zero meridian is that it doesn't run through Paris ;)
<sivang> Keybuk: how so?
<thom> sivang: geography?
* thom apologises
<sivang> s/how so/why so/
<sivang> thom: ^^
<sivang> ;-)
<Ng> Keybuk: the current one at least ;)
<Keybuk> sivang: France wanted it to go through Paris, and even after it was decided it would go through London, sulked and for decades continued to ignore that and use one that went through Paris on all of their maps
<Keybuk> sivang: of course, the line you stood on is actually just over 100m from the modern meridian ;)
* iwj goes climbing.  G'night all.
* HiddenWolf is tempted to tell half the development team to take it to -offtopic, just for kicks
* HiddenWolf hides
<jdong|laptop> Kamion: what are your thoughts towards a ntfsprogs 1.13 sync from debian?
<jdong|laptop> Kamion: 1.13 adds support for dealing with hardware faults
<jdong|laptop> (bad sectors, IO errors)
<Kamion> jdong|laptop: feel free to send me a mail
<jdong|laptop> Kamion: will do
<JB[away] > moin
<sivang> Keybuk: ah, so *where* is the modern meridian? :-)
<JB[away] > pitti are you here ?
<pitti> JB[away] : yes
* sivang yays for instant curry rice out of the box
<Keybuk> sivang: like I said, about 100 metres to the east
<JB[away] > pitti: you know my bug report?
<twb> Is 6.10b known to (not) work under Qemu (with kQemu loaded)?
<JB[away] > https://launchpad.net/distros/ubuntu/+source/apache2/+bug/62820
<Ubug2> Malone bug 62820 in apache2 "RPC over HTTP" [Undecided,Unconfirmed]  
<pitti> JB[away] : the apache2 one with mod-proxy?
<JB[away] > yes
<JB[away] > i read on the changelog
<JB[away] >  Add 048_reverse_proxy_fix, to resolve a regression in 2.0.55 with
<JB[away] >       mod_proxy, mod_ssl and HTTP POST requests (upstream bug #37145)
<Ubug2> Malone bug 37145 in linux-source-2.6.15 "UniChrome Pro IGP not shown in lspci; X doesn't work" [Medium,Needs info]  http://launchpad.net/bugs/37145
<JB[away] > that is fix ?
<pitti> JB[away] : maybe
<pitti> I didn't check
<JB[away] > for me dont work 
<JB[away] > i think adam do a mistake
<thom> hrm, how does one teach ubugtu that apache's bugzilla is at http://issues.apache.org/bugzilla/ ?
<HiddenWolf> thom: one talks to Seveas
<thom> JB[away] : those two look unrelated at first glance
<thom> in fact, see http://issues.apache.org/bugzilla/show_bug.cgi?id=37145#c23 and c24
<Ubug2> issues.apache.org bug 37145 in mod_proxy "data loss with httpd-2.0.55 reverse proxy method=post" [Critical,Resolved: fixed]  
<thom> Seveas: apache's bugzilla is at http://issues.apache.org/bugzilla/ ; please could you do the correct magic to teach ubugtu about it?
<JB[away] > thom @ Ubug2 see my Bug Report on https://launchpad.net/distros/ubuntu/+source/apache2/+bug/62820
<Ubug2> Malone bug 62820 in apache2 "RPC over HTTP" [Undecided,Unconfirmed]  
<thom> JB[away] : yes, i have seen that one
<thom> that is why i said "those two look unrelated"
<JB[away] > the bug is fixed on 2.0.56
* sivang Keybuk we quite fell for the UK I must tell you, especially the river banks in London and Scotland's low and midlands ( we didn't manage to see the high lands as well)
<JB[away] > but not in ubuntu apache packages
<sivang> Keybuk: ^^
<JB[away] > today i read the changelog and the bug was fixed but not really
<sivang> Keybuk: that's lots of greens very different to our lots of brown and yellow landscape.
<thom> JB[away] : no, the patch that fixed 37145 was applied. THAT IS NOT THE BUG YOU ARE SEEING
<JB[away] > ???
<JB[away] > you mean the problem is not fixed?
<pitti> JB[away] : that's why the bug is still open
<thom> there is no reason that the patch that was applied would fix the bug you are reporting
<JB[away] > is this a apache problem or ubuntu guys?
<thom> it could just as well be a connectivity issue between the proxy and the upstream server
<thom> since the errors are saying "we timed out trying to get content from blah"
<JB[away] > on debian sarge with 2.0.54 works fine
<JB[away] > with same config
<thom> on the same machine? with the same networking?
<JB[away] > same network config
<JB[away] > but not same machine
<Seveas> @bugtracker add apache bugzilla http://issues.apache.org/bugzilla/ Apache
<Seveas> apache bug 37145
<Ubugtu> Apache bug 37145 in mod_proxy "data loss with httpd-2.0.55 reverse proxy method=post" [Critical,Resolved: fixed]  http://issues.apache.org/bugzilla/show_bug.cgi?id=37145
<Seveas> thom, --^
<JB[away] > Critical,Resolved: fixed :)
<thom> Seveas: grazi mille
<thom> JB[away] : it's still NOT the same bug
<JB[away] > than i must to create a new bug report to apache?
<thom> no, please don't
<JB[away] > thom why not?
<thom> you have filed the bug on your distribution of choice
<thom> let them sort out whether it should go upstream or not
<JB[away] > i dont think that ubuntu fix the bug :)
<BenC> how do I check on the build status of a dapper-proposed upload of linux-source-2.6.15?
<Keybuk> https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.15
<BenC> Keybuk: it doesn't show up in there
<Keybuk> oh, that's missing  proposed
<BenC> I uploaded it awhile back
<Keybuk> ahh
<Keybuk> did you have it approved yet?
<BenC> guess not :)
<Keybuk> that would be why then
<BenC> can I get it approved?
<BenC> mdz: Can I get approval on the dapper-proposed upload of 2.6.15?
<jdong|laptop> BenC: how's my favorite kernel guy doing today :D
<BenC> jdong: so far, great...how about you?
<BenC> jdong: I have your patch ready for a final kernel upload tomorrow
<jdong|laptop> BenC: awesome. i'm doing just fine. edgy's looking really nice now :)
<BenC> feh, edgy's old news :)
<jdong|laptop> crimsun: are you around?
<BenC> Linux gullible 2.6.19-1-generic #4 SMP Wed Oct 4 12:24:59 EDT 2006 i686 GNU/Linux
<jdong|laptop> BenC: LOL wow
<jdong|laptop> BenC: is that recommended? ;0
<jdong|laptop> ;)
<mdz> BenC: is there an email somewhere in my inbox about it?  it's a bit full at the moment and I didn't see it
<mjg59> BenC: Uh. You want to do the final kernel upload tomorrow?
<BenC> mdz: No, I wasn't aware that we needed approval for proposed, thought it was only for -updates
<jdong|laptop> crimsun: http://ubuntuforums.org/showthread.php?t=270676
<BenC> mjg59: Near final...I'm almost sure we'll have some last minute stuff..I uploaded bcm43xx patch today though
<mdz> BenC: the procedure is at http://wiki.ubuntu.com/StableReleaseUpdates
<mdz> I emailed about it but only to -devel
<jdong|laptop> crimsun: this user seems to report that the acer alc883 probleem still exists in dapper
<BenC> mdz: I saw it, and read it, but I guess I misunderstood that part :)
<mjg59> BenC: There's still several regressions that need fixing up
<BenC> mjg59: Yeah, there's quite a few
<BenC> there's at least one suspend regression from dapper
<mdz> BenC: maybe it could be more explicit
<jdong|laptop> mjg59: are you aware of but 61711?
<jdong|laptop> bug 61711 even
<Ubugtu> Malone bug 61711 in usplash "no boot splash and very slow booting" [Undecided,Confirmed]  http://launchpad.net/bugs/61711
<mdz> we want to have some discussion about the update ideally before it's prepared
<jdong|laptop> mjg59: that nabbed me on my other amd64 box
<mjg59> jdong|laptop: Yes
<mjg59> jdong|laptop: Nvidia?
<jdong|laptop> yep
<jdong|laptop> nforce mobo
<mjg59> jdong|laptop: Yes, so it's the same one you told me about before?
<jdong|laptop> mjg59: no
<jdong|laptop> mjg59: each of my 3 boxes has a different usplash bug :)
* jdong|laptop feels lucky :D
<Kamion> hmph, bug 61576 is going to be a bit of a pain to fix
<Ubugtu> Malone bug 61576 in kickseed "Disk selector appears with kickstart " [Undecided,Confirmed]  http://launchpad.net/bugs/61576
<Kamion> finding the first device is easy - list-devices disk | head -n1
<BenC> mdz: Why is it so hard to get stuff into proposed...I would have expected -proposed to be a little slack, and -updates to be difficult
<Kamion> but you can't assume that hard disk devices are available until after hw-detect has run
<Kamion> and IIRC there's no hook between hw-detect and partman
<mjg59> jdong|laptop: Ok. It's almost certainly the same thing.
<BenC> mdz: I never want to migrate my kernels from -proposed to -updates, for example...it's just an "official" testing facility for me
<Kamion> I think I might have to have kickseed install its own partman script ...
<mdz> BenC: the idea of -proposed is to stage the update; we don't want things to go into -proposed unless there's certain to be a corresponding -updates upload
<mdz> BenC: so we need to agree in advance about the appropriateness of the upload
<BenC> mdz: because of the -updates/-security weirdness, that'll surely never happen for me
<jdong|laptop> mjg59: ok, if you say so
<jdong|laptop> mjg59: would you know why my vt's are corrupted on my ATI?
<jdong|laptop> mjg59: bug 63558
<Ubugtu> Malone bug 63558 in usplash "Latest usplash leaves my consoles corrupted" [Low,Confirmed]  http://launchpad.net/bugs/63558
<jdong|laptop> mjg59: it used to work before the last usplash upload :)
<BenC> mdz: I don't think -proposed is what I want for these kernels, but that leaves me with no place to have them available for broad testing
<mdz> BenC: what kind of things do you want to publish?
<BenC> mdz: What I want is to be able to patch up kernels with a lot of simple, but important fixes (missing PCI ID's, sound fixes, patches backported from edgy, etc...)
<BenC> the jmicron thing for example, so people can install dapper on these new core 2 duo's, and the scsi_slave fix like what porkpie in #ubuntu-kernel needs
<elmo> Kamion: dude, will edgy on powerpc let me do root raid?
<mdz> BenC: -backports?
<mdz> either -backports or a PPA
<BenC> PPA == personal package archive?
<infinity> We don't do direct uploads to -backports, and PPA doesn't exist. :)
<jdong|laptop> backports probably won't work too well for this purpose
<BenC> infinity: how does -backports work?
<jdong|laptop> BenC: a script automagically pulls an edgy source package, mangles the version, and sends it to build
<jdong|laptop> no source modification is allowed, etc
<BenC> oh, yeah, that's not what I want
<jdong|laptop> right
<BenC> *sigh*
<BenC> I need -proposed-never-send-to-updates
* jdong|laptop senses dapper-bleeding-edge repo :)
<BenC> it's not even that bad :)
<infinity> BenC: What you really want is PPA, mdz is right, it just doesn't exist yet.
<mdz> infinity: we can do direct uploads to -backports
<Kamion> elmo: I've heard reports of broken RAID in the edgy installer, so at the moment I can't say for sure
<elmo> doh
<mdz> we had a policy against it, but the last time this came up the consensus was that modified source uploads from -core-dev were OK for backports
<infinity> mdz: Does the upload policy actually allow for it currently?
<jdong|laptop> mdz: I've recently heard that soyuz was locked down to disallow even core-devs?
* infinity goes to check the source.
<infinity> At any rate, this hardly qualifies as a "backport", so still feels like a bad fit.
<jdong|laptop> infinity: can you still check the source for me?
<jdong|laptop> infinity: I got a few backports up my sleeve if that's the case
<mdz> infinity: that part is unknown
<mdz> infinity: (the upload policy)
<mdz> I'm not sure whether the upload policy for -backports actually enforces the way we have been using it, to be honest
<mdz> infinity: from Ben's description, it sounds like select backported fixes
<mdz> it's actually the "backported support for new hardware" channel that has been discussed but is not properly specified yet, much less implemented
<BenC> basically it is backported patches
<BenC> but they are also patches that I want migrated eventually into dapper point releases
<BenC> some of them need installer/cd rebuilds in order to test (like jmicron)
<mdz> hmm
<BenC> this is only something I would need for dapper too
<mdz> we don't yet have a proper plan for how to provide updated installer/cd builds for new hardware support in older releases; it's something we should talk about in november
<BenC> edgy isn't going to be as important for this
<BenC> mdz: Can I get my kernels blindly accepted into -proposed for now given that they aren't going to be considered for -updates, and I have no other channel? Until november where we can discuss a better plan?
<mdz> BenC: they will be clobbered by later uploads destined for -updates anyway
<BenC> mdz: Not really, I had setup the ABI for these as -50, so that -security never clobbers them
<BenC> but I will be merging -security stuff into these kernels as they come out
<mdz> BenC: they're built from the same source, though, no?
<BenC> seperate git branch
<mdz> we can't have two versions of the same source package in -proposed
<BenC> same .orig.tar.g
<BenC> there will only be one version in -proposed
<mdz> you have 1) a kernel which isn't destined for -updates, but which you want built and published for testing, and 2) a kernel which is destined for -updates, fixing regressions in dapper
<mdz> no?
<BenC> mdz: Because of the -updates/-security cross version brokeness that I've been warned about, the updates would eventually migrate to -security uploads with a security release
<BenC> so dapper has two git tree's (same .orig.tar.gz base)...the -security is just the same kernel we've always had
<jdong|laptop> mdz: does dapper-updates take universe packages?
<mdz> but non-security changes should be staged in -proposed now
<mdz> jdong|laptop: sure
<jdong|laptop> k
<mdz> at the discretion of MOTU
<BenC> mdz: That's where I wanted to stage them
<mdz> BenC: we're talking about two different sets of non-securiy changes, though, right?
<BenC> mdz: But when they get enough testing, and are approved, they would have to be migrated with a security upload
<mdz> yes
<mdz> agreed
<BenC> so nothing ever goes into -updates
<BenC> do you want to discuss this over the phone?
<BenC> might be easier to explain
<zul> maybe have a edgy-git kernel in universe
<mdz> ok
<mdz> landline?
<sabdfl> mjg59: really love the new usplash!
<BenC> mdz: StableReleaseUpdates is updated
<jdong> sabdfl: yeah, it really does rock (when it works!)
<jdong> sadly, each of my 3 boxes has a unique usplash bug :)
<mdz> BenC: thanks, will have a look
<LaserJock> does StableReleaseUpdates apply equally to Universe?
<LaserJock> mdz: ^^? or do you want MOTUs to decide that?
<mdz> LaserJock: the latter
<mdz> though I strongly recommend using StableReleaseUpdates or something very close to it
<jdong> mdz: so currently does backports allow core-dev to do manual uploads?
<jdong> I'd like to do a backport of edgy's readahead
<LaserJock> mdz: should we be using -proposed too? or is that too much archive-admin work
<jdong> I've tested it well, and the only source mod it needs is to have Dapper's boot.list put back in
<mdz> jdong: I do not know whether that is the case
<mdz> but that is how it should work
<mdz> it will need a Launchpad admin to confirm
<jdong> hmm, what would happen if a core-dev uploads, and it's not the case?
<jdong> woudl it just get rejected?
<mdz> jdong: same answer; I'm not sure
<mdz> it depends on exactly how it's set up on the launchpad side of things
<jdong> ok
<Kamion> I'm not sure either, but chances are either a reject or dropped-on-the-floor in such a way that only archive admins can find out why
<jdong> mdz: would you be OK with a backport of https://launchpad.net/products/dapper-backports/+bug/63275
<Ubugtu> Malone bug 63275 in dapper-backports "readahead-list " [Undecided,Confirmed]  
<jdong> mdz: I have tested it very extensively on my machines
<jdong> I've made this procedure as a forum howto and received no negative feedback on it
<mdz> jdong: it only changes the file list, right? absolutely
<jdong> mdz: well, my only modification is to revert the file list to dapper's list. Edgy's list doesn't make sense on dapper
<mdz> jdong: oh, so you want to backport edgy readahead minus the list changes?
<mdz> I'm OK with that as well
<jdong> mdz: correct
<seaLne> does anyone know whether encrypted root should work in edgy?  i've seen some debian bug reports but not sure if they effect us
<jdong> mdz: we all love faster bootups :)
<jdub> argh, python-2.5
<LaserJock> anybody seen jono today?
<jdong> seb128: do you have a moment?
<jdong> Kamion: Tonio_ uploaded the readahead-list backport... does anything appear to be happening at your end?
<Kamion> Listing ubuntu/dapper-backports (UNAPPROVED) 1/1
<Kamion> ---------|----|----------------------|----------------------|---------------
<Kamion>   104064 | S- | readahead-list       | 1:0.20050517.0220-0u | nine minutes
<jdong> ooh, so it worked and landed in unapproved?
<infinity> Apparently.
<jdong> Kamion: can you approve it? :)
<Kamion> just done
<seb128> jdong: pong
<Kamion> seems to have worked perfectly
<jdong> seb128: the nautilus 100% CPU usage bug has been really plaguing me recently
<Kamion> (famous last words)
<jdong> seb128: I can perfectly reproduce it... how can I help you get more debug info about it?
<seb128> jdong: ah, I didn't hear of it for some time
<seb128> jdong: describe a way to get it
<seb128> the issue is that I don't get it, so not easy to debug
<jdong> seb128: open up a nautilus to your home folder or somewhere else
<jdong> seb128: in the same folder, do " mencoder test.avi -o test2.avi -oac copy -ovc copy"
<jdong> to create a new avi, and slowly stream some data into it
<jdong> refresh nautilus a few times
<jdong> and watch CPU usage skyrocket
<_MMA_> Hello room. My name is Cory. (MetalMusicAddict on the forums) Im heading the Mubuntu Project: https://wiki.ubuntu.com/Mubuntu Is there someone I can speak with who is good at creating meta-packages?
<seb128> _MMA_: "good at" is not easy to determine, better to ask your question
<seb128> I assume a bunch of people there know about how to do one
<sivang> _MMA_: essentially a meta package just exists to depend on other packages
<_MMA_> I dont know how to make them. I need someone to help me on my team. :) I guess thats the short of it.
<sivang> _MMA_: you can take as an exampl eubuntu-desktop
<jdong> seb128: using that procedure reproduces the bug 100% of the time for me....
<Ubugtu> Malone bug 100 in rosetta "uploading po file overwrites authors list" [Medium,Fix released]  http://launchpad.net/bugs/100
<_MMA_> I know.
<sivang> sorry, ubuntu-desktop
<jdong> seb128: it's really irritating when it causes a 12-hour encode to take twice as long :)
<sivang> see how it was built, and try to immitate, replacing the package name and switching in your dependencies
<_MMA_> Honestly, Im looking for a team member. I have so much to do myself now as it is. Im good at figuring things out if I have the time. Time is the one thing Im lacking.
<_MMA_> Im here "recruiting". If someone has the time.
<seb128> jdong: spatial or browser mode, icon or list view?
<seb128> jdong: no issue with a few tries on my box
<jdong> seb128: spatial mode, icon view
<jdong> refreshing a few times while the avi is generating leads to the problem
<jdong> (you gotta catch it while the avi is generating)
<seb128> _MMA_: not the right change to recrut, most of people here are already overworked, better trying #ubuntu-motu
<seb128> jdong: ok, thank you, I'll try to get it that way
<jdong> mencoder test.avi -o test2.avi -oac copy -ovc x264 -x264encopts bitrate=400
<jdong> that should give you ample time :)
<seb128> is nautilus having the thumbnail update clock when you get the issue?
<Kamion_> jdong: I must say I'm not overly convinced that the "only ubuntu-core-dev can upload directly to backports" rule is implemented; it looks like just the normal component checks are applied
<Kamion_> jdong: however, that's ok, because it all lands in unapproved anyway and we can check it
<Kamion_> (sorry, not sure if you saw me say that earlier because I think I had already dropped off)
<_MMA_> seb128: Ok. I thought that channel was more for maintaining Universe. Ill give 'em a ring, see what happens. Thank you.
<seb128> _MMA_: it is for universe, the point is than most of people on #ubuntu-devel are already doing lot of things and not likely wanting to step to work on a new subproject
<jdong> seb128: yes, I get the thumbnail update clock
<jdong> Kamion: ok, thanks for the heads-up
<seb128> jdong: you should not while it's working
<seb128> it tries to thumbnail only if the file didn't change for 5s
<jdong> seb128: well, I do.... :(
<seb128> which should not happen while mencoder is running
<jdong> seb128: it is indeed a clock icon
<[Pitcher] > hi all, new server of support to ubuntu /server -m irc.ubuntuzone.org:6668 ;)
<seb128> the standard clock icon?
<[Pitcher] > hi all, new server of support to ubuntu /server -m irc.ubuntuzone.org:6668 ;)
<seb128> or the icon it's using while generating a thumbnail?
<Tonio_> mdz: talking about backports, I was thinking about proftpd
<Tonio_> mdz: the mysql part doesn't work at all with the current dapper version, see bug 59359
<Ubugtu> Malone bug 59359 in proftpd "proftpd-mysql-1.2.10-27ubuntu3 has stopped authenticating with mysql" [Undecided,Confirmed]  http://launchpad.net/bugs/59359
<jdong> seb128: oh wait, never mind
<seb128> ?
<jdong> seb128: the bug happens with an incomplete avi it seems like
<Tonio_> mdz: that's pretty annoying for a 5 years (server) supported version...
<jdong> seb128: let me try to get you better instructions on reproducing it
<seb128> jdong: ok
<_ion> Is [pitcher]  a spambot?
<Tonio_> mdz: I attempted to backport the edgy version and it works like a charm.... interested in an upload to dapper ?
<tseng> _ion: i dont think so
<tseng> Tonio_: 5 year server support doesnt apply to universe
<mdz> Tonio_: backports -> jdong
<tseng> Tonio_: its a best effort by the community
<jdong> seb128: ok, with nautilus open looking at the directory, do the mencoder command
<jdong> seb128: while that's running, press F5 like 5 times
<jdong> seb128: now, CTRL+C on the mencoder
<Tonio_> tseng: yes I know, but proftpd is a major component on the server part, especially for people using LAMP
<tseng> Tonio_: you could argue alot of things are a major component of something or other
<Tonio_> tseng: heh, true :)
<tseng> Tonio_: there is a clear line in the sand between main and unvierse, proftpd is currently out
<[Pitcher] > hi all, new server of support to ubuntu /server -m irc.ubuntuzone.org:6668 ;)
<[Pitcher] > hi all, new server of support to ubuntu /server -m irc.ubuntuzone.org:6668 ;)
<Tonio_> tseng: that doesn't prevent to close the bug by a backport afaik
<jdong> Tonio_: does proftpd build in a pbuilder?
<Tonio_> jdong: yup
<tseng> Tonio_: not at all.
<_ion> tseng: Still think it was not a spambot? :-P
<tseng> _ion: dunno, it's gone
<jdong> Tonio_: then I've got no issue with it... let me verify first
<jdong> Tonio_: open that ticket as also affecting upstream dapper-backports
<seb128> jdong: nop, no bug, maybe my box is too fast or something, do you have a slow box?
<jdong> seb128: happens on my core duo and amd64
<tseng> jdong: both smp?
<jdong> tseng: nope, one smp
<seb128> jdong: I think it's http://bugzilla.gnome.org/show_bug.cgi?id=357704
<Ubugtu> Gnome bug 357704 in Monitoring (inotify) "Infinite loop in monitoring code" [Critical,Unconfirmed]  
<seb128> jdong: no really idea on how to fix it for now though
<jdong> seb128: could be.... :-/
<jdub> i think it might be time to upgrade my linode to edgy
<tseng> jdub: mine is staying on dapper
<tseng> jdub: i dont see the impetus to move forward
<tseng> LTS rules
<jdub> perhaps in that case, we should've stuck with breezy, the best release yet ;)
<tseng> breezy wasnt developed with LTS in mind
<HiddenWolf> seriously, what's the drive to go to edgy?
<tseng> and a guarantee of security updates
<jdub> tseng: no, but it was better than dapper :)
<HiddenWolf> Dapper does pretty much everything, unless you run into a bug.
<HiddenWolf> jdub: how so?
<gnomefreak> is edgy defaulting to python2.5 now?
<infinity> gnomefreak: No.
<gnomefreak> oh
<jdub> HiddenWolf: breezy was a better release in general, dapper got messy (next time, hopefully we know an LTS will be an LTS at least 12 months ahead, instead of six)
<gnomefreak> on a basicly clean install (other than heldback poython packages i just got updates for python-minimal2.5
<jdub> gnomefreak: some python-gnome packages were built against it - probably a buildd / conflicts problem
<gnomefreak> ah ok
<gnomefreak> well i will file bug on the syntax errors
<seb128> jdub: dude, breezy was not better than dapper
<HiddenWolf> seb128: well, that depends. Dapper has a bug that bugs me that wasn't in breezy. ;)
<jdub> seb128: it so was :)
<seb128> HiddenWolf: that's not a troll chan, thank you
<seb128> jdub: thank you for assuming the 6 weeks I spent fixing desktop bug were useless
<seb128> jdub: we did fix a lot of small glitches and bug for dapper we didn't have time to fix with any previous version
<jdub> seb128: i'm not -- just in general, i felt breezy was more solid, and that applies to everything from upstream, installer, etc.
<seb128> really not my feeling
<jdub> seb128: i also think gnome 2.12 was more solid than 2.14
<seb128> not to speak we pushed lot of fix to dapper-updates compared to previous -updates
<jdong> seb128: my  dapper box does not exhibit the 100% cpu bug
<seb128> jdub: you must think that 2.16 is a joke then :/
<jdub> seb128: yeah, the amount of updates has influenced my appreciation of dapper too
<seb128> jdub: 2.12 had gst0.8
<seb128> jdub: how can you consider it better than gst0
<seb128> 0.10
<jdub> seb128: i don't
<seb128> I think 2.14 was good
<seb128> 2.16 is not
<seb128> gtk2.10 has issues, the gnome-vfs etc switch to dbus has issues too
<jdub> but again, i felt breezy was a better release *in general* (not specific to gnome, etc)
<seb128> k, I disagree ;)
<jdub> yeah, some biggish changes that haven't had much testing
<seb128> jdub: you should compare breezy installer to dapper alternative, not ubiquity :p
<seb128> alternate
<jdub> heh
<jdub> but Real Users wouldn't :)
<seb128> real users would think dapper has the same old good text based installed and new cool desktop CD one ;)
<infinity> seb128: Is there a new pygtk on the way that reverts to python2.4 instead of python2.5?
<seb128> infinity: what python2.5?
<infinity> seb128: apt-cache show python-gtk2 | grep python2.5
<seb128> infinity: $ dpkg -L python-gtk2  | grep python | grep gtk.so
<seb128> /usr/lib/python-support/python-gtk2/python2.5/gtk-2.0/gtk/_gtk.so
<seb128> /usr/lib/python-support/python-gtk2/python2.4/gtk-2.0/gtk/_gtk.so
<seb128> infinity: ?
<seb128> infinity: you know, we have that new policy things
<seb128> several versions of python to the same package
<infinity> Depends: python2.5
<seb128> balem python-support? :p
<Amaranth> Provides: python2.5-gtk2, python2.4-gtk2
<Amaranth> Depends: python (<< 2.6), python-support (>= 0.3.4), python (>= 2.4),
<seb128> blame
<seb128> infinity: what arch is that?
<seb128> I've "Depends: python (<< 2.6), python-support (>= 0.3.4), python (>= 2.4)" on my edgy amd64
<infinity> seb128: i386... I have what you show for 2.10.3-0ubuntu1, but have python2.5 for 2.10.3-0ubuntu2
<seb128> infinity: ah, I've not apt-get updated yet, will have a look on it
<infinity> So, yes, I'd guess python-support 0.5.2 was the culprit.
<infinity> Or not... Both were built with that version.
<infinity> Hrm.
<sbalneav> Is fuse-utils now putting the fuse module into /etc/modules?  Seems that way from the logs.
<AnAnt> anyone knows where to get info (other than dash manual) about field expansion in dash ? the problem is that I got a variable VAR=foo1 foo2 ... , and I need to access a certain field (either foo1 or foo2 , ...)
<sbalneav> Seems so, from dpkg -e.  OK, I don't need to do that in ltspfs then.
<infinity> seb128: Hrmph.  Scanning edgy-changes, I don't immediately see anything uploaded/changed between ubuntu1 and ubuntu2 that sticks out as a scapegoat.
<seb128> infinity: the new version installs /usr/bin/pygtk-demo which uses "#! /usr/bin/python2.5"
<seb128> infinity: I'll fix that
<infinity> Oh, duh.
<infinity> That'd do it alright. :)
<infinity> Thanks.
<seb128> np
<seb128> thank you for pointing it
<seb128> and sorry for the bug ;)
<Kamion> seb128: I'd very much rather have built ubiquity over two releases, the first one as non-default, rather than blasting it straight in as the default
<Kamion> seb128: but commercial pressures meant that wasn't possible
<seb128> right
<seb128> not speaking about ubiquity I find the dapper polish level better than for previous versions
<jdub> Kamion: what's marc brockschmidt's nick? (is he an ircer?)
<elmo> jdub: HE
<jdub> thanks elmo 
<jdub> oh, that means i have to oftc or something
<jdub> ahr, here, but not here
<AnAnt> wifi-radar daemon ends after a short while, I think it is a bug
<illovae> ohayo :)
<illovae> first sorry for my english, but it's not my native langage
<seb128> hi
<illovae> i know there is an option -g for cp who make a progress bar avalaible while copying big files
<illovae> when i test it on my dapper, it doesn't work
<illovae> is it possible that the option is not integrated in the coreutils in the dapper version ?
<illovae> i can give you my source on linuxfr.org but it's in french
<illovae> i don't know if the coreutils are developed by the UbuntuDevels
<illovae> or if it's just a port from debian
<illovae> so...
<illovae> i ask here anyway
<seb128> illovae: we sync the packages on Debian, version might mismatch though
<seb128> illovae: is that a new cp feature?
<illovae> i don't know, i was just seaching for a tool who give a progress bar while copying files like wget
#ubuntu-devel 2006-10-05
<seb128> nautilus? ;:)
<illovae> but i know it is working, but i think it's depends of the coreutils devel
<illovae> i know it is working on mandrivia
<illovae> lol seb128 
<illovae> ^^
<seb128> what coreutils version is shipped with mandriva?
<illovae> hehe, good question
<illovae> look at this, 3 years ago > http://www.mail-archive.com/bug-coreutils@gnu.org/msg00610.html
<illovae> well i don't know the version on mandrivia i don't have it, i just saw a screenshot from it, on linuxfr.org
<seb128> illovae: according to http://linuxfr.org/~pascalscl/13847.html that was a Mandriva patch
<seb128> they stopped using it apparently
<seb128> the current spec has no such patch
<illovae> erf... i was thinking that this patch wasn't added on coreutils in debian or ubuntu
<illovae> but was available on other distribution
<seb128> doesn't look like
<illovae> what do you think of this patch ? a good idea, or the end-users don't want it ?
<illovae> i mean, maybe the devels can integrate it on the next rlz of coreutils
<seb128> I think it would have been accepted upstream or Mandriva would still be shipping it if it was good
<seb128> they probably stopped using it for a reason
<illovae> i'm really sorry i don't have any knowledge about how do i can demand that for a future version, maybe it's not the good place
<jdong> illovae: file a bug report agains the package
<seb128> usual way to ask to get a change is the bug tracker
<illovae> yeah, it appears that the shellusers don't care about a fonction like this
<illovae> oki jdong thx :)
<illovae> k seb128 
<illovae> oki
<desrt> is the decision for mountainview sponsorship delayed or does no answer = negative?
<illovae> thank you all for answering me with taking on your own time, i hope i wasn't too disturbing
<illovae> and again sorry for my english :D
<seb128> np ;)
<seb128> your english is good enough, don't worry
<zul> desrt: its been announced already
<illovae> k thanks but it's difficult lol, i write in english with the speed of a child
<desrt> so last time i think they sent out a "sorry, tough luck" email...
<LaserJock> I don't know that they are completely done though
<LaserJock> desrt: so maybe they haven't sent the "tough luck" emails yet
<desrt> nod.
<sivang> I've received it already :-)
<sivang> this mid-day
<ajmitch> LaserJock: I got mine
<ajmitch> just this morning
<sivang> maybe it was this morning,
<sivang> I got delusinal and started drinking the minute I saw it so can't recall >;-)
<illovae> sorry again, just a question for security : 'cp' and 'mv' are parts of coreutils right ?
<illovae> (for my bug report)
<desrt> ajmitch; did you get a tough-luck one or a friendly-love one?
<sivang> desrt: there are friendly-love ones as well? :)
<desrt> the "please come and we'll pay" ones :)
<ajmitch> desrt: tough luck, I suck, etc :)
<desrt> wow.  they actually said you suck?
<ajmitch> no
<desrt> that's tough indeed :p
<ajmitch> it was implied :)
<sivang> yes
<sivang> in mine as well ;)
<desrt> i guess failing SoC makes you a bit of a lepper :(
<seb128> illovae: they are
<illovae> thank a lot seb128 :)
<seb128> np!
<desrt> seb128; did you ever see my gdm hackery?
<desrt> seb128; i was sort of wondering if you could help me out with something
<seb128> desrt: I don't think so
<seb128> maybe
<ajmitch> desrt: I expect that
<seb128> what is that about? ;)
* sivang is happily selecting and manipulating DB2 Viper data from Python, joy!
<desrt> when you successfully login the login screen stays on
<desrt> and the 'enter your password' area is replaced by a progress bar
<desrt> which slides along as you login
<desrt> and the gdm window disappears only after the desktop is completely ready
<ajmitch> desrt: enlightenment-like bling?
<desrt> so you don't get all sorts of flickering when logging it
<desrt> it looks extra nice if the gdm background is similar to the desktop background
<seb128> desrt:  http://bugzilla.gnome.org/show_bug.cgi?id=322056
<Ubugtu> Gnome bug 322056 in general "allow to set background image when using graphical greeter" [Normal,Assigned]  
<desrt> seb128: more like http://bugzilla.gnome.org/show_bug.cgi?id=355190
<Ubugtu> Gnome bug 355190 in general "[rfe]  gdmgreeter continues to run during login process" [Enhancement,Unconfirmed]  
<seb128> desrt: that is what Mandriva do, that avoid jumping by a transitional uni-color background
<desrt> see the screenshot for an idea -- http://bugzilla.gnome.org/attachment.cgi?id=72465&action=view
<desrt> 'cept it's no longer a pulsed progress bar -- it's a real one
<seb128> right, those are 2 different ways to make the transition gdm to desktop smoother
<desrt> in any case i'm catching a fair amount of resistance from upstream on the issue
<desrt> and "distro X does it this way already" is sometimes good leverage :)
<seb128> right
<seb128> I'm not convinced I would prefer your way to the bug I pointed
<desrt> hmm.  ok.
<seb128> switching directly to the desktop background with the splash is good too
<seb128> I would need to try
<desrt> cool
<desrt> you need some gnome-session love in order for it to work properly
<seb128> I just think it would feel weird to have the gdm screen staying for the time of the session startup
<desrt> but i think there's some stuff attached to the bug that lets you emulate it with appropriate shellscrpts
<desrt> seb128; i hate to say it, but "see also: macos, windows"
<desrt> :)
<desrt> anyway.  friend is here.  gotta run.
<seb128> see you later
<sivang> laters desrt 
<seb128> almost time to sleep here ;)
<sivang> seb128: do you follow Paris time?
<seb128> correct
<sivang> so we have now have same time :)
* sivang read the last sentence and realizes he needs to go to sleep
<crimsun> LaserJock: pong
<LaserJock> I pinged you in here?
<crimsun> probably in -motu, migrating.
<bddebian> Howdy folks
<fossa>  i'd like to talk to a software developer or someone familiar with the field about what kind of salary i can expect as a member of a development team.
<nictuku> fossa, if you know, please tell me
<nictuku> if you find out, I mean
<fossa> nictuku, no one seems to have any idea.  it could range anywhere from $45-80K
<bluefoxicy> gimme some help here
<bluefoxicy> what happens on the initrd
<bluefoxicy> or more specifically what happens between executing /linuxrc and getting to readahead
<bluefoxicy> I believe it may be possible to improve readahead efficiency massively, but this is based on a couple big assumptions
<bluefoxicy> primarily, I am making the assumption that the boot order is initrd->linuxrc->load a bunch of hardware modules->mount and pivot root->pass control to upstart->load some more hardware->mount some essential file systems->bring up readahead
<bluefoxicy> in which case, initrd->linuxrc->load modules for rootfs and underlying hardware->activate read-ahead process in the background->continue as normal would take advantage of the time other hardware is being probed for and initialized
<wasabi> Hmm. Where's teh "reopen" button in LP?
<wasabi> On a bug.
<infinity> wasabi: Edit the bug and change the status from Fix Released to something else?
<wasabi> Don't have a status option anywhere I can find.
<infinity> Bug number?
<wasabi> bug 43465
<Ubugtu> Malone bug 43465 in libpam-krb5 "Unable to unlock." [Medium,Fix released]  http://launchpad.net/bugs/43465
<wasabi> oh there
<wasabi> you have to click on the "affects"
<wasabi> Heh. I got it.
<infinity> Yeha. :)
<infinity> There used to be a little arrow there that made it more obvious it was expandable.
<infinity> Not sure why that went away.
<wasabi> Thanks!
<bluefoxicy> whaaaa....
<bluefoxicy> the initrd has 176 modules on it?
<HrdwrBoB> it has all modules in it
<bluefoxicy> HrdwrBoB:  isn't that counterproductive
<ajmitch> wasabi: we could probably drag in new libpam-krb5 from debian, if you can test it & get back with some info on it
<bluefoxicy> HrdwrBoB:  that being, you have to load those all, unpack them into memory, modprobe them each, they have to be stored on disk in the initrd image...
<ajmitch> since it's still in universe
<infinity> bluefoxicy: Yes, it's inefficient, but it's the safest approach.  You can choose to have your initrd built with "MODULES=dep" to try to guess which modules to include and make it smaller, but it's less safe.
<bluefoxicy> infinity:  ah.
<infinity> bluefoxicy: See initramfs.conf(5)
<bluefoxicy> infinity:  is there a reason it's technically infeasible to detect rootfs file system type and the hardware it runs on?
<infinity> MODULES=dep also, of course, means that upgrading your motherboard or moving the hard drive to another box will leave you with an unbootable system.
<bluefoxicy> ...?
<HrdwrBoB> since there is no modules for that system
<infinity> If you only include the driver for your specific disk controller, you get a new controller...?
<bluefoxicy> The PCI drivers aren't generic.. the IDE interface should be generic except it won't have DMA (I've run without the IDE controller driver before, it's slow)
<infinity> Something an "expert" could deal with fine, but not robust for the ideal user.
<infinity> s/ideal/average/
<bluefoxicy> infinity:  the SATA controller I use will probably not work
<HrdwrBoB> even for an expert it's a PITA
<bluefoxicy> you _NEED_ the driver for the specific SATA you have
<infinity> bluefoxicy: Yes, that's my point.
<infinity> bluefoxicy: Hence why we build the "fat" initrd by default.  Much safer and easier for users to not break.
<bluefoxicy> for me when I had Gentoo I could never figure out my IDE controller until the last year of using it
<bluefoxicy> so I never had DMA
<bluefoxicy> but the generic IDE support got me actual access to the disk
<bluefoxicy> infinity:  nods, good points anyway.  But... NETWORK card drivers?
<infinity> Similar argument.  Fat initrds for thin (or chubby) clients.
<infinity> We don't actually load/probe them unless you're booting from a network, so it's just a bit of wasted space.
<bluefoxicy> infinity:  alright.  Is it safe to attempt to get the rootfs access immediately and get rootfs mounted early from the initrd, in its fat form?
<infinity> That's pretty much the whole point of initramfs anyway.
<infinity> I'm not sure how much more quickly we can get there.
<infinity> It's not like it does anything ELSE. :)
<bluefoxicy> what about the other hardware?  That's loaded from rootfs, even when it's got duplicate modules in initramfs?
<infinity> (Well, except for cute stuff like usplash and bootchart and thins)
<bluefoxicy> infinity:  about when does readahead come into play?
<infinity> Hardware loading is pretty much just done by udev, in two passes.
<infinity> So, what modules you have available determines what gets loaded.
<infinity> (I lied about the network driver thing, still thinking of pre-udevplug days)
<infinity> So, yeah, your NIC driver will probably get loaded in the initramfs.  No big deal.
<infinity> I don't have any NICs that actually take time to settle.
<infinity> Or, wait.  Maybe Scott calls udevplug with an argument to only load storage class stuff.
<infinity> Okay, I should go read the code again. :)
<infinity> Ahh, yeah, it just loads storage class stuff if you're booting local.  I was right the first time.
<infinity> So your NIC won't get loaded until we switch to the real root.
<bluefoxicy> infinity:  Well my endpoint is that I want to back readahead to when it's immediatly feasible to begin reading files off the rootfs, especially before drivers start getting loaded; drivers need to initialize hardware, and if readahead is running in the background while hardware is initting you have a CPU bound problem in parallel with an IO bound problem and they both parallel quite nicely.
<bluefoxicy> but I don't entirely understand what's happening at boot
<infinity> We tossed around the idea of two readahead invocations (one for rootfs, one for the full fs), but we don't really read enough from the rootfs before mounting /usr to make it worthwhile.
<infinity> So, we do readahead pretty much as soon as /usr is mounted.
<bluefoxicy> what about moving the mount of /usr back earlier, say as soon as you can satisfy access to its device
<infinity> It's already as early as it can get.
<bluefoxicy> mm.
<infinity> Check /etc/rcS.d, and tell me what you think could happen after /usr is mounted.
<bluefoxicy> oh, rcS is always started?  (couldn't figure that part out on my own)
<infinity> Oh, hey, Scott did give us that second readahead invocation.
<infinity> So, even that's happened.
<bluefoxicy> cool
<infinity> Yeah, rcS is the "boot" runlevel.
<infinity> You go from initramfs to rcS to whatever default runlevel you have (usually rc2)
<bluefoxicy> hmm
<bluefoxicy> the only other thing I can think of is that readahead is not adaptive; but preload is too much of a nightmare to me
<wasabi> ajmitch: Sorry. I don't think it's libpam-krb5's fault.
<ajmitch> wasabi: oh well, I'll look at reasons to get it updated anyway :)
<wasabi> Heh.
<wasabi> We're going to be doing directory integration stuff at the summit.
<wasabi> libpam-krb5 will be a part of that. ;)
<jdong> bluefoxicy: preload is indeed a nightmare
<jdong> bluefoxicy: on my box, it tends to cause extra disk IO more than anything else
<bluefoxicy> jdong:  I think it c.. yeah, thrashing.
<ajmitch> wasabi: yes, I'm really hoping to get there if at all possible
<jdong> bluefoxicy: personally I'd like to see more work in the readahead department
<jdong> I like readahead
<bluefoxicy> jdong:  How early can I get inotify up
<jdong> if prefetchers are made for GNOME, firefox, etc...
<jdong> all I think are necessary are launcher wrapper scripts
<ajmitch> wasabi: I have a few things to bring up..
<wasabi> ajmitch: Hope ya make it. Planning on it?
<bluefoxicy> jdong:  preload is probably dumb enough to read-ahead entire libraries
<jdong> bluefoxicy: I don't think preload has any level of intelligence :D
<ajmitch> wasabi: looking at how I can get there
<bluefoxicy> I would read-ahead their headers only first and then go back and read their .data  and let .text be
<bluefoxicy> (dynamic linking ONLY cares about headers...)
<bluefoxicy> jdong: I would tie the read-ahead into init mainly; just-in-time read-ahead is pretty pointless, except maybe reading in library headers to make dynamic linking more IO bound
<jdong> bluefoxicy: jit readahead reduces disk seeking
<bluefoxicy> I mean, you start loading Gnumeric.  It's going to immediately start picking up libraries.  Possibly faster than you can read them in.
<jdong> bluefoxicy: that's a pretty big deal for something like GNOME startup
<bluefoxicy> jdong:  I could make the dynamic linker do it.
<jdong> my GNOME startup is clearly IO bound
<bluefoxicy> no, seriously, ld.so could be hacked to do it
<bluefoxicy> it reads the needed library section (DT_NEEDED?) and loads libraries one by one, it could easily fork() and set up a readahead() call to each in their header area (and then exit) while it goes and dynamic links
<bluefoxicy> i'm severely unmotivated to try to hack glibc
<bluefoxicy> I know drepper and friends will just be like "that sucks fuck off" and then show up 3 weeks later with a slightly altered patch "we wrote this, some other guy tried to do something like this but his was stupid ours is much cooler"
<mjg59> bluefoxicy: We've heard this before
<bluefoxicy> mjg59:  oh, right, yeah.  I've seen it too many times.
* bluefoxicy shrugs and curls up.
<nictuku> infinity, maybe NWU will enter Debian experimental soon, I believe. Will you still be able to review its security, as you offered months ago?
<infinity> nictuku: If I have time, I can look at it sometime, sure.
<nictuku> infinity, thank you. I'll let you know when it gets to the next milestone
<whiprush> mjg59: when you refer to docks in your post to the list, do you mean things like resuming in the dock?
<whiprush> or just having the dock work?
<nixternal> xorg-driver-fglrx broken?  can't get it to work here now..was working until i reboote =/
<HrdwrBoB> yeah
<HrdwrBoB> looks like kernel has been updated and fglrx hasn't
<nixternal> ok..whew ;)
<infinity> Err, but the kernel didn't have an ABI change...
<infinity> At least, wasn't meant to.
<infinity> Oh well, I'll be uploading a new LRM later anyway, so maybe the problem will just go away.
<nixternal> as long as i get my 1600x1200 back soon, i don't care ;)
<freakabcd> hi all
<freakabcd> crimsun, err.. i believe this guy did a _working_ sample implementation _before_ dapper was released!
<freakabcd> and its suddenly edgy+1 material?
<freakabcd> don;t tell me you guys decided even before dapper was released that binary deltas will be edgy+1 material? heck somehow i think it might even be edgy+2 material :(
<crimsun> freakabcd: "suddenly" is a bit far flung
<freakabcd> sorry, it is indeed.
<freakabcd> but could you elaborate on the idea that it was pre-conceived waay back that its edgy+1 material?
<tfheen> freakabcd: was there an implementation in the archive before feature freeze?
<freakabcd> tfheen, i dunno about dapper. but surely before even edgy opened for devel
<freakabcd> its somewhere in the mailing list archives.
<tfheen> freakabcd: oh?  Can you point me to the spec?
<freakabcd> https://lists.ubuntu.com/archives/ubuntu-devel/2006-May/017602.html
<freakabcd> there might be another main thread somewhere else. but thats the one i found byt looking just now
<tfheen> that's not a spec, though.  Our development process is spec-focused where all features should have a spec before they are implemented
<freakabcd> err.. what i meant was. if you read that thread: theres not much interest in even writing a spec.
<freakabcd> you can;t expect 1 person to do all the work of writing the spec and implementing a proof-of-concept
<freakabcd> the guy wrote a proof-of-concept that works. now write a spec and a proper implementation (i guess by committee). this never happened
<tfheen> if there's no interest in the feature, nobody will write the spec.
<tfheen> it's quite simple, really
<freakabcd> really, people just underrate bandwidth.
<Treenaks> really, some people overrate it
<freakabcd> updating huge megabytes of packages for few kb of changes
<tfheen> that might be, but somebody needs to write the spec and make sure it gets targetted for a release.  That requires somebody to push for it, not just write a sample implementation and hope it all works out in the end.
<Hobbsee> tfheen: no magic wand waving?  no fun!
<jdub> wang!
<tfheen> Hobbsee: heh. :-)
<tfheen> Hobbsee: good morning
<ajmitch> afternoon Hobbsee 
<tfheen> freakabcd: and complaining about missing features after feature freeze is a bit late.
<freakabcd> apologies, my objective was not to engage in an 'include this feature or die' conversation.
<tfheen> https://wiki.ubuntu.com/FeatureSpecifications tells a bit about how the process works
<Hobbsee> hey tfheen, ajmitch :)
<bluefoxicy> boot chart says things are a mess I/O wise.  Hrm.
<bluefoxicy> How early can I get inotify up
<pitti> Good morning
<Hobbsee> hey pitti 
<dholbach> good morning
<seb128> mdz_: I think I didn't get a reply to the mail I sent you where I suggested seeding avahi-daemon, is that still pending reply on your side?
<mdz_> seb128: I don't think it's in my inbox; please resend
<seb128> mdz_: it was a reply to your mail about avahi-daemon activated by default (following on the debian thread about it)
<seb128> mdz_: ok, will do
<tfheen> mdz_: any chance you can nag LP people to get https://launchpad.net/products/malone/+bug/62495 fixed or worked around?  RC will be painful without it fixed.
<Ubugtu> Malone bug 62495 in malone "Milestone bug list doesn't sort properly" [Undecided,Confirmed]  
<cbx33> ping mvo
<mvo> hello cbx33
<heno> tfheen: when shall we set the WinFOSS freeze at? I'm easy, the remaining work is trivial anyway
<cbx33> preffered method for upgrading a dapper machine to edgY?
<seb128> update-manager -d 
<cbx33> I need to do an upgrade test for edubuntu for ogra
<cbx33> hmmm
<heno> This page doesn't actually have an RC FREEZE data AFAICS https://wiki.ubuntu.com/EdgyReleaseSchedule
<tfheen> heno: personally, I like to get stuff done early rather than late, so either ten or seven days before RC?
<cbx33> seb128 i get nothing
<cbx33> just the normal update
<mvo> cbx33: update-manager -c -d, please let me know about the result 
<cbx33> ok
<cbx33> will try again
<cbx33> mvo got it with that command, but only if I export my proxy details first
<cbx33> this was raised as a bug last time
<heno> tfheen: ok, monday is 10 days before, we can do that
<mvo> cbx33: do you use gnome-terminal? is your proxy configured via gconf?
<cbx33> hmmm lemme check not sure on this machine
<cbx33> it is certainly configured in apt
<tfheen> heno: if that's not enough time, do tell me, though
<cbx33> i just set it up in the gnome network proxy 
<cbx33> using the auto config script option
<cbx33> and it still doesn't work
<heno> tfheen: the only thing is if Firefox put out a very important fix late in the process, but I can ask for a special exception for that
<heno> So we'll go with monday
<cbx33> doesn't seem to work at all mvo
<mvo> cbx33: this is probably a transient failure, this whole thing works by using http_proxy. that is passed via gksu and gnome-terminal. if you use the gnome-terminal that is still open it will fail unfortunately
<tfheen> heno: sure.
<cbx33> ah ok
<cbx33> I'll try not using gnome terminal
<mvo> cbx33: *but* please file a bug about this, so that I can fix it properly 
<cbx33> nope still doesn't work even if I run from the menu
<cbx33> only way I can get it to successfully run is to export the proxy details first
<mvo> cbx33: oh, plesae file a bug then, I will fix it with the next upload (fix should be straight-forward)
<cbx33> mvo no problem
<mvo> thanks
<Burgundavia> cbx33: do you not have an LP account?
<ogra> Burgundavia, https://launchpad.net/people/petesavage
<Burgundavia> ogra: odd, because mdz commented on that bug that he couldn't find pete
<ogra> which bug ?
<cbx33> mvo - https://launchpad.net/distros/ubuntu/+source/update-manager/+bug/40626
<Ubugtu> Malone bug 40626 in update-manager "Update manager ignores proxy settings when attempting to download upgrade tool for Dapper." [Medium,Needs info]  
<cbx33> Burgundavia: I know but I do have an account else I wouldn't have been able to do a lot of things ;)
<cbx33> that was created ages ago
<mvo> cbx33: ok, updated
<cbx33> ty dude
<ogra> Burgundavia, he's edubuntu member and motu ... 
<cbx33> ogra starting the upgrade now
<Burgundavia> ogra: yes, that is what I thought
<ogra> cbx33, thanks, and apparently you identified a bug already ;)
<cbx33> maybe it's because I'm PeteSavage and not Pete Savage
<cbx33> I reported it back in the breezy -> dapper
<cbx33> but then I think before I could LP it, someone else had
<seb128> cbx33: dunno if you read the comments, your gconf change is not good
<cbx33> I havn't had a chance to read yet
<cbx33> seb128 oh?
<cbx33> I'll go read
<seb128> cbx33: it breaks login in some cases apparently
<seb128> cbx33: I got gconfd complaining than /var/....USER directory can't be created
<cbx33> grr
<seb128> cbx33: and session exiting on that
<cbx33> *&%$
<cbx33> hmm.....
<cbx33> any ideas?
<seb128> no, nothing trivial
<cbx33> shute
<seb128> either look at gconfd-2 code and make it handle that fine
<cbx33> ogra anything from your end?
<seb128> or make something create those directories, not sure on where to plug that though
<cbx33> seb128 sure - hmm
<seb128> it would be easy to create them for existing users
<seb128> the issue is if you create a new user it would need to create the directory too
<ogra> i'd add it to users-admin then ...
<cbx33> yeh
<seb128> and I don't fancy try to change adduser, etc for that
<Kamion> argh no
<Kamion> users-admin <- wrong place
<ogra> oh, why ?
<seb128> because it's a gconf directory
<ogra> additional groups are added there as well
<ogra> ah, k
<Kamion> ogra: people add users with useradd, adduser, or hell they create them on a totally different machine using NIS or whatever
<cbx33> true
<seb128> and some people add users who don't use GNOME :p
<Kamion> there's no way to do this correctly by patching the user creation tools
<ogra> right
<cbx33> ok ogra I'm going for the upgrade....ok?
<Kamion> if you want a per-user directory you need a component running as root to create it
<cbx33> Kamion: yup
<cbx33> but it's too late for that now
<seb128> the way is probably to make gconfd-2 not complain when the directory doesn't exist
<cbx33> again too late for that now
<seb128> probably yep
<cbx33> damn it
<cbx33> it worked fine here
<seb128> it doesn't here
<ogra> cbx33, we have a component running as root ...
<Kamion> cbx33: if it's too late for that now, then the patch surely needs to be reverted
<ogra> why cant S-C-P create it if needed ?
<Kamion> too late to do it at all correctly => don't do it at all ...
<seb128> ogra: I'm not going to change gconf in a way which makes it break if you root component is not running
<cbx33> ogra: sure 
<cbx33> but scp isn't runnign all the time
<ogra> right
<seb128> Kamion: I didn't upload the patch since I faced the issue with my test user on my desktop
<cbx33> and the dir is created in pessulus
<ogra> i thought its only about creating the dir ... (didnt know it breaks without it)
<Kamion> seb128: ah right, good
<cbx33> ogra: no....that's the issue
<cbx33> pessulus creates it......
<cbx33> when you first load it for a specific user
<seb128> (in fact I uploaded the patched version and a next one reverting it but both had wrong targets and were refused)
<ogra> cbx33, it would be nice if you could CC me in the conversation about such issues next time ...
<cbx33> ogra this is the first I've heard of it
<ogra> since i only understand half of what you guys are talking about atm
<cbx33> we have a dir created to allow per user mandatory keys
<ogra> yep
<cbx33> but if that dir doesn't exists - some machine fail to login
<seb128> ogra: cbx33 asked me to add "xml:readonly:/var/lib/gconf/users/$(USER)/gconf.xml.mandatory" to the gconf path
<seb128> ogra: I did the change yesterday
<ogra> ah
<seb128> started gdmflexiserver --xnest and logged in with my test user
<ogra> that was the patch discussed with vuntz right ?
<cbx33> yes
<cbx33> he suggested that dir for it
<seb128> and gconf complained that /var/lib/gconf/users/USER can't be created and doesn't exist
<ogra> where he said that *could* work but would need testing
<seb128> and the session exit
<ogra> right
<seb128> so it's no go from me
<cbx33> it "does" work
<ogra> lets postpone that for edgy+1 then
<cbx33> for me
<seb128> it works when I log in with gdmflexiserver and not when I use gdmflexiserver --xnest
<seb128> for a reason I don't explain yet :p
<cbx33> argh !
<ogra> to get more testing and a proper solution for gconf ...
<cbx33> ok....
<cbx33> ogra we can put that line in a howto on the wiki
<cbx33> I've never used gdmflexiserver - so 
<cbx33> I generally test on real machines :(
<seb128> right, that's one a conffile change
<seb128> no need to rebuild a package for it
<cbx33> indeed
<cbx33> and per user mandatory keys is a "advanced" feature anyway
<seb128> cbx33: better to test such changes with all sort of situations
<ogra> ok
<cbx33> seb128 - I need more info then :0
<cbx33> heheh
<cbx33> i don;t know all the weird and wonderful ways you guys test yet
<cbx33> so I'm updating now ogra
<ogra> cbx33, are you coming to MV btw ?
<ogra> if so, lets put up a spec and invite seb128 to the table ;)
<ogra> SCP will need more enhancements anyway ... 
<seb128> :)
<cbx33> totally
<pitti> mjg59: on my ibook, resuming from STR causes the hard drive spindown time to be reset to 5 seconds; that's destroying the disk (besides being annoying), so I always have to manually reset it to some sane value (15 minutes); do you know which part causes this?
<giftnudel> pitti: laptop-mode
<pitti> giftnudel: it's not installed
<pitti> that's universe
<pitti> it's a standard edgy beta installation
<giftnudel> but there is something which does this kind of thing
<giftnudel> pitti, so you don't have /etc/laptop-mode/laptop-mode.conf ?
<pitti> giftnudel: I do, it's from laptop-mode-tools
<giftnudel> it's in that file
<giftnudel> LM_AC_HD_IDLE_TIMEOUT_SECONDS, LM_BATT_HD_IDLE_TIMEOUT_SECONDS, etc
<pitti> giftnudel: argh, indeed: CONTROL_HD_IDLE_TIMEOUT=1, TIMEOUT_SECONDS=5
<pitti> WTF????
<pitti> so that kills hard disks on all arches
<giftnudel> yes
<pitti> even for AC power
<giftnudel> well, no, it's not active for ac
<pitti> giftnudel: it is, I am on AC
<pitti> LM_AC_HD_IDLE_TIUMEOUT_SECONDS=5 <= default
<giftnudel> yes, but there is still a setting to disable it on ac
<pitti> it should be off for AC and something like 15 minutes for battery
<giftnudel> yes, this sounds reasonable
<pitti> giftnudel: do you know the difference between LM_ and NOLM_?
<giftnudel> laptop-mode and no laptop-mode
<pitti> ah, thanks
<pitti> giftnudel: so, the AC timeout for NOLM is 7200, and for LM 5
<giftnudel> yes
<pitti> mjg59: do you agree to raising the default timeouts?
<giftnudel> "laptop-mode stop" uses the no l-m thing, and ac and batt are for l-m on
<giftnudel> pitti: it is explained at the start of the file
<pitti> giftnudel: ok, thanks for your help!
<giftnudel> ENABLE_LAPTOP_MODE_ON_AC=0
<giftnudel> this is also an important option
<giftnudel> yes, no problem
<pitti> giftnudel: then this one obviously does not work on the ibook
<giftnudel> it seems so, but I really suggest a complete review of all options
<pitti> I'll file a bug about it for discussion
<giftnudel> target it to 6.10, it's easy fixable, but I think we should reach a consensus before that
<giftnudel> and backport it to dapper after that, since it really spins down the disc after 5 secs which is a lot!
<tonfa> gug
<giftnudel> oh, I think laptop-mode is not enabled on edgy atm (it gets switched off and on on a regular basis due to some bug reports)
<tonfa> pitti: ping
<pitti> hi tonfa 
<tonfa> pitti: is there some channel for apport related discussion ?
<tonfa> or /query ?
<pitti> giftnudel: ah, bug 29529, was already filed
<Ubugtu> Malone bug 29529 in laptop-mode-tools "HDD powerdown every 2 seconds in Dapper" [Critical,Confirmed]  http://launchpad.net/bugs/29529
<pitti> tonfa: /query is fine for me, or use this channel
<giftnudel> pitti: thanks, I found that too
<tepsipakki> poking with a stick here, but couldn't 'uname -r' in Ubuntu tell something about the OS version as well?
<thom> changing uname is badness
<Kamion> that'd be out of spec for uname -r and would break things
<Kamion> use lsb_release
<pitti> tepsipakki: try lsb_release -a
<tepsipakki> ok, that looks nice
<Kamion> lots of code parses uname -r (or the equivalent kernel structure) to work out the kernel version it's running on
<tepsipakki> yeah, I see
<tepsipakki> it's just that lsb_release isn't available on other unices ;)
<Kamion> that's easily checked ...
<tepsipakki> solaris and tru64 seem to be the ones that output something sensible with uname -r, macosx outputs the kernel version (8.7.0 on 10.4), aix just "2" on 5.2 etc
<Kamion> the commercial Unixes often sync up the kernel version with the distribution release
<tepsipakki> but I understand that it isn't trivial to change uname in linux.. especially if lsb_release is the standard way to tell the distro in linux
<Kamion> but given a known flavour of Unix, uname -r should be considered to have a fixed format
<tepsipakki> yes, maybe I won't file a bug about it, instead inform the unix-punks to use lsb_release in linux ;)
<tepsipakki> uname works too, if you know which kernel is in wich
<tepsipakki> +h
<Keybuk> ogra: sysvinit, you about to do it?
<Keybuk> if not, I have a quick upload
<ogra> Keybuk, then do it
<Keybuk> ogra: should ldm not also be in that list?
<ogra> Keybuk, nope
<ogra> ldm doesnt have an initscript
<ogra> ltsp-client starts the screen scripts for ltsp, one of them is ldm
<ogra> but there isd for example also the startx screenscript that starts an XDMCP session
<ogra> depending on what you select in your lts.conf file
<ogra> (ldm is just the default)
<ogra> i had two reports now that there is a conffile prompt for login.defs during upgrades
<givre> pitti: #35354 , David Zeuthen has just commit a fix for that bug which is actually in git : http://gitweb.freedesktop.org/?p=hal.git;a=commit;h=2ea340399bf8cf3d2bb6bd1b5c4ecbc2042e93d4
<pitti> bug 35354
<Ubugtu> Malone bug 35354 in nautilus "hal does not recognize NTFS-FUSE mounted devices as mounted" [Medium,Needs info]  http://launchpad.net/bugs/35354
<pitti> givre: ah, sweet
<givre> pitti: tested it and it works great
<pitti> givre: could't you have told me 30 minutes ago? I just uploaded a new hal :)
<pitti> (nevermind)
<givre> pitti: i saw, yeah ;)
<ogra> hrm, 2what apart from shadow touched /etc/login.defs ?
<Treenaks> Upload the pod bay doors HAL
<ogra> Kamion, ^^^ ? any idea ?
<ogra> i see you merged it ...
<givre> pitti: there is still a possible issue about the right options to allow
<givre> pitti: ntfs-fuse & ntfs-3g use locale= instead of iocharset=
<givre> pitti: it's could be good to add it
<pitti> givre: that's an entirely separate bug, isn't it?
<givre> pitti: separate ? the option stuff ?
<givre> pitti: i'll forward you the email i get from David Zeuthen if you want
<givre> pitti: there is too change in the commit, one for autofs, which is in any not in edgy hal, and one for fuse
<givre> pitti: the right change to do is add at the bug, http://librarian.launchpad.net/4667871/support-fuse.patch
<Kamion> ogra: shadow's within its rights to change /etc/login.defs (and it did). The question is more: what other script changed /etc/login.defs?
<ogra> right
<Kamion> and that I don't know
<Kamion> conffile prompts are only a bug if a script changed the conffile
<Kamion> they aren't a bug in general
<ogra> i cant find anything touching it by grepping through /var/lib/dpkg/info/*
<Kamion> then quite possibly those users changed it and forgot about it
<ogra> nope
<ogra> cbx33, installed a plain dapper and did an edubuntu upgrade test for me
<Kamion> ok
<ogra> so its untouched
<ogra> and i had a report from pips1 during a beta upgrade 
<ogra> intrestingly *my* /etc/login.defs in edgy has 
<ogra> -rw-r--r-- 1 root root 11K 2006-09-22 03:36 /etc/login.defs
<Kamion> 482803f5fcf4df8ad4f99fb8b0ee3ff1  /etc/login.defs
<ogra> i'm pretty sure i didnt get a new login package since i installed ... so something touched it as well on 2006-09-22
<ogra> 1f6b6a6190933f3a324db770df21e1a7  /etc/login.defs
<ogra> (edgy)
<Kamion> my timestamp matches the last login
<Kamion> package
<Kamion> ogra: could you diff yours against http://people.ubuntu.com/~cjwatson/tmp/login.defs, please?
<ogra> ok
<ogra> ogra@edubuntu:~/packages$ diff login.defs /etc/login.defs 
<ogra> 177,178c177,178
<ogra> < UID_MIN                        1000
<ogra> < UID_MAX                       60000
<ogra> ---
<ogra> > UID_MIN 1000
<ogra> > UID_MAX 60000
<ogra> aha
<ogra> whitespace :(
<esputo> hello, I would like to create a dapper server iso with updated packages, I've been reading arround but I get stuck on the creation of "Packages" files under /dists/ directory, is there any tool for that?
<pitti> givre: thanks, I'll read the mail
<pitti> esputo: apt-ftparchive does that normally
<esputo> thak's pitti I'll give it a look
<pitti> esputo: also, take a look at https://help.ubuntu.com/community/InstallCDCustomization
<Kamion> ogra: it's not gnome-system-tools or something messing with that file?
<givre> pitti: better : http://lists.freedesktop.org/archives/hal/2006-October/006308.html
<ogra> Kamion, ah, that could be i think i added a testuser around that time
<ogra> i'll add another one
<pitti> givre: thanks; I added that to the bug trail
<ogra> ogra@edubuntu:~/packages$ ls -lh /etc/login.defs 
<ogra> -rw-r--r-- 1 root root 11K 2006-10-05 12:14 /etc/login.defs
<ogra> Kamion, yep, it is
<ogra> wow, that was a good guess :)
<ogra> dholbach, ?? ^^^
<ogra> why is it touching it ?
<givre> pitti: thanks
<dholbach> what is touching what?
<ogra> dholbach, g-s-t rewrites /etc/login.defs
<dholbach> ah, g-s-t
<ogra> and adds whitespace
<Kamion> s/adds/removes/
<cbx33> ogra: ok I have another
<ogra> err, right
<cbx33> initramfs.conf
<Kamion> that's not so much the point though - it shouldn't touch the file if the values it wants to write are the same as those that are already there
<ogra> i dont see a reason to touch it at all though
<ogra> cbx33, hmm
<cbx33> the RESUME field setting has been altered
<cbx33> that's the only thing
<Kamion> RESUME should live in a separate file now, typically /etc/initramfs-tools/conf.d/resume
<Kamion> there may be some glitchiness in that upgrade
<cbx33> -RESUME=/dev/mapper/Ubuntu-swap_1
<cbx33> +#RESUME=
<cbx33> is the only diff on that file
<dholbach> ogra: system-tools-backends, /usr/share/system-tools-backends-2.0/scripts/Users/Users.pm, line 655
<cbx33> got enough info on that one? - chall I continue with a replace?
<cbx33> that's /etc/initramfs-tools/initiramfs.conf
<ogra> cbx33, yep
<dholbach> ogra: it's used since you can change that for example in the g-s-t UI - but I guess it could be a tad more careful with preserving whitespaces *shrug*
<ogra> it should
<cbx33> it wasn't just whitespace
<dholbach> called from UsersConfig.pm, line 77
<cbx33> sorry I've missed some of the convo
<cbx33> and cgi-irc makes it difficult to scroll back up
<ogra> the system breaks apparently if you don5t let the package overwrite it with the package file
<ogra> pips1 had that case
<ogra> he couldnt log in anymore
<cbx33> i replaced so unfortuantely I can't tell you on that score :(
<cbx33> shall I replace with this initramfs?
<ogra> (i'll ask him for details if he's around)
<cbx33> ok
<ogra> cbx33, yes, thats apparently known
<seb128> dholbach: what is used?
<Kamion> Riddell: so, assuming that I fix the DCOP calling problem in ubiquity (which I'm working on now), how do I disable the kded medianotifier?
<dholbach> seb128: s-t-b seems to touch /etc/login.defs and somethin in edubuntu land (not sure if i understood correctly) doesn't cope with whitespace changes
<cbx33> can I ask...is it necessary to regenerate the suaplsh so many times
<seb128> dholbach: ah, k
<cbx33> usplash
<Kamion> dholbach: nothing to do with Edubuntu - /etc/login.defs is a conffile owned by shadow
<Kamion> er, login
<dholbach> &Utils::Replace::split ($file, $login_defs_prop_map{$key}, "[ \t] +", $$config{$key});
<cbx33> on slower machines it takes a long time to regenerate 3-4 times
<Kamion> dholbach: you have to be very careful when editing conffiles to avoid unnecessary changes
<Kamion> making sure to replace with the same amount of whitespace would help
<ogra> urgh !
<ogra> the craftsmen need to shut down my power
<cbx33> nooooooo
<cbx33> battery?
<cbx33> generator
<cbx33> treadmill??
<ogra> no, we get a solar power system and they are doing the final wiring
<cbx33> ahhhhh yes your solar power
<ogra> brb
<seb128> carlos: around?
<seb128> carlos: any reason https://launchpad.net/distros/ubuntu/+source/yelp/ has no "translation" link working?
<cbx33> is it a known one about exports ?
<cbx33> I have a debconf popup
<carlos> seb128: translations need a distrorelease as a context
<Kamion> Riddell: HAH, fixed the DCOP problem - just need to use kdesu --nonewdcop
<carlos> seb128: for instance, https://launchpad.net/distros/ubuntu/edgy/+source/yelp/
<seb128> carlos: ok, thank you
<carlos> seb128: please, file a bug about that, I think is quite easy to add links to the prefered distrorelease
<seb128> carlos: bug on what product?
<carlos> rosetta
<seb128> ok
<Riddell> Kamion: for logout?
<dholbach> sladen: thanks for taking care of fschoep's patch
<Riddell> ah, medianotifier
<Kamion> Riddell: well, I fixed it so that we can make reboot work now
<Kamion> (properly, that is)
<Riddell> Kamion: you're a genius
<cbx33> dudes this debconf thing is horrid
<cbx33> :p
<Kamion> Riddell: still don't know how to disable the medianotifier though
<Riddell> Kamion: turning off medianotifier is "dcop kded kded unloadModule medianotifier"
<cbx33> it popped up so I asked it to show me changes
<seb128> carlos: https://launchpad.net/products/rosetta/+bug/64154
<Ubugtu> Malone bug 64154 in rosetta "package page should have a link to current translation" [Undecided,Unconfirmed]  
<Kamion> that's not debconf's fault, it's ucf
<cbx33> which it did in the update manager windows text consoly thing
<Kamion> (probably)
<Kamion> debconf is just the framework, don't blame it
<carlos> seb128: thanks
<seb128> np
<cbx33> and i tried pressing space enter, eventually it's q i needed to press
<cbx33> Kamion sorry I'm not blaming
<cbx33> I'm just end usering on this one ;)
<givre> pitti: i was thinking that adding the right options to volume.mount.valid_options is only needed when you use a solution like gnome-mount, isn't it ?
<Kamion> Riddell: oh, dcop kded kded unloadModule maybe?
<Riddell> Kamion: that's what I said :)
<Riddell> 11:34 < Riddell> Kamion: turning off medianotifier is "dcop kded kded unloadModule medianotifier"
<Kamion> Riddell: oh, I totally missed it
<Kamion> Riddell: and guessed it myself ;-)
<Kamion> whoops
<Kamion> ok, cool, I'll try to wire that in
<cbx33> btw guys - http://www.progbox.co.uk/finals/RC/exportUB2.ogg
<cbx33> shorter login sound
<Kamion> Riddell: do I have to unload the mediamanager too?
<Riddell> Kamion: don't think so, that just means KDE uses HAL instead of reading fstab, but medianotifier should be the annoying popup boxes part
<pitti> Kamion: if you have some seconds, can you please take a look at bug 61092?
<Ubugtu> Malone bug 61092 in mozilla-firefox-locale-all "mozilla-firefox-locale-en-gb contains incorrect translations of "disk" (both dapper and edgy)" [Low,Needs info]  http://launchpad.net/bugs/61092
<pitti> Kamion: I think the current Firefox en-GB translation is correct, but I'd appreciate your opinion
<Kamion> "disc" is a somewhat ... fanatic British English approach, IMHO
<Kamion> most computer-literate British English speakers I know use disk in the manner described by the reporter (i.e. not for CDs, but for practically everything else)
<Ng> yeah, disc is something flat and round
<Ng> otherwise disk
* Keybuk agrees
<Kamion> I do know a few people who'd say "hard disc", but they also spell "font" as "fount"
<Keybuk> I violently dislike people who do s/disk/disc/
<Kamion> and other such archaisms
<Keybuk> Kamion: computer programme ?
<Ng> I'd guess it's from discus
<Kamion> Keybuk: right
<pitti> ok, then I do The Big Sed to fix that; thanks, guys
<Keybuk> I just consider "disk" to be jargon, short for "diskette"
<Spads> pro-grammammy
<tfheen> Kamion: fount?  Is that legal?
* pitti has major trouble with keeping apart AE and BE spellings
<pitti> I can never quite remember whether grey/gray or -ize/-ise is AE or BE
<Kamion> tfheen: very very old
<Kamion> I can never remember grey/gray myself
<Kamion> I use grey, but then I also used to use -ize before I got bored of it and switched to -ise
<Kamion> Riddell: hmm, well that worked, but for some reason the subsequent loadModule didn't seem to work
<Kamion> Riddell: do you care? I think it's probably more important to get it unloaded to avoid the annoying popups
<Keybuk> pitti: -ize/-ise is different depending which BE dictionary you use
<Keybuk> Oxford prefer -ize, Cambridge prefer -ise
<Riddell> Kamion: no, I don't care about loading it back
<pitti> joy
* pitti guesses his writing is a wild mixture of both
<Kamion> Riddell: righto, done then, I'll hope it's just a glitch
<tfheen> I guess grey is british since it's Gandalf the Grey, not Gandalf the Gray.
<Riddell> pitti: grey, -ise.  ignore the silly Oxford people
<pitti> Riddell: I'll get gray hear while thinking about that :)
<Keybuk> pitti: Cambridge says grey ...
<Keybuk> David appears to have hidden my OED
<tfheen> also, HTML only allows gray, which is annoying.  At least, it used to back in 1996.
<Ng> tfheen: and center :(
<tfheen> grey tended to be interpreted as green, which left me dumbfounded for a bit.
<Riddell> I'm pretty sure CSS allows grey
<tfheen> Riddell: HTML, not CSS.  This was back before CSS.
<Kamion> http://www.w3.org/TR/html4/types.html says it's still only gray in HTML
<Keybuk> pitti: OED says grey too
<tfheen> when HTML 2.0 was the new and shiny thing.
<Riddell> yes
<Keybuk> so gray must be American
<Keybuk> though both note that gray is a colour for horses
<ogra> Keybuk, meh, ltsp-client is the first service started in rc2 ... so num_services is still 0
<Keybuk> ogra: ?
<tfheen> apart from the pink overload, I liked the explanation in http://www.bernzilla.com/item.php?id=232
<ogra> Keybuk, sorry, num_steps
<ogra> Keybuk, num_steps is initially set to 0, and the case condition breaks without adding 1 to it
<Keybuk> yes?
<ogra> so if ltsp-client is the first service in a runlevel num_steps is still zeroed ... and i dont get progressbar steps at all
* Keybuk is still failing to see your point
<Keybuk> if ltsp-client is the first service, you don't want progress steps?
<ogra> i want them
<Keybuk> well, you can't have them
<Keybuk> so there
<ogra> but the code prevents me from getting them
<Keybuk> :)
<ogra> well, it should add 1 to num_steps before the break
<Keybuk> the code doesn't count the step that stops usplash, for obvious reasons
<Keybuk> no, it shouldn't
<Keybuk> otherwise the users will never *see* it hit 100% cause usplash gets stopped
<ogra> well, if i make it the second service, i see a gap at the end of the progressbar
<Keybuk> it's zero based so it hits 100% then usplash stops
<ogra> it never gets to the full end
<Keybuk> that's wrong
<ogra> right
<Keybuk> if you make it the second service, then num_steps = 1
<ogra> but it gets to 90%
<Keybuk> so it would reach 100% after the end of the first step
<Keybuk> and you wouldn't see a gap
<ogra> i can live with that for now and will make ltsp-client the second service, but i think num_steps should be at least 
<ogra> 1
<Keybuk> no, it shouldn't
<ogra> lets talk about it in MV :)
<Keybuk> otherwise you'd never see the end of the progress bar
<Keybuk> it has to hit 100% before usplash it stopped
<Keybuk> have you bothered to read rc?
<pitti> tfheen: wrt. bug 60448 you had some thoughts, too; I would rotate the current .xsession-errors to .xsession-errors.prev and create a fresh .x-e on login; is that fine for you?
<Ubugtu> Malone bug 60448 in xorg ".xsession_errors file grows out of control & saturates disk space" [High,In progress]  http://launchpad.net/bugs/60448
<Keybuk> it tells usplash to change the progress when the script run *FINISHES*
<Keybuk> not before it starts
<Keybuk> so it's entirely correct that num_steps=0 if the display manager is the first thing
<ogra> hmm
<Keybuk> because you want no steps for that entire runlevel
<Keybuk> I could believe there's a bug simply because it divides the progress bar up
<ogra> anyway, i'll make it the second service for now 
<Keybuk> it leaves the last third for the rc2
<Keybuk> but because there's nothing in rc2, it never actually fills that final third
<ogra> another prob (with udev i guess)
<Keybuk> with udev?!
<tfheen> pitti: I'd prefer to have the file be resized in-place to not put random junk files in ~
<ogra> since i added DO_NOT_SWITCH_VT i get a long delay for usb devices
<Keybuk> what the frak has udev got to do with anything?
<Keybuk> *blink*
<Keybuk> show me a bootchart
<ogra> no keyboard or moouse input for quite some time (20-30secs)
<Keybuk> and /var/log/udev
<ogra> oh, there is an error on console ...
<funman> hi
<ogra> Keybuk, usb 4-1.2: device descriptor read/64, error -110
* Keybuk points at BenC
<Keybuk> iz kernel boog
<Keybuk> or probably dodgy usb cable or something
<ogra> hmm, the client still uses -9 ... i should probably update first :)
* pitti boggles
<pitti> tfheen: hm, weird - in my current edgy .x-e is cleaned already on login
<ogra> pitti, 
<ogra> ogra@edubuntu:~/devel/edgy-ltsp$ ls -lh /home/ogra/.xsession-errors 
<ogra> -rw------- 1 ogra ogra 652K 2006-10-05 12:49 /home/ogra/.xsession-errors
<ogra> i logged in a minute ago ...
<ogra> here its not cleaned
<pitti> hm, for a fresh user it is for me
<pitti> my own is 6.9KB and looks fresh, too
<ogra> what should clean it (note i'm not using gdm)
<tfheen> pitti: hmm, weird.  The code doesn't look like it cleans it.
<pitti> ogra: that's what I'm wondering, too; /etc/X11/Xsession appends only
<dholbach> heno: replaced gok with onboard
<pitti> maybe gdm cleans it, I'll look
<ogra> thats wrong then :)
<ogra> Xsession should clean it
<pitti> a grep -r xsession-errors in /etc/ revealed nothing else
<RicardoPerez> carlos: ping
<carlos> RicardoPerez: pong
<Keybuk> Kamion: do you have a moment to check over some code for me
<Kamion> Keybuk: sure
<pitti> I don't get it -- modifying /etc/X11/Xsession doesn't seem to have any effect 
<pitti> seb128: does gdm do some black magic which circumvents /etc/X11/Xsession?
<seb128> pitti: what do you mean?
<ogra> pitti, how about adding the cleanup code to /etc/X11/Xsession.d in a separate script ?
<Keybuk> kamion: http://people.ubuntu.com/~scott/migrate-inittab.pl.txt
<tucoz> Hi, i am trying to track down this bug: https://launchpad.net/distros/ubuntu/+source/xserver-xorg-video-ati/+bug/52695
<Ubugtu> Malone bug 52695 in xserver-xorg-video-ati "xorg-driver fglrx interferes with r300 dri" [Undecided,Unconfirmed]  
<seb128> pitti: do you pick the GNOME or the default system session from gdm?
<tucoz> I noticed that LIBGL_DRIVERS_PATH is set to the wrong path in my case. it is set to /usr/X11R6/lib/modules/dri/. do you know where to go from here, to see where that is exported?
<pitti> ogra, tfheen: so this seems to affect Kubuntu/Edubuntu only (the bug report is from a Kubuntu user, too)
<pitti> seb128: hm, whatever is the default for a fresh user
<ogra> pitti, i think Xsession.d is the right place ... probably one of the xorg_common scripts should do it
<pitti> ogra: I'm fine with changing the Xsession script, but I'd like to test it :)
<pitti> seb128: I mean that changing /etc/X11/Xsession does not have *any* effect; it seems to be ignored when logging into gdm
<ogra> right, if it breaks gdm that would indeed be wrong ...
<pitti> ogra: .d is too late
<Kamion> Keybuk: reading
<ogra> pitti, ok
<pitti> ogra: Xsession first creates/appends .xsession-errors and then executes .d
<Kamion> Keybuk: I'd use an arrayref for the elements of %gettys, rather than joining them with : and having to split them up again
<pitti> ogra: changing it won't break gdm, since gdm doesn't seem to use it in the first place :)
<Keybuk> Kamion: yeah, I couldn't remember how to do those ;)
<Keybuk> example?
<Kamion> Keybuk: $gettys{$1} = [$rlevel, $process] ;
<Keybuk> oh, [ ]  
<pitti> seb128: I suspect that it executes /etc/gdm/Xsession, but then I wonder who cleans up ~/.xsession-erros on login?
<Kamion> Keybuk: my ($rlevel, $process) = @$gettys{$_};
<Keybuk> how do get stuff back out?
* Keybuk was trying ( )
<tfheen> ajmitch: regarding the mono problem on the desktop cd, if f-spot is happy from a terminal, everything's fine, right?
<Keybuk> too much Python
<Kamion> Keybuk: or $gettys{$_}[0]  to access single elements
<Kamion> Keybuk: er, sorry, I think that should be @{$gettys{$_}}
<ogra> pitti, well, if gdm would choke because the files doesnt exists or something ... was my fear
<Keybuk> yup
<StevenK> Kamion: I think either work.
<Kamion> {} binds less tightly than sigils
<Keybuk> my brain rememberd it once you showed the example
<seb128> pitti: hum, not sure, I'm finishing lunch and I'll have a look
<tfheen> Kamion: or $gettys{$_}->[0] , iirc
<Kamion> tfheen: yes; $gettys{$_}[0]  is syntactic sugar for that
<funman> do you know if gcc SSP made some regressions ?
* tfheen has taken to preferring -> for dereferencing references in perl.
<funman> like packages working without the SSP, i.e. no segfaults , and triggering a stack smashing with SSP
<Kamion> StevenK: no, only @{...} works
<tfheen> funman: yes, sure.  emacs21, for instance.
<pitti> a-haa
<StevenK> Kamion: Yes, sorry, I just checked.
<torkel> pitti: iirc "Gnome" does not run /etc/X11/Xsession, but "Default System Session" does
<funman> tfheen: so what's wrong in that case, emacs or gcc ?
<pitti> ogra, seb128: gdm-2.16.1/./daemon/slave.c:wipe_xsession_errors (struct passwd *pwent,
<tfheen> funman: emacs.  One of the functions have a wrong parameter list.
<pitti> so, gdm has its own code to wipe
<Kamion> StevenK: otherwise it's "dereference $foo to get a list, then get the first element of that ... hold on, why does this expression start with a @?"
<tfheen> funman: I Just Haven't Found Time To Fix It Yet.
<ogra> pitti, ugh, even in .c
<StevenK> Kamion: *nod*
<funman> hmmm
<tfheen> funman: how so?
<funman> sorry ?
<tfheen> funman: any particular reason for you asking your question?
<funman> yes, problems with vlc
<tfheen> funman: I'm not aware of SSP breaking any correct C code, though, but I haven't investigated it closely; pitti might know better.
<funman> i couldn't reproduce on a system without SSP, and a backtrace of the stack smashing learned me nothing
<pitti> I don't ATM, sorry
<norber> hello, mi name is norber and i asked a question in a ubuntu-es and they don know. my english is very bad, sorry.  i have a laptop and i buy a card audio usb. I want listen a song (example dover) by the two cards audio. Is possible?
<funman> i have little debugging experience so i may not look correctly
<Kamion> Keybuk: ... need to get breakfast before reading the rest of this
<funman> i emailed crimsun about that, he's the vlc package maintainer
<Keybuk> Kamion: ok
<pitti> torkel: doesn't seem to work for me; 'default system session' also uses the gdm one
<Keybuk> I need to run to Tesco to get bagels, so we'll discuss it after lunch-time:)
* pitti installs kdm for testing this
<sivang> ah Tesco.. if only they had that cinemon malt loaf so I could take some with me back :)
<sivang> Keybuk: how are their bagles? the garlic bread rolls for heating up in the oven are quite nice
<pitti> seb128: ok, nevermind then; I use xdm for testing now, it works there
<ogra> pitti, wonderful :)
<ogra> next time use ldm :P
<doko_> smurf: ping
<seb128> pitti: is gdm doing something wrong? I've not really followed on the issue I was having lunch ;)
<ogra> seb128, its doing something on its own that should be done in Xsession
<pitti> tfheen: ok, I'll do the truncating then for {k,edu}buntu
<seb128> any reason why it should be done in Xsession?
<ogra> so it was broken for non gdm users
<tfheen> pitti: cheers.
<ogra> seb128, for (k,x,l)dm, yes
<pitti> seb128: well, not exactly wrong, but we cannot control the ~/.xsession-errors handling in /etc/X11/Xsession[.d]  scripts
<seb128> pitti: should I patch the gdm code out?
<StevenK> % head -n 1 debian/dbmail.init
<StevenK> #!/bin/sh --posix
<pitti> seb128: not for my sake, I don't mind deleting the previous session's .xsession-errors; tfheen might do, though
* StevenK reloads his shotgun.
<tfheen> pitti: it's not "OH MY GOD THE SKY IS FALLING"-bad, but I'd prefer if we didn't, yes.
<_ion> stevenk: Wow. :-)
<StevenK> seb128: Stupid question, if you have a second?
<pitti> tfheen: what do you think of that:
<pitti> # truncate ERRFILE if it is too big to avoid disk usage DoS
<pitti> if [ "`stat -c%s \"$ERRFILE\"`" -gt 500000 ] ; then
<pitti>   F=`tail -c 500000 "$ERRFILE"` && echo "$F" > "$ERRFILE"
<pitti> fi
<tfheen> pitti: I'd prefer if we saved the last N bytes.
<pitti> with N == ?
<pitti> I thought 0.5MB is more than enough
<seb128> StevenK: don't ask to ask just ask
<pepsiman> what would truncate it if I never log out?
<tfheen> oh, but your solution will truncate it to 0 bytes when it's bigger than 500k?
<tfheen> oh, sorry
<tfheen> mea culpa, I can't read.
<pitti> tfheen: no, it takes the last half MB
<StevenK> seb128: Are you aware of any issues of font colors in progress bars?
<pitti> I just need the F=`` echo F juggling to avoid a temporary file
<tfheen> pitti: then it's fine; I'm obviously blind. :-)
<tfheen> pitti: or you could just use sponge
<pitti> tfheen: ok, great; I tested it with xdm, works fine
<seb128> StevenK: there is a bug open on ubuntulooks about not enough contrast between text and font color
<pitti> tfheen: sponge is in universe
<tfheen> pitti: that's easily fixed, though.
<pitti> tfheen: and essentially it doesn't do much else than F=``; echo $F>, does it?
<pitti> but in general yes, sponge is useful
<StevenK> seb128: I'm seeing strangeness on my Edgy machine - the color under the "done" part of the progress bar is white and gray.
* pitti appends || true for robustness' sake
<tfheen> it doesn't do much else in this particular case, no.  Shells aren't too fond of null bytes and such, though
<pepsiman> seb128: in qemu I couldn't see the edgy progress bar move at all
<pitti> tfheen: true; well, I better use a temporary file then
<imbrandon> doko ping
<imbrandon> moins pitti and tfheen
<pitti> hi imbrandon 
<Seveas> mjg59, did you know usplash currently is rather broken? writing text and usplash_put_part generate weird-colored output
<pitti> Keybuk: can you please approve hal (bug 56484) and cupsys (bug 54277) uploads to dapper-proposed
<Ubugtu> Malone bug 56484 in hal "hal does not detect non-ATAPI CD-ROM drives" [Unknown,Confirmed]  http://launchpad.net/bugs/56484
<Ubugtu> Malone bug 54277 in cupsys "cupsd can't access /var/log/cups/error_log permission denied" [High,Fix released]  http://launchpad.net/bugs/54277
<tfheen> heno: what's happening with https://launchpad.net/distros/ubuntu/+source/casper/+bug/58836 ?  Is it still valid?
<Ubugtu> Malone bug 58836 in casper "F5 options need to be linked to the right casper options" [Undecided,Unconfirmed]  
<raphink> anyone has seen/worked on http://www.kde-apps.org/content/show.php?content=14779 ?
<pitti> Riddell: bug 58636, isn't that actually a langpack issue? or are kcmlocale.mo files not shipped in the langpacks for some reason?
<Ubugtu> Malone bug 58636 in language-pack-kde-ka "language-support-kde-ka - even then installed georgian users can't see georgian KDE UI." [Undecided,In progress]  http://launchpad.net/bugs/58636
<pitti> Riddell: i. e. that should fix itself with the next langpack update, right?
<Riddell> pitti: they havn't translated kcmlocale, or hadn't at the last langpack update
<pitti> Riddell: it seems to be translated in Rosetta
<Riddell> pitti: so it does, so yes it'll be fixed with the next langpack update
<pitti> but daily edgy langpacks do not have kcmlocale.po, hmm
<Riddell> pitti: for ka or all?  I'm sure I've seen it in other languages
<pitti> I looked in -ka-base
<pitti> Riddell: I cannot find such a file; maybe 'kcmlocale' is not the correct domain name
<pitti> oh, silly me, it's there for other languages
<Riddell> it was only translated for ka three days ago
<pitti> Riddell: ok, then Rosetta probably just lags behind a bit
<_ion> Is there a plan to move ntfs-3g to main?
<tfheen> Riddell: Have you tried to reproduce https://launchpad.net/distros/ubuntu/+source/casper/+bug/62693 with a current daily?  IIRC, it's fixed now.
<Ubugtu> Malone bug 62693 in casper "kubuntu accessibility features don't run" [Undecided,Unconfirmed]  
<Riddell> tfheen: no I havn't, I'll give it a shot when I find a minute
<tfheen> Riddell: cool, thanks.  I had a silly syntax error which probably broke it.
<tfheen> (which is now fixed)
<cuco> hi, i am building a package for ubuntu, which needs to create some mysql tables. on debian, i used the extra file: debian.cnf. this does not work on ubuntu. any ideas whay can i do...?
<cuco> the question is, how do i install sql tables from postinst scripts ...?
<tfheen> rodarvus: https://launchpad.net/distros/ubuntu/+source/casper/+bug/59618 ; should casper preseed xorg's config or should xorg look at /proc/cmdline?
<Ubugtu> Malone bug 59618 in casper ""Safe graphics mode" doesn't use VESA" [Undecided,Confirmed]  
<rodarvus> tfheen, I think preseeding xorg config would be a a more generic solution (as other options could be forced in the same way) - also making xorg look into /proc/cmdline would make us diverge from upstream (debian)
<tfheen> rodarvus: ok.  Do you remember offhand what I need to preseed it with?
<rodarvus> not from the top of my mind, I'm sorry :/
<tfheen> np, I'll poke it myself, then
<tfheen> hmm
<tfheen>       if [ -n "$XFORCEVESA" ]  || [ -n "$(grep xforcevesa /proc/cmdline)" ] ; then
<tfheen>         DEFAULT_DRIVER=vesa
<tfheen> is there already.
<tfheen>       fi
<rodarvus> heh
<jdong> aah! what on earth!
<jdong> since when did ich8 stop working?
<jdong> yikes... isn't kernel freeze today?
<tfheen> it is
<jdong> looks like bug 63516....
<Ubugtu> Malone bug 63516 in linux-source-2.6.17 "ICH8 doesn't work" [High,Confirmed]  http://launchpad.net/bugs/63516
<jdong> that's a pretty serious regression... will it get fixed after freeze?
<zul> afaik ben is working regressions
<StevenK> Phew, I have an ICH6
<StevenK> :-P
<zul> er...workin on regressions
<tfheen> jdong: it's targetted for 6.10
* jdong whacks StevenK with his ich8 :)
<Keybuk> pitti: they're on my list
<pitti> thanks
<tfheen> hmm, why is usplash dark blue on black?  It's not the most readable colour choice possible.
<Keybuk> black on black?
<tfheen> no, dark blue on black.
<tfheen> it's possible to read, but hard.
<dholbach> iwj: hello! can I tempt you to have a look at bug 63814? it's about a breakage of epiphany, which gives upstream a bit of pain (lots and lots of edgy users complain about crashes at bugs.gnome.org). I tried to apply the patch he was referring to, but didn't have much luck.
<Ubugtu> Malone bug 63814 in firefox "please include patch for a highly visible crash in epiphany" [Undecided,Confirmed]  http://launchpad.net/bugs/63814
<sivang> Keybuk: lol:
<sivang>  * Undo Sivang's evil, evil, evil patching of things in the debian
<sivang>     directory and just apply the patch, damnit!
* sivang is dumb to just now notice this
<Keybuk> Kamion: did you get a further look at my Perl?
<iwj> dholbach: Looking at it now.
<dholbach> iwj: Gracias.
<iwj> The patch looks reasonable to me.
<sivang> iwj: have you seen an issue in which everytime you run firefox it thinks the previous session was abruptly interruped and thus want sto "resotre session || ignore and start new||
<sivang> "
<iwj> Do you need this fixing urgently ?  If not I'll just assign myself the bug and apply the patch next time I'm fiddling with firefox.
<sivang> iwj: ?
<iwj> sivang: Yes, but only once when my whole system was completely hosed.
<sivang> iwj: also, bookmarks are for some reason not working on my firefox, that is I can click 'add' but nothing happens form the add bookmark dialog
<sivang> iwj: it's constantly reproduciable here
<iwj> Obviously there's something wrong with your profile.
<dholbach> iwj: the count of dups at http://bugzilla.gnome.org/show_bug.cgi?id=354790 is still bearable, I think
<Ubugtu> Gnome bug 354790 in Mozilla interaction "crash on plugin native window destruction [@gtk_widget_destroy - ~nsPluginNativeWindowGtk2] " [Critical,Resolved: notgnome]  
<sivang> iwj: any info I can provide to help fix the two issues?
<dholbach> iwj: I wanted to let you know, because my own attempts failed.
<iwj> sivang: TBH, given that I'm probably not going to have time to debug this, your best bet is to make a new profile and just copy the bookmarks across.  You could also try deleting stuff semirandomly from your profile directory.  (Take a copy of the bookmarks first.)
<iwj> dholbach: You tried to apply that patch and failed ?
<sivang> iwj: I already lost the bookmarks , so that's going to be easy ;-)
<dholbach> iwj: yeah, see my last comment on the bug
<sivang> iwj: (4-5 dist upgrades ago)
<dholbach> iwj: but it FTBFS at another place (so it seemed to me).
<iwj> dholbach: Oh, yes.
<iwj> dholbach: How odd.
<iwj> sivang: :-/
<dholbach> iwj: maybe chpe will know what to do about it
<smurf> doko_: pong
<iwj> dholbach: That doesn't seem related at all.
<dholbach> iwj: I built it in an up-to-date edgy amd64 pbuilder.
<iwj> dholbach: Are you able to build the unpatched source ?  (I wouldn't recommend messing with this without ccache and a huge buffer cache, though.)
<dholbach> i'll try - I'm doing bug triage in the meantime - so that's going to be fine ;-)
<iwj> dholbach: No, don't try.
<iwj> Let me do it.  I know all the tricks.
<dholbach> iwj: Thanks a lot - I knew you'd be way cleverer about it. ;-)
<iwj> I've just been through the pain and know how to avoid about half of it ...
* iwj reconfigures the bug.
<dholbach> Yooohoo. :-)
<iwj> Chase me if it gets too bad and I'll push it up my todo list.
* tfheen wants faster machines.
<Kamion> Keybuk: I'd use 'if ($idx < @job)' rather than 'if ($job[$idx] )'
<dholbach> iwj: chpe will be happy.
<Kamion> still looking over the rest of it
* iwj checks that 1ubuntu3 built on amd64.  Yes.  Hmm.
<Kamion> sivang: IIRC moving sessionstore.js aside fixed that for me
<Kamion> as far as I can tell firefox doesn't delete that file after restoring the session, so after one crash it bugs you about it evermore
<sivang> Kamion: did you experience lost bookmarks as well? 
<Kamion> sivang: n
<Kamion> no
<Kamion> this is for the bug where "restore session" appears all the time
<sivang> Kamion: k, thank you
<smurf> Would anybody like to figure out why the Live CD no longer works on an old iBook? :-/
<Kamion> Keybuk: what's the open/close pair at the end for? could do with a comment at least
<Keybuk> just to touch the file so upstart reloads it
<Kamion> Keybuk: if it's just to touch the file, 'my $time = time; utime $time, $time, "/etc/event.d/$_"' is more usual
<Keybuk> that won't cause an inotify CLOSE_WRITE event?
<Kamion> oh, silly inotify
<Kamion> Keybuk: do you plan to migrate stuff like sulogin, rcS, rc configuration?
<Keybuk> I really don't see how that's possible
<Keybuk> it would be too much of a headache to get right
<Kamion> Keybuk: also, %ids appears to be unused apart from checking for duplicates
<Kamion> fair enough
<sivang> Kamion: thanks, that worked.
* tfheen kicks gksu in ze nuts
<Kamion> Keybuk: otherwise, looks fine to me ...
<simira> tfheen: behave!
<sivang> nice, after removing the profile firefox tells me to restart ubuntu
<tfheen> simira: it started!
* sivang init's to 1 and back
<webben> I've noticed that gnome-orca is marked as "Low urgency" on Launchpad. Is there a mechanism for expressing a desire that a
<webben> it should be higher urgency?
<seb128> gnome-orca is a package?
<seb128> what does the urgency mean for the package? where do you read that?
<StevenK> seb128: It's probably the upload details
<webben> seb128, https://launchpad.net/distros/ubuntu/+source/gnome-orca
<webben> on the lefthand side under "Maintainer defaults"
<seb128> ah, that's the upload
<seb128> the urgency setting is of no use with launchpad
<webben> what does it mean then?
<seb128> it's useful for Debian to determinate of fast the package has to move to testing
<seb128> s/of/how
<webben> that isn't related to how important the package is?
<seb128> maybe launchpad should not display that info
<seb128> no
<seb128> packages have no "importance"
<seb128> they are to main or universe basically
<webben> then what does determine how fast a package moves to testing?
<seb128> there is no testing
<seb128> dapper is stable
<seb128> nothing migrate to stable
<seb128> and next one is edgy
<seb128> and we upload without delay to edgy
<webben> you mean this urgency stuff has no relevance to how ubuntu does things at all?
<seb128> correct
<webben> ah okay then :)
<seb128> it's used by Debian
<seb128> and we have no interest to change the format for Ubuntu
<seb128> so it's around, just not useful
* StevenK wonders if the publisher has crashed
<webben> i see
<seb128> have to run for half an hour, bbl
<webben> seb128, thanks for explaining that; bye for now :)
<seb128> np
<kristog> do you know if a people.ubuntu.org service is planned?
<ogra> Kamion, i pm'd you the logs from our conversation about the edubuntu name change ...
<ogra> i think you can revert it safely
<Fade> hrmn. known bug that python upgrade breaks in pycentral?
<Fade> http://pastebin.com/800753
<janimo> pitti: hi, can you review system-config-printer and python-cups in time for RC?
<pitti> janimo: erm, you do not seriously want that for edgy??
<janimo> pitti: of course I do. why?
<pitti> we are past UVF and FF and approaching RC freeze and such
<janimo> that was the whole point of it
<pitti> ugh
<janimo> well it's not an UVF as it sat in universe for a while
<pitti> that's indeed bold
<janimo> well since there;s no other printer add gui in xubuntu there;s not much to break :)
<pitti> janimo: I'd like to get mdz's blessing for turning our printer GUI upside down at that point
<janimo> and it's one of the most requested pieces
<janimo> pitti:  uhm, for xubuntu only
<tfheen> I thought pitti enabled the web interface now?
<pitti> tfheen: I did
<janimo> it is not for ubunt obviously
<pitti> janimo: hmm
<janimo> not edgy anyway
<janimo> pitti: did you think I want to replace gnome-cups-manager :) ?
<pitti> janimo: well, I didn't test it at all so far (I postponed that to feisty on my personal list)
<ogra> pitti, are we allowed to leak f-f already ? 
<janimo> pitti: ok, I did not ever think of having that in ubuntu edgy that;s for sure. We may have had some miscommunication
<tfheen> janimo: hard freeze is in seven days, jfyi.
<janimo> pitti: it;s strictly for xubuntu, as right now the only way to add aprinter is via the web ui
<janimo> tfheen: I know, but if this app is not there there's nothning in its place
<janimo> so the risk is low
<janimo> it is one of the most impiortant edgy xubuntu specs
<funman> crimsun: till not there?
<janimo> I specifically chose this route as opposed to patching gnome-cups0-manager to gtk onlyness, to avoid interfeering with ubuntu desktop
<pitti> janimo: the point is, if we put it in main now and it screws something up, we have to support it
* tfheen is leaning towards pitti's stance here -- we're _way_ past FF.
<janimo> pitti: AIUI, the xubuntu bits are not 'reaaly' supported even if in main
<janimo> there for easy CDing
<janimo> pitti: that tool is shipped by FC6 next week by the way
<pitti> janimo: how do you mean? we support all main things, and if there is a grave bug past release in the printer config app, we have to deal with it in -updates and such
<janimo> so it cannot be that bad, but admittedly it may expect something else in debian
<tfheen> that's a slippery slope once edubuntu starts to have a xubuntu ltsp modes as well, too.
<janimo> anyway myself gauvain and others on xubuntu-devel tested it and it worked fine
<pitti> well, I do not have a good feeling about it TBH
<janimo> tfheen: I hope that for edgy+1 xubuntu and ubuntu printer tools will be the same
<pitti> I'm fine with taking a look at it, but I cannot judge the releasability quality and compatibility with printer models and access modes in a short time
<janimo> but I would not like to go another cycle without graphical 'add new printer'
<pitti> janimo: I hope that, too
<pitti> I so much want to get rid of g-c-m
<pitti> that's why I really appreciated geting printer-config
<pitti> but I never imagined it for edgy
<janimo> pitti: so either this fedora tool or till's drake can take over in edgy +1
<pitti> right
<pitti> janimo: ok, as I said, I'll review it, but promotion should get past mdz
<janimo> pitti: I thought it was clear from the start that I uploaded for wide testing for ubuntu edgy+1 but also for xubuntu edgy
<janimo> after all it was speccied in paris :)
<janimo> pitti: as for supported, jbailey said they are not staffed for xubuntu support
<janimo> so it is in main but not supported for customers
<janimo> the annuncements also specify community supported
<pitti> oh, I wasn't aware that we make that kind of distinction
<janimo> pitti: well, not written anywhere as far as I can tell, it's just the way it is AIUI
<ogra> tfheen, thats still at least one release away ...
<janimo> I do not mind as long as CDs can be rolled
<tfheen> janimo: which spec would that be?  I can't see any edgy-targeted specs which are relevant?
<tfheen> ogra: hence "slippery slope"
<pitti> seb128: I'd appreciate your comment on u-devel wrt. 'Edgy "Crash Reports"'
<ogra> pitti, just point at edubuntu, "they're rewriting kdeedu so why should we support non gnome apps" :P
<seb128> pitti: I was going to reply
<janimo> tfheen: https://features.launchpad.net/distros/ubuntu/+spec/xubuntu-printer-config
<pitti> seb128: ah, thank you
<seb128> np
<seb128> pitti: does apport still limit the dump to 100M?
<pitti> seb128: I'm not sure at that point what to do TBH
<pitti> seb128: no, the default is 200 MB now
<tfheen> janimo: it's not targeted for any release, though
<seb128> pitti: my main issue with apport is that bugzilla get over 500 ubuntu bugs a week atm and we are already cracking under bug flood without those
<pitti> seb128: right
<seb128> pitti: there is no way we would cope with that amount of bug
<pitti> seb128: if gnome is happy with getting b-b reports, can cope with it, and the workflow works fine, there's little reason to change it at that point
<tfheen> janimo: in the future, _please_ make sure that anything you want in is actually targetted.  Stuff which isn't targetted (be it bugs, features, whatever) fall off our radar and we end up using lots of time rescuing it.
<tfheen> janimo: also, implementation status "unknown" at this point is, well, not useful.
<janimo> tfheen: ok, I somehow thought in parsi that accepted means targeted at edgy
<janimo> and then forgot about the  issue
<janimo> sorry
<tfheen> janimo: and it's not approved either?
<pitti> seb128: I guess we need an one-click gnome upstream bug reporting and automatic symbolic stack traces before we switch that?
<pitti> ok, I'm off for a bit
<janimo> tfheen: I guess I should have kept track of the specs closer
<tfheen> janimo: I'm not trying to pick on you; it's just that those seemingly-minor things end up causing us lots of grief.
<janimo> for this specific one imlementation meant, package fedora tool and m,assage ot work without some deps, and wait to get on the CD
<seb128> pitti: right
<ogra> tfheen, and that specs needed to be implemented before FF
<tfheen> janimo: wouldn't the web UI be acceptable for edgy and we can get this into edgy+1?
<janimo> tfheen: I know you are not. nevertheless I am sorry for not being more disciplined about it :)
<ogra> but as long as its xubuntu only i dont mind ...
<janimo> tfheen: the web interface scred people in dapper
<tfheen> janimo: also, you not being an employee means I can't shout that loudly at you for not following procedures. :-P
<sivang> hehe
<tfheen> janimo: ok, so you have something you're _confident_ that works which is just now working except for it being in universe, is that the situation?
<janimo> tfheen: right
<tfheen> janimo: ok, let's hear what pitti says when he's back, then.
<tfheen> pitti: ^^
<janimo> he said he'll wait on matt's approval IIRC
<janimo> Gloubiboulga: ping
<Keybuk> OH, WOW
<Keybuk> I HAVE A GEM OF A BUG
<Keybuk> tfheen: are you listening? :)
<tfheen> Keybuk: loud and clear.
<Keybuk> you use the usplash TEXT_URGENT thing on the Live CD so that when it shuts down/restarts, it says "Press ENTER" ?
<tfheen> yes
<Keybuk> well, imagine for a moment that the user is a bit lazy
<Keybuk> and left the install sitting there for, oh, a few minutes
<Keybuk> what do you think happens? :)
<tfheen> Keybuk: I change the timeout to a day, iirc.
<Keybuk> usplash definitely timed out
<Keybuk> and I was sitting at a little _ cursor
<tfheen> let me see
<heno> I've seen that too
<tfheen> heno: did you see me asking you about accessibility status?  If you could look at the casper bug about it, that'd be good
<heno> tfheen: I'll look
<tfheen>     /sbin/usplash_write "TIMEOUT 86400"
<tfheen>     /sbin/usplash_write "TEXT-URGENT Please remove the disc, close the tray (if any)"
<tfheen>     /sbin/usplash_write "TEXT-URGENT and press ENTER to continue"
<Keybuk> could the console blanker kill usplash?
<tfheen> hmm, maybe.
<Keybuk> uh
<Keybuk> dude
<Ng> I have  abug I need to report that we've noticed on pretyt much all of our server tests of the live CD where rebooting just leaves us at a blinking _
<Keybuk> no, I see what happened
<Keybuk> you rolled a 32-bit int :)
<Ng> is that likely to be the same thing?
<tfheen> Keybuk: 86400 should fit comfortably into a 32 bit int.
<Keybuk> 86,400,000,000 is rather bigger than INT_MAX
<Keybuk> timeout is stored internally in usex
<tfheen> GNR
<Keybuk> uh sec!
<tfheen> why?
<Keybuk> because it uses usleep() ?
<tfheen> and seriously, it needs a way to say "don't time out, ever"
<tfheen> timeout 0 used to do that
<Keybuk> yeah, timeout 0 did that, until Seveas broke it
<Kamion> usplash_down still sends TIMEOUT 0
<Seveas> ?
<Seveas> what did I break?
<Keybuk> Kamion: no it doesn't, I fixed that
<Kamion> ah, my checkout is out of date
<Kamion> Keybuk: "fixed"
<Kamion> surely usplash_down was correct and usplash was wrong :)
<Keybuk> seb128: GNOME Setting Daemon fuckage on fresh edgy install - known?
<Keybuk> Kamion: one was easier to fix ;P
<ogra> *g*
<seb128> Keybuk: depending
<Keybuk> seb128: on?
<ogra> religious usplash wars 
<Seveas> I'm more worried about color b0rkage in usplash since r82
<seb128> Keybuk: there is a bug happening one time every 40 boots
<Seveas> it breaks all themes 
<Keybuk> seb128: this was the second boot
<tfheen> Keybuk: we could just make it use a long and only lesser arches would have to care.  Or fix timeout 0
<Kamion> usplash is so much the village bike
<Kamion> or the core-dev bike
<seb128> Keybuk: mdz got it once on desktopCD boot and never since
<Keybuk> tfheen: <g> "lesser arches" being anything not amd64?
<tfheen> Kamion: we should build it a shed.
<Keybuk> seb128: I just got it on a vmware install
<tfheen> Keybuk: hey, ia64 will make do as well
<seb128> Keybuk: do you have anything useful to the logs? is it reproducible?
<Keybuk> seb128: which logs?
<seb128> Keybuk: ~/.xsession-errors
<ogra> .xsession-errors ?
<Keybuk> nothing in there
<Kamion> or make it a uint64_t; we have C99
<seb128> k
<Keybuk> well, just some C chatter
<Kamion> int64_t rather
<ogra> seb128, i've seen it too on ltsp ... 
<Keybuk> Kamion: not unless you compile -std=c99 ?
<Keybuk> or has that changed now
<seb128> Keybuk: we have one bug being that gst_init() seem to fail sometimes, I'm going to look at that one soon
<Kamion> and hope it doesn't overflow the long in struct timeval tv_sec
<tfheen> Kamion: sure, that's fine, but I'd actually rather just have us fix timeout 0 or timeout -1 to work.
<ogra> but only very rarely and not reproducable
<Kamion> tfheen: yeah
<Kamion> Keybuk: we could do that if necessary
<tfheen> (either's fine, but both blow up ATM, iirc)
<heno> tfheen: could you give me a bug # ? I can't see anything obvious
<Keybuk> Kamion: I agree with tollef here
<Kamion> yeah, so do I really
<Seveas> is there anyone besides mjg59 with an svgalib fetish around?
<Ng> Keybuk: tfheen: sorry, not intending to pester, but did you see what I said above? should I still file it?
<Keybuk> (though I never understood why that timeout 0 was in splash_down to start off with)
<giftnudel> tfheen: not -1, so that you can use unsigned numbers, you don't need negative timeouts
<tfheen> heno: https://launchpad.net/distros/ubuntu/+source/casper/+bug/58836
<Ubugtu> Malone bug 58836 in casper "F5 options need to be linked to the right casper options" [Undecided,Unconfirmed]  
<tfheen> giftnudel: seriously, we only care about timeouts which are in the range of "seconds" to "a couple of minutes" or "never".
<tfheen> it's not like we're strained for bits.
<tfheen> Ng: it's mostly fixed already, apart from usplash being silly.
<tfheen> Ng: it's actually the same bug we're talking about.
<Ng> tfheen: that's fine, thanks :)
<heno> tfheen: there are no recent updates on that bug. I need more context. I was off IRC for a bit, testing, rebooting, etc.
<Keybuk> seb128: seems to be intermittent, yes
<giftnudel> seb128: gnome-settings-daemon doesn't start after logout, is that known?
<seb128> giftnudel: yeah, nothing is supposed to start after logout
<seb128> things are supposed to stop on logout
<giftnudel> seb128: ;) , I mean on second logon
<seb128> I have the issue sometimes, not every time though
<giftnudel> hmm, I have it everytime ...
<funman> are there any deadline for update packages of universe ?
<seb128> Keybuk, giftnudel: I'll patch gnome-settings-daemon to have some verbose log and will ping you back then to get a log about the issue
<funman> i just fixed a serious bug in vlc
<seb128> funman: one week ago
<seb128> funman: ah? bug fixing, still plenty of time
<funman> nice :)
<giftnudel> seb128: ok, I have time ...
<elmo> seb128: do you know offhand what package the network properties dialog comes from?
<seb128> giftnudel: have time for?
<funman> i'm waiting for crimsun to come back and i'll inform him
<giftnudel> seb128: for testing
<seb128> elmo: gnome-system-tools
<elmo> seb128: danke schoen
<seb128> de rien ;)
<giftnudel> seb128: (the next few days)
<seb128> giftnudel: a few min, I finish that reply on ubuntu-devel about GNOME bugs
<seb128> k, cool, thank you
<giftnudel> I have that too
<eracc> Hi folks. I asked this in #ubuntu but never saw an answer so decided I'd ask people more likely to know. Why are there no webmin packages in Dapper nor in Edgy?
<tfheen> heno: is it still valid?  If so, what needs to be fixed?
<Kamion> eracc: 'cos they were removed from Debian
<eracc> Ouch. I'm looking to switch our servers to ubuntu server but I rely on webmin a lot. :-(
<Kamion> eracc: see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=343897
<Ubugtu> Debian bug 343897 in ftp.debian.org "ftp.debian.org: Please remove all webmin related packages" [Wishlist,Closed]  
<heno> tfheen: I haven't tested a CD since you fixed that syntax bug a few days ago. I saw it in the changelog now though so I'll DL and test
<tfheen> heno: thanks.
<eracc> I guess I can get the package from webmin.com then. Thanks, Kamion.
<tfheen> heno: RC freeze is in a week and I would hate us to not have good accessibility because of some stupid bug somewhere, hence me pestering you now rather than in a week. :-)
<heno> tfheen: yes, please pester about this stuff!
<heno> It sort of balances out my pestering :)
<tfheen> heno: if you could get kubuntu accessibility tested too, that'd be excellent.
<heno> yep, will do
<tfheen> heno: it's also so I don't become a blocking point -- I'm starting to do full-time RM work on monday or so, and won't have time to hack casper then
<heno> right
<Gloubiboulga> janimo, quick pong
<Kamion> eracc: I believe that's the best and recommended approach at the moment, yes
<tfheen> seb128: http://librarian.launchpad.net/2924235/casper-1.56-no-eject-hotkey.patch should work for disabling the "eject" hotkey, right?
<janimo> Gloubiboulga: sent you a mail 
<seb128> tfheen: I think so
<janimo> Gloubiboulga: the idea is to get multibuild.mk in as it is, and polish afterwards
<seb128> tfheen: keyboard key you mean, right?
<tfheen> seb128: yes.
<janimo> Gloubiboulga: or we can miss RC
<tfheen> seb128: https://launchpad.net/distros/ubuntu/+source/casper/+bug/34643 is the bug
<Ubugtu> Malone bug 34643 in Baltix "Live CD can be inadvertently ejected via hotkey" [Undecided,Unconfirmed]  
<seb128> tfheen: because if you press on the drive button it's going directly to g-v-m
<Gloubiboulga> janimo, ok
<tfheen> seb128: can we turn that off?  Having people eject the live cd while it's running is.. bad.
<funman> crimsun: i hope you'll be happy to know that the vlc bug is know fixed in svn repository
<Gloubiboulga> janimo, I'm away for a moment, I'll ping Martin & Seb when I'll be back
<janimo> Gloubiboulga: it does not affect other packages and the ones that could use it wll have a few extra lines no?
<janimo> at least until a cleaner way is found
<Gloubiboulga> janimo, right
<seb128> tfheen: ask pitti about that one he probably knows better, it's hal,g-v-m magic
<tfheen> seb128: ok, thanks.
<seb128> np
<seb128> the patch you pointed should work fine for the keyboard multimedia key
<tfheen> yeah, understood.
<tfheen> pitti: how can I make pressing the hardware eject button not do anything?  Having people eject the live cd while it's running makes the world blow up.
<janimo> Gloubiboulga: sure, thanks
<tfheen> hmm, should we mail u-d-a about the string freeze?
<seb128> tfheen: should the drive be locked while something is using it?
<seb128> tfheen: I mean, eject usually doesn't work if you are using the CD
<tfheen> seb128: yes, it has lots of stuff mounted from it.
<tfheen> seb128: it's just for the desktop CD.
<ogra> tfheen, you can force lock it from casper 
<ogra> i can give you some python snippet
<tfheen> ogra: casper can't use python.
<tfheen> C or shell, please.
<tfheen> and it won't help if something unlocks it..
<ogra> hmm, no idea how that works in shell or C though 
<tfheen> what does the python code look like?
<ogra> we use it for the opposite in ltsp clients to force unlock it
<ogra> fcntl.ioctl(f, CDROM.CDROM_LOCKDOOR, 0)
<ogra> very simple 
<kristog> tfheen: do you have time for speak about bluetooth?
<ogra> its locked if you set it to 1
<funman> or cat /proc/sys/dev/cdrom/lock
<tfheen> kristog: I don't know much about bluetooth, but sure.
<tfheen> ogra: 'k, thanks.
<ogra> tfheen, it might be that pitti just sets the sysctl bit for it now
<pitti> tfheen: hm, funny; it took two releases to make the CD eject button work properly, and all sorts of people complain that it didn't :)
<tfheen> pitti: haha. :-)
<pitti> tfheen: in fact I find that quite useful - I often eject the CD and just reboot, instead of shutting down :)
<kristog> thom: ah sorry, i saw your name in the changelog of bluez-utils :(
<kristog> ops
<kristog> tfheen: ^
<tfheen> kristog: well, I uploaded it for something or another, I can't remember.  Anyway, what's your question?
<pitti> tfheen: well, if there's a good reason to disable the button, we can certainly hack a gconf key into g-v-m to inhibit ejection
<pitti> but frankly, it's a hardware button, why shouldn't it work?
<tfheen> pitti: https://launchpad.net/distros/ubuntu/+source/casper/+bug/34643 is the bug.
<Ubugtu> Malone bug 34643 in Baltix "Live CD can be inadvertently ejected via hotkey" [Undecided,Unconfirmed]  
<kristog> tfheen: ATM bt-suite in ubuntu edgy is useless, if you try to scan for devices nothing will discover
<kristog> tfheen: 59222, https://launchpad.net/bugs/56651
<Ubugtu> Malone bug 56651 in bluez-utils "Missing passkey-agent binary" [Undecided,Confirmed]  
<tfheen> kristog: oh, that.  I've been meaning to fix that, actually.
<bluefoxicy> http://bluefox.kicks-ass.org/stuff/bluefox/images/edgy-20061005-1.png
<kristog> tfheen: ah ok, so you are working on them :) cool
<tfheen> Seveas: Ubugtu is buggy.  When it gets URLs like the one above it shouldn't say "baltix", it should pick the ubuntu one.
<tfheen> kristog: so many bugs so much time.. That I am intending to fix it doesn't mean I'll get around to it
<ogra> tfheen, i asked for that ages ago ... Seveas just likes balitx :P
<_ion> Hmm, apport-retrace -d fails with KeyError. I'll check Malone a bit later.
<kristog> tfheen: uh :) ehhee :)
<pitti> _ion: I bet I know the reason
<pitti> _ion: and I also bet that you didn't yet upgrade to 0.26
<AstralJava> Sheesh, devs, I'm sorry to burst into this like I didn't know you're busy enough, but what have you done to Edgy?! It's insanely fast, and still manages to use less battery than Dapper did! Thank you for making protable computing so much more enjoyable! :)
<_ion>     needed_deps.add((pkg, dependency_versions[pkg] ))
<_ion> ii  apport         0.26           automatically generate crash reports for deb
<tfheen> kristog: send me a mail about it and I'll try to get it tomorrow?
<tfheen> kristog: tfheen@ubuntu.com
<pitti> _ion: you didn't click on 'report bug', but ignored the crash and then tried to apply apport-retrace to it, right?
<AstralJava> protable == portable
<kristog> tfheen: ok, thank you
<pitti> _ion: oh, ok, then I lost my bet, sorry :)
<_ion> pitti: I clicked report bug, and then ran apport-retrace -s -d /var/crash/_bin_sh.1005.crash
<pitti> AstralJava: oh, sorry, we'll get that fixed :-P
<pitti> _ion: yeah, there's probably a bug in that function which figures out the dependencies
<_ion> (I tested it with sh -c 'kill -SEGV $$', /bin/sh hasn't actually crashed. )
<kristog> tfheen: i will try to send you patches for them.
<pitti> _ion: ugh, I bet there's a realpath() missing somewher
<pitti> _ion: can you please file a bug? I cannot care for it right now
<_ion> pitti: Yes, as i said, will do it a bit later.
<AstralJava> pitti: Hands off!! :)
<Seveas> tfheen, launchpad changed again and I haven't yet modified the bots
<Seveas> launchpad devs should stop doing that
<ogra> Seveas, liar ... youre a secret balix dev ... admit !
<_ion> Do the bots screenscrape the launchpad website?
<Seveas> _ion, no
<Seveas> there is a nice rfc822 version of bug overviews
<Seveas> (after I repeatedly and loudly complained that screenscraping broke all the time)
<Seveas> but changing Unknown to Undecided confuses ubugtu
<mdz> pitti: printer stuff -> if it only affects Xubuntu, it's janimo's call
<pitti> mdz: ok, if we can have something potentially badly broken in main
<mdz> Burgwork,cbx33: cbx33 has a launchpad account but the name on it didn't match the name used in the changelog
<Burgwork> mdz, ah
<mdz> tfheen: I've been working around bug 62495 using advanced search, and now I don't even notice (just changed my bookmark)
<Ubugtu> Malone bug 62495 in malone "Milestone bug list doesn't sort properly" [Undecided,Confirmed]  http://launchpad.net/bugs/62495
<mdz> tfheen: this also has the advantage of not showing the spec noise
<bddebian> Heya folks
<ogra> Kamion, the fuzzy translation bug with server/console mode was gfxboot-theme ? 
<ogra> or was it d-i i should file against ?
<pitti> hmm, is the announcement of the new apport-retrace with super powers something appropriate for u-d-announce?
<Kamion> ogra: gfxboot-theme-ubuntu
<ogra> thanks
<Kamion> oh, dear lord, it's a hand-rolled po file parser, no wonder
<ogra> oh, youre already looking at it ?
<Kamion> yeah
<ogra> so should i not file the bug ?
<Kamion> ogra: nope, no need now, I've got it fixed
<Kamion> ogra: thanks for the reminder
<ogra> cool,. thanks 
<ogra> so i declare edubuntu free of known bugs !
<ogra> lets see about the unknown ones :P
<bddebian> heh
<sivang> janimo: it works like a charm
<janimo> sivang: nice, one less reason to use win
<sivang> janimo: indeed. However the bank site uses popups, and it won't work :-/
<Kamion> ok, first cut at the tasksel fixes for usplash complete
<Kamion> but I have to go out now before testing it; night all
<ogra> night Kamion and thanks for all the fixes today :)
<Ng> out of interest, when is the next dapper langpack release likely to be? I read something earlier about it being embargoes atm?
<pitti> Ng: I uploaded them to -proposed today, Keybuk or Kamion have to approve them
<Ng> ah cool
<pitti> Ng: after they do, they'll be uploaded to -updates 7 days after
<Ng> someone accosted me earlier about dd segfaulting and I was a bit confused until I tracked down the bugreport on a language pack
<Ng> thanks :)
<bSON> hi
<givr1> pitti: do you think that the David Zeuthen patch to support Fuse could meet edgy ? 
<bSON> is there any reason why https://wiki.ubuntu.com/AlwaysEnableUniverseMultiverse is in review so long?
<givr1> pitti: i could understand that it could be considerate as a feature, just wanting to know
<givr1> s/wanting/wanted
<JB[away] > moin
<dholbach> Treenaks: I made some changes to your bluetooth/todo suggestion
<Treenaks> dholbach: ok, great :)
<dholbach> Treenaks: I saw too many items like that on "TODO lists" already
<Treenaks> dholbach: Whatever it takes to get it done ;)
<Treenaks> dholbach: I want to browse in the train ;)
<Treenaks> s/browse/irc/ :P
<dholbach> I just meant to say "don't dump an item like that on a todo list, if you mean to get it done". :-)
<S0me1> hi everyone
<S0me1> how i can send an idea to ubuntu team?
<funman> just write it down
<S0me1> ok
<LaserJock> putting it on the wiki (wiki.ubuntu.com) is good
<S0me1> i see ok thanks 
<Treenaks> dholbach: oh, sorry then :)
<Kamion> funman: because obviously we read everything that is written everywhere? :-)
* Kamion uses his new-found omniscience to steal funman's bank details
<funman> at least you did
<desrt> Kamion; aren't you supposed to be sleeping?
<Kamion> desrt: at 8pm?
<funman> well nice Kamion, will you fill it ?
<desrt> Kamion; oh.  i see what happened.  nevermind :)
<desrt> Kamion; in that case, do you know why usplash flickers on shutdown?
<Kamion> desrt: nope, no idea I'm afraid
<desrt> shame.
<desrt> i wonder if init is whacking the process when it does the "sending SIGTERM/KILL to everyone"
<Kamion> my guess for somebody who would know would be Keybuk
<desrt> nod.  i've been meaning to ask him but he hasn't been around much
<desrt> then i saw you were talking about usplash last night so i thought you might know :)
<dholbach> iwj: you had any luck with the rebuilding of firefox on edgy amd64?
<tfheen> mdz: using an advanced search doesn't give me the option of reordering the columns though
<mdz> tfheen: you mean multicolumn sort?
<mdz> you can sort on one column using the drop-down
<tfheen> mdz: oh, true, that's so not-obvious that changing that and pressing "search" just changes the already-present search result.
<feAR`> hi
<feAR`> First of all, I am sorry for my English. 
<dholbach> Kamion, Keybuk: can you promote python-virtkey to main? it's a dependency of onboard (which is in main and seeded already).
<tfheen> it also doesn't display assignee, which is useful.
<feAR`> Am...Who is responsible for Ubuntu cd's autorun?
<feAR`> :)
<mdz> feAR`: mvo
<feAR`> where could I find him? :}
<Kamion> dholbach: done
<dholbach> Kamion: thanks!
<mdz> feAR`: what do you want to ask him?
<feAR`> mdz, we are creating free software cd (something like theopencd.org) but just for Lithuanians, and I am the project coordinator.
<feAR`> I would like to ask how to change the size of k-meleon window
<feAR`> I can't find where to set the window size..
<mdz> feAR`: oh, that's a completely different thing
<mdz> you're talking about the Windows autorun
<mdz> feAR`: that's heno
<mdz> feAR`: https://launchpad.net/people/henrik
<bluefoxicy> ...... my ~/.evolution/addressbook directory is 419 megs
<bluefoxicy> I never even used the addressbook.
<feAR`> gh, how to find him
<_ion> bluefoxicy: You know how Evolution's UI somewhat resembles Microsoft Outlook? Well, that's another feature they're imitating.
<bluefoxicy> _ion:  lol
<feAR`> ok
<wasabi_> Hmm. Some people need to make cups printing programs connect directly to remote printers, and store queues in ~/.printers.conf
<wasabi_> With the obvious entries for ipp://localhost/printer residing in there.
<wasabi_> So authentication to the printer happens appropiatly.
* wasabi_ adds that to a list of things to do that will never get done.
<ajmitch> wasabi_: good, someone else put in a request for libpam-krb5 updates :)
<wasabi_> Cool.
<wasabi_> What's changed anyways?
<ajmitch> bug 64189
<Ubugtu> Malone bug 64189 in libpam-krb5 "UVF: please sync from debian" [Medium,Needs info]  http://launchpad.net/bugs/64189
<wasabi_> I submitted a patch for that, almost a year ago, heh
<wasabi_> For something.
<wasabi_> Dunno if it ever made it in, since it seems to have no upstream.
<ajmitch> bug fixes, mainly
<ajmitch> apparantly there is an upstream still
<wasabi_> Yeah, 3 of em.
<wasabi_> Heh;.
<ajmitch> wonderful
<wasabi_> RedHat maintains their own fork.
<ajmitch> that's extra-special
<wasabi_> Wonder if anybody fixed the service_err result.
<wasabi_> So I can do service_err=1 auth_err=2
<wasabi_> Used to return auth_err when the KDC was unreachable.
<ajmitch> right, 2.x has plenty of changes for caching & realm-specific stuff
<wasabi_> Nice.
<wasabi_> I use pam_ccreds.
<ajmitch> so we can hopefully get this in
<wasabi_> It's nice to have processing jump to it when service_err is returned from krb5, and jump to invalidate the cache when it returns auth_err
<jdong|laptop> tseng: do you know where that dapper mono repository is?
<ajmitch> wasabi_: we can always try & get a patch into edgy
<wasabi_> I'll have to review the state it's in currently.
<wasabi_> I'll check it out when I get home.
<ajmitch> ok
<tfheen> iwj: what's happening with 57161?
<geser> does bug 52803 qualify to be fixed for edgy?
<Ubugtu> Malone bug 52803 in gsfonts-x11 "insufficient dependency on xfonts-utils" [High,Confirmed]  http://launchpad.net/bugs/52803
<tfheen> seb128: https://launchpad.net/distros/ubuntu/+source/control-center/+bug/22876 is targetted for 6.10, but you say "probably won't be fixed for edgy".  Which one is correct?
<Ubugtu> Malone bug 22876 in control-center "There is no way to control which sound device or mixer the keyboard shortcuts use" [Unknown,Confirmed]  
<seb128> tfheen: I didn't remember about the patch when I added the comment, I'll have a look at the patch for edgy
<tfheen> seb128: thanks.
<seb128> tfheen: no need to bother with the desktop them, there is about 10 of them and I've then in control ;)
<seb128> s/desktop them/desktop bugs
<Ng> hmm, does anyone happen to know how rhythmbox identifies usb devices as music players?
<tfheen> seb128: ok, thanks, I won't then. :-)
<tfheen> seb128: but I'll roar at you if they're not all gone in six days. :-P
<seb128> Ng: probably the hal informations about the device
<seb128> tfheen: fine with me ;)
<tfheen> seb128: thanks
<Ng> seb128: ok thanks, I'll poke around the device manager to see why my new mp3 player isn't showing up ;)
<Ng> aha, there's a portable_audio_player capability and category
<jdong|laptop> zul: with ubuntu's xen, can you change the distribution of RAM while the system/VM's are running?
<jdong|laptop> (smack me if I'm asking retarded questions  about Xen0
<zul> no i think you have to restart it but try it out
<jdong|laptop> so you have to specify how much RAM you give to dom0 ahead of time?
<jdong|laptop> the last time I used Xen I found that real irritating
<zul> yep
<jdong|laptop> mmkay, I'll set aside a test box
<jdong|laptop> can amd64 hosts run i386 guests?
<ajmitch> you can shrink dom0's ram usage
<LaserJock> hehe, that reminds me of a certain thread in -devel
<ajmitch> but you can't increase beyond what it was booted with
<jdong|laptop> ajmitch: ah, so I can boot dom0 to use all available RAM then shrink it as I need to boot children?
<ajmitch> yes
<ajmitch> it just happens
<funman> dom0 just can access all RAM anyway
<zul> right time to go home
<funman> and then you'll allocate some dom0's free RAM to domUs
<jdong|laptop> ah ok
<jdong|laptop> and are the wiki's documents on how to use Xen still valid for Dapper?
<funman> url?
<funman> i don't know if ubuntu changed xen tools
<ajmitch> probably similar enough
<jdong|laptop> https://wiki.ubuntu.com/XenOnEdgy?highlight=%28xen%29
* ajmitch goes off to upload new xen-3.0
<jdong|laptop> final question, will Xen process and close 120 outstanding backports requests for me while I take my nap? :D
<ajmitch> jdong|laptop: no
<jdong|laptop> lol
<jdong|laptop> have a nice day, everyone
* jdong|laptop off to play with xen
<AnAnt> I was just running apt-get dist-upgrade, and it told me that will install some indian & far eastern fonts, why is that ?
<AnAnt> what will a non asian do with all those fonts ?
<funman> watch, not read, asian texts
<AnAnt> funman: and ?
<funman> and nothing, that's all
<AnAnt> funman: 50 extra MB to watch asian text that I won't understand ?
<funman> exactly
<funman> can you see what will make these fonts install ?
<AnAnt> ubuntu-desktop I think
<AnAnt> because when I chose to do upgrade instead of dist-upgrade, it told me that it will hold ubuntu-desktop & ubuntu-minimal back
<sbalneav> If you're browsing the internet, and get directed to an Asian site, with asian characters, the proper thing to do would be to display the characters correctly, as opposed to a web page full of gibberish characters.  Therefore, to do the correct thing, you need the fonts.  This isn't really a development question though, is it?
<funman> AnAnt: i don't know if you already experienced
<funman> but it's very funny to let a friend use your computer, and make that he can use his native language
<AnAnt> k, I just found that it is less than 50 MB
<AnAnt> maybe even half that size
<geser> Kamion: do I still need an ACK from a MOTU for a sync request in universe when I already have a confirmed UVF exception?
#ubuntu-devel 2006-10-06
<crimsun> funman: excellent, thank you
<funman> :)
<funman> was the package updated already ?
<joejaxx> Kamion: are you around?
<crimsun> funman: not yet, I'm still at work and have not been able to wrest time for Ubuntu yet (but will within the next 4 hours). If Sam hasn't updated the vlc source package in Sid, I'll backport from svn directly.
<funman> ok
<jdong> what would trigger a xen0 "attempted to kill idle process" panic on boot?
<jdong> is that equivalent to not being able to mount root?
<funman> probably
<jdong> mmmkay
<jdong> my root is a bit out of the ordinary (on dm/LVM)
<funman> dm ?
<jdong> device mapper
<jdong>  /dev/mapper/main-root
<funman> look at the logs
<funman> xm log
<jdong> what logs?
<funman> xen logs
<funman> hum is it for domU or dom0 ?
<jdong> oh cool, xen can write to undetected filesystems?
* jdong ducks
<jdong> it's for dom0
<jdong> my hd is not touched at all before xen panics
<jdong> and then a few seconds later, it auto-reboots
<jdong> the backtrace wasn't scrollable
<jdong> barely readable for a few seconds
<funman> sorry
<funman> sorry xen write logs about domUs
<jdong> yeah, I can imagine it does
<funman> then maybe the kernel is fucked
<funman> what is it ?
<jdong> the xen kernel that edgy has
<jdong> it's on amd64
<funman> :/
<funman> sorry i don't run ubuntu
<funman> nor i own a 64bits pc
<jdong> k, I'll play with it some more
<funman> try to recompile a kernel
<jdong> not in the mood for that....
<funman> https://alioth.debian.org/download.php/1561/linux-2.6.16-xen3.0.2-hg9629.patch.gz
<jdong> I don't want to see if xen works that badly
<jdong> I just wanted to see if edgy's xen would work out of the box
<funman> :p
<funman> hmm
<jdong> I actually don't have much of a reason for running xen, except for fun
<funman> i had issues about initrd
<jdong> I am suspecting the initrd doesn't start LVM/device-mapper properly
<jdong> I'll ask mr. xen tomorrow
<gnomefreak> i thought i remember someone saying pyton-gtk-1.2 was fixed?
<gnomefreak> python-gtk-1.2 even
<_ion> Wow, avahi-daemon is installed by default? That rules.
<Seveas> _ion, it was added to the seeds today
<_ion> Yeah, i just read the ubuntu-meta changelog.
<bddebian> Howdy
<grexk> hello everyone, is pam_ldap broken in edgy?
<LaserJock> grexk: Launchpad would be the place to look for that info
<grexk> http://pastebin.ca/192561 I have this configuration, when I reboot it stuck before mounting local filesystem
<grexk> but when I remove ldap from /etc/nsswitch.conf, I can boot without problems.
<grexk> brb
<BenC> anyone here have ich8 chipset machine that uses the achi driver?
<thejoe> I'm trying to install Ubuntu 6.06LTS.  I already have partitions set. I manually edit the partitions during the installation to set up swap and root partitions.  I set up the swap partition, but when I click next the size displays 0kb and I'm unable to install.
<minghua> thejoe: please ask support questions on #ubuntu, thanks
<thejoe> Ok
<tfheen> ajmitch: why do you put the xen udev rules in /etc/udev rather than in /etc/udev/rules.d?
<ajmitch> tfheen: probably something I missed when checking it
<desrt> dir.d is weird... not made any better by some particularly high profile misusers
* ajmitch sees that earlier versions of the package didn't use rules.d either
<tfheen> ajmitch: that's wrong.  In ubuntu, the rules should go into the rules.d, none of the symlinking stuff which is in Debian.
<ajmitch> looks like there's a few packages thet get it wrong. I'll fix up xen
<tfheen> thanks.
<tfheen> make sure to get the "move the conffile" bits correct too
<esac> hi, how does one go about getting a new version of a program included in the apt repositories for dapper ?
<tfheen> esac: you don't.  Dapper's released.
<esac> but what about upgrades ?
<tfheen> what do you mean?
<esac> in dapper if i do apt-get install rdesktop, i get 1.4.1 .. 1.5.0 has since been released
<tfheen> yes, and?  We don't update a released distro with new versions.
<esac> seriously ? :) ok i was under the mistaken impression that when i did an apt-get upgrade, that it picked up new versions of packages
<tfheen> esac: I have no idea where you got that impression from, since we've never done things that way.
* jdong has found culprit patch of bug 57872
<Ubugtu> Malone bug 57872 in gnome-power "regression: pressing power button no longer brings up logout dialog" [Unknown,Unconfirmed]  http://launchpad.net/bugs/57872
<pitti> Good morning
<tfheen> morning, pitti
<janimo> hi pitti
<pitti> hi janimo, hey tfheen 
<desrt> 
<desrt> erp
<dholbach> good morning
<janimo> dholbach: morning
<dholbach> hey janimo
<sivang> morning
<janimo> hi sivang
<sivang> hi janimo , what's up?
<Chipzz> esac: you do get new versions, just not new *upstream* versions. you get bugfixes
<janimo> seb128: hi, python-gnome2 FTBFS, should I work aorund that ar are you going to?
<seb128> give me a break
<janimo> seb128: a proper fix needs to be found, but until then make check should be disabled
<seb128> you already commented on the wrong bug about it
<janimo> seb128: why wrong? It was that change that causes it no?
<seb128> any reason it should not be fixed properly now?
<seb128> right
<seb128> the bug was about the split
<seb128> and you commented saying the new version ftbfs
<janimo> seb128: well if you got a ifx at hand sure. If it takes a few days it may be good to fix the FTBFS first
<seb128> which is a totally different issue
<janimo> to let the new binarties in the archive
<seb128> I'll fix it, we don't let thing not building, don't worry
<seb128> no need to ping me every day about it
<tfheen> mvo: you seem to have a lot of 6.10-targetted bugs; are you in control of them?  There are also some bugs which aren't assigned to you, but where you're probably the guy who knows most about them.
<janimo> seb128: that was not the wrong bug btw, and it was not about the split AFAICT
<janimo> seb128: bug 28279
<Ubugtu> Malone bug 28279 in kdetoys "kdetoys: new changes from Debian require merging" [Medium,Rejected]  http://launchpad.net/bugs/28279
<seb128> janimo: it was the wrong bug, it was a fixed bug
<mvo> tfheen: I used the milestone quite liberally, I will go over them now to see wich are really critical. A lot of those should already be closed
<janimo> typo
<seb128> janimo: no point to argue, there is a build issue you open a bug about it, you don't comment on a fixed bug
<tfheen> mvo: ok, thanks.
<tfheen> mvo: please do target stuff, it gives me a feel for what needs to be fixed. :-)
<janimo> seb128: you should use pbuilder before uploading
<seb128> janimo: give me a break
<mvo> tfheen: sure :) I used it for stuff like "nice-to-have" as a reminder for myself a lot as well as for really critical stuff
<seb128> janimo: bothering people is anti-productive, you know that?
<janimo> seb128: stop being arrogant!
<fabbione> janimo, seb128: please guys.. take it easy eh?
<seb128> janimo: you just make me waste 5 min to reply to your stupid arguments for I bug I know about and will fix
<fabbione> it's not even 11am and i am hacking on glibc
<seb128> I could have fixed the bug during that time
<janimo> you made an upload which FTBFS I ask if I can fix it or you get around it yourself and you start with your BS again
<seb128> hey fabbione ;)
<fabbione> hey seb128 
<fabbione> janimo: calm down please
<fabbione> both of you
<fabbione> no point in arguing
<seb128> janimo: you already bug commented on launchpad yesterday, I don't need to be pinged several time about the same issue, that's just annoying
<seb128> pressure don't make things go faster
<seb128> I've lot to do, let me a day to fix it
<janimo> seb128: I pinged because I could upload the fix myself to let you work on other things
<janimo> seb128: but ok go ahead youself
<fabbione> STOP
<seb128> you don't have a fix, you just want to revert the change
* fabbione points his fingers around and wants an handshake
<fabbione> all friends like before
* seb128 hugs fabbione
<seb128> :)
<fabbione> :D
<fabbione> janimo: btw.. i did install xubuntu on one of my toys...
<fabbione> not too bad..
<fabbione> i expected worst to be hounest :)
<tfheen> seb128: I promised I wouldn't nag you about stuff assigned to desktop bugs for 6.10, but bug 36251 is 6.10-targetted and not assigned to ubuntu-desktop.  Are you handling those or do you want me to reassign or ... ?
<Ubugtu> Malone bug 36251 in edgy-gdm-themes "Unreadable Font Size for GDM Login/Password" [Medium,Confirmed]  http://launchpad.net/bugs/36251
<seb128> tfheen: iz artwork bug
<janimo> fabbione: anything you find lacking in xubuntu?
<tfheen> seb128: ok, so fschoep then?
<fabbione> janimo: not really.. no.. it's enough for what i usually do.. that means opening a few xterms and ssh to servers :)
<seb128> tfheen: I'll speak with dholbach to know what is the way to get an artwork fix properly, I don't know if they use some bzr or something
<tfheen> seb128: thanks.
<seb128> np
<dholbach> seb128, tfheen: fschoep works on that, afaik
<janimo> fabbione: even twm is enough for that ;)
<fabbione> janimo: yeah i know :)
<fabbione> oh
<fabbione> there was something
<fabbione> xterm in xubuntu doesn't set PATH properly
<fabbione> ~/bin specifically
<tfheen> fabbione: xterm doesn't set PATH. :-P
<fabbione> tfheen: tsk.. it does in ubuntu...
<tfheen> fabbione: no, bash or zsh or whatever does
<janimo> fabbione: I just ran an xterm and it sourced .bashrc fine, I have ~/bin set
<fabbione> janimo: not here
<fabbione> tfheen: right.. bash.. well you got the point
<janimo> fabbione: did you run plain xterm? (say via alt-f2)
<fabbione> janimo: from the menu iirc
<fabbione> i can check later tho
<fabbione> right now the machine is doing a test install
<janimo> fabbione: and is it xterm or some other terminal like xfce4-terminal?
<fabbione> janimo: i will need to re-check.. i use that installation as external viewer for x-plane.. nothing too fancy :)
<janimo> ok
<fabbione> the only reason i noticed is because i need an LD_PRELOAD
<fabbione> and i use a script in ~/bon
<fabbione> yeah right.. bon(G)
<fabbione> bin
<fabbione> you get it
* tfheen injects coffee into fabbione's bloodstream
* fabbione sucks in
<xorl> how long does pbuilder take to check itself on initial
<Hobbsee> xorl: depends how fast your computer is
<Hobbsee> andhwat your download speed is
<xorl> 20down 2.2Ghz AMD64, pretty fast?
<Hobbsee> shouldnt take that long then
<Hobbsee> hey Keybuk 
<Keybuk> *yawns*
* Hobbsee drops icecubes down Keybuk's back
<Hobbsee> that'll wake you up
<Keybuk> heh
<Keybuk> that's just the kind of thing David would do
<lifeless> morning Keybuk 
<xorl> how long does it usually take? like 20-30 min or less, never used it before.
<lifeless> congrats on upstart, it is looking sweet
<Hobbsee> Keybuk: david?
<Hobbsee> xorl: probably.  just wait
<xorl> making base.tgz already
<xorl> ll
<xorl> lol so i can safely assume it's damn near done.
<Hobbsee> yeah
<Keybuk> Hobbsee: my partner
<Keybuk> lifeless: thanks
<Hobbsee> Keybuk: ahh..
<sivang> sladen: would it be possible to install bzr on muse?
<sivang> hi Hobbsee , what are you up to today?
<Hobbsee> sivang: heya.  not sure yet.  might go visit a friend o fmine
<sivang> Hobbsee: I mean in packaging, kubuntuing etc :-)
<Keybuk> pitti: so the ddebs contain the full binaries?
<Hobbsee> sivang: well, if i'm there, i wont be doing any packaging
<tfheen> morning, Hobbsee 
<Seveas> tsss, the almighty Hobbsee can't even split herself? ;)
<sivang> hey Seveas 
<Seveas> hi
<Hobbsee> Seveas: not when there's only dialup internet there :P
<Hobbsee> hey tfheen!
<ajmitch> Hobbsee: how unfortunate
<ajmitch> Hobbsee: you need to pick better friends ;)
<Hobbsee> ajmitch: indeed
<Hobbsee> hah
<pitti> Keybuk: no, just the detached debug symbols
<seb128> pitti: any plan to make them ship the source code too btw? I think the debug rpm do that
<pitti> seb128: ugh, that would make them even bigger
<pepsiman> pitti: how do you detach debug symbols?  objcopy?
<Keybuk> pitti: aren't the things in /usr/lib/debug/sbin etc. supposed to be full binaries?
<pitti> pepsiman: yes
<sladen> sivang: hmm, bzr isn't in sarge
<Keybuk> quest dbg% file usr/lib/debug/sbin/init
<Keybuk> usr/lib/debug/sbin/init: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), not stripped
<ogra> pitti, oooh, i guess you forgot about the gstreamer autosink stuff as well, right ? i just remembered we have soemthing left to look into ...
<Keybuk> pitti: clearly I'm missing something ... ?
<pitti> Keybuk: not to my knowledge; /usr/lib/debug is the standard path for detached debug symbols (where gdb looks for them by default)
<pitti> Keybuk: and the original dh_strip also only puts the debug symbols there, not the full binaries
<pitti> Keybuk: well, they are ELF files, but there's no code :)
* Hobbsee attacks Seveas with a big pointy Ubugtu with of doom!
<Keybuk> pitti: aahhh
<pitti> $ /usr/lib/debug/usr/bin/gedit 
<pitti> bash: /usr/lib/debug/usr/bin/gedit: cannot execute binary file
<Keybuk> so if I install that, gdb will automatically locate the debug symbols for it?
<seb128> correct
<pitti> Keybuk: yes
<sladen> sivang: build/point me to the debs.  OTOH muse only appears to have 38MB of disk free
<Keybuk> why -dbgsym, not -dbg?
<pitti> seb128: the symbolic stack trace has file names and line numbers; that should be sufficient IMHO and avoids doubling the package sizes again
<pitti> Keybuk: to not conflict with existing -dbg packages
<Keybuk> how do you generate them?
<pitti> Keybuk: apt-cache show pkg-create-dbgsym
<sivang> sladen: ah, then nevermind, I don't want to consume more disk space there then.
<sladen> Keybuk: and AFAIK they only have symbols, split out afterwards
<seb128> pitti: right
<sivang> sladen: I should probably use supermirror to store my branches instead :-)
* seb128 thinks Keybuk should read the spec
<Keybuk> pitti: heh
<Keybuk> cute
<pitti> Keybuk: FYI, https://wiki.ubuntu.com/AptElfDebugSymbols
<sladen> sivang: you don't actually need bzr to store a copy of your branches
<pitti> Keybuk: yeah, another debhelper Hack of Death :)
<Keybuk> pitti: btw, on apport, last time I had a crash, it didn't actually do anything to file the bug for me
<Keybuk> it just gave me a window with the crash filename
<sladen> Keybuk: it's the type of daft crack you'd come up with, only pitti got there first
<Keybuk> is that all it's supposed to do?
<pitti> Keybuk: it's supposed to open the packages' bug page in the browser
<Keybuk> sladen: I'd just change debhelper directly and mail pictures to joeyh
<Keybuk> pitti: I was expecting it to actually file the bug, and automatically detect duplicates
<Keybuk> I guess that's the "next version"?
<Keybuk> (I'd heard you talking about that at some point)
<pitti> Keybuk: yeah, that's 'bug reporting tool'
<pitti> Keybuk: apart from that, I do not think that we should file actual bugs for automatic crash detections
<pitti> we'll get flooded
<pitti> we need a separate db for that IMHO
<Keybuk> yeah, those need to be support requests or something
<Keybuk> or have a Malone "crash reports" section
<pitti> the latter rather
<Keybuk> view all crash reports -> link crash report to bug -> etc.
<pitti> exactly
<pitti> and an automatic dup finder
* Keybuk wonders what apport does when init segfaults
<pitti> Keybuk: it should actually work since it's spawned from the kernel
<pitti> but right, would be interesting
<Keybuk> init does install its own segv handler
<sivang> pitti: a dup filter running agains the same speperate db yes?
<pitti> Keybuk: ah, then it won't be called
<sivang> *against
<Keybuk> actually, it probably would
<pitti> Keybuk: but it might not install a handler for SIGFPE or SIGBUS
<pitti> apport triggers on those, too
<Keybuk> the segv handler forks, and in the child sets the segv signal back to default, then raises SIGSEGV
<Keybuk> and in the parent, just waits for the child to finish, before carrying on and pretending nothing happened
<pitti> heh, clever
<pitti> bbiab
* Keybuk couldn't think of anything better
<Keybuk> we stared at the kernel code hard enough to decide that there was no major consequences of ignoring a SEGV
<xorl> man for one file (qingy) the deps on that thing are nuts with pbuilder
<xorl> lol
<Hobbsee> hey sfllaw 
<jernst> hi, is there any official ubuntu kernel with soft RAID built-in (RAID0) ?
<sivang> morning sfllaw 
<fabbione> jernst: all of them..
<ogra> http://pastebin.ca/192862 ouch
<ogra> thats from a chroot upgrade dapper->edgy 
<ogra> is our linux-image package missing a dependency ?
<jernst> fabbione: it seems that raid comes in a module so that it's not possible to have a root filesystem on raid0
<fabbione> jernst: it's a module, but it is perfectly possible to have root on it. use initramfs
<ogra> s/dependency/versioned dependency/
<gnomefreak> ogra: i got that on an upgrade and rebooted into kernel and it would set up using dpkg --config -a
<ogra> gnomefreak, well, it should have the right version of mkinitramfs if it tries what it does imho
<gnomefreak> agree
<ogra> kernel team ?? ^^^^
<ogra> (fabbione, BenC ??)
<fabbione> ogra: what?
<ogra> see above
<ogra> http://pastebin.ca/192862 happens during an upgrade of a dapper chroot to edgy
<fabbione> and why on earth do you have a kernel installed in a chroot?
<ogra> fabbione, thin clients :)
<jernst> fabbione: thanks, I didn't know about it. Will do some research... Is there a Debian/Ubuntu way of doing it so that it is correctly build when the kernel is updated (sorry to ask questions here, but the user channel doesn't seem to know about such issues)
<fabbione> jernst: it's our default way of doing stuff.
<fabbione> jernst: man update-initramfs
<ogra> fabbione, looks to me like we should have a versioned dependency on the right initramfs-tools package 
<dholbach> hey heno
<fabbione> jernst: but please move this somewhere else.. it's really offtopic here
<heno> hey dholbach
<fabbione> ogra: i have never seen that error upgrading machines here
<ogra> well, gnomefreak said he saw it on a normal upgrade
<ogra> and solved it with dpkg --configure -a after reboot
<gnomefreak> fabbione: i saw it on 2 of my upgrades
<fabbione> gnomefreak: i did a dist upgrade 2 hours ago... and i didn't see it
<gnomefreak> it looks exactly like it from what i remember
<fabbione> ogra: how did you upgrade?
<ogra> dapper->edgy ?
<gnomefreak> fabbione: this was weeks ago
<gnomefreak> ogra: yeah ive been testing upgrades so i can keep help up to date
<fabbione> ogra: "how" not "what"? what tool did you use?
<ogra> http://pastebin.ca/192871
<ogra> essentially after that reciepe
<ogra> (i'm not the one upgrading, cbx33 is testing thin client upgrades for me)
<xorl> cant build a deb package out of this, nuts.
<iwj> tfheen: bug 57161> Nothing is happening with it; thanks for bringing it to my attention.  The right answer is to use libnspr-dev, not libnspr4-dev.
<Ubugtu> Malone bug 57161 in xulrunner "Impossible to install libsmjs-dev with firefox present" [Unknown,Confirmed]  http://launchpad.net/bugs/57161
<xorl> the configure script cant find directfb although it's part of the deps
<fabbione> ogra: well get the info, because even using apt-get dist-ugrade, initramfs-tools are updated before the kernel
<ogra> which info ?
<fabbione> ogra: on how he did test the upgrade?
<tfheen> iwj: there's that and an epiphany-breaking bug which are your bugs that are targetted for 6.10.  If you could look at them and fix them urgently-ish, that'd be good.
<ogra> fabbione, after the reciepe in http://pastebin.ca/192871
<ogra> a simple dist-upgrade
<iwj> I have just assigned #57161 to me; it wasn't, previously.
<xorl> with pbuilder why cant I see the config.log error?
<iwj> dholbach mentioned the epiphany bug and said it wasn't particularly urgent.  But fine, if it's urgent for you I'll get right on it.
<tfheen> iwj: it's targetted for 6.10, RC freeze is on Thursday.
<iwj> 6 days from today, yes.
<tfheen> yes, and with a weekend in between.
<iwj> Right.
<tfheen> that's urgently-ish
<tfheen> (in my vocabulary)
<iwj> I think it would be better to do the epiphany fix on Monday rather than today.  If it breaks something it will be easier to fix straight away.
<tfheen> iwj: fine with me
<iwj> Right.
<Keybuk> yeah, there's bad history with iwj touching mozilla-related packages on Friday ;)
<ogra> heh
<tfheen> just trying to make sure it gets fixed, I don't care that deeply about it happening today or monday, but I do want it before thursday.
<iwj> Right.
<heno> tfheen: I tested the (ubuntu) live CD yesterday with the F5 option but still no joy :(
<tfheen> heno: :-(
<tfheen> heno: did you manage to get it debugged?
<heno> tfheen: not sure where to poke. the at-spi stuff is not turned on; it doesn't seem to activate anything
<tfheen> heno: hmm, ok.  I'll poke it after finding some food, I think.
<heno> tfheen: thanks, I'll bring it up at the a11y meeting
<heno> Luke might poke around a bit as well
<heno> TheMuso: ^ we're talking about the casper settings on the live CDs
<xorl> when i run pbuilder when its done compiling and all that good shtuff it dpkg-deb gives an error tar: -: file name read contains nul character (this the dash after the ver  prog_ver-1_arch.deb?)
<iwj> mvo: Can you shed any light on bug 64012 ?  It seems that this person's /var/lib/dpkg/available contains `Status' fields.
<Ubugtu> Malone bug 64012 in dpkg "Bogus chars in "available" file after upgrade" [Medium,Needs info]  http://launchpad.net/bugs/64012
<mvo> iwj: no, I don't have more information than what is in the report. But as I wrote there I strongly suspect a HW problem. I just wanted to have a second pair off eyes looking at it
<jernst> fabbione: thanks for your help, everything works now
<TheMuso> tfheen: Any references to gnopernicus in scripts/30accessibility can be changed to orca.
<fabbione> jernst: no problem
<TheMuso> There are probably other necessary changes, but I need to look into those further.
<TheMuso> WIll get back to you.
<iwj> mvo: Fair enough.  It's definitely very strange.
<tfheen> TheMuso: just s/gnopernicus/orca/g in that file?  I'll do that.
<tfheen> TheMuso: if you can test the rest too, excellent
<TheMuso> Will do. I think some of the stuff related to magnification needs changing as well, but I will know more once I have tested it.
<dholbach> a11y team meeting about to start (for those of you, who're interested).
<xorl> what keyserver does the dpkg-buildpackage check?
<tfheen> your local keyring.
<tfheen> pitti: re 56755, was it you or mdz who made it 6.10?  With the obvious approach not working, I'm not sure it's doable for 6.10?
<pitti> tfheen: I added the milestone since it initially seemed easy to do
<pitti> tfheen: I'll remove it probably
<pitti> it's too intrusive to fix it now IMHO
* pitti is still waiting for is sudo upstream bugzilla password
<tfheen> pitti: yeah, agreed.  If it had been the easy fix it looked like it would have been fine, but when it's not -> defer.
<xorl> night guys
* Keybuk giggles
<Keybuk> there's still one guy utterly *convinced* that mount-by-UUID is all about tracking users
<ajmitch> canonical is out to control the world again?
<infinity> Keybuk: mount-by-UID could be interesting, I guess...
<Ng> haha
<Keybuk> of course, we could send a little packet every time a filesystem is mounted containing its UUIDs and where it was mounted
<Keybuk> and then Jane could track them, and gain a unique user count
<Keybuk> then we wouldn't need to do with with ntp <g>
<Keybuk> but I better not give silbs ideas
<infinity> I hear that users really like "product activation", we could just give that a try.
<ajmitch> Microsoft are doing some nice innovations with vista in that area
<Keybuk> heh
<Keybuk> I like the MS product activation stuff
<Keybuk> whenever it fails, just phone them
<infinity> A friendly dialog that says "Yes, the source is free, if you don't like activation, fork."
<Keybuk> they appear to assume nobody pirating their software would have the balls to call them and ask for a key
<pitti> Keybuk: wrt bug 63738, file-rc does not support the multiuser option, right? So I cannot just add an alternative dependency
<Ubugtu> Malone bug 63738 in cupsys "cupsys breaks systems with file-rc installed" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63738
<infinity> Keybuk: We could just do "phone-only activation", with no internet option, to give people in the office someone to talk to.
<Keybuk> pitti: *shrug* it's a bit irrelevant in edgy
<Keybuk> I sincerely doubt upstart can even run file-rc :p
<pitti> ok :)
<pitti> then I'll just reject the bug, I guess
<ogra> Keybuk, my usb problem on the thin client definately is triggered by DO_NOT_SWITCH_TV
<ogra> *VT
<Keybuk> certainly if you have file-rc installed, you can't have upstart-compat-sysv installed
<Keybuk> ogra: lies.
<Keybuk> you have a USB device that breaks if your machine does not call "chvt 1" at an appropriate place?
<ogra> if i drop the variable in front of the usplash start command it works... 
<ogra> as well as if i put a chvt -t 7 in front of it
<ogra> it only breaks with the variable set
<Keybuk> ogra: I look forward to reading your debugging analaysis
<ogra> so i suspect its a race with X or something
<ogra> the devices work if i replug them once i'm in X
<infinity> X and kernel in a bus-scanning race?
<ogra> well, i'll look into it, but currently the chvt -t 7 gives me exactly what i want on the thin client ...
<ogra> so i lean to just stay with it ... (we only have tty1 and 7 on thin clients anyway)
<Keybuk> ogra: I'd recommend finding out why it breaks first, before deploying random fixes
<ogra> as i said, i'll look into it ... but it works fine as is now ...
<Keybuk> ogra: what is the USB device?
<ogra> lsusb doesnt show me the mouse ...
<Keybuk> it's a mouse?
<ogra> the keyboard is 0430:0005
<Keybuk> you're using /dev/input/mice in xorg.conf, not /mouseN or /inputN ?
<Keybuk> oh, usb keyboard
<Keybuk> yeah, you're probably racing X
<Keybuk> "sleep 1" would solve it to, I suspect
<ogra> i use whatever the postinst creates in xorg.conf
<Keybuk> the lack of chvt just means you get to X slightly fasty
<Keybuk> uh, faster
<ogra> we're running dpkg-reconfigure during boot
<ogra> hmm, well ... the xorg.conf generation happens as pre-last servbice in rcS and X is started as the second service in rc"
<ogra> *rc2
<ogra> so its probably still generating the config ...
<ogra> no
<ogra> hmm
<ogra> X wouldnt start 
<Keybuk> Will remove the following packages from edgy:
<Keybuk>    file-rc |     0.8.10 | source, amd64, hppa, i386, ia64, powerpc, sparc
<Keybuk> oops
<Keybuk> :)
<infinity> Man, OpenOffice is really clunky...
<ogra> hmm, looking at usplash init i dont see why it should break ...
<zul> 'ksg ajmitch hi
<zul> doh
<ajmitch> heh
<smurf> usplash doesn't seem to like 800x640 screens very much -- either that, or something mis-guesses my iBook's resolution
<smurf> *grumble* worked in dapper. I hate regressions.
<Keybuk> mjg59: around?
* dholbach hugs infinity
* Keybuk decides to drive the UDS scheduler nuts
<mjg59> Keybuk: Hi
<Keybuk> mjg59: I've proposed a spec for edgy+1 ... get rid of the usplash timeout entirely
<Keybuk> are you going to be in attendance?
<mjg59> Keybuk: Nope
<infinity> Rationale being that "we don't display stuff on the console anymore anyway, so why bother timing out?"
<Keybuk> infinity: exactly
<mjg59> Keybuk: We still display kernel errors
<infinity> Not true if one drops "quiet" from their commandline, mind you.
<infinity> And yeah, we display errors.
<mjg59> And right now, have no way of getting those into usplash
<Keybuk> why can't we get those into usplash?
<mjg59> But if you can provide some mechanism to ensure that things like missing root filesystems or a kernel oops get reported to the user without them having to fiddle with configuration, that would be good
<infinity> I propose something called "bluesplash", which will blit OOPSes and PANICs to the framebuffer in a pleasant white-on-blue VGA font.
<infinity> It'll be revolutionary.
<Keybuk> infinity: brown!
<Keybuk> BROWN SCREEN OF DEATH!
<Keybuk> can you think of a more appropriate colour?
<Keybuk> we could nickname it the shit-screen
<infinity> "Ubuntu pooped!"
<imbrandon> lol
<infinity> Not quite as cool as a guru meditation, but I suppose it would do.
<Ng> nothing will ever beat a guru
<Keybuk> we could have a picture of a very angry elmo
<imbrandon> heh
<infinity> "Tickle this!"?
<Treenaks> Keybuk: http://www.netsplit.com/events/2005/ubuntu-down-under/ubuntu-down-under-027_screen.jpg ;)
<pitti> mjg59: I'd appreciate your opinion on bug 29529 -- do you agree to raising the timeouts?
<Ubugtu> Malone bug 29529 in laptop-mode-tools "Laptop HDD powerdown every 5 seconds" [Medium,Confirmed]  http://launchpad.net/bugs/29529
<infinity> We could go back to our roots and make it a pr0n screen of death.
<StevenK> elmo, showing the true sysadmin attitude.
<infinity> Hey, that's my hand in that picture.  I'M FAMOUS.
<mjg59> pitti: Uhm. The *entire point* of laptop mode is that the drive spins down quickly.
<pitti> mjg59: but starting and stopping the drive every 5 seconds will kill it, apart from that it doesn't help to safe power
<infinity> mjg59: 5 seconds seems excessively quick.  Won't it just eat power constantly spinning it back up?
<mjg59> infinity: 5 seconds may be slight overkill, but not hugely
<mjg59> If you set a longer timeout, it'll never spin down
<mjg59> Certainly 15 minutes is entirely pointless
<pitti> mjg59: the point is, if I constantly access my HD, it *shall* not spin down
<infinity> I know the power draw of spinning up drives is non-trivial.  To the point where my old desktop required a two-pass power-on sequence (I'd hit the switch once to power on the drives, but the mobo and video would be dead, then quickly kill and re-power while the drives were still spinning to get the rest of the system up)
<mjg59> pitti: 15 minute timeout = if you access the drive once during those 15 minutes, the drive will not spin down
<smurf> mjg59: there's probably a sensible compromise somewhere between these two extremes ...
<mjg59> pitti: Which will mean that you might as well set it to forever, because /something/ during that time is going to read of disk
<StevenK> infinity: That sounds like your power supply is a little underpowered.
<pitti> mjg59: I'm just concerned about killing my drive; you can only spin up and down a drive so many times
<pitti> 5 minutes or so might be a good compromise
<infinity> StevenK: It was, yes.  Was a 300W PSU and it had 8 10,000RPM drives in it.  I was too lazy to buy a new PSU.
<pitti> mjg59: but I see absolutely no reason to spin down the drive when it's connected to AC
<Ng> does the new power graphing stuff in edgy give sufficient resolution to compare leaving the drive spinning vs powering it up frequently?
<Keybuk> pitti: why does your drive spin up?
<Keybuk> that would be worth debugging?
<mjg59> pitti: Right, there's no reason for it when it's on AC
<StevenK> infinity: JESUS. No wonder. :_P
<pitti> Keybuk: well, because I'm working with my computer? :)
<mjg59> pitti: And if that's happening, that should be fixed
<Keybuk> pitti: an ordinary emacs/gcc/run cycle shouldn't cause a spin up
<pitti> mjg59: yeah, the default configuration seems to indend to use 2 hours, but it's 5 seconds nevertheless
<Keybuk> it'd be worth checking whether you have some gnomeish thing of doom
<pitti> Keybuk: no, it happens everytime I start something in the shell
<mjg59> pitti: But, for reference, with these settings my 2.5 year old laptop is still well within limits (according to SMART)
<Keybuk> pitti: what kinds of things do you start?
<smurf> infinity: so put in the delay-spin-up jumpers. That's what they're there fore.
<mjg59> pitti: So fix that, rather than anything else :)
<pitti> Keybuk: unusual commands, like 'ls', 'vi', or 'ps'
<Keybuk> pitti: none of those on usual files should cause a spin up
<pitti> Keybuk: well, they do, I can't help it
<Keybuk> the results of ls should be in the page cache from last time you did it
<Keybuk> then debug why they do
<Keybuk> look at vm/block_dump
<infinity> smurf: Don't have the box anymore, but I'm pretty sure the drives didn't have hard jumpers for that.
<pitti> I still think that 5 minutes would be a more sensible limit than 5 seconds
<Keybuk> 5 minutes is far too long
<pitti> if, as Keybuk says, machines with more memory do not access the disk so often, then 5 minutes would work for them, too
<mjg59> pitti: And I think it's likely that that would be equivalent to 5 hours
<Keybuk> that means that if, in a 5 minute window, you cause the disk to spin up, it won't spin down!
<Keybuk> which effectively means it will never spin down
<pitti> Keybuk: right
<pitti> Keybuk: that's exactly what I want -- if I'm working with the computer, leave the disk running
<Keybuk> when I'm on laptop mode, my disk only spins up every few minutes, and then only for five seconds
<Keybuk> pitti: turn off laptop mode
<pitti> hmm
<pitti> Keybuk: well, I know how to do that, but not every user might
<mjg59> We don't enable laptop mode by default in any case
<Keybuk> the whole point of laptop mode is that it keeps your disk DOWN for as long as possible
<Keybuk> not UP
<pitti> mjg59: I never enabled it, so it must be by default
<pitti> it's a fresh edgy beta install
<mjg59> pitti: Is this on PPC?
<pitti> Keybuk: yeah, but up/down/up/down/up/down every 5 seconds spoils that
<pitti> mjg59: yes
<Keybuk> pitti: then debug why that happens
<mjg59> pitti: Ok. Fix PPC :)
<tfheen> Keybuk: re making the scheduler explode -- are topics up already?
<Keybuk> tfheen: I've been proposing things, yeah
<mjg59> pitti: I don't have any mobile PPC hardware, so I've no idea why that's happening. It's not the case on x86.
<Keybuk> and I'm using my "very small spec" method again
<pitti> Keybuk: dude, because I'm executing something in /bin :) and 256 MB memory isn't enough to keep the world in the cache
<Keybuk> pitti: then turn off laptop mode
<pitti> mjg59: ok, good to know; I'll look into that then
<mjg59> pitti: I've no intention in changing the laptop-mode settings. On x86, things work (and the drive gets set back to sensible timeouts on AC)
<pitti> mjg59: NB that the bug reporter is on x86
<pitti> so it doesn't seem to work on all hw either
<Keybuk> the correct thing to do when laptop-mode is spinning up the drive all the time is debug why it's spinning up at all
<Keybuk> not to break it
<mjg59> pitti: The bug is ancient and ought to have been closed
<giftnudel> Keybuk: it's the apps
<giftnudel> Keybuk: like epiphany spins up the disk on loading an image and closing a tab, so browsing with epiphany + laptop-mode = pointless
<Keybuk> giftnudel: why does epiphany load the image off the disk?
<pitti> as I said, it happens with simple shell commands, too
<giftnudel> laptop-mode is working just fine
<Keybuk> why is the image not in the page cache?
<Keybuk> pitti: ls should be in your page cache
<giftnudel> Keybuk: if it adds it to the disk cache i suppose
<pitti> Keybuk: maybe ls itself, but not the directory it's displaying?
<Keybuk> pitti: you really ls random directories all over your disk while on battery power?
<ogra> sooo, sleep doesnt help either with my usb/usplash race ... seems the only thing that really prevents the breakage is the chvt 7
<mjg59> I think my useful contribution to this discussion is done
<Keybuk> pitti: challenging yourself to find a directory you've never looked at before?
<pitti> Keybuk: *sigh* I discovered that bug for the reason that I worked normally with my box, not to annoy people
<giftnudel> I suppose you have to fix all apps that constantly access the hardrive
<Keybuk> pitti: right, but your proposed solution is wrong
<Keybuk> increasing the laptop mode timeout beyond a matter of seconds would make it effectively useless
<pitti> Keybuk: well, we have a different opinion about the effectiveness of fast spindowns
<pitti> that doesn't make mine wrong per se
<Keybuk> if, as you say, you cause your disk to spin up EVERY FIVE SECONDS
<Keybuk> then increasing the timeout would just make it never spin down, no?
<pitti> correct
<Keybuk> so why not just turn off laptop mode?
<Keybuk> if you never want your disk to spin down, you want laptop mode disabled
<pitti> Keybuk: because I'm a dumb user and do not know how to turn it off
<Keybuk> it's not turned ON by default
<pitti> Keybuk: I never turned it on
<Keybuk> at some point you have enabled it
<pitti> until yesterday I wasn't even aware of it
<giftnudel> well, the point is not to never spin the disk down but not up-down-up-down ...
<Keybuk> pitti: grep LAPTOP_MODE /etc/default/acpi-support
<pitti> Keybuk: powerpc, no acpi
<shawarma> giftnudel: No. up-down-up-down is fine at the right intervals. 
<Keybuk> pitti: that's probably the bug
<giftnudel> shawarma: yes, but not 4 times in 40 seconds
<Keybuk> giftnudel: if the disk needs to come up every 5s, there's no way to prevent that
<Keybuk> mjg59: is laptop mode enabled by default on powerpc?
<pitti> Keybuk: you really want to tell me that it's the right thing to spin down the disk if I need it every 5 seconds?
<Keybuk> pitti: no, if you need it every 5 seconds you don't want it ever spun down at all
<pitti> (that has nothing to do with fixing apps to not do that, of coruse)
<Keybuk> however it's the right thing to spin down the disk after 5s if you don't need it
<shawarma> giftnudel: actually, I'm quite sure the original benchmarking done when designing laptopmode showed that 10 seconds was a very reasonable setting. 
<pitti> Keybuk: right, and that's what I keep saying all the time
<giftnudel> shawarma: i'm just scared that it kills my hd
<giftnudel> maybe add something like a back-off algorithm
<giftnudel> wait more if spun up often
<Keybuk> pitti: to me, the bug is that laptop mode gets enabled on powerpc because there's no acpi-support conffile, so there's no ENABLE_LAPTOP_MODE=false
<shawarma> The article in LinuxJournal about it (with some benchmarks): http://www.linuxjournal.com/article/7539
<giftnudel> shawarma: thanks
<pitti> Keybuk: ah, that sheds some light now, thanks
<shawarma> pitti: What does /proc/sys/vm/laptop_mode say?
<mjg59> Keybuk: Conceivably, which (as I mentioned) is a bug
<pitti> shawarma: '2'
<smurf> Keybuk: care to take a quick look at bug 64327 ?
<Ubugtu> Malone bug 64327 in upstart "No console stdout when booting the LiveCD with "single"" [Undecided,Unconfirmed]  http://launchpad.net/bugs/64327
<Keybuk> pitti: as for the timeout, try increasing it a second at time
<pitti> mjg59: laptop-mode-tools reads /etc/default/acpi-support, or another file, too?
<Keybuk> you may find that 7s is the right point for you
<AlinuxOS> doko_, ping.
<mjg59> pitti: Possibly just acpi-support
<Keybuk> smurf: it's not a bug?  that's deliberate
* Keybuk -> lunch
<doko_> AlinuxOS: pong
<Seveas> mjg59, your 'don't use palettes' usplash_svga patch broke usplash_put_part, usplash_clear and usplash_text. I get blueness in the kubuntu theme with revision 82, not with revision 81 (bug 64171). I tried to debug it, but am at a loss :/
<Ubugtu> Malone bug 64171 in usplash "Colors look bad " [Undecided,Unconfirmed]  http://launchpad.net/bugs/64171
<smurf> Keybuk: why the hell should single-user mode not write startup messages to the console?
<pitti> mjg59: hmm, the best equivalent I can think of is pbbuttonsd -- its postinst could generate an /etc/default/acpi-support with 'ENABLE_LAPTOP_MODE=false' if it's not yet present
<infinity> smurf: Nothing writes console messages anymore, unless you boot without "quiet" on the command line.
<AlinuxOS> doko_, hello, I don't know really what happened but since last update of georgian (ka) locale there is no icons on OpenOffice.org Writer's interface and others..
<AlinuxOS> something is wrong I think :/
<smurf> infinity: I *do* boot without "quiet" on the command line
<Seveas> err, I mean blueness in the ubuntu theme (kubuntu is *supposed* to be blue ;))
<infinity> smurf: Right.  Hence, no messages.
<smurf> "debug", even. Heaps of nice kernel messages, but none from userspace.
<infinity> smurf: Err, wait.  I read that was "with", not "without".
<smurf> infinity: 'xactly.
<infinity> smurf: upstart is *meant* to give output without quiet...
<doko_> AlinuxOS: which desktop? did you do a complete dist-upgrade? did you change the icon-styles yourself in the OOo options?
<smurf> infinity: ... which is why I filed that bug ...
<AlinuxOS> no doko_ , no changes ... just a user communicated it for me in this moment..
<AlinuxOS> I've started my OO.org writer and there is no icons 
<infinity> smurf: Well, assuming upstart-logd is installed, anyway.
<doko_> <doko_> AlinuxOS: which desktop? did you do a complete dist-upgrade? 
<pitti> mjg59: alternatively to the pbbuttonsd hack, can I change /etc/init.d/laptop-mode to not enable laptop mode if /etc/default/acpi-support is not present at all?
<AlinuxOS> Edgy Eft, Calculating upgrade... Done
<AlinuxOS> 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
<AlinuxOS> doko_, no new dist-upgrade packages.
<doko_> doko_> <doko_> AlinuxOS: which desktop?
<AlinuxOS> http://taya.convert.ge/screenshot35.png
<AlinuxOS> http://taya.convert.ge/screenshot36.png
<mjg59> pitti: Uh. That would just never make it work on ppc.
<smurf> OK, changed the bug to say "debug single" instead of "single". That doesn't make the bug go away unfortunately. ;-)
<doko_> AlinuxOS: ok, KDE
<mjg59> pitti: It should have a config file on PPC too
<AlinuxOS> User: Kubuntu Edgy Eft. 
<pitti> mjg59: well, I guess this setting really belongs to /etc/default/laptop-mode
<AlinuxOS> Me: Ubuntu Edgy eft = GNOME
<mjg59> pitti: Not really on x86, since it's handled by the acpi scripts
<AlinuxOS> the same result.
<AlinuxOS> doko_, 
<pitti> hmm
<doko_> AlinuxOS: dpkg -l openoffice.org-style*
<pitti> mjg59: hm, since acpi-support doesn't exist on ppc, I'm also fine with creating the default file in pbbuttonsd's postinst; it's a nasty hack, but unintrusive
<mjg59> pitti: Hm. What does policy have to say about this? :)
<pitti> mjg59: it wouldn't like it
<mjg59> Yeah.
<mjg59> Adding a laptop-mode config file on PPC and checking that sounds like the Right thing to do
<mjg59> It's fine to source from both of them (in the case of them existing)
<pitti> but if l-m uses a configuration file from a non-depended package, it's already an unclean situation, so how much worse can it get :)
<pitti> mjg59: ok, WFM, too
<AlinuxOS> doko_, http://paste.ubuntu-nl.org/25802/
<pitti> mjg59: /usr/sbin/laptop_mode reads ENABLE_LAPTOP_MODE from /etc/default/laptop-mode
<pitti> mjg59: this file doesn't seem to exist by default, so maybe I can just use this on ppc?
<mjg59> Sure
<doko_> AlinuxOS: is openoffice.org-kde installed in the KDE installation?
<AlinuxOS> doko_, that's users: http://paste.ubuntu-nl.org/25803/
<AlinuxOS> doko_, ok I'll ask her.
<pitti> mjg59: oh, ugh, l-m-tools is arch:all, so I'll create it in the postinst
<AlinuxOS> doko_, no it's not installed on her pc.
<AlinuxOS> on my computer there is no openoffice.org-gnome.
<doko_> AlinuxOS: you should install these ... (dependency of ubuntu-desktop / kubuntu-desktop)
<AlinuxOS> doko_, testing...
<tfheen> mjg59: oh, do you happen to know why the usplash text is dark blue on black?
<AlinuxOS> doko_, do you still accept gsi files (updates I mean) ?
<doko_> AlinuxOS: probably
<AlinuxOS> is there a dead line or something ?
<doko_> iwj: ping
<AlinuxOS> every month or , once in 2months there is some corrections and updates in UI.
<Keybuk> smurf: why should it?
<Keybuk> if you use the "(recovery mode)" option, it will write messages
<mjg59> tfheen: Because usplash_put_part is broken
<mjg59> tfheen: Which I don't entirely understand, given that I'm pretty sure I just cut and paste the same code from usplash_put and it works fine there
<tfheen> hmm, and reconfiguring gnome-power-manager makes usplash unhappy.
<AlinuxOS> doko_, (you are doing super!) it's great to see improvements. As Georgian Ministry of Instruction is going to use Kubuntu in schools.
<mjg59> Ok, I'm bored of this now.
<mjg59> Can we please have some mechanism to prevent people filing bugs against "acpi" unless they really mean to?
<Keybuk> mjg59: I liked the guy who filed bugs against usplash because his sound card and network card wasn't working
<zul> like electro-shock treatment
<Fujitsu> mjg59, /everything/ is either the fault of acpi or upstart. There's no other possibility.
<Fujitsu> zul, those LP guys are really taking their time implementing that feature.
<mjg59> Fujitsu: Given that acpi is a command line tool that parses /proc/acpi and prints useless information, the things I blame it for are limited
<zul> heh...maybe someone should spec it out
<Keybuk> Fujitsu: or "boot", a package of bootstrapping functions for GNU R
<Fujitsu> Keybuk, that's impressive.
<kristog> it's possibile to use cdeboostrap for bootstrap edgy?
<Fujitsu> mjg59, so of course everything is caused by it.
<Kamion> kristog: no, it's not supported as far as I know
<tucoz> i found a bug and a solution to a problem when running dpkg-reconfigure xserver-xorg. who should i talk to?
<Kamion> kristog: but there's no point anyway
<mjg59> tucoz: launchpad.net
<tucoz> :)
<Kamion> kristog: everything cdebootstrap was useful for (automatic dependency resolution, basically) debootstrap now does
<mjg59> tucoz: In general (this isn't true in all cases) putting it in Launchpad will ensure that the right people see it. Picking one individual person won't necessarily
<shawarma> pitti: /win 2
<shawarma> doh...
<tucoz> mjg59, ok. thanks.
<iwj> doko_: Hi.
<iwj> Err, amd64.  I assume it must be something with your setup.  I haven't built ff on the colo amd64's recently and I don't have one here, but it built in LP so I propose to just apply the patch and build it on i386 and expect the LP buildd to DTRT.
<doko_> iwj: about firefox/xulrunner ... the problem with eclipse: it only works with xulrunner now, problems with the NS_InitEmbedding stuff in firefox.
<iwj> Err, is this a new thing ?  I don't know anything about it ...
<doko_> no, not new, just needed by eclipse
<iwj> doko: Do you have a bug reference or something with some details ?
<Kamion> ok, with any luck that's the tasksel/usplash mess fixed
<Kamion> that only needed fixes in four separate places
<Fujitsu> And was an upstart bug. Or was it acpi? Or both?
* Fujitsu ducks.
<doko_> iwj: http://dev.eclipse.org/mhonarc/lists/linux-distros-dev/msg00082.html
<kristog> Kamion: we should file a bug to include edgy in the debian debootstrap package.
<Kamion> kristog: I believe there already is one
<Kamion> kristog: but it should *NOT* be included until edgy is final
<Kamion> because the edgy debootstrap script does change occasionally throughout development
<Kamion> ah, there's one for Ubuntu dapper
<kristog> Kamion: yes
<tfheen> the dapper one works fine as long as you pass --resolve-deps, iirc
<doko_> Kamion, Keybuk: please sync ecj-bootstrap before the weekend (#64073), I would like to use it for the next OOo build over the weekend
<Keybuk> smurf: removing quiet and adding single works for me -- have attached screenshots to the bug
<Keybuk> smurf: also, from reading the kernel source, quiet trumps debug
<smurf> Keybuk: looks like you didn't do that on the LiveCD
<Keybuk> smurf: that looks like a LiveCD syslinux prompt to me
<tfheen> that'd be special.  The desktop cd uses isolinux, not syslinx.
<tfheen> not syslinux even
<Keybuk> ok, isolinux then
<Keybuk> :)
<Kamion> doko_: please describe the Ubuntu changes you want to overwrite in the bug
<Kamion> doko_: we won't process sync requests without that, I'm afraid
<smurf> Keybuk: Hmm. You seem to be right, seems to have been a mix-up on my part.
<smurf> Keybuk: Anyway, the last kernel message I see on my PPC is the one from squashfs, then there's a lot of CD acctivity but nothing more to be seen. :-/
<Keybuk> smurf: if you left "splash" in, the output would have been on tty7 under usplash
<Keybuk> smurf: that's because the PPC boot loader doesn't let you remove kernel options
<doko_> Kamion: is this sufficient?
<Keybuk> https://features.launchpad.net/distros/ubuntu/+spec/webcam-gestures
<Keybuk> *giggle*
<funman> helo
<Kamion> doko_: yes, thanks, although in future we prefer a description rather than just a changelog paste; in practice too many people seem to automate the changelog paste and we've found that not everyone actually checks ...
<pitti> seb128: did you ever get an useful apport report with SIGABRT?
<seb128> pitti: no
<pitti> seb128: they usually come from exception hanndlers or assertion failures
<pitti> seb128: and usually the backtrace is useless for them
<seb128> right, that's my opinion too
<pitti> seb128: I'm pondering to just ignore SIGABRT for now
<pitti> seb128: I have a bug open about grabbing the text of the message (similar to grabbing mono's stack trace output) but that's nothing for edgy
<pitti> when we have that ^, we should catch abort again
<seb128> ignoring SIGABRT looks fine to me
<seb128> right
<seb128> having the assertion message is useful
<fabbione> Kamion: when you have time bug #59228
<Ubugtu> Malone bug 59228 in cpio "cpio build glitch breaks Unicode char handling" [Unknown,Fix released]  http://launchpad.net/bugs/59228
<fabbione> Kamion: we are close to the end of the tunnel :)
<sabdfl> mjg59: ping
<desrt> seb128; it's difficult to get a good read from inside a signal handler
<seb128> desrt: why?
<desrt> seb128; in the case of a segfault a good strategy might be to fire up the debugger in 'continue' mode and then have the signal handler return
<desrt> that'll re-trigger the crash
<desrt> and the debugger will get a better read
<seb128> ah
<desrt> seb128; if you think about how signal handlers are called, it's pretty random
<seb128> but you should get a function calls history still though, no?
<desrt> seb128; they happen at any point in the code... so in some cases your stackframe is gonna be in a messed up state
<mjg59> sabdfl: Hi
<desrt> seb128; also, signal handlers don't return to the normal place in the code... they return to a special kernel trampoline (to restore the values of registers, etc)
<desrt> it's amazing backtracing works at all when a signal handler is running, imo :)
<desrt> (obviously has some special help for it built-in to the debugger)
<seb128> hum
<seb128> I see
<seb128> doesn't look trivial to change though :/
<desrt> nice
<desrt> abort gets rethrown if the signal handler returns
<desrt> seb128; correct solution, i think, is to modify the part of bug-buddy (or whatever) that lives in process
<desrt> seb128; currently it attaches gdb to the process and issues 'bt' straight away
<desrt> seb128; it should actually attach gdb, issue 'c' then the process should return to where it was executing in which case the abort or the segv will be thrown again and the debugger will catch it and get a much cleaner trace
<seb128> desrt: 
<seb128> $ cat /usr/share/bug-buddy/gdb-cmd
<seb128> bt
<seb128> thread apply all bt full
<seb128> q
<desrt> yup.  first there should be a 'c' :)
<desrt> (with appropriate support in-process)
<desrt> i think the parent currently ends up in waitpid() or something
<desrt> (having seen a billion bugbuddy stacktraces you think i'd know this more certainly)
<seb128> I don't really get why abort or segv will be thrown again
<desrt> abort contains code specifically so that it will be thrown again if the handler returns
<seb128> ah
<desrt> including explicitly unsetting the handler, it seems
<desrt> segv will happen again unless your handler manages to deal with the problem that caused the crash
<desrt> like.. the null pointer will still be null (or whatever)
<desrt> so it'll try again and crash again
<desrt> seb128; presumably a synchronous version of g_spawn or something is used to launch the bugbuddy... a good first crack would be to try changing that to async, then add a sleep(10); or something to wait for the debugger to start and attach to the process
<desrt> then just return from the signal handler
<desrt> and add a "c" to the gdb commands file
<desrt> if you're sufficiently lucky then that may work :)
<desrt> (and makes a good start at a patch that you might want to get upstreamed)
<seb128> that looks like a crackish idea
<seb128> might work though ;)
<desrt> the idea of calling a debugger on yourself from a signal handler is crackish
<desrt> this is equivalently crackish, yes :)
<seb128> how else would you get a backtrace?
<desrt> "remember what you did to cause the crash and do it again while running under the debugger" used to be a popular favourite
<seb128> it works better
<seb128> I used to ask people to copy the bt from bug-buddy
<seb128> for some months I ask them to run it under gdb though
<seb128> I had some cases or bug-buddy was giving nothing useful and where gdb works fine
<seb128> seems to be a real issue for evolution triagers though
<seb128> most of their bt are empty
<desrt> well, hopefully i am right :)
<seb128> desrt: do you think you could have a try to a proof of concept? ;)
<desrt> i don't know for sure... but empirical knowledge and intuition says that it must be true
<seb128> I'll otherwise, but probably not before edgy
<desrt> ok.  if i know you're not working on it i'll try something this weekend at the cottage
* desrt makes sure to grab source and build-deps for bugbuddy before leaving
<desrt> are there any weird libbugbuddy package or something or is it all one thing?
<desrt> libgnome, maybe?
<seb128> desrt: libgnomeui set the crash handler
<desrt> awesome.  thanks.
<seb128> desrt: bug-buddy is called and run gdb
<seb128> np, thank you for having a look at it :)
<desrt> i probably don't even need bugbuddy source
<desrt> but can't hurt :)
<seb128> the edgy package has a patch to libgnomeui to not set the crash handler if /apps/bug-buddy/run_on_crash is set
<seb128> that's a "let apport doing its job" patch :)
<seb128> but apport doesn't do better job at getting the bt 
<desrt> is apport this spiffy new bugbuddy-type thing?
<desrt> er.  one case that my idea will deal poorly with is if you manually send a sigsegv/sigabrt to an app
<desrt> because then the bugbuddy will start up but when the signal handler returns it won't be rethrown
<desrt> that's a pretty border case, though
<seb128> desrt: right, apport is the distro wide bug-buddy pitti worked on for edgy
<desrt> k
<desrt> maybe i'll grab source for that, too :)
<desrt> is it python?
<desrt> er.  does it run some sort of a system daemon?
<seb128> the dump is made by the kernel itself
<desrt> oh!  of course!
<desrt> that's what people used to do
<desrt> they used to have corefiles
<desrt> and run the debugger on that
<seb128> that's what apport do
<seb128> doesn' work better than bug-buddy though
<desrt> that's useful information
<desrt> i wonder if libgnomeui's abrt/segv handler still runs?
<seb128> bug-buddy runs first
<desrt> ok.  so that's why.
<seb128> if you don't unset /apps/bug-buddy/run_on_crash
<desrt> i bet if you cut bugbuddy out of the picture entirely then apport would work a lot better
<seb128> no
<tfheen> Riddell: did you have a chance to test the kubuntu accessibility stuff?
<desrt> apport gets run by the bugbuddy code?
<seb128> desrt: my libgnomeui patch doesn't set the signal handler if the gconf-key is not set
<seb128> no, I've patched libgnomeui
<seb128> by default it's running
<desrt> ok
<desrt> i'm confused
<Riddell> tfheen: no, not yet I'm afraid
<desrt> how does apport find out about crashed processes?
<seb128> if you unset /apps/bug-buddy/run_on_crash then the signal handler is not set
<seb128> and apport get the crash
<desrt> right... but how does it know that a crash has happened?
<seb128> pitti: around? ;)
* desrt chuckles
<desrt> i'll figure it out :)
<desrt> anyway.  i'm away for the long weekend
<desrt> cheers
<seb128> desrt: apport has a kernel side for the crash detection and the dump apparently, I've not looked into details
<seb128> desrt: have fun!
<bddebian> Howdy
<AlinuxOS> mjg59, hello, You have alredy fixed Georgian (ka) fontconfig issue and it's good. But, but in Edgy or Dapper repos there still remains an old (0.2 version) ttf-bpg-georgian-fonts package. Please see tha last comment here: https://launchpad.net/distros/ubuntu/+source/ttf-bpg-georgian-fonts/+bug/55966 Thank You a lot.
<Ubugtu> Malone bug 55966 in ttf-bpg-georgian-fonts "ttf-bpg-georgian-fonts.conf problem." [Undecided,Confirmed]  
<AlinuxOS> "ttf-bpg-georgian-fonts.conf problem." there is no fontconfig problem anyway.
<jdong> who is in charge of gnome-power-manager?
<Treenaks> in charge! good pun! :P
<jdong> I didn't mean it :)
<jdong> I've found the fix for the logout dialog not coming up
<Seveas> jdong, ooh!
<Seveas> nice one
<jdong> Seveas: yeah, ooh is right :)
<jdong> patch # 56 , hunk #1
<Seveas> I was puzzled by not getting that dialog when pressing the power button
<jdong> yeah, apparently whoever wrote patch 56 went overboard on removing gnome_client_request_save() calls :D
<jdong> so that the code branch for interactive logout was basically nil :)
<jdong> I commented in the bug report already, but it doesn't look like there's anyone in there that's paying attention from the packaging standpoint
<jdong> which is why I asked who's in charge of the package
<jdong> (looking at the package and its outstanding bugs, it doesn't look terribly maintained either....)
<highvoltage> where can I get more information on Ubuntu landscape?
<jdong> huh?
<highvoltage> apt-cache show landscape-client
<highvoltage> it sounds like a web-minny thing for ubuntu
<jdong> does sound very cool
<jdong> have you tried searching landscape on the wiki?
<highvoltage> I googled, but it wasn't very useful (wiki'ing now)
<highvoltage> nope, not there either
<Kamion> it's not a public project yet
<Kamion> only its name by virtue of the package name :-)
<highvoltage> ok :)
<highvoltage> will it be free software?
<Kamion> I don't honestly know
<Kamion> I've not paid a lot of attention to it
<highvoltage> ok, np. I'll hold on and see what happens :)
<jdong> Kamion: have you had a chance to consider my ntfsprogs proposal yet?
<Kamion> fabbione: gotcha
<Kamion> jdong: not yet - will look now
<Kamion> I've had Andreas Lloyd here for most of the day
<fabbione> Kamion: thanks dude
<keescook> morning!
<Keybuk> Kamion: and how is Mr Andreas?
<jdong> Keybuk: you're on TB, right?
<Keybuk> yes
<jdong> I've been recently considering becoming MOTU more and more... I've found myself poking MOTU's too much to do backports-related work
<jdong> I was wondering as a TB member, what would it take to convince you that I am MOTU material :)
<Keybuk> I didn't realise you weren't already
<Kamion> Keybuk: seems fine. my throat hurts from talking all day now, though :)
<Keybuk> Kamion: I believe I'm to have him on Monday
<rubikcube> hi, where does ubuntu (dapper) load the PATH from? /etc/environment ?
<jdong> Keybuk: on the original backports meeting, ogra kept on pushing for me to be MOTU, but it was agreed that backports/MOTU were orthogonal, and that was the end of that
<fabbione> Kamion: thanks for approving.. 
<Keybuk> jdong: I can only speak for myself, but I can't think of any immediate concerns; you've had sufficient exposure to our procedures, and even to packaging, to be considered
<Keybuk> jdong: obviously you'll need to answer the usual questions about what you want to do in universe, etc.
<jdong> ok
<jdong> perhaps I'll put myself on the next TB then....
<jdong> Keybuk: who are the other TB's again?
<Keybuk> next TB is tuesday
<Keybuk> mdz, mjg59 and sabdfl (though I think he's forgotten <g>)
<jdong> ok
<jdong> I think from the group, you'd be the one most familiar with me...
<Keybuk> indeed
<jdong> the thing is, I've not really done all that much of MOTU work... I have contributed a few patches against acidrip/ktorrent recently, as well as researching an x264 UVFe
<jdong> so there's not all that many MOTU's who can vouch for my abilities...
<Keybuk> it's what you plan to do, and your ability to do it, that will count
<jdong> virtually the only thing that I need to do in Universe is loosen tightened build-deps when they're not needed in universe but needed in backports
<jdong> I've mostly been poking MOTU's for that, but they're getting annoyed and often ignoring me :D
<crimsun> s/ignoring/resource-constrained/g
<jdong> crimsun: I am using ignoring affectionately :)
<jdong> I know how busy you guys all are, and you have your own agendas, etc
<jdong> which is why I'd like to be a bit more independent and less of a maintenance burden for others
<highvoltage> jdong: I don't know you but it sounds like you are too hard on yourself
<jdong> highvoltage: sometimes I am very demanding on myself, and I never like to say anything that might overestimate my abilities....
<jdong> that's one of my flaws...
<jdong> Kamion: thanks for your response on the ntfs thing
* Kamion finally manages to reproduce the gtk.main_quit crash locally
<Kamion> only four months later
<jdong> Kamion: I know that we have a lot of customized code on the package, but are there future plans (edgy is certainly not a target) for a newer gparted?
<Kamion> jdong: I hope that in edgy+1 I'll be able to stop using it in the installer
<Kamion> so people who care can do what they like ;)
<jdong> Kamion: ntfsresize's FAQ asserts that Ubuntu's version has some known partition table corrupting bugs in certain instances....
<Kamion> jdong: does it say Ubuntu dapper or edgy or anything more specific?
<jdong> which sounds slightly concerning, though I've yet to follow up
<Kamion> because edgy's version is a good deal newer than dapper's
<Kamion> we're still a bit behind upstream, but I didn't know there was anything all that drastic
<jdong> Kamion: I believe it deals with dapper's
<jdong> Kamion: they seem to preach by that new version of gparted being featured on the gparted livecd
<Kamion> are they purely going by version numbers?
<Kamion> because I backported an NTFS fix to gparted before dapper release
<jdong> they might be
<jdong> as I said, I didn't really follow up on it
<Kamion> fair enough
<Kamion> if you do find out that there's a problem, I'd certainly be willing to propose a stable update
<jdong> mmkay
<jdong> is there a set date of when a 6.06.2 release would be made?
<Kamion> not at the moment
<Kamion> it's not even certain that there will be one, although neither is it certain that there won't
<jdong> ok
<jono> hi guys
<highvoltage> hi jono
* pitti waves to jono
<jono> do we know if the ubuntu book excepts are staying in Edgy?
<sladen> afternoon jono, how's the jet lag?
<jdong> aren't there some ubiquity bugs on 6.06.1 though?
<jono> hey highvoltage pitti 
<jono> sladen, fly back today :)
<Kamion> jono: they've already been changed to links to a website
<Kamion> jdong: well, yes, but there are ubiquity bugs in edgy too ...
<Kamion> 6.06.1 is a LOT better than 6.06, but I agree more could be done
<jdong> :)
<jdong> I've generally had great luck with 6.06.1
<jono> Kamion, ok cool, I will let the publisher know
<Kamion> I'm not aware of any regressions in 6.06.1 though
<jono> Kamion, is this the final decision?
<Kamion> which would be the really scary thing
<Kamion> jono: I think so - we took it for CD space reasons, and it was discussed on ubuntu-devel and cleared with Matt and Mark
<Kamion> jono: if there are good arguments to the contrary, we'd listen, though - it's not necessarily a closed subject
<jdong> Kamion: btw, do _you_ know who's supposed to handle gnome-power-manager?
<jono> Kamion, ok cool, fine with me :)
<mjg59> jdong: Nobody
<sladen> jdong: various people, what's your issue
<jono> Kamion, just need to know what was decided to let Prentice Hall know
<jono> thanks :)
<jdong> sladen: I've found the culprit to the logout dialog regression....
<jdong> bug 57582?
<Ubugtu> Malone bug 57582 in Tilix "It`s not possible to dist-upgrade" [Critical,Confirmed]  http://launchpad.net/bugs/57582
<jdong> no
<jdong> bug 57872
<sladen> jdong: fantastic, bug #57582
<Ubugtu> Malone bug 57872 in gnome-power "regression: pressing power button no longer brings up logout dialog" [Unknown,Unconfirmed]  http://launchpad.net/bugs/57872
<jdong> it's that first hunk in debian/patches/56-disable-session-save-on-shutdown.patch
<jdong> sladen: I think that  gnome_client_request_save() request was mistaken for something that would save the session
<jdong> while from what I understand/researched it merely brings up a login dialog
<jdong> logout*
<jdong> the second hunk is what saves the session without telling the user
<jdong> was just wondering if you guys can double-check my findings and fix that annoying bug :D
<sladen> jdong: what we want is session-closing, but no reference to session saving (they probably wanted hibernate instead)
<jdong> sladen: right. patch 56's first hunk is definitely incorrect. it takes out the only action in that else if branch
<jdong> sladen: from all the researching I've done, that gnome_client call is the way to bring up the logoff dialog
<sladen> jdong: righto
<jdong> sladen: the second hunk, I am not so sure on. That call might actually save the session :D
<Kamion> hah, 20+ ubiquity bugs fixed
<Kamion> I think that's a perfectly good excuse to go out for a bit
<jdong> sladen: in which case, we want to preserve that 2nd hunk
<jdong> Kamion: how many more to go? ;-)
<jdong> (jk, take a well deserved break)
<Kamion> oh, only about 400. but that's one of the two major remaining classes of undiagnosed bugs, so I feel a lot better
<Keybuk> I do wish ubuntu wouldn't display the 3D screensavers in vmware ;)
<jdong> Keybuk: yeah, I was gonna come and yell at the vmware image creators for not thinking that one through!
<jdong> Keybuk: oh yeah, wishlist, edgy eft vmware images should include the vmmouse package
<jdong> and its xorg.conf should use it
<Keybuk> there are "vmware images" ?
<jdong> Keybuk: yeah, on cdimage.ubuntu.com
<Keybuk> shiny
<jdong> certainly shiny
<jdong> but they also display 3d screen savers :D
<Keybuk> I just boot the CDs in it
<jdong> that works too :)
<jdong> though you need to hand it more RAM than I'd like to
<Keybuk> *shrug*
<Keybuk> my usual thing is download all the cd images, and boot three at a time
<jdong> random question, what does it take to enable this DT_GNU_HASH thing
<elmo> Kamion: you were saying the other day that you thought root raid installs might be fucked - do you know for sure yet, and/or is it already fixed?
<Keybuk> elmo: fabbione fixed it
<elmo> ok
<Keybuk> assuming it was the "they won't boot" problem
<sladen> Keybuk: that's easy enough to fix, extend laptop-detect with a  --or-is-vmware  option and get the gnome-screensaver setup to use that parameter aswell
<jdong> I just tried FC6 yesterday, and it's really... alarming... when it runs faster in vmware on my sempron than ubuntu on my dual core
<jdong> and apparently that's dt_gnu_hash at work
<elmo> Keybuk: yes
<Keybuk> oh, that was kinda kooky
<Keybuk> was doing an upgrade test
<Keybuk> and the background image changed underneath during the upgrade
<jdong> lol
<jdong> the in-place upgrade really needs a few warnings
<jdong> :)
<jdong> namely, crashing your panel by adding an applet in the middle of the upgrade isn't recommended
<jdong> or, your tooltips might change into gibberish as we change your fonts
<jdong> or, firefox might begin speaking XML to you.... 
<fabbione> elmo: it should be fixed. at least on my 3 test machines works
<elmo> fabbione: cool, thanks
<fabbione> elmo: if you find a problem, please let me know ASAP and we can see why
<elmo> fabbione: we've only tested with edgy beta, if you say you've fixed it since then and it works for you,I'm happy to believe you
<sabdfl> Keybuk: that's really "full confidence in the rest of the team" ;-)
<fabbione> elmo: yes it was fixed after beta.. a bit hackish but it should do. 
<fabbione> elmo: basically once mdadm is installed and mdadm.conf is generated, we copy the conf in the initramfs to have md RAID UUID info and wait for it to appear (via mdadm --scan)
<Keybuk> sabdfl: hmm?
<fabbione> elmo: once the raid is available (or raids) then the boot goes further.
<_ion> dholbach: Please see bug 64372.
<Ubugtu> Malone bug 64372 in loudmouth "Crashes when connecting to server that requires STARTTLS" [Undecided,Unconfirmed]  http://launchpad.net/bugs/64372
<jdong> Keybuk: I think sabdfl wants to say s/Keybuk/elmo
<fabbione> elmo: no attempts to check how many raid devices are available when we run it because you migth start in degraded mode.
<elmo> fabbione: cool, thanks
<fabbione> elmo: it's the only way to handle the situations in which devices appear after the first mdadm run. There is also a 3 minutes timeout for super huge storage systems that takes ages to make 300 devices to show up
<fabbione> elmo: always welcome..
* fabbione calls it a day and heads to play x-plane
<fabbione> mvo: i will be back later for when mdz is around
<Kamion> elmo: it was a partitioner problem I thought I'd heard of, not a boot problem; but I admit I didn't look at it very closely since I was doing other things at the time
<sabdfl> Keybuk: re TB
<Keybuk> sabdfl: can you remember the last time you attended one? :p
<sabdfl> oh, i just remember the really feisty ones ;-)
* dholbach hugs mjg59
<Keybuk> it was at UBZ, a year ago, wasn't it? :)
<sabdfl> you exaggerate
<sabdfl> that was only 11 months ago
<Zdra_> Does someone knows where to fill upstream bugs for libnotify ? I just reported this bug for the ubuntu package but I think it should go upstream: https://launchpad.net/distros/ubuntu/+source/libnotify/+bug/64382
<Ubugtu> Malone bug 64382 in libnotify ""attach-icon" property doesn't exists" [Undecided,Unconfirmed]  
<trappist> Zdra_: upstream for libnotify seems to be at chipx86.com, which seems to be down atm
<dholbach> Zdra_: mvo in #ubuntu-desktop just looks at it
<dholbach> Zdra_: galago-project.org is the upstream page - they have trac set up
<Zdra_> dholbach: ok thanks... this website seems down ... :(
<dholbach> yeah :/
<_ion> dholbach: Did you see the bug report?
<dholbach> _ion: about libnotify?
<_ion> < _ion> dholbach: Please see bug 64372.
<Ubugtu> Malone bug 64372 in loudmouth "Crashes when connecting to server that requires STARTTLS" [Undecided,Unconfirmed]  http://launchpad.net/bugs/64372
<dholbach> _ion: I get around 700 bug mails a day :-)
<_ion> dholbach: Hehe.
<dholbach> _ion: looking at it now
<dholbach> _ion: we should subscribe the telepathy team to loudmouth bugs
* dholbach does that now
<dholbach> _ion: I'll forward it and apply the patch
<kristog> dholbach: thank you :)
<dholbach> _ion: thanks a lot for working on this: you ROCK!
<_ion> dholbach: Thanks.
* dholbach hugs _ion a.k.a. Johan "beatbox" Kiviniemi :-)
* _ion hugs dholbach back
<_ion> :-)
<dholbach> _ion: http://developer.imendio.com/issues/browse/LM-62
<_ion> Thanks.
* dholbach hugs _ion again
<dholbach> good to have you on the team
* gnomefreak wonder when wednesday's hug day is gonna end :(
* gnomefreak woke up this morning to over 200 emails most bugs
<HiddenWolf> gnomefreak: when they release duke-nukem-forever. ;)
<gnomefreak> ;)
* gnomefreak trying to catch up to dholbach's karma
* dholbach hugs gnomefreak
* gnomefreak hugs dholbach 
* highvoltage hasn't been hugged today
* HiddenWolf hugs highvoltage tight
* gnomefreak hugs HiddenWolf 
<highvoltage> hehe. I didn't expect that :)
<gnomefreak> oops
* highvoltage hugs HiddenWolf and gnomefreak and dholbach 
<gnomefreak> thats why you dont get hugged nick completion gets HiddenWolf 
* gnomefreak hugs highvoltage 
<HiddenWolf> ;)
<gnomefreak> theres a python 2.6 in repos already?
<gnomefreak>  Warning: 'with' will become a reserved keyword in Python 2.6
<gnomefreak> a little soon to be thinking about 2.6 IMHO
<o_cee> is Till Kamppeter around?
<_ion> dholbach: https://launchpad.net/distros/ubuntu/+source/cohoba/+bug/64398
<Ubugtu> Malone bug 64398 in cohoba "Sends wrong type to telepathy-gabble" [Undecided,Unconfirmed]  
<_ion> dholbach: No patch yet. I'm too tired to concentrate at the moment. Perhaps i'll be able to fix that during the weekend, unless someone else fixes it first. :-)
<dholbach> _ion: you should probably ping the guys in #telepathy about it - maybe they're working on something already.
* dholbach hugs _ion
<o_cee> Steffen Joeris around?
<infinity> For those who don't read mailing lists, soyuz will be offline for a fair chunk while we're upgrading drescher and rebuilding apt-ftparchive caches.
<infinity> https://lists.ubuntu.com/archives/ubuntu-devel/2006-October/021519.html
<sivang> infinity: this is to prepare to edgy+1 ?
<infinity> sivang: No, read the mail.
<sivang> infinity: right, /me crawls back to his hole
<geser> could someone target bug 52803 to be fixed in edgy? (if it qualifies of course)
<Ubugtu> Malone bug 52803 in gsfonts-x11 "insufficient dependency on xfonts-utils" [High,Confirmed]  http://launchpad.net/bugs/52803
<highvoltage> you know you're tired when you stare at a usplash screenshot and wait for it to finish booting.
<infinity> highvoltage: Was it full screen?
<o_cee> anyone know anything about the foo2zjs drivers? Bug #6017
<Ubugtu> Malone bug 6017 in dapper-backports "Update to latest package to make HP LaserJet 1020 work" [Undecided,Unconfirmed]  http://launchpad.net/bugs/6017
<infinity> highvoltage: If not, wow.  Go to bed.
<highvoltage> no, it was in a web browser
<infinity> highvoltage: harsh.
* highvoltage goes to bed even though it's only 20:33... been a long day :)
<_ion> How is it possible to take a screenshot of usplash?
<highvoltage> goodnight!
<_ion> 'ght.
<highvoltage> _ion: you can boot from it in qemu, but there are many ways
<_ion> Ah.
<zul> iwj: ping
<fabbione> mvo, mdz: ping?
<mvo> fabbione: pong
<iwj> zul: Hi.
<iwj> Is this about my edit to XenOnEdgy ?
<iwj> I have a working automatic domU constructor now.
<mdz> fabbione: pong
<fabbione> mdz: i think we should talk one minute about 63680
<fabbione> mdz: do you have time now before mvo and i call the night?
<mdz> fabbione: quickly
<mdz> before my phone rings again
<fabbione> mdz: well we would like to find a solution for that problem... and mvo has something already boiling around...
<mdz> fabbione: messing around with apt's problem resolver in the last weeks of release is not OK
<mdz> do you have another idea?
<fabbione> mdz: that's not our suggestion
<mvo> mdz: exactly, I was more thinking about a text-mode based dist-upgrader 
<fabbione> mvo: was thinking of a text version of the upgrader
<mdz> that's worse
<mvo> mdz: it would just be a different frontend to the upgrader
<mvo> oh?
<mdz> we're not adding features now
<mdz> what other options do we have?
<mvo> for the python-foo stuff, none AFAICS. only to document it in the release notes
<fabbione> mvo: what's the other option for apt to think that it must upgrade ?
<fabbione> for upstart at least.. but well we ship python stuff also on server CD
<mvo> I think the upstart thing could be fixed
<mvo> in apt by using the "essential" flag from the candidate version 
<fabbione> mvo: how dangerous is that?
<mdz> it would need to be fixed in dapper apt
<mvo> I can dig into the python-foo stuff again, but I have not that much hope
<mvo> right
<mvo> that makes matter worse
<fabbione> other options?
<mdz> dummy packages
<mdz> that's the only other thing I can think of
<fabbione> mvo: would that work?
<mdz> it would work but it sucks
<mvo> ++
<fabbione> mdz: i agree that it sucks..
<mdz> it may suck more than having to run apt-get install
<mvo> we could provide a simple python-apt fixup script, but that would suck too
* mvo thinks we definitely need a text-based dist-upgrader. its only a couple of lines of code, the frontend code is nicely abstracted
<mvo> edgy+1 :)
<fabbione> hmmm
<_ion> Yeah, that would be cool.
<fabbione> i think adding a Provides: to upstart won't help shit
<mvo> the code for this is (in a basic form) in my repository already
<fabbione> mvo: not for edgy.. mdz has already blacklisted that option
<mvo> sure
<fabbione> if we introduce the meta-packages.. are we guaranteed that it will work?
<fabbione> and what meta packages do we need to create?
<mdz> yes, we need it, but a) it is way too late, and b) it doesn't solve the problem
<mdz> users who do their upgrades with apt know how to deal with held back packages
<mdz> I agree that it sucks, but it has been sucking for months and now it is too late
<fabbione> mdz: it has been sucking for months due to the Break: thingy and i did swallow it as "it has to be done that way"
<fabbione> but afaik the break thing has been reverted
<mdz> what does this have to do with breaks?
<fabbione> the 2 steps apt update
<mdz> this is a normal file conflict not a break
<mdz> oh, you mean upstart
<fabbione> yeps i know..
<fabbione> yeah
<iwj> Why not Replaces ?
<fabbione> Replaces: sysvinit
<fabbione> it does
<mvo> so it will come down to putting it into the release notes
<fabbione> apt seems to hate upstart
<mdz> see the bug report; the trouble is due to essentialness
* mvo wouldn't call it "hate" 
<fabbione> mvo: it just loves it in a different way :)
<madduck> are you guys fighting the problem that sysvinit is/was essential and now APT complains when replacing it with upstart?
<mvo> exactly :)
<mdz> fabbione: creating empty python2.x-foo in edgy and removing the conflicts would fix it, yes
<mvo> madduck: yes
<mdz> madduck: not complains exactly, just needs to be told twice
<fabbione> what was the issue of making upstart Essential ?
<fabbione> because it was for a while and then reverted?
<madduck> mdz: ah, none of the "Yes, I know what I am doing" stuff?
* madduck was discussing the same issue for Debian today.
<fabbione> madduck: please read the bug report
<madduck> 63680?
<fabbione> yes
<madduck> is there a shortcut to the bug report? like https://launchpad.net/63680 ?
<fabbione>  /bugs/$bugnum
<madduck> thx
<fabbione> mvo: i am ok with whatever solution you think is best and won't destroy upgrades to edgy+1
<fabbione> mvo: we have only 2 options
<fabbione> - release note
<madduck> fabbione: so the gist is that you want to fall back to the upgrader no matter what?
<fabbione> - dummy packages
<fabbione> - anything else?
<madduck> .oO(debian will take the dummy package approach...)
<fabbione> madduck: no i want to be able to dist upgrade dapper -> edgy with apt-get..
<madduck> fabbione: good.
<fabbione> i don't want the dist-upgrader (generally speaking)
<mvo> fabbione: I can't think of anything right now. but I will ponder some more to come up with something
<mvo> madduck: what problem did you fought in debian?
<fabbione> mvo: ok sounds like a plan.. i will be around tomorrow and a bit more fresh than i am now
<madduck> mvo: that sysvinit is essential and thus apt won't replace it.
<madduck> mvo: apt-get install file-rc on any debian machine if you want to experience the effect
<fabbione> mdz: can we have tomorrow to think about other possible alternatives and mail you?
<madduck> fabbione: please put me on CC.
<madduck> madduck@d.o
<fabbione> madduck: subscribe to the bug. that's mostlikely where we will store the info
<fabbione> mail as in add stuff to the bug
<madduck> k
<fabbione> mvo: would that work for you?
<mvo> fabbione: absolutely
<fabbione> mvo: ok let's adjourn sometimes tomorrow when we are more fresh
<fabbione> mdz: cheers.. we will let you know by tomorrow
<mvo> fabbione, mdz: thanks!
<Kamion> geser: done
<geser> Kamion: thanks
<madduck> mvo: maybe you could just fix #169241 ? :)
<dholbach> madduck: let poor mvo go to bed :-)
<madduck> dholbach: no way. :)
<madduck> fine...
<gnomefreak> i see kamion been busy ;)
<LaserJock> bddebian: ping?
<Kamion> hmm, how about I upload a non-broken version of ubiquity before leaving for the weekend
<Kamion> looks like my filesystem-mounting code wasn't quite as well-tested as I thought
<gnomefreak> tfheen: you have a minute. you closed a bug i wanted to ask you about why
<bddebian> LaserJock: Yo, sorry
* jdong notes that bug 57872 is still silent
<Ubugtu> Malone bug 57872 in gnome-power "regression: pressing power button no longer brings up logout dialog" [Unknown,Unconfirmed]  http://launchpad.net/bugs/57872
<gnomefreak> jdong: looking at it. do you happen to know if apport reports freezes?
<jdong> gnomefreak: AFAIK it only reports crashes (i.e. segfault)
<jdong> gnomefreak: what does that have to do with the bug?
<jdong> there's no "freeze" involved
<gnomefreak> nothing but i needed an answer to it
<gnomefreak> still looking at bug
<jdong> the reason it doesn't work is very simple... the functionality was removed by patch 56
<jdong> (kind of humorous, actually)
<gnomefreak> trying to figure out how to get a log of a freeze
<gnomefreak> jdong: this is fixed in edgy is it not?
<jdong> gnomefreak: not fixed in edgy
<jdong> it is an edgy regression
<jdong> and it's been getting the cold shoulder
<tfheen> gnomefreak: sure
<jdong> even though I've now fully identified the culprit and commented in the ticket
<gnomefreak> so has my samba man page error that was sent upstream
<jdong> I'd expect a high priority bug to get more attention than that
<gnomefreak> tfheen: the bug i marked as casper (cant think of bug number atm) but should casper ask you to upgrade on livecd? since those upgrades may affect the install?
<tfheen> gnomefreak: no, why should it?
<Kamion> gnomefreak: there's a ubiquity bug already about having it auto-upgrade itself, but that sort of UI belongs to ubiquity IMHO not casper
<gnomefreak> tfheen: the guy upgraded (the livecd) before installing it and he ended up with a borked system. now this could have been due to the upgrade itself but i can see how the upgrade than install would affect outcome
<Kamion> (you don't want to spend time upgrading from the network in the middle of booting up
<Kamion> )
<gnomefreak> ah ok ty
<gnomefreak> this guy is pissed cause the bug was closed
<Kamion> gnomefreak: was this 6.06?
<Kamion> as opposed to 6.06.1?
<tfheen> gnomefreak: the shipped desktop CD hopefully won't have any updates available, so upgrading is kinda moot.
<gnomefreak> he didnt say if it was point release or not
<Kamion> there was a known bug in dapper's ubiquity that it wasn't pointing apt at the target system properly
<Kamion> so upgrading the live session could confuse it
<Kamion> that's fixed in 6.06.1
<Kamion> bug 47859
<Ubugtu> Malone bug 47859 in ubiquity "crashes if some packages on live fs are unconfigured" [High,Fix released]  http://launchpad.net/bugs/47859
<gnomefreak> ok ty ill dig up the bug and let him know
<Kamion> (the description in the title is not complete; all sorts of weirdness can happen due to apt pointing at the wrong /var/lib/dpkg/status)
<tfheen> upgrading your desktop cd could very well leave you with an inconsistent system which could crash and burn.  There's a reason why I disable the update notifier.
<tfheen> if upgrading works and fixes something for you: great, but I'm not sure we want to make it supported.
<gnomefreak> he also filed 4-5 bugs in one :(
<Kamion> tfheen: ew, you're fixing the blue-on-black text on live CD shutdown, right?
<tfheen> Kamion: it should be fixed, agreed.
<Kamion> well dodged :-)
<tfheen> Kamion: can you file a bug on usplash (if there's none already) and target it for 6.10?
<LaserJock> Kamion: is there any plan on intel mac support in Ubquity for Edgy?
<Kamion> LaserJock: no, sorry
<LaserJock> ok, just wondering
<tfheen> Kamion: I talked briefly with mjg59 about it earlier today and he pointed me in roughly the right direction, but I haven't fixed it yet, no.
<LaserJock> my iMac is feels so lonely without Ubuntu ;-)
<Kamion> I think I've barely scraped fixing up ordinary mac support ;)
<Kamion> tfheen: is it the theme, or usplash itself?
<tfheen> Kamion: I'm not sure, I think it's in usplash itself.
<tfheen> 13:59 < mjg59> tfheen: Because usplash_put_part is broken
<tfheen> 14:00 < mjg59> tfheen: Which I don't entirely understand, given that I'm pretty sure I just cut and paste the same code from usplash_put and it works fine there
<gnomefreak> tfheen: bug im talking about is bug 63645 but i will take care of it ty Kamion and tfheen 
<Ubugtu> Malone bug 63645 in casper "Error in update manager" [Low,Rejected]  http://launchpad.net/bugs/63645
<tfheen> is what he told me.
<tfheen> gnomefreak: oh, the bug with lots of bug reports in it, well I did tell him to file separate bugs for his issues.
<Kamion> tfheen: that's bug 64171
<Ubugtu> Malone bug 64171 in usplash "Colors look bad " [Medium,Confirmed]  http://launchpad.net/bugs/64171
<gnomefreak> he said he did but i have yet seen them
<Kamion> it's targeted to ubuntu-6.10 already
<tfheen> gnomefreak: some people seem to think that it's better to file one big report rather than a couple small ones, for some reason.  It isn't.
<tfheen> Kamion: ok, it wasn't this morning
<Kamion> gnomefreak: he says he's running edgy, not dapper, so it's not the above problem
<gnomefreak> Kamion: and tfheen im sorry this is 6.10 livecd that told him to upgrade before installing
<tfheen> gnomefreak: the desktop CD has the upgrade notifier disabled, so how he's "told" to upgrade I have no idea.
<gnomefreak> tfheen: i dont know either i wasnt sure if it was supposed to be a bug in casper or ubiquity
<Kamion> gnomefreak: his installer bug is some weirdo grub-installer crash that I won't pretend to understand, probably very hardware-specific
<Kamion> but he's already filed that separately
<gnomefreak> i told him to try install without upgrade first cause i wanted to see if it had anything to do with upgrading first
<gnomefreak> but he didnt
<funman> i'm having some problems with the installer of today's live cd
<funman> i try for the 3rd time, and i'll give you details
<Kamion> funman: is it complaining about execv() only taking string arguments, or something along those lines?
<funman> yep
<Kamion> funman: yeah, saw that myself, fixed in ubiquity 1.1.29
<funman> is there a patch i can use ?
<Kamion> hmm, give me a minute
<Kamion> funman: apply http://people.ubuntu.com/~cjwatson/tmp/ubiquity-r1639.patch to /usr/share/ubiquity/install.py
<funman> looks simple :/
<funman> plus, keyboard configurations aren't auto selected using the language setting
<Kamion> yeah, I know about that too, but it's a bit harder to fix
<funman> nor they are translated
<Kamion> not-translated won't be fixed for edgy I'm afraid, sorry
<funman> it's a large amount of data
<Kamion> we switched to a totally new keyboard configuration backend, which is better in almost all respects, except that it has no translation support for the layout or variant names
<funman> why not ask the translation teams ?
<Kamion> we'll just have to take that hit for edgy and fix it next time round
<Kamion> no *support*
<Kamion> not no translations
<funman> hmm ok
<Kamion> it's unfortunate, but there you go
<Kamion> not having the old console keymap nightmare is worth it
<funman> :)
<Kamion> if it had been for dapper, it would have been a different story
<funman> where is the code for keyboard selection ?
<Kamion> the keyboard thing is bug 60067; I've targeted it at ubuntu-6.10
<Ubugtu> Malone bug 60067 in ubiquity "Keyboard default choice should follows geographic localisation" [Wishlist,Confirmed]  http://launchpad.net/bugs/60067
<Kamion> funman: primarily in console-setup
<Kamion> it's a bit messy, it's a conflict between the use of console-setup on a normal system and its use in ubiquity
<Kamion> on a normal system, you want to go with what 'locale' says, but in ubiquity, that's not accurate and you need to grab the installer question
<Kamion> but switching the detection order round doesn't work either because normal systems may have debian-installer/locale in their debconf database but the value may be out of date
<Kamion> so I'm still pondering the right approach
<Kamion> there's one possible really gross approach - create /usr/lib/ubiquity/compat/locale which actually fetches the locale to use from debconf
<funman> i'm not used to debconf
<Kamion> well, it's just a database plus a simple protocol plus a few frontends for user interaction
<Kamion> in this case it's only its database part that's relevant - the installer sticks stuff like the selected locale in that database and expects other bits of the installer to retrieve it from there later on
<funman> i'm just viewing your page on launchpad
<funman> you work a lot! are you employed by Canonical ?
<tfheen> the "confirmed email address: cjwatson@canonical.com" kinda gives him away, eh?
<funman> well i didn't read all details ^^
<funman> hum i can't see it
<Kamion> yes, I am
<funman> wouldn't launchpad show these details if the user is seeing _his_ page ?
<Kamion> although maintaining a package that has a dialog that encourages people to file bug reports does rather boost my karma slightly artificially ;-)
<Kamion> I'm not sure I'd recommend that approach though
<funman> my page is still visible :(
<funman> i know they plan to implement a "Delete all my infos" button but they have a lot of work to do before
<Kamion> there may be some spam harvesting protection on the e-mail addresses
<Kamion> I don't know the details
<funman> hmm i when i plugged the alimentation of the hard disk, it smelled like grilled pig
<funman> i think the disk didn't like :/
<funman> *pouf* computer shutdown
#ubuntu-devel 2006-10-07
<Aladin> hi all, i have really no idea about linux and can only programm in python, but would be happy if there is any boring, easy thing i could do for the project
<jdong> I really am sick of waiting on bug 57872... If I prepare a debdiff would any core-devs here be willing to sponsor an upload?
<Ubugtu> Malone bug 57872 in gnome-power "regression: pressing power button no longer brings up logout dialog" [Unknown,Unconfirmed]  http://launchpad.net/bugs/57872
<crimsun> jdong: please get additional testers to confirm and to note their positive experiences
<jdong> crimsun: ok, will do
<Tonio_> is there a problem on the build system today ?
<Tonio_> I uploaded kipi-plugins yesterday, and I can see they have been built there https://launchpad.net/distros/ubuntu/+source/kipi-plugins/0.1.2-1ubuntu1
<Tonio_> but they haven't joined the repos...
<Seveas> Tonio_, it's down for maintenance
<Tonio_> Seveas: okay now I understand :)
<Seveas> see ubuntu-devel mailinglist
<Tonio_> Seveas: I'm reading this.... strange I missed that mail...
<Tonio_> hum, probably my antispam....
<Tonio_> Seveas: thanks for the info
<funman> jdong: i can test for you
<bddebian> Howdy
<Kamion> Tonio_: kipi-plugins was in the NEW queue due to the addition of kipi-plugins-doc. I've processed it now.
<Kamion> Tonio_: BTW, is there a good reason for kipi-plugins-doc to be Architecture: any? Looks like it should really be Architecture: all.
<Tonio_> Kamion: hum indeed... my falt on that point
<Tonio_> fault
<Tonio_> Kamion: want a reupload ?
<Kamion> Tonio_: whenever it's convenient
<Kamion> no rush
<Tonio_> Kamion: yeah sure, will probably do this tomorrow
<Kamion> ta
<ciphernemo> Is there a list of name brand PCs known not to install dapper? I need to add one if there is.
<mdke> I'm trying to get a simple target in a Makefile which just does a "cp" command, but when I run it, it returns "make: `book' is up to date." What is the problem?
<infinity> mdke: It means the file "book" exists.
<infinity> mdke: Makefile targets are files, if the file exists, it won't re-make it.
<mdke> infinity: ah!
<mdke> infinity: thanks
<mdke> changing the target name has worked
<infinity> You could also mark the target as a phony target, which would have a similar effect.
<mdke> I'm fine either way
<AlinuxOS> Hello, mjg59 ! I saw that 0.3 source code exists, but there is no .deb package yet ?https://launchpad.net/distros/ubuntu/+source/ttf-bpg-georgian-fonts/0.3  can you tell me what's the problem is ? Thank you.
<Hobbsee> AlinuxOS: because it failed to build.
<AlinuxOS>  edgy i386   Failed to build, Ah I saw this.
<Hobbsee> cp: cannot stat `./debian/ttf-bpg-georgian-fonts.conf': No such file or directory
<Hobbsee> from the build log
<AlinuxOS> I hope that mjg59 could fix it :)
<AlinuxOS> Hobbsee, thank you for info!
* Hobbsee wouldnt have a sponsor, even if she could upload it
<AlinuxOS> Hobbsee, she ? 
<Hobbsee> AlinuxOS: no, i'm a green, bug eyed alien.
<AlinuxOS> :D
<AlinuxOS> Hobbsee, I don't understand you, but it's ok! ;)
<Hobbsee> AlinuxOS: yes.  she.  
<tseng> hi Hobbsee 
<tseng> hello from Boston
<Hobbsee> hey tseng!  boston hey?  cool :)
<tseng> yeah
<StevenK> You're right, Boston is cold.
* Hobbsee wonders why boston.
<sivang> hey tseng :)
<tseng> hi sivang 
<kristog> tseng: hello
<tseng> hi
<kristog> tseng: say hello to daf :)
<bddebian> Howdy
<joejaxx> Kamion_: are you around?
<ed_> i am experiencing a mount issue using 2.6.18, i have used the .config from 2.6.15 that comes with dapper. mount reports that my xfs filesystem is already mounted or busy. there is nothing wrong with the filesystem as it mounts just fine using the kernel that comes with dapper. the filesystem is not mounted, it's not listed in /etc/mtab or /proc/mounts
<ed_> is anyone available who can suggest what might be wrong
<tseng> this isnt a support channel (see topic)
<tseng> we do not ship or support 2.6.18, sorry
<ed_> fair enough. i thought it might be a mount package problem
<bluefoxicy> Somebody ping me when GPLv3 is released and Debian Legal has a chance to go at it.
* bluefoxicy goes back to what he was doing.
#ubuntu-devel 2006-10-08
<funman> crimsun ?
<crimsun> funman: hi
<funman> i'm just looking at your mail
<funman> the fix is in 3 changesets
<funman> it was fixed by me, then i fixed my fix, and finally someone cleverer than me fixed the whole thing
<funman> :)
<funman> 16949, 16953, 16956
<crimsun> funman: thanks, I'll do that tonight
<popey> mjg59: ping
<mjg59> popey: Hi
<popey> hi, that MP-BIOS bug seems to be somewhat erratic
<popey> sometimes the machine boot fine, sometimes not
<popey> now it seems to be fine, tried warm and cold
<mjg59> Hm
<popey> also, don't know if it's related but the cpu frequency doofer in gnome claims that this cpu doesn't support frequency scaling
<mjg59> What is it?
<popey> core2duo
<mjg59> Ok, so that's clearly a lie
<mjg59> Can you pastebin your dmesg?
<popey> :)
<popey> yus
<popey> http://paste.ubuntu-nl.org/25928/
<mjg59> popey: What happens if you try to modprobe speedstep-centrino?
<popey> FATAL: Error inserting speedstep_centrino (/lib/modules/2.6.17-10-generic/kernel/arch/i386/kernel/cpu/cpufreq/speedstep-centrino.ko): No such device
<mjg59> And anything added to dmesg?
<popey> no
<mjg59> un
<mjg59> Fun
<popey> report bug?
<mjg59> Yeah
<Fujitsu> popey, you mean it fails to boot about 1 in 20 or 30 boots?
<popey> Fujitsu: yeah, possibly more frequently than that
<Fujitsu> I've got a Dell Inspiron 630m (PM 1.6GHz) that does the same, although it's not very frequent.
<popey> mjg59: what else shall I tack on the bug report besides dmesg? lspci -vv ?
<Fujitsu> But I have got frequency scaling.
<mjg59> popey: Nah, lspci isn't useful
<popey> ok, done, bug 64605
<Ubugtu> Malone bug 64605 in linux-source-2.6.17 "No frequency scaling on Core2Duo " [Undecided,Unconfirmed]  http://launchpad.net/bugs/64605
<popey> thanks mjg59 
<Hobbsee> BenC: you around?
<mjg59> Hurrah!
* mjg59 gets usplash working on amd64 nvidia
<ajmitch> excellent!
<_ion> What was the problem?
<mjg59> No idea
<mjg59> I've updated the x86emu code used
<mjg59> And now it seems happy
* Toadstool hugs mjg59 
<mjg59> Awh crpa.
* mjg59 pokes more
<mjg59> Grah.
<mjg59> So it /did/ work
<mjg59> And now it works no longer
<_ion> Ouch.
<mjg59> Damnit.
<mjg59> Clearly something I did at some point changed the state of the chip in some way
<_ion> Re: bug 64324, does usplash use svgalib on Macs?
<Ubugtu> Malone bug 64324 in usplash "usplash screen corrupted on old iBook" [Undecided,Unconfirmed]  http://launchpad.net/bugs/64324
<_ion> mjg59: Btw, the picture someone attached to bug 64624 is exactly what usplash looks like on my computer.
<Ubugtu> Malone bug 64624 in usplash "[edgy]  usplash corrupted" [Undecided,Unconfirmed]  http://launchpad.net/bugs/64624
<finalbeta> Edgy does spell checking in xchat 2. Will spell checking be available in more programs in the future as an operating system option? or does this remain an individual program choice? Can one change languages in the fly? Personally I have to use two all the time, and a third every X time.
<highvoltage> finalbeta: best to ask on #ubuntu
<finalbeta> It's edgy tech. But it's more a question as to where the dev team is going to take this.
<Treenaks> this is a channel about development, not user questions
<bddebian> Howdy
<highvoltage> howdy, bddebian!
<bddebian> Heya highvoltage
<Fade> quiet in here today.
<HiddenWolf> Fade: it's sunday, everyone with half a brain or half a life is taking a day off. :)
<funman> i guess we have none of both :/
<HiddenWolf> :)
* highvoltage neither
<Fade> HiddenWolf: heh. I wish I had both. ;) I'm stuck at werk today.
<smurf> cupsys bug: removing usb printer #0 hides any other USB printer you might have. Duh.
<HiddenWolf> Fade: ugh, nice job. :)
* Treenaks has his weekends off.. but still manages to write loads of code for his brothers website
<Treenaks> but now it's almost done \o/
<HiddenWolf> heh, write loads of code for mine too, pretty please? :P
<Fade> so this xemacs situation is seriously getting on my nerves.
<pepsiman> use gvim instead
<Fade> https://launchpad.net/distros/ubuntu/+source/xemacs21/+bug/57586
<Ubugtu> Malone bug 57586 in xemacs21 "XEmacs segfaults on startup in Edgy" [Undecided,Unconfirmed]  
<Fade> I think that should be confirmed. reported on two arches now. :(
<tortoise_> onboard has just been put into main but unfortunately a dodgy revision was picked up from bzr that has loads of bugs.  Is there any way this can be updated before release?
<Burgundavia> tortoise_: file a bug against it
<sivang> tortoise_: and I'd also say subscribe ubuntu-core-dev team
<tortoise_> Burgundavia sivang: ok
<tortoise_> Burgundavia: What do I file a bug against? If i file it against onboard only I get notified an I can't do anything about it
<Burgundavia> tortoise_: against onboard. If ou cannot file a bug against it, file a bug against Malone about not being able to file a bu
<tfheen> sivang: no, don't subscribe ubuntu-core-dev.
<sivang> tfheen: oh, oops sorry 
<sivang> tfheen: I just noticed the maintainer is 'ubuntu-core-dev'
<tfheen> tortoise_: please file a bug against onboard and tell me the bug #.  I'll target it for 6.10 so we'll pick it up.
<sivang> tfheen: so my poor reasoning followed
<tortoise_> tfheen: thnaks
<RicardoPerez> doko: ping
<sivang> tortoise_: fixing this would be as simple as pulling latest branch into the ubuntu package?
<tortoise_> sivang: yep
<tortoise_> revision 38 from http://bazaar.launchpad.net/~onboard/onboard/main
<sivang> hi ivoks 
<ivoks> hi
<sivang> ivoks: did you manage to have a connection with pygi?
<ivoks> i didn't spoke with him for couple of days
<sivang> ivoks: are you able to text him?
<ivoks> no :/
<sivang> ah, I see never mind, thanks anyway
<ivoks> what's the problem?
<sivang> :)
<sivang> ivoks: we're having issue swith spammers spamming all over libburn in trac
<ivoks> :)
<tortoise_> tfheen: https://launchpad.net/distros/ubuntu/+source/onboard/+bug/64736
<sivang> ivoks: I suggested switching to LP, and some other devs suggested other login protected solutions. bottom line, we need to talk to him to see what he says.
<Ubugtu> Malone bug 64736 in onboard "Bad revision picked up from bzr - many bugs" [Undecided,Unconfirmed]  
<sivang> tfheen: I can probably do this "fix", will it require UVF or so ?
<ivoks> sivang: i think he'll be ok with LP, but, of course, you should contact him
<sivang> ivoks: indeed.
<tfheen> sivang: I'd prefer to have Henrik's input on it, actually.
<sivang> tfheen: okay, sure.
<Fade> tfheen: I have a workaround for that xemacs bug.
<tfheen> Fade: oh?
<Fade> the fact that it segfaults is an upstream bug, but basically it was dying due to font resolution.
<Fade> reordering the font loadpaths in xorg.conf works around the problem.
<Fade> I think this might be related to defoma, but if the xorg.conf has been brought forward from an older ubuntu installation, the font lines in the configuration file cause a bunch of applications to have conniptions.
<Fade> in xemacs' case, it results in a segfault, but it also fixes the GNU emacs problem I tied to that bug report. I'll add another comment to my bug when I get back from dinner.
<dtamas> hi! I just want to know, when will firefox 2.0b update to rc2? or it will be change to iceweasel?
<dtamas> where can i get answer to this question?
<gnomefreak> dtamas: i doubt it will be before release but i cant answer that for sure
<dtamas> ok, thanks
<windshear_> hello
<windshear_> i have a problem with the kernel, it hangs on the first time after shutdown that i try to boot,   the second try works
<windshear_> i've removed the quite splash option from the kernel
<windshear_> i can now see that it hangs at usb 3-2: usb disconnect, adress 3
<windshear_> anyone know why I always have to try 2 times to be able to boot?
<robertj_> would patches be accepted that allowed gksu & friends to use the keychain?
* robertj_ looks at updatemanager sorely
<probono> hi all, i'd like to bring your attention to bug # 59779 - the solution is stated there as well but i don't know who would need to take action to implement the solution
<probono> https://launchpad.net/distros/ubuntu/+source/casper/+bug/59779
<Ubugtu> Malone bug 59779 in klik "Loop-mount doesn't work on Live CD (Casper)" [Undecided,Unconfirmed]  
<gnomefreak> probono: the people that need to know know about it he even replied to the bug
<probono> gnomefreak, thank you
<gnomefreak> yw
<mjg59> Right. usplash palette issue sorted
* HiddenWolf hugs mjg59
<HiddenWolf> unless I'm mistaking you did that in your off-hours. :)
<mjg59> "off-hours"?
<mjg59> You realise I don't work for Canonical, right? :)
<HiddenWolf> You don't? *feels reality hit with a thud*
<HiddenWolf> You do so much work, I just assumed. :)
<mjg59> The only time I have to work on this stuff is my off-hours...
<HiddenWolf> Still, messing with usplash on a sunday-night deserves a hug. Doubly so now. :)
<zul> ...or a beer
<mjg59> Bleah. Right, dapper kernel doesn't magically make X start working again.
<mjg59> (over suspend/resume)
<HiddenWolf> zul: beer-over-irc protocol isn't yet perfect. I wouldn't want to get freenode wet.
<mjg59> Hrm.
<mjg59> Reinstalling this machine would be awkward.
* mjg59 goes to find another scratch laptop
#ubuntu-devel 2007-10-01
<jdong> can an apparmor god explain what "kw" is in permissions?
<jdong> I can't find a manpage for "k"
<jdong> in the documentation I've consulted...
<Kmos> jdong: https://bugs.edge.launchpad.net/edgy-backports/+bug/141181 -> can you check this one ?
<ubotu> Launchpad bug 141181 in edgy-backports "Please backport ddclient" [Undecided,New] 
<jdong> Kmos: in the middle of something currently, can you e-mail me with these bugs?
<Kmos> jdong: ok =) thx
<Kmos> cya
<pwnguin> jdong: i dont even seem to have apparmor running =/
<jdong> pwnguin: aww well you should.... it's pretty nice for some things, like I just wrote some profiles for my irssi client and such
<jdong> pwnguin: I don't trust my perl abilities not to have a few shell injection capabilities ;-)
<pwnguin> jdong: i thought it was installed by default
<jdong> it is...
<pwnguin> jdong: perhaps its not enabled by default on an upgrade?
<jdong> it should be
<pwnguin> or perhaps it conflicts with something else i have
<jdong> pwnguin: it's not running and spewing cupsd denied messages into dmesg?
<pwnguin> nope
<CarlFK> someone wana help me collect info for a bug report on gutsy alt installer?  (cuz all I got is "FATAL: Could not load /lib/modules/2.6.22-12-386/modules.dep: No such file or directory" and "can too!")
<jdong> pwnguin: hmm playing with apparmor a bit more... and BOY! is skype curious!
<jdong> it traverses down all of ~/.mozilla recursively, and also requests to see /proc/1/cmdline for some reason?
<Amaranth> jdong: why would it want to know what init is in use?
<Amaranth> it's all /sbin/init, no?
<jdong> Amaranth: I have no clue
<jdong> Amaranth: why would it want to open mode "r" all of my ~/.mozilla files either?
<jdong> when skype AFAIK has no web browsing functionality?
<Amaranth> it's looking for the skype firefox extension
<jdong> Amaranth: ah, interesting...
* jdong writes better rule then...
<jdong> so it needs to be able to traverse down /home/*/.mozilla/**/
<dobey> it might also parse the cookies?
<jdong> dobey: I don't see how tha'ts any of skype's business though
<ion_> It might also send anything interesting from ~/.mozilla/** to interested parties. :-)
<jdong> ion_: lol call me paranoid but I am worried it wants something with my history and cookies :)
<jdong> is there some way of writing an apparmor rule in "inverse"
<dobey> jdong: well, the only way to share cookies is to look in each browser's directory for where it stores cookies, currently
<jdong> like allow everything in .mozilla.... EXCEPT bookmarks.html, etc
<dobey> so basically, deny everything in .mozilla :)
<jdong> lol
<jdong> deny almost everyhing ;-)
<pwnguin> someone else was pointing out that skype was hitting /etc/shadow
<pwnguin> a while back. i donno what that was
<pwnguin> or maybe it was /etc/passwd
<pwnguin> shadow'd be a much scarier thing i think
<superm1> pwnguin, yeah there is a post on the skype forums about it
<superm1> really i dont see a big deal with hitting /etc/passwd.  It's world readable, so why not.
<dobey> probably because it grabs your real name or something from /etc/passwd
<dobey> there's nothing wrong with hitting /etc/passwd
<dobey> plenty of gnome/kde already do it
<dobey> getpwnam ()
<dobey> srsly
<holycow> the problem really is that its closed source and you can't check WHY its doing all of that
<dobey> well
<dobey> you can ltrace the app
<dobey> and it should show getpwnam () or whatever
<dobey> which would give you more clue than "omg! it's opening /etc/passwd!"
<dobey> :)
<jdong> pwnguin: it only hits /etc/passwd, which is not all that abnormal for something that even does a ls -alh
<jdong> [114990.104000]  audit(1191199733.820:5567):  type=1503 operation="inode_permission" requested_mask="r" denied_mask="r" name="/proc/1/cmdline" pid=20237 profile="/usr/bin/skype"
<jdong> ^^ that's the last thing I'm REALLY puzzled about
<holycow> well if you read up on how skype works ... you'd also note that they already do some shady things to make it just work
<holycow> for example to bypass nat types of situatios they exploit a flaw in an rfc of some sort, i forget which one but it has to do with how udp packets are handled
<holycow> to establish a 2 way connection outside of the nat
<holycow> its pretty clever actually ... some clever people created this product
<jdong> holycow: ah the classic person A hammers person B's UDP port, person B hammers person A's udp, in a manner agreed by the two hosts via a 3rd party (skype server) :)
<jdong> and soon enough NAT is tricked into thinking it's an established route
<holycow> jdong: acutally that sounds exactly what i read about
<dobey> heh
<holycow> jdong: right exactly
<jdong> yep, it's a neat trick :)
<dobey> if the hammer doesn't work... use a bigger hammer.
<jdong> AFAIK if you mirror the two source-port/dport pairs correctly (one host is mirror of the other) it's brain-dead easy to punch through
<holycow> it was a bit eye opening reading that indeed
<jdong> some torrenting DHT implementations do the exact same thing
<holycow> makes me want to block all udp traffic
<holycow> heh
<jdong> holycow: meh what services do you run over UDP though? :)
<holycow> nothing actually :)
<holycow> good poitn
<jdong> exactly
<jdong> if you did, then it'd behoove you to run a simple iptables firewall on the host with a basic allow-local-subnet, block-everything-else rule
<StevenK> Can someone please give-back gimp on i386?
<holycow> StevenK: say what?
<StevenK> holycow: The i386 builder that was building gimp had a few issues. gimp has apparently been currently building on verdansky for 12 hours
<fabbione> morning
* jetscreamer waves goodbye
<bddebian> Heya fabbione
<pwnguin> +#include <acl/libacl.h>
<pwnguin> any ideas on where to find the package i need to depend on to get that?
<StevenK> pwnguin: libacl1-dev
<pwnguin> hmm. searching apt-cache for libacl is much shorter than just acl =/
<fabbione> pwnguin: http://archive.ubuntu.com/ubuntu/dists/gutsy/Contents-i386.gz
<fabbione> pwnguin: zcat that file |grep "fileyouwant"
<pwnguin> surely i have a local cache of that?
* Hobbsee waves to fabbione
<fabbione> pwnguin: no you don't
<fabbione> hey Hobbsee
<pitti> Good morning
<Hobbsee> pitti!
* pitti hugs Hobbsee 
* Hobbsee hugs pitti
<dholbach> good morning
<Hobbsee> morning dholbach!
<dholbach> hey Hobbsee
<ion_> Hi
<pitti> hi ion_
<superm1> morning dholbach
<dholbach> hey superm1
<superm1> how are you doing?
<dholbach> good good - how are you?
<superm1> i'm a bit agitated.  we were planning on announcing our mythbuntu beta disks on friday, but have bug 144043 and bug 144395 affecting our builds really poorly unfortunately
<ubotu> Launchpad bug 144043 in linux-ubuntu-modules-2.6.22 "kernel BUG at /build/buildd/linux-ubuntu-modules-2.6.22-2.6.22/debian/build/build-generic/fs/unionfs/inode.c:1057!" [Undecided,Confirmed]  https://launchpad.net/bugs/144043
<ubotu> Launchpad bug 144395 in linux-ubuntu-modules-2.6.22 "unionfs oopses for http processes" [Undecided,New]  https://launchpad.net/bugs/144395
<superm1> so ubiquity is tending to randomly stall :(
<dholbach> oh :-/
<superm1> i'm at a loss still how the normal gutsy beta disks weren't affected as badly as we were
<Hobbsee> keescook: ping
<Hobbsee> argh, dammit!
* Hobbsee hit a, not s.
<Mithrandir> did the world implode?
<Hobbsee> (apologies to the readers of ubuntu-devel ML)
<Hobbsee> no
<carlos> pitti: did your script find the language pack update exported Saturday night?
<pitti> carlos: oh, I didn't change the cron jobs yet
<pitti> carlos: will adapt them today
<carlos> pitti: the update export took around 43 minutes
<carlos> so I don't expect it to be a problem like the full export was
<pitti> carlos: for updating the cronjobs, can you please give me a current table of when the export happens for which release?
<carlos> sure, let me look for the cron tasks scheduled I sent to Stuart...
<siretart> morning folks!
<dholbach> hey siretart
* siretart hugs dholbach :)
* dholbach hugs siretart back
<\sh> moins
<siretart> yay. cryptsetup works with UUIDs as well :)
<pitti> siretart: !
<siretart> pitti: the trick is this: not the 'pseudo' block device must be uuid'ed, but the real device. and that one is the 2nd column in /etc/crypttab, and not the one in /etc/fstab
<siretart> pitti: I'm going to upload a new partman-crypto right now
<pitti> ah, cool
<siretart> I'm not sure if we should bother to convert existing volumes
<pitti> I didn't know that crypttab would support uuids
<siretart> I just tested it by entering that manually and just booting it
<siretart> :)
<siretart> [and yes, I did recreate my initramfs and checked that it actually uses uuids] 
<siretart> pitti: I'm just not sure if we should bother converting existing crypttabs
<siretart> since we haven't supported cryptsetup before, and can therefore assume that existing users are competent enough to fix potential breakage themselves
<Mithrandir> siretart: don't.  They contain a human-generated name, so we can reasonably expect that to be unique on a host.
<Mithrandir> same as for LVM
<siretart> Mithrandir: I take that as "don't convert existing /etc/crypttab", right?
<Mithrandir> siretart: correct
<siretart> that would be my guess as well
<pitti> right, that would be too hackish
<Mithrandir> siretart: or are you meaning the source device rather than the target name?
<pitti> siretart: if it just touches partman, then we won't break upgrades, and new installations will DTRT
<siretart> Mithrandir: I'm only talking about the "source device". the "target name" must be consistent in /etc/{fs,crypt}tab
<Mithrandir> siretart: the source device should be converted, unless it's unique already.
<Mithrandir> siretart: and the target name does not have to be consistent.
<Mithrandir> backup-crypt /dev/disk/by-id/md-uuid-30859f04:dcfabcf1:60f4d120:ee3978a4 /var/local/backup-lukskey luks,checkargs=ext2 in crypttab
<Mithrandir> UUID=299178d5-99c5-482e-a807-c073ead853f1 /backup       ext3    defaults       02
<Mithrandir> in fstab
<Mithrandir> works fine.
<siretart> pitti: it touches partman-target (which should mangle the target name in /etc/fstab), udev (volumeid.postinst, to not mangle the "target name" in /etc/fstab, both already uploaded) - and partman-crypto, to mangle the "source device"
<siretart> Mithrandir: for root on cryptofs,  the "target name" must be consistent in /etc/{fs,crypt}tab
<siretart> else the cryptroot hook in initramfs will break
<siretart> pitti: what's left is the partman-cryto upload, which I'm about to upload right now
<Mithrandir> siretart: that might be; I'm just doing encrypted raid.
<siretart> Mithrandir: I investigated that issue last thursday and friday
<siretart> by reading the crypyroot hook and partman-crypto
<Mithrandir> siretart: anyway, that sounds like an issue which should be fixed, and which is fairly easy to fix too?
<siretart> they are coded with that assumption in mind
<siretart> Mithrandir: right, I have the fixes already ready and uploaded
<siretart> partman-crypto pending ACCEPTance right now
* pitti hugs siretart 
* siretart hugs pitti back :)
<siretart> there is a very tiny visual issue left: the "target name" is named like 'sda5_crypt'.
<pitti> i. e. although it is just a name, it will get confusing if it isn't on sda any more
<siretart> in the case sda5 is named hda5 back or something, this would be a bit confusing, but won't break anything, since this is only the 'virtual target name'
<siretart> right
<fabbione> cjwatson: i think something is wrong the tasks in the archive. server netinstall fails with:
<fabbione> Oct  1 07:21:40 in-target: E:
<fabbione> Oct  1 07:21:40 in-target: Couldn't find task ubuntustudio-desktop
<fabbione> Oct  1 07:21:40 in-target:
<fabbione> Oct  1 07:21:40 in-target: tasksel: aptitude failed (100)
<fabbione> no tasks selected at all
<fabbione> just plain install
<pitti> .. studio??
<fabbione> yeps.. this is on sparc, and reproducible at will
<pitti> hey seb128
<seb128> hello pitti
<pitti> calc_, seb128: FYI, I'm putting back ooo-{base,evolution}
<seb128> ok
<kagou> good morning
<seb128> lut kagou
<pitti> calc_: however, that'll oversize the alternates again; maybe there are some more points on my 'recent OO.o growth reasons' list which can be reverted?
<kagou> hey seb128 , pitti
<pitti> moin kagou
<seb128> mjg59: could you try to ping somebody from the desktop team before uploading desktop packages? Your gnome-control-center upload conflicts with a 2.20.0.1 which was almost ready to be uploaded
<StevenK> pitti: Morning!
<pitti> hey StevenK, how are you?
<mjg59> seb128: Ah, sorry about that
<StevenK> pitti: Would you mind giving back gimp on i386? It looks like vernadsky choked on it.
<mjg59> seb128: I noticed it while doing hotkey-setup fixes and wondering why the video stuff wasn't working
<seb128> mjg59: that's alright, merging your change now ;)
<pitti> StevenK: currently building already
<seb128> mjg59: I think the 0xaa value came from Keybuk
<StevenK> pitti: Yes, but it's listed as building on vernadsky, and apparently has been for 20 hours. And vernadsky is showing as not available on the +builds page.
<pitti> oh, that
<StevenK> Hence the vernadsky choking on gimp. :-)
<pitti> StevenK: sorry, we need infinity or cprov for that; "Cancel current job" does not work in the UI
<StevenK> pitti: Ah, right. Hopefully your mentioning them will get them to see what you said. :-)
<kwwii> pitti: I have an updated wallpaper package (99% likely that this is the final change), could you take a look?
<mjg59> seb128: Yeah, we had the wrong one set at one poitn
<kwwii> pitti: the default wallpaper file size is some 90kb larger than the previous - no way to avoid that without loosing quality though
<pitti> kwwii: sure, can you please put the source package somewhere?
<pitti> kwwii: yeah, not being able to use jpeg sucks, but we can't help that now
<pitti> kwwii: NB that the next alternates are oversized again (I just added ooo-base back)
<ion_> Not being able to use JPEG why?
<pitti> due to some weird 'warty-bla.png' hardcoded gconf value
<kwwii> http://sinecera.de/gutsy-wallpapers_0.17.tar.gz, http://sinecera.de/gutsy-wallpapers_0.17_source.changes, http://sinecera.de/gutsy-wallpapers_0.17_source.build, and http://sinecera.de/gutsy-wallpapers_0.17.dsc
<ion_> Filenames are for humans, not computers. :-) Have you tried whether gnome-desktop is as stupid as to not load a JPEG image called foo.png?
<pitti> heh, that might actually work
<kwwii> pitti: I already suggested that to dholbach but his comment that that is quite a hack is right
<dholbach> kwwii: I think we can drop feisty-session-splashes, right?
<dholbach> kwwii: we don't use a splash screen atm
<ion_> kwwii: As long as gnome-desktops image loader is not stupid, the only problem is that a human might think its a PNG based on the filename.
<dholbach> I think soren found another problem with it
<soren> dholbach: Hm?
<dholbach> seb128: it should be OK to drop the feisty-session-splashes now (at least not have ubuntu-artwork depends on it)
<ion_> For software, a plain list of inodes would be sufficient to find data, filenames *only* exist for humans. :-)
<soren> dholbach: Ah, the png/jpg thing?
<dholbach> soren: the "rename the .jpg to .png" trick
<pitti> kwwii: ok, I wait a bit with the upload until this discussion settles
<soren> dholbach: Yeah, stupid eog tries to do magic things if the file is called .jpg..
<cjwatson> fabbione: oh, meh, ok, I'll figure out a fix
<fabbione> cjwatson: thanks a lot
<soren> dholbach: Probably to extract EXIF info or something.
<kwwii> dholbach: yes, we can drop it, afaik
<ion_> I can understand guessing the MIME type based on the filename on remote directories, but theres no reason not to read the file header on local HDDs on todays hardware.
<dholbach> Installed-Size: 148
<dholbach> Size: 82582
<soren> dholbach: Or is it the other way around? I forget. ANyhow, it doesn't work properly which could cause problems if users happen to be using nautilus or eog to browse around in /usr/share/backgrounds :(
<dholbach> yeah :-/
<soren> dholbach: It's a bug in eog more than anything else, though.
<soren> dholbach: It shouldn't be relying on extensions for anything.
<dholbach> *nod*
<Mithrandir> we could, like, fix it.
<dholbach> pitti: I dropped the depends on feisty-session-splashes; we can demote it to universe soon
<soren> Mithrandir: Are you volunteering? :)
<Mithrandir> soren: no. :-)
<pitti> dholbach: where? gutsy-wallpapers doesn't have this dep?
<ion_> soren: Indeed.
<dholbach> pitti: from ubuntu-artwork
<pitti> ah
<dholbach> also, I fixed http://daniel.holba.ch/sponsoring to respect subscriber and assignee and filter out people that are not in motu/ubuntu-core-dev
<dholbach> that way I can subscribe people to bugs and people won't think "oh this is assigned to <person>, I better not touch it any more"
<calc_> pitti: ok, i'm waiting on translations from carlos and then i'll be doing another upload, hopefully in the next day or two
* calc_ notes he should probably be in bed about now
<pitti> calc_: oh, I didn't expect you to be awake at this hour :)
<pitti> calc_: did you find anything else to size down?
<calc_> pitti: not yet :(
<calc_> pitti: we might gain a little bit when i drop portaudio v19 but i think they are just going to pull v18 back into main so not sure how much that will help
<pitti> calc_: no chance either to drop libhsqldb-java and/or libxalan2-java+libxerces2-java?
<TheMuso> cal/c
<TheMuso> calc_: I don't think there is much of a difference between pa19 and pa18
<calc_> TheMuso: oh ok
<dholbach> calc_: bug 135086?
<TheMuso> We'll save 4MB only it seems, or there abouts.
<ubotu> Launchpad bug 135086 in unzip "zipgrep: exit code always 0" [Unknown,Confirmed]  https://launchpad.net/bugs/135086
<calc_> dholbach: i'll try to get to that later today
<dholbach> thanks calc_
<pitti> TheMuso: "only"? 4 MB is great
<calc_> TheMuso: save 4mb by going back to pa18
<calc_> TheMuso: that is huge if so
<TheMuso> calc: This is only going on actual package size, not installed size.
<calc> TheMuso: so 4MB compressed then?
<dholbach> Riddell: bug 136425? pitti: bug 139671?
<ubotu> Launchpad bug 136425 in qt4-x11 "qtconfig-qt4 in Accessories?" [Undecided,Confirmed]  https://launchpad.net/bugs/136425
<ubotu> Launchpad bug 139671 in hal "hal-device-manager window should be titled "Hardware Information"" [Undecided,In progress]  https://launchpad.net/bugs/139671
<calc> yipee! :)
<pitti> TheMuso: how, though? the external libportaudio is tiny
<pitti> dholbach: meh string freeze meh
<dholbach> soren: what do you think about the change in bug 138181?
<ubotu> Launchpad bug 138181 in network-manager-openvpn "Network Manager's openvpn plugin doesn't respect DHCP's domain setting." [Low,Fix committed]  https://launchpad.net/bugs/138181
<TheMuso> pitti: yeah as I said, I haven't done a thorough check.
<dholbach> pitti: then best to milestone it as 'later'?
<dholbach> pitti: just let the patch author know and I'll unsub u-m-s
<pitti> dholbach: it's assigned to me now anyway, so unsub'ing is fine
<calc> pitti: looks like it might only be 40KB difference
<dholbach> pitti: thanks
<pitti> done
<pitti> calc: right; I'm still hoping we can get rid of above java deps; they haven't been there in tribe 5, and they would save 5 MB
<calc> i think i may be wrong that the java deps weren't in tribe 5 because java was completely disabled
<calc> which breaks among other things ooo base
<soren> dholbach: I've got the network-manager-openvpn on my TODO list for today anyway. I'll be looking at it a bit later.
<dholbach> soren: rock on
<soren> ;)
<calc> pitti: i'll try to find out to what extent not having the java stuff breaks base for each package
<calc> pitti: but i know base uses a lot of java stuff for it to work pretty much at all
<cjwatson> calc: I'm beginning to think the right answer is simply to remove -base from the CDs
<pitti> heh, I was just about to ask for the same
<pitti> cjwatson: we did that for beta in fact
<calc> cjwatson: could be, of course bits of base are used by writer, but for the most part writer functionality would be ok
<cjwatson> wouldn't it be better to have a really good -base downloadable from the network than a neutered one on the CD? it doesn't really seem like a core feature
<calc> cjwatson: yea
<cjwatson> calc: in what circumstances are they used?
<calc> cjwatson: it breaks a few things in writer if base isn't installed like for mail merges, and bibliography.. probably some other things i don't know of off the top of my head
<cjwatson> it would be useful to know what writer says when that happens
<pitti> calc: does that tell the user to install -base? or does it just crash or something?
<cjwatson> e.g. "error code c182734" vs. "please install -base"
<calc> cjwatson: it just doesn't work, no error from what i recall
<TheMuso> pitti: So if OOo goes back to pa18, what do we do now to get it back into main, so that an espeak upload can use it?
<calc> cjwatson: upstream believes in having everything always installed :\
<pitti> TheMuso: I don't mind much which pa version is in main, I just don't want both
* calc purges base locally to look around
<pitti> TheMuso: once you two decide which one you want/need, I can promote/demote
<TheMuso> pitti: As you said in the bug report. I'm just wondering what we do now.
<pitti> TheMuso: do you need 18 for espeak, or doesn't it matter?
<pitti> calc: does OO.o work better with portaudio18? or is 19 ok?
<calc> actually without base trying to use bibliography crashes ooo
<calc> pitti: before i turned on v19 support ubuntu wasn't using it at all, so not sure
<calc> pitti: i was going to just turn it back off
<cjwatson> calc: I think it would be a good use of time to try to fix that
<TheMuso> pitti: As I explained in 140673, espeak works with 19, but theres something wrong with 19, causing speech to be cut off, and espeak to freeze.
<cjwatson> we're going to need to be able to split OOo up, either now or in the future
<TheMuso> bug 140673
<ubotu> Launchpad bug 140673 in espeak "Espeak + portaudio v19 causes undesirable lock-ups." [Medium,Confirmed]  https://launchpad.net/bugs/140673
<nrdb> Hi, I have been looking into the initrd of 7.04, I notice that the mount point for the 'root' filesystem seems to be '/root', is this correct ?  when is this changed to '/' ?
<pitti> TheMuso: and it does need libportaudio in the first place? doesn't work with alsa, or so?
<calc> cjwatson: i don't know that those are the only two things that break with -base removed but those are the first two i have found
<cjwatson> nrdb: that's correct. /init chains to the real root filesystem as its last action
<seb128> TomaszD: the template not updates are not all due to missing Build-Depends on intltool
<TheMuso> pitti: Since espeak is cross-platform, it uses portaudio and portaudio only.
<pitti> ah
<Amaranth> TheMuso: is that my bug?
<TheMuso> Amaranth: the espeak + portaudio bug? No.
<Amaranth> dang, i'd really like to be able to use orca to test stuff :)
<TheMuso> Amaranth: That is if you refer to 140673.
<nrdb> cjwatson: I presume its the executable 'run-init' that does this ?
<cjwatson> nrdb: yes
* calc goes back to bed, bbl
<nrdb> cjwatson: so if I want a unionfs as my 'root' I would pass the mount point of the union to 'run-init' ?
<pitti> calc: FYI, giving back OO.o on sparc/powerpc; stumbled over the udev postinst error, apparenlty
<cjwatson> nrdb: yes
<cjwatson> nrdb: exactly as the live CD does in fact
<nrdb> cjwatson: thanks for the help :)
<nrdb> cjwatson: I have been looking at what the LiveCD does, but there is a lot of stuff done by the casper scripts, and I wanted to understand more before I fiddled with the script any more.
<pitti> LongPointyStick: you sponsored a new evolution-sharp upstream release which breaks ABI (new soname) for mruiz; the changelog does not mention a FF exception bug; who will take care of fixing the reverse dependencies? I will keep this in the NEW queue until someone uploads fixed beagle and gfax
<pitti> LongPointyStick: (or reverts the package to the older version)
<TomaszD> seb128, aren't those I've reported ?
<seb128> TomaszD: what do you mean?
<TomaszD> seb128, aren't those issues I've reported caused by the missing build-dep?
<seb128> TomaszD: like the rhythmbox issue is not a missing Build-Depends on intltool, if you look at the build log you will notice that intltool-update is called correclty
<seb128> TomaszD: no
<TomaszD> alright, I'll keep that in mind. Where can I see those build logs?
<seb128> on launchpad
<seb128> go to package page, the overview tab
<seb128> click on the version you want
<TomaszD> seb128, I see now
<TomaszD> seb128, what about gnome-screensaver then?
<TomaszD> duh, I'll look at the build log :] 
<TomaszD> "echo 'langpack.mk: po/Makefile* mentions intltool, but intltool-update is not available'; "
<TomaszD> so I think I was right there
<TomaszD> yep, pretty sure it's a missing intltool build-dep there
<TomaszD> cool stuff this build log
<TomaszD> alright, no more bogus reports from me then
<TomaszD> it's the same with serpentine
<pitti> seb128: bah, shall I just add intltool as a cdbs build dep?
<seb128> pitti: I'll do it, I've an another small change to do
<seb128> pitti: cdbs Depends you mean, right?
<pitti> seb128: right (note that cdbs is in bzr)
<seb128> (ok)
<TomaszD> If you guys have some time, this is my pet peeve https://bugs.launchpad.net/ubuntu/+source/gnome-panel/+bug/147278
<ubotu> Launchpad bug 147278 in gnome-panel "[gutsy]  tooltip of workspace switcher doesn't pick up translations" [Undecided,New] 
<highvoltage> soren: congrats on being core-dev!
<soren> highvoltage: \o/ Thanks!
<pitti> siretart, cjwatson: partman-crypto-loop moved back to main; I'll test tomorrow's daily alternate
<seb128> TomaszD: we got like 100 new desktop bugs during the WE so that will take some time
<siretart> pitti: err, how das partman-crypto-loop work? I haven't used/looked at it yet
<TomaszD> seb128, sure, I understand.
<pitti> siretart: er, I mean partman-auto-crypto
<siretart> ah
<pitti> carlos: one q: when the cronjob automatically fetches and updates gutsy/PPAs, how to tell the rosetta UI? (it currently says 'unused')
<soren> Have you guys ever experienced the initramfs getting cut short?
<carlos> pitti: right now, you need to tell jtv, danilo or me
<pitti> carlos: hm, twice a week/
<pitti> ?
<carlos> pitti: I hope that at the end of october, we will get it automatically once buildd finish processing your upload
<carlos> pitti: well, it should be done only when you upload your packages to the public archive
<carlos> PPAs doesn't count for that
<pitti> carlos: something like appending "&& mail -s "gutsy delta pack uploaded" carlos@ubuntu.com" after the dput? :)
<carlos> pitti: that's enough, yes, I don't expect you to ping us on IRC each time :-P
<pitti> ok
<carlos> pitti: but use rosetta@launchpad.net, please
<pitti> carlos: ok, I'll include the version into the mail
<pitti> and that
<carlos> pitti: thank you
<carlos> pitti: but remember, only for published packages in the archive
<pitti> right
<TomaszD> carlos, pitti, hi. I was just wondering about the r-m not having any translations issue. Have you figured it out yet? "Launchpad does export that translation. The problem should be in the process that generates the .deb packages based on the tar.gz we export."
<Nafallo> mjg59: my Lenovo R61 doesn't have laptop-mode enabled when I unplug AC. is that a bug? (powertop just told me about lots of things I would have supposed happened automagically)
<pitti> TomaszD: no, I had hoped that the last langpacks would include it
<carlos> pitti: launchpad exported those translations
<carlos> I already checked it
<mjg59> Nafallo: No, it's not a bug
<carlos> pitti: so seems like they are lost in the process to create the .deb package
<mjg59> For reasons we're still entirely unclear on, it seems to cause hangs on some systems
<TomaszD> pitti, the 20070928 langpack doesn't contain the translation
<ion_> nafallo: Have you turned it on in /etc/default/laptopsomething?
<Nafallo> mjg59: ouch :-/. yet another whitelist or blacklist needed?
<mjg59> No, it needs fixing
<pitti> carlos, TomaszD: ah, I see; my package classificator only reads main/source/Sources.gz, will fix that
<Nafallo> ion_: not there.
<Nafallo> oh. there is is...
<Nafallo> in acpi-support
<TomaszD> pitti, THANK YOU! One of the last loose ends in gutsy's translations
<carlos> pitti: ok, thanks
<ion_> Ah, right.
<Mithrandir> mjg59: any particular reason for libusplash-dev not to ship a shlibs file?
<mjg59> Incompetence on my part?
<Mithrandir> heh, I'll fix
<ion_> nafallo: You also need to restart /etc/init.d/laptop-mode after enabling it for the power event scripts to do anything.
<Nafallo> ion_: cheers
<mjg59> ion_: No
<ion_> mjg59: Hm, ok. I had a memory of the script creating some file in /var/run, without which the laptop-mode script doesnt do anything. I was probably wrong, then.
<Nafallo> mjg59: . /etc/default/laptop-mode < deprecated?
<mjg59> Yes
<Nafallo> thought so :-)
<Nafallo> laptop-mode status looks kinky :-)
<mjg59> Just ignore the laptop-mode command
<mjg59> We've hacked it to small pieces to make it plausibly sane, but it's still utter crack
<Nafallo> ehrm. I'm starting to believe in that :-P
<fabbione> cjwatson: thanks for the fix on tasksel
<cjwatson> np
<pitti> carlos: https://translations.launchpad.net/ubuntu/feisty-updates/+latest-delta-language-pack does not work
<pitti> carlos: and neither s/feisty-updates/feisty/
<pitti> carlos: ah, is that because https://translations.edge.launchpad.net/ubuntu/feisty/+language-packs does not list any exported delta packs?
<carlos> pitti: right
<carlos> you will need to wait until their slot this week
<carlos> so they are generated
<pitti> carlos: but /feisty/ is right, not /feisty-updates/ ?
<carlos> pitti: is feisty, not feisty-updates
<cjwatson> mvo: I'm changing debconf so that it doesn't break if some random python module won't compile
<cjwatson> mvo: with any luck that'll get rid of a class of upgrade failures
<cjwatson> or at least make them a lot less severe
<mvo> cjwatson: that sounds good
<pitti> carlos: hm, but shouldn't the dapper export have happened last night?
<carlos> pitti: no, it's scheduled for tonight
<sladen> off-by-one-error
<pitti> 00 22 * * 1
<pitti> isn't that Monday?
<pitti> oh, ignore me
<pitti> I thought that was 0:22, not 22:00
<carlos> pitti: :-P
<carlos> pitti: if you want to change the schedule, just tell me it
<carlos> we are flexible and we are not tied with any other process running first
<pitti> no, that's fine, I'm just a retard with reading crontabs :)
<pitti> ok, I'll test the dapper PPA uploading tomorrow
<carlos> ok
<pitti> carlos, TomaszD: langpack-o-matic fixed for restricted, FYI; next gutsy base update will fix it completely
<carlos> pitti: thanks. Is that the one planned for 11th October?
<carlos> pitti: or will you do a new full export?
<TomaszD> pitti, thanks
<carlos> or just a patched one with the same version we have right now in Gutsy?
<pitti> carlos: oh, new full export for the release candidate
<carlos> ok
<carlos> pitti: remember that you need to request it 3 days before you want to use it..
<pitti> right
<pitti> carlos: I uploaded the current gutsy delta pack (no automated mail yet)
<carlos> ok
<carlos> I will note it in our UI
<seb128> TomaszD: is libwnck translated in your locale? the workspace switcher applet tooltips come from it
<TomaszD> seb128, checking
<TomaszD> seb128, no, this one isn't. but the "translate this application" button in the workspace switcher pointed me to gnome-panel
<seb128> TomaszD: there is strings coming from the panel and from libwnck, we could remove the items though
<TomaszD> seb128, no no I'll manage, I found the missing strings in rosetta, will translate them now
<Whoopie> cjwatson: Hi, latest ntfs-3g introduced --disable-library configure option. this links the ntfs-3g library. the benefit is that the filesize sum is less and the preformance increased. Will be update to latest ntfs-3g before release?
<seb128> TomaszD: ok, cool
<cjwatson> Whoopie: on my list, though I wasn't planning on doing significant repackaging, just a straight update
<cjwatson> and it's only on my list to investigate, so this is not a promise
<Whoopie> cjwatson: ok ;)
<TomaszD> seb128, we have only 4 people (with me included) on the Polish GNOME upstream translation team, so our resources are quite... well, small. We managed to translate 97% of GNOME, libwnck, orca and a small part of gnome-games is what's been left untranslated :(
<TomaszD> tough luck, seems libwnck is very important
<seb128> TomaszD: good job! ;)
<seb128> yeah
<seb128> you still have time to get it translated in gutsy though so that should be alright
<TomaszD> yeah, it's way too late for other distros though
<slytherin> dholbach: ping
<nrdb> I am trying to mount a drive in the init file in initrd, I used the command "[ -d ${rootmnt}/mnt/hdc1 ]  || mkdir -p ${rootmnt}/mnt/hdc1" any ideas why this isn't creating a directory in the '/mnt/' directory ?
<cjwatson> that code looks fine although the [ -d ]  is unnecessary since mkdir -p already handles that
<cjwatson> it should create a directory in /root/mnt/ though, not /mnt/
<cjwatson> (and BTW the Ubuntu standard is to use /media/ for that ...)
<TomaszD> seb128, got another one for you, confirmed lack of intltool build-dep in build-log for gnomebaker https://bugs.launchpad.net/ubuntu/+source/gnomebaker/+bug/147624
<ubotu> Launchpad bug 147624 in gnomebaker "[gutsy]  gnomebaker should build-dep on intltool, no template available" [Undecided,Confirmed] 
<nrdb> cjwatson: but as the 'run-init' command moves the mount wouldn't that end with it being in "/mnt" ?
<cjwatson> nrdb: yes. perhaps you created the directory before mounting the filesystem on /root?
<cjwatson> (run-init doesn't really move the mount, BTW; it merely changes where you're standing ...)
<nrdb> cjwatson: I don't think so, its just before the 'run-init' command.
<cjwatson> I don't know, then. You're in the best place to debug it :)
<Mithrandir> nrdb: why are you doing this in the initramfs instead of later on?
<nrdb> cjwatson: I think I know why, it isn't a writable fs at that point.
<Nafallo> kylem: why doesn't /usr/share/doc/xserver-xorg-video-intel/ have changelog.Debian.gz?
<Nafallo> :-)
<zul_> Nafallo: its 7:30am in the morning he might not be up yet
<Nafallo> zul_: ah. well, I guess he will fix it when he is then ;-)
<Nafallo> thanks
<cjwatson> nrdb: that's not true for us
<seb128> TomaszD: there is no language pack for universe
<TomaszD> hmm, seb128 so build-dep on intltool wouldn't fix anything? the mainline translation in rosetta isn't used
<TomaszD> or at least something that's being used is terribly out of date
* Hobbsee waves
<seb128> TomaszD: it should not be in rosetta
<pitti> hey Hobbsee
<TomaszD> seb128, so the build errors should be ignored?
<seb128> TomaszD: what build error?
<Hobbsee> pitti!
<TomaszD> seb128, same as with other apps that need to have a intltool build-dep, like serpentine or others
<TomaszD> the buildlog complains about missing intltool-update and such
<seb128> TomaszD: other applications are in main and have the translation stipped at build time, that should not be the case of gnomebaker
<TomaszD> ok
* smurf hates X regressions. laptop+gutsy = blank screen in X. :-/
<mjg59> What hardware?
<smurf> mjg59: ATI. See lp#147635
<mjg59> Right. Fixed upstream.
<smurf> Good. ETA?
<mjg59> Oh, interesting. Maybe not, in fact.
<mjg59> Does X start at all?
<smurf> Yes. Apart from the fact that I cannot see anything, everything seems to be working. :-/
<mjg59> So no gdm?
<smurf> including console switching
<tepsipakki> it uses wrong output I guess
<smurf> tepsipakki: probably. With an empty xorg.conf (or the one from feisty) that's a bit surprising though.
<Whoopie> smurf: I also own a Samsung P35 and it works with 6.7.194
<tepsipakki> smurf: right, try 6.7.194 first
<tepsipakki> log says it's .193
<StevenK> pitti: evolution-sharp is in binary NEW due to libevolution2.0-cil -> libevolution3.0-cil jump. I've got the two uploads prepared if you can wave it through NEW?
<Whoopie> smurf: btw, I have a problem with it and gnome-power-manager. does changing the brightness via /sys/class/brightness/asus/brightness also generate an ACPI event for you?
<pitti> StevenK: ah, that was what I was asking Hobbsee about earlier
<Hobbsee> pitti: what were you asking me about earlier?  was i here?
<pitti> StevenK: there was no FF exception bug in the changelog, and I wasn't aware of who would care for the transition
<smurf> Whoopie: Yeah, brightness fluctuates wildly here, that was the next problem to tackle. :-/
<pitti> Hobbsee: to LongPointyStick
<Hobbsee> pitti: ah, i havent read the log from that yet
<StevenK> pitti: Ah. I'm happy enough to deal with the transition, I'm doing so because it appears in NBS.
<tepsipakki> smurf: gutsy has .194, please update :)
<smurf> tepsipakki: downloading
<StevenK> pitti: If you want to reject it, I'm happy for you to do so, I've spent a whole five minutes on it
<Whoopie> smurf: you need to disable the /etc/acpi/events/asus-brightness-{up,down}
<pitti> StevenK: no, I wouldn't like to reject binary NEWs
<smurf> Whoopie: I gathered as much, but it's still a regression.
<Whoopie> smurf: the problem is the DSDT which generates an event. :(
<pitti> StevenK: I would like people to mention FF exception bug numbers in changelogs :)
* Hobbsee wonders a) why gimp is a native package, and b) why gimp-data is not the same version as gimp.
<smurf> Whoopie: Who started listening to crap events like that?  :-/
<pitti> StevenK: NEWed; I take it your new uploads have proper build deps, so feel free to upload
<mjg59> Whoopie: Does hitting the brightness keys actually do anything without those events?
<StevenK> Hobbsee: a) It oughtn't to be. b) It hasn't built on i386 yet
<Whoopie> mjg59: yes, brightness control is done in hardware. it's just for the OSD.
<Hobbsee> StevenK: ah, great.
<mjg59> Whoopie: Right. Grab hal-info, take a look at how the Thinkpads are flagged
<Hobbsee> StevenK: i thought we built all binaries for the source at the same time.
<mjg59> Then add something similar
<StevenK> Hobbsee: gimp-data is arch all
<StevenK> Hobbsee: Which is only built on i386
<StevenK> Hobbsee: verdansky choked on it. We need infinity or cprov to get it unstuck.
<StevenK> pitti: Right. I shall update their changelogs and upload.
<Hobbsee> StevenK: oh right, yes.
<pitti> meh, why oh why doesn't pysqlite3 allow you to change the timeout?
* pkern whistles.
* Hobbsee goes thru a weekend's worth of Long Pointy Stick of DOOM!!!!!!!!!!!!!!! 
<Hobbsee> hiya cprov!
<StevenK> pitti: Tell cprov about gimp's problem? I'm having trouble phrasing.
<StevenK> pitti: And beagle and gfax have both been uploaded, both of which are universe.
<pitti> StevenK: doing
<cprov> Hobbsee: hi there, what's up ?
<Hobbsee> cprov: the sky.  and varying thoughts about componentry of ppas.
<StevenK> Like the i386 ppa builder.
<cprov> interesting subject.
<Hobbsee> yeah, that too
<Whoopie> mjg59: I tried something this: http://en.pastebin.ca/721607
<Whoopie> mjg59: but I couldn't see any improvements.
<mjg59> Whoopie: You'd then need to restart hal
<Whoopie> smurf: could you also try?
<Whoopie> mjg59: I did
<mjg59> Whoopie: Does lshal show that key?
* StevenK looks to see if any enterprising souls have filed bugs about gimp's current uninstallability
<smurf> Whoopie: will do
<Whoopie> mjg59: I think, it did. I grep'ed for it. but I have the P35 not here, so can't test.
<Hobbsee> StevenK: 2.
<StevenK> Hobbsee: Sigh.
<Hobbsee> StevenK: https://bugs.edge.launchpad.net/ubuntu/+source/gimp/+bug/147628
<StevenK> Hobbsee: Let me merge and bitch-sl^Wcomment.
<ubotu> Launchpad bug 147628 in gimp "Gutsy Gibbon 7.10 - unmet dependencies: gimp: Depends: gimp-data (>= 2.4.0~rc3) but 2.4.0~rc2-1ubuntu1 is to be installed" [Undecided,Fix committed] 
<smurf> Whoopie: seems I need to get the cat hairs out of the keyboard first *grumble*
<StevenK> Hobbsee: Which you've already done. :-)
<Hobbsee> yeah
<StevenK> Hobbsee: The problem is that verdansky grabbed gimp, and hasn't let go.
<Hobbsee> StevenK: heh.  it wont build?
<Whoopie> smurf: hehe
<StevenK> Hobbsee: No other i386 builder will try gimp since verdansky is trying. Apparently.
<Hobbsee> ah, right, yes
<smurf> Whoopie: yeah, my editing skillz suffer when I can't even move the cursor in both directions
<Whoopie> mjg59: the problem is that g-p-m changes the brightness through sysfs and that interferes with the ACPI events. That's my guess.
<smurf> Bah. dpkg troggers are seriously cool, but not so when aptitude insists on starting a new dpkg for what feels like Every. Single. Packet.
<smurf> s/trogger/trigger/
<cjwatson> s/Packet/Package/ too :)
<smurf> cjwatson: Bah :-)
<pkern> mjg59: Did you read my PM? It seems that I went offline inbetween. \:
<mjg59> Whoopie: Yes, the firmware is being irritating in this case
<Hobbsee> StevenK: you've got both the new beagle and e-d-s?
<StevenK> I didn't think e-d-s needed a rebuild?
<smurf> On to the next problem ... any firefox font display experts in here?  :-/
<pkern> smurf: You mean the ligatures problem?
<Hobbsee> StevenK: sorry, beagle-backend-evolution
<smurf> pkern: 'xactly
<StevenK> Hobbsee: Which is built from beagle. I uploaded beagle and gfax
<Hobbsee> StevenK: which presumably dont build yet, as this thing's sitting in NEW
<Hobbsee> no, wait.
<pkern> smurf: Problem known, no fix yet (disable Pango or disable ligatures in the default font)... i.e. change font or start Firefox with some obscure envvar to disable Pango.
<Hobbsee> which presumably will have to be given back, to build with the new library.
<pkern> smurf: #37828 that is
<StevenK> Hobbsee: They should hit DEPWAIT, and will be retried automatically.
<StevenK> Hobbsee: pitti and I have done this before. :-)
<smurf> pkern: thanks
* pkern wonders if ligature rendering does actually work in those languages Pango adds.
<Hobbsee> pitti: OK, please let that thru (and sorry, i forgot to deal with it earlier)
<pitti> Hobbsee: I NEWed it 20 minutes ago, should be on the way to the archive in publisher
<nrdb> cjwatson: can you please have a look at http://paste.ubuntu-nl.org/39257/   it is the last part of the init file I am using, it is hanging at the begining of the startup now.
<pkern> Probably not, whyever it needs Pango. I don't know.
<cjwatson> nrdb: sorry, I'm doing a million other things
<nrdb> cjwatson: ok, thanks for the help.
<Hobbsee> pitti: cool, thanks.  (and there was a bug #)
<\sh> why is ia32-libs missing from the feisty archives?
<pitti> ia32-libs | 1.5ubuntu9 |        feisty | source, amd64
<pitti> \sh: hm? it seems to be fine?
<\sh> yes, I know...but just installing a feisty
<\sh> server...and adding all archives (m,r,u,mu) and apt-get update and apt-cache search ia32 brings nothing
<Mithrandir> \sh: what does apt-cache policy ia32-libs say?
<pitti> that works on my feisty at least
<pitti> \sh: and it's in main
<\sh> forget it...my boss is a jerk
<pitti> (in feisty, anyway, we demoted it in gutsy)
<pkern> And installed i386? :-P
<Whoopie> smurf: you should close your bug report.
<\sh> pkern, right
<\sh> pkern, and gives me the fault
<smurf> Whoopie: as soon as I checked that the thing works now :-P
<pkern> \sh: Thought that when I read your statement. ;)
* \sh needs really a new employer..
<pkern> \sh: You got all the ia32 libs at your fingertips now (:
<Whoopie> mjg59: btw, why don't we add tp_smapi anymore?
<\sh> pkern, /me should kick this guy to hell.....*gnarf*
<manchicken> \sh: What's your job market?
<smurf> Whoopie: no, still fluctuating. Worse, when it does that it generates NULL characters so that I also cannot login on the console. :-/
<maks> where do i find the daily nebootable d-i tar.gz ?
<maks> ah google
<maks> nevermind, you should leave links :P
<pkern> blackle
<Whoopie> smurf: then disable the acpi events.
<Whoopie> smurf: but lshal shows brightness_in_hardware?
<Whoopie> smurf: I'd be interested if ASUS laptop owners are also affected.
<smurf> Whoopie: will check
<agoliveira> Whoopie: I didn't get the thread from the beginning but I do have an Asus laptop (a G1). Is there anything I can do to help?
<Whoopie> agoliveira: the samsung laptop also uses asus_acpi. but when gnome-power-manager changes the brightness, an ACPI event is triggered. this results in a brightness change loop.
<Whoopie> agoliveira: so if you open g-p-m preferences and move the brightness slider, do you see any events with "acpi_listen"?
<agoliveira> Whoopie: Let me check
<agoliveira> Whoopie: I just remembered that I'm not using asus_acpi but asus_laptop instead which is far more complete, at least for asus notebooks. whitout, for instance, I can't switch to an external monitor.
<smurf> Whoopie: nope -- no brightness_in_hardware in lshal
<Whoopie> agoliveira: the problem is that asus-laptop doesn't support the samsung at the moment. because the brightness control in the DSDT is different from the asus ones.
<Whoopie> smurf: did you restart hal?
<smurf> Whoopie: of course
<agoliveira> Whoopie: I see.
<Whoopie> smurf: lshal | grep system.hardware.vendor
<smurf> Whoopie: that's SAMSUNG all right :-/
<Whoopie> smurf: reboot? :)
<smurf> Whoopie: already did that too
<Whoopie> smurf: and just greping for brightness?
<smurf> Whoopie: nothing
<Nafallo> ehrm
<Nafallo> I plugged in the power and gpm disappered...
<lemsx1> Nafallo: perhaps you meant to ask that on #ubuntu+1 ?
<Nafallo> lemsx1: that wasn't a question.
<TomaszD> seb128, I have a hunch. It's strange, but please listen for a moment :]  I think that if a universe application actually uses rosetta for translations (which is the case for gnomebaker and ndisgtk for example) then these translations aren't being used in Ubuntu. I checked it with both these programs and both of them are translated in rosetta, but don't appear to be in Ubuntu. Especially ndisgtk is completely in English while it had a Polish trans
<TomaszD> lation for a long time in Rosetta. I've been fixing the translation now but it's pointless if it's not going to be used.
<seb128> TomaszD: right, that's a rosetta bug, they should not be listed there, talk to carlos maybe he can mask those
<lemsx1> Nafallo: ah, just making sure ;-)
<seb128> carlos: do you know why gnomebaker from universe is on rosetta?
<TomaszD> seb128, but these programs use Rosetta for translations that are not Ubuntu-specific, gnomebaker devs just use it for mainline development... at least they used to
<seb128> TomaszD: ok, so that's their job to get those translations in the tarballs they roll
<seb128> TomaszD: and to update the templates
<TomaszD> uhuh
<TomaszD> ok
<seb128> TomaszD: the upstream templates don't come from package builds
<seb128> TomaszD: since the package strings can be different
<seb128> it's up to upstream to provide update templates to launchpad
<TomaszD> alright.
<rohan> crimsun had once told me how to build kernel sound modules using just the source code obtained from the alsa hg repository. i lost those instructions, can someone please tell me how to do it again ?
<rohan> the sound card module used is snd-hda-intel
<Mithrandir> asac: did you end up deciding on a directory where plugins common to all browsers should go?
<asac> Mithrandir: according to upstream its a bug that /usr/lib/mozilla/plugins isn't used by firefox et al.
<Mithrandir> asac: ok, so I can stuff plugins in /usr/lib/mozilla/plugins and expect them to be used {now,soonish}?
<asac> Mithrandir: but in gutsy+1 we will definitly have a single plugins directory
<asac> Mithrandir: are packaging a new plugin?
<Mithrandir> kinda.
<Mithrandir> it's acroread, and it's not going in a public repo.
<asac> Mithrandir: ok ... i will let you know tonight. Have to verify if its an easy fix before comitting on this.
<Mithrandir> asac: I don't mind if it doesn't work completely just now, but it'd be good to have it working at least for Hardy
<asac> Mithrandir: hardy is a safe bet ... if you can wait for it, there is nothing todo :) ... xulrunner-1.9 will take care for that
<Mithrandir> asac: rock on!
<bddebian> Heya
<soren> Hi, bddebian!
<bddebian> Hello soren
<pitti> kwwii, dholbach: what was  the outcome of the gutsy-wallpapers discussion? shall I upload kwwii's new package, or did you find a way to reduce the size?
<Kopfgeldjaeger> hi
<dholbach> pitti: no, I don't know any; I'm OK with that change
<toresbe> http://nopaste.org/p/aKinluP5 <- i'm seeing this behavior with Gutsy. Some kind of a kernel bug?
<sladen> what needs shrinking?
<toresbe> I'm submitting a bug report after this dist-upgrade completes and I've rebooted into the new kernel.
<pitti> sladen: the gutsy wallpaper is currently shipped as rather large PNG
<pitti> sladen: mostly because some ancient gconf default requires it to be called sth. like 'warty-background.png'
<sladen> 888K    /usr/share/backgrounds/warty-final-ubuntu.png
<sladen> 380K    /usr/share/backgrounds/elephant-skin.jpg
<toresbe> never mind, latest initramfs updated it.
* toresbe goes away in shame
<bddebian> OK, so where in gconf does it store what screensaver I'm using?
<soren> bddebian: I often find "gconftool-2 --dump / | grep stuff" very useful. :)
<tepsipakki> pitti: I have a new discover-data ready, adds a number of nvidia cards that the current driver (nv) supports. Ok to upload?
<pitti> tepsipakki: deferring to slangasek
<pitti> tepsipakki: please attach a debdiff to the bug
<tepsipakki> pitti: ok
<bddebian> soren: That kind of helps, thanks.  I see tons of stuff for gnome-screensaver, but I don't see anything for if I was running say xscreensaver. :-(
<soren> bddebian: Ah, no, that probably wouldn't be in gconf.
<ogra> bddebian, there should be ~/.xscreensaver if you use that
<ogra> gnome uses whatever gets started by /etc/xdg/autostart/ where xscreensaver doesnt put anything atm
<bddebian> Grr.  What I'm trying to do is set up brightside to be able to use xscreensaver or gnome-screensaver instead of forcing one or the other
<ogra> well, you can only run one at a time anyway
<bddebian> Ideally I would just check which on is running I suppose
<ogra> likely
<bddebian> Aye but the debian package uses xscreensaver-command foo and I patched it in Ubuntu a while back to use gnome-screensaver-command foo
<bddebian> It should ideally handle both
<ogra> you cant judge that by installation status ... the thing is that if you have ubuntu-desktop and xubuntu-desktop installed for example they will both be there
<sladen> pitti: that image is very suitable for jpeg'ing;  it'd probably be worth putting in the effort to update the gconf keys and handle all the sides cases as a resonable looking image down to ~150kB
<kwwii> pitti: one thing to note is that the current file size is quite smaller than the one we shipped with feisty
<pitti> slangasek: right, I hope that'll happen in hardy
<ogra> so you need to actually check which one is actually running
<bddebian> That's what I thought.  Hmm, how would I do that?
<Whoopie> agoliveira_lunch: any results?
* ..[topic/#ubuntu-devel:clem92] : Development of Ubuntu (not support, even with gutsy; not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/edgy/feisty, #ubuntu+1 for gutsy support | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Gutsy Beta released!
* ..[topic/#ubuntu-devel:clem92] : Development of Ubuntu (not support, even with gutsy; not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/edgy/feisty, #ubuntu+1 for gutsy support | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Gutsy Beta released!
<clem92> sry
<ogra> bddebian, from a script i'd check if $(pgrep -u $USER -f gnome-screensaver -c) > 0 or something like that
<ogra> if that C code, find something equivalent :)
<ogra> *thats
<bddebian> It's C and I have been searching for how to do it :-(
<agoliveira> Whoopie: Ooops... I understood that as I was using asus_laptop instead of asus_acpi you weren't interested.
<agoliveira> Whoopie: Anyway, answering your question, the brightness slide works nicelly and no acpi events are generated.
<Whoopie> agoliveira: ok, thanks a lot. if you find the time, could you also try with asus_acpi?
<Whoopie> agoliveira: I know it's not working that good for you, but ...
<agoliveira> Whoopie: No problem, I can try... hold on.
<agoliveira> Whoopie: Same result.
<Whoopie> agoliveira: thanks, then it's a buggy DSDT on my side.
<Whoopie> agoliveira: could you send me yours?
<agoliveira> Whoopie: I have a fixed my DSDT, indeed.
<tkamppeter> pitti, ping
<pitti> hi tkamppeter
<tkamppeter> pitti, it seems that CUPS is using "apparmor force-reload" in its maintainer script and this option has been taken out of the apparmor startup script.
<tkamppeter> pitti, this causes apport reporting installation/upgrade problems on many printing packages
<tkamppeter> pitti, see for example bug 147703
<ubotu> Launchpad bug 147703 in hplip "package hplip 2.7.7.dfsg.1-0ubuntu2 failed to install/upgrade: vereistenproblemen - blijft ongeconfigureerd" [Undecided,New]  https://launchpad.net/bugs/147703
<tkamppeter> pitti, bug 146885, bug 134453, bug 146748, bug 146742, bug 146739, bug 135635, bug 134453
<ubotu> Launchpad bug 146885 in update-manager "cups-pdf fails during upgrade (was: package update-manager 1:0.78 failed to install/upgrade: ErrorMessage: SystemError in cache.commit(): E:Sub-process /tmp/tmpM_pNBz/backports/usr/bin/dpkg returned an error code (1))" [Undecided,Incomplete]  https://launchpad.net/bugs/146885
<ubotu> Launchpad bug 134453 in cups-pdf "package cups-pdf 2.4.6-3ubuntu5 failed to install/upgrade: le sous-processus post-installation script a retourn une erreur de sortie d'tat 1" [Undecided,Incomplete]  https://launchpad.net/bugs/134453
<ubotu> Launchpad bug 146748 in hal-cups-utils "package hal-cups-utils 0.6.13+svn83-0ubuntu1 failed to install/upgrade: " [Undecided,New]  https://launchpad.net/bugs/146748
<ubotu> Launchpad bug 146742 in foomatic-db-hpijs "package foomatic-db-hpijs 20070813-0ubuntu1 failed to install/upgrade: " [Undecided,New]  https://launchpad.net/bugs/146742
<ubotu> Launchpad bug 146739 in hplip "package hplip 2.7.7.dfsg.1-0ubuntu2 failed to install/upgrade: " [Undecided,New]  https://launchpad.net/bugs/146739
<StevenK> Bad tkamppeter!
<mvo__> asac: I got bugreports about network-manager not working with ndiswrapper, is there a way for it to detect that ndiswraper is providing the interface and keeping its fingers off it?
<mvo__> asac: (e.g. #97616)
<asac> mvo__: he? just configure the interface in /e/n/i ... nm will not touch it then
<tkamppeter> Is there a limit on how many bug numbers in one message ubotu processes? I have posted 7 bug numbers and ubotu go tired after five.
<asac> bug 97616
<ubotu> Launchpad bug 97616 in update-manager "network monitor is installed by default, while ndiswrapper was used in 6.10" [Undecided,New]  https://launchpad.net/bugs/97616
<joebaker> Question:  If I've used module-assistant to install the kqemu module and I install a new kernel update provided by Ubuntu will the module automatically recompile and be ready for the next reboot?
<asac> mvo__: hmm from what i know ndiswrapper works with nm
<asac> mvo__: in some cases it might not work, but in general it should
<mvo__> asac: ok, it may well be that this is old informaton
<mvo__> asac: great, I will close the bugreport then
<asac> mvo__: good ... tell them they should file specific bug reports if ndiswrapper doesn't work with nm for them
<pitti> tkamppeter: that would be a grave bug in apparmor; force-reload must exist in any init script according to DP
<pitti> tkamppeter: not sure, but my /etc/init.d/apparmor does have force-reload
<tkamppeter> pitti, I am backm
<tkamppeter> 
<tkamppeter> OOo has torn down my system completely had to do a hardware reset
<tkamppeter> pitti, see bug 147703, log file http://launchpadlibrarian.net/9622106/DpkgTerminalLog.txt
<ubotu> Launchpad bug 147703 in hplip "package hplip 2.7.7.dfsg.1-0ubuntu2 failed to install/upgrade: vereistenproblemen - blijft ongeconfigureerd" [Undecided,New]  https://launchpad.net/bugs/147703
<superm1_> mvo__, ping
<tkamppeter> pitti, I get
<tkamppeter> Unable to find apparmor_parser, installation problem?: Failed.
<tkamppeter> invoke-rc.d: initscript apparmor, action "force-reload" failed.
<tkamppeter> usage: update-rc.d [-n]  [-f]  <basename> remove
<tkamppeter>        update-rc.d [-n]  <basename> defaults [NN | sNN kNN] 
<tkamppeter>        update-rc.d [-n]  <basename> start|stop NN runlvl [runlvl]  [...]  .
<tkamppeter> 		-n: not really
<tkamppeter> 		-f: force
<tkamppeter> Looks like some component of apparmor is still missing in main.
<pitti> tkamppeter: where do you get that?
<pitti> it's in apparmor
<pitti> (the package)
<pitti> tkamppeter: weird; both the init script and apparmor_parser are in the very same package
<pitti> tkamppeter: do you have 'apparmor' installed at all?
<tkamppeter> I have found that in the log file http://launchpadlibrarian.net/9622106/DpkgTerminalLog.txt of bug 147703
<ubotu> Launchpad bug 147703 in hplip "package hplip 2.7.7.dfsg.1-0ubuntu2 failed to install/upgrade: vereistenproblemen - blijft ongeconfigureerd" [Undecided,New]  https://launchpad.net/bugs/147703
<tkamppeter> pitti, I cannot reproduce it by myself. For me every update goes smoothly.
<Hobbsee> ScottK: oh damn.  clamav != spamassassin
* Hobbsee should really go to bed.
<LjL> Hobbsee: assuming you're gmt+12, yeah, i think so.
<Hobbsee> +12?  that might be a bit far.
<Hobbsee> i think we're only +10 or +11.
<Hobbsee> it's almost 3am, nayway
<LjL> oh then it's not late.
<ScottK> Hobbsee: Yes?
<Hobbsee> ScottK: you'll find out.
<ScottK> I see it.
<ScottK> Want to ack it anyway?
<ScottK> Or does that one still count?
<Hobbsee> ScottK: if i cant figure out which source package is which, do you really expect me to be able to make that kind of decision at this hour?
<Hobbsee> ScottK: i'd like to see the upstream changelog
<ScottK> Hobbsee: Upstream changelog diff is in the bug now.
* Hobbsee will look later
<ScottK> OK
<sladen> mjg59: how come so few things are soon in alsamixer now;  eg. no modem or many of the other options there used to be
<mjg59> sladen: It depends what the driver claims the hardware exposes
<seb128> carlos: changing the names of the po in the export is not nice
<sladen> mjg59: so things like jacksense are now intentially hidden by the driver?
<mjg59> I think hda is sufficiently complicated that it doesn't make sense to think of jack sense as a single micer element
<pwnguin> which is all and well should jack sense actually work
<mjg59> pwnguin: Well, it wouldn't help in this case - if there were a mixer option, it wouldn't work either
<mjg59> In ac97 there was a standard codec register that corresponded to that
<mjg59> So it was nice and straightforward
<pwnguin> actually
<pwnguin> i have a headphone element
<pwnguin> that works
<pwnguin> toggles the headphone jack, then just turn down the front speakers
<mjg59> Yeah, that's a definition of "works" that is somewhat less than ideal :)
<pwnguin> its better than the older versions of works
<pwnguin> that included not being able to turn the front speakers down
<pwnguin> i think i misinterpreted the conversation as saying they did away with that
<mjg59> No
<pwnguin> well, i think theorerically, there is no "mic" jack
<pwnguin> just a conventional one
<tkamppeter> pitti, still there
<elmo> if I lose (fullscreen) video after suspend/resume, who's bug would that likely be? X?  kernel?
<elmo> also, if I can't suspend/resume while on batter, kernel?
<elmo> batterY
<Kmos> elmo: i think it's kernel
<me_> emacs22-gtk takes 100% cpu here... and I can't find any emacs bugs in launchpad... not tracked there? (or better yet, anybody know how to fix it :)
<cjwatson> me_: start at https://bugs.launchpad.net/ubuntu/+source/emacs22
<cjwatson> don't use bare /emacs or whatever unless you're intentionally filing an upstream bug
<bddebian> Is there a chance anyone could give me some advice on this brightside thing?  Trying to figure out a good way to tell it to use xscreensaver or gnome-screensaver dynamically.  I should be able to use gconf but I don't see a sane way to do that.
<me_> cjwatson: ok, thanks... I guess I'll file a new bug... though I think I've read something about this behavior before
<Kmos> me_: bug 147756
<ubotu> Launchpad bug 147756 in tracker "Possible memory leak in trackerd" [Undecided,New]  https://launchpad.net/bugs/147756
<carlos> seb128: hi, what do you mean by 'changing the names of the po in the export is not nice' ?
<superm1> asac, ping
<asac> superm1: yes?
<superm1> hi asac, i just wanted to check on bug 95064, with an idea of when to expect an upload with it (We were going to work around it with mythbuntu if its going to be a bit)
<ubotu> Launchpad bug 95064 in network-manager-applet "add XFCE to OnlyShowIn" [Medium,In progress]  https://launchpad.net/bugs/95064
<asac> superm1: tomorrow :) (or maybe even today)
<superm1> okay cool :)
<pochu> pitti: are the new freezes already applying? i.e., can we upload bug-fix releases without asking for an UVFe?
<pochu> pitti: https://wiki.ubuntu.com/FeatureFreeze says that there's no problem with bug fix releases, but I'm not sure that applies for Gutsy...
<ogra> mdke, ping
<mdke> ogra: (In case I'm not around at the moment, please provide a bit of information about what you want and I will respond when I get back)
<pitti> pochu: yes, as announced that's effective now; please be considerate, though :)
<pitti> tkamppeter: re
<Kopfgeldjaeger> hi
<pochu> pitti: sure, will be (and I need a core-dev to upload too ;) ). Thanks for the info.
* pochu closes the new bug report page :)
<tkamppeter> pitti, have you seen my last answer, the "Unable to find apparmor_parser, installation problem?: Failed." was only in the log of the bug report. I could not reproduce it.
<pitti> tkamppeter: I saw it, yes; but I have no idea about it
<tkamppeter> pitti, did you have a look into the other "failed to install/upgrade" bugs which I have listed earlier?
<me_> ubotu: That one doesn't seem to be emacs related... ?
<me_> ah, sorry
<me_> Kmos: That one doesn't seem to be emacs related... ?
<Kmos> me_: no.. i confused with someone who talks about a tracker bug
<Kmos> me_: sorry
<Windkracht8> Hello all, I have a problem with starting gdm on gutsy, can someone tell me what data is needed to make a bug report
<ScottK> Windkracht8: Try #ubuntu-bugs.
<hunger> Any progress on the bluetooth front?
<geser> keescook: Hi, are you interested in a debdiff for an imagemagick merge (fixing several CVEs)?
<glatzor> hello bryce
<bryce> hi glatzor
<glatzor> bryce: I disabled support for ati and intel drivers in guidance. Riddell will upload a new version sson
<glatzor> soon
<lamont> dear ubuntu-archive god-of-the-day: gcc-4.1 is new on hppa... gcc-4.1-hppa64 needs to be main (kernel build-depend) otherwise I think it's straightforward
<bryce> glatzor: good to hear
<lamont> who's ubuntu-archive today?  Riddell ??
<ScottK> geser: keescook might also be a good one to look at the gnupg upload.
<glatzor> bryce: no it is time to disappoint the users. I plan to blog about this issue before the release.
<glatzor> bryce: regarding from what I have read on the German forums many users expect to have finnally solved all monitor related issues with randr 1.2
<glatzor> and they hope to configure it with the "new" gui
* bryce nods
<bryce> however, the only way to have achieved that would be to not update any of the drivers, since upstream is moving everything to xrandr now
<bryce> certainly would be better to just add xrandr support to displayconfig-gtk
<Riddell> lamont: Mithrandir on monday's, but he's often too busy
<lamont> ok
<lamont> Riddell: ISTR hearing you say it was your archive today...
<glatzor> bryce: I am still unsure in which direction displayconfig should go, extending the current infrastructure by randr 1.2 or a greater rewrite with 2+ monitor support
<Riddell> lamont: I'm tomorrow
<lamont> ah, ok.
<lamont> you wanna NEW gcc-4.1/hppa, or should I poke Mithrandir ?
<glatzor> bryce: but do you know any graphics card that can support more than 2 outputs?
<Riddell> lamont: let me look
<bryce> glatzor: I've never seen one but it wouldn't surprise me to hear they exist
<Riddell> lamont: accepted
<lamont> Riddell: and gcc-4.1-hppa64 promoted to main?
<lamont> it "used-to-was-be"
<glatzor> bryce: I would like to avoid adding complexity to the user interface that only covers a very small set of use cases.
<bryce> glatzor: It would seem the priority would be to get the dual monitor xrandr set up working, since this is what is described in the DisplayConfigGtk spec - it does say there explicitly that >2 heads is not going to be supported yet, and I agree those of us with >2 monitors are a small use case
<Riddell> lamont: I don't follow you
<lamont> I was assuming that it was NEW because of gcc-4.1-hppa64 being a new binary package.
<lamont> that package needs to be in main
<lamont> or why was it blocked?
<glatzor> bryce: we have written this spec :)
<glatzor> bryce: I am already thinking about Gutsy+1.
<Riddell> lamont: several new binaries http://paste.ubuntu-nl.org/39301/
<lamont> Riddell: wow.  ok
<lamont> and thanks
<bryce> glatzor: I think the priorities are 1) single monitor, 2) laptop+external using xrandr 1.2 drivers, 3) dual-head layouts with xrandr 1.2, 4) >2 head support with xrandr 1.2, 5) dual-head with Xinerama
<bryce> I don't think 4 can be done yet, but _maybe_ by Hardy
<bryce> I list dual head with Xinerama last since it will only be needed for the rare drivers that still don't have xrandr yet; I think as time goes on that set is going to get smaller and smaller, so 5 may even not be needed long term.
<slangasek> lamont: what was the status of the expect FTBFS fix?
<glatzor> bryce: do you expect nvidia or fglrx driver with xrandr support in the gutsy time frame?
<bryce> no
<lamont> slangasek: I thought I did the requestsync on that...
<lamont> feh
* lamont updates 137837 to request the sync
<bryce> glatzor: I'm thinking more of the hardy time frame
<lamont> slangasek: sorry - I thought I'd done that.  137837 is now in ubuntu-archive's hands
<slangasek> ok, thanks
<lamont> mind you, the same fix in expect-tcl8.3 demonstrated that expect reaches _very_ deep into tcl internals where it doesn't belong.  we don't want that one.  (and I may get around to fixing that new FTBFS sometime before we have the package removed from the archive)
<Kopfgeldjaeger> gn8
<keescook> geser: yes, please.  bug 144425 exists for it
<ubotu> Launchpad bug 144425 in graphicsmagick "[ImageMagick]  security issues with releases prior to 6.3.5-9" [Medium,In progress]  https://launchpad.net/bugs/144425
<geser> keescook: http://members.ping.de/~mb/imagemagick.debdiff
<geser> should I attach it to the bug is the link enough for you?
<keescook> geser: I can attach it; thanks for building the diff!
<geser> keescook: can you also ACK bug #147822? (fixes CVE-2007-4974)
<ubotu> Launchpad bug 147822 in libsndfile "Please sync libsndfile (main) from Debian unstable (main)" [Undecided,New]  https://launchpad.net/bugs/147822
<ubotu> Heap-based buffer overflow in libsndfile 1.0.17 and earlier might allow remote attackers to execute arbitrary code via a FLAC file with crafted PCM data containing a block with a size that exceeds the previous block size. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4974)
<keescook> geser: sure thing
<ScottK> keescook: geser's also done Bug 147343 if you have time for it....
<ubotu> Launchpad bug 147343 in gnupg "gpg ignores 1 as valid trust value" [Undecided,Confirmed]  https://launchpad.net/bugs/147343
<keescook> ScottK: cool, looking
<soren> How do I get a list of milestoned bugs assigned to myself or a team?
<soren> Ah, I can order by milestone and then guess where the cutoff is.
<Luke_S> Hi... is there a way to rebuild an install CD to have a custom usplash screen, the x window system with the minimum necessary packages, and a few cusotm packages? (make it boot into a custom X based application. no desktop manager)
<ScottK> soren: Would you please have a look at Bug #147861.  It catches a CVE fix.
<ubotu> Launchpad bug 147861 in inotify-tools "[UVFe]  Update to inotify-tools 3.11" [Undecided,New]  https://launchpad.net/bugs/147861
<soren> ScottK: Am i the only one who is annoyed by the policy of requiring a diffstat, but not the actual diff?
<soren> ScottK: Now I can see that there's 10 new lines in libinotifytools/src/inotifytools.c, but what it they're all crack?
<soren> Grr...
<soren> ScottK, geser: Ack'ed.
<sladen> Luke_S: yes, https://help.ubuntu.com/community/LiveCDCustomization
<geser> soren: if you are still interested: http://members.ping.de/~mb/inotify-tools.debdiff
<soren> I am :)
<soren> geser: Thanks for that! :)
<slangasek> soren: is there any progress on #119075?  it's still assigned to you, who is the "resident Debian maintainer person" mentioned in the log?
<slangasek> (bug #119075, let's make that)
<ubotu> Launchpad bug 119075 in mysql-dfsg-5.0 "Root password policy for mysql" [High,Confirmed]  https://launchpad.net/bugs/119075
<soren> slangasek: funny, I was just writing about it in my weekly activity report. :)
<soren> slangasek: If you hang on for two minutes, it'll hit your inbox :)
<cjwatson> soren: yeah, I think diffstats are rather unhelpful and pointless too
<soren> cjwatson: What's the policy for UVFe request for main? Same?
<cjwatson> do something sensible
<cjwatson> diff is just fine
<slangasek> soren: heh, cheers
<Whoopie> smurf: Hi again, I tested with a feisty live CD and the problem also exists there with generated acpi events when changing brightness via sysfs.
<Whoopie> smurf: so it's not a regression, "just" an annoying DSDT "feature".
<slangasek> soren: FWIW, my take on the question, if the permanent fix isn't available yet, is that it's better to prompt for a mysql root password than to leave the server unsecured, and it's better to prompt for this password during the install then to require the user to take some post-installation action before being able to use the server.  do you agree?
<soren> slangasek: Are you familiar with the policy about questions during install?
<Riddell> keescook: that's those kdelibs/base and qt3/4 security patches all up to date in gutsy
<slangasek> soren: perhaps not. :)
<slangasek> soren: but feel free to turn the comparison on its head, as an assertion that these two options are both worse than a "prompt during install" option that's considered unacceptable
<cjwatson> soren: FWIW, the policy applies to the default Ubuntu desktop install
<slangasek> (i.e., I'm not saying "we should prompt during install", I'm saying "we should rule out these other solutions and see what's left")
<soren> cjwatson: Ah, really?
<cjwatson> soren: if it's necessary to achieve security, I don't think anyone's going to shoot you for an extra question during the Ubuntu server install if you select a task involving the mysql server
<soren> cjwatson: I've never seen it in writing, actually.
<cjwatson> soren: though it probably ought to be regarded as a bug and removed again in a future release
<soren> cjwatson: The reason it came up, was because someone (fabbione, I think) pointed out that we shouldn't be asking more questions than in previous releases due to a sabdfl decree :)
<cjwatson> soren: it's sort of one of the bits that are embedded in the heads of the founding developers and people have varying interpretations
<cjwatson> but the original decree was in the days when we had one CD and that was it
<cjwatson> we should of course avoid drifting towards infinity-questions installs
<soren> cjwatson: Of course, of course.
<cjwatson> https://wiki.ubuntu.com/UbuntuArchitecture states something in the general vicinity of this but isn't terribly explicit
<cjwatson> I'll see if I can think of something coherent
<slangasek> "Applications should work immediately upon installation, without requiring additional steps, whenever possible. This "instant gratification" makes users more productive and allows them to explore the software choices available"
<soren> cjwatson: That would be much appreciated. It's one of the policies many people refer to, but noone can actually define.
<cjwatson> soren: like slangasek, I'm not saying "you should do this", but don't discard it out of hand
<slangasek> there you go, installing a broken mysql server package and expecting the user to configure it later is a bad idea ;)
<soren> cjwatson: Well, since we're in no position to do the "right thing" (i.e. making the mysql-owning user able to do admin stuff to mysql), the proper thing to do IMO is ask the question.
<soren> I just thought that was out of the question.
<slangasek> soren: setting a random password isn't an acceptable workaround?
<soren> slangasek: No.
<slangasek> ok
<soren> slangasek: That makes it *really* difficult for novice admins to do anything at all to their mysql server.
<soren> slangasek: They'd have to either remember to write it down if we show it during install (noone ever does that) or be able to find it easily somewhere.
<soren> ...but making it easy to find, makes it hard to keep secret :)
<slangasek> right, or if we gave them a way to reset the password without knowing it, this would be Ubuntu-specific and not described in any of the upstream/generic howtos
<soren> slangasek: I had a patch to do that, actually.
* keescook hugs Riddell 
<cjwatson> plus showing a password during install is an instant pass for a hysterical slashdot article ;)
<soren> slangasek: It used the debian-sys-maint user, but it was rejected, afair.
<soren> I'll see if I can dig it up and see if it makes sense at this point. Tomorrow, though.
* soren -> bed
<slangasek> ok, 'night
<soren> Night, all.
#ubuntu-devel 2007-10-02
<asac> bryce: bug 147676 ... could this be done properly?
<ubotu> Launchpad bug 147676 in imwheel "Any Logitech mouse buttons does NOT work in FireFox LTSP xorg gpm imwheel yelp icedove iceweasel" [Undecided,New]  https://launchpad.net/bugs/147676
<bryce> asac, thanks I'll take a look
<Chipzz> man, that bugreport is CRAP :p
<Chipzz> "Any Logitech mouse buttons does NOT work in FireFox xorg gpm imwheel yelp icedove iceweasel etc."
<Chipzz> first of all this is not even a sentence
<sladen> and even if it was, it's quite long for a subject line :)
<Chipzz> 2nd of all the guy is just throwing a whole bunch of unrelated program names together and expects that to be a valid bugreport
<dobey> that is totally a sentence
<Chipzz> firefox/xorg/gpm/imwheel ok
<Chipzz> but the rest?
<dobey> you just need to learn Engrish better :)
<Chipzz> he's confusing consumers apps (like firefox, icedove, iceweasel and yelp) with daemons or servers (xorg, gpm, imwheel)
<Chipzz> *and* I don't think we support gpm + X config?
<Chipzz> do we?
<dobey> i i just like how firefox is listed N times
<dobey> i didn't realize that imwheel still existed
<dobey> gpm probably is supported
<Chipzz> it's deprecated IMHO
<dobey> i don't know what it has to do with X though
<bryce> asac: generally I've been holding off on doing much work on improving input stuff, since with Hardy when we go to xserver 1.4, we should be able to take advantage of input hotplug and avoid all these configuration tweaks
<Chipzz> dobey: you have to correctly set your mouse type in order for gpm to work
<mjg59> If you want cut and paste on the console, it's kind of important
<dobey> Chipzz: you have to correctly set your mouse type for X to work
<dobey> :)
<mjg59> dobey: No, the kernel does most of that now
<Chipzz> mjg59: I *know* what gpm is :) I have used it for errr, over 7 years :)
<mjg59> Chipzz: I wasn't talking to you
<dobey> mjg59: the kernel deals with mouse buttons and ZAxisMapping in xorg.conf?
<mjg59> It depends what level you're looking at
<dobey> or X is smarter about dealing with it now?
<asac> bryce: ok, please drop a note in bug and set to won'tfix?? ... maybe verify if the bugs he mentions are of the same class and will be gone with 1.4 was well. Thanks!
<mjg59> It abstracts away the mouse protocol stuff that used to be required in X
<dobey> so X is smarter about it
<mjg59> I believe that the ZAxis stuff is still required, though
<bryce> asac, will do.  Think I'll try to dupe some of these while I'm at it, if they are indeed dupes
<dobey> you still have to tell it what buttons are scroll/etc... i think
<mjg59> No, now the kernel recodes everything to look like the Microsoft extended protocol
<asac> bryce: if there are others with a firefox target, feel free to invalidate them ;)
<mjg59> But yeah. It's not practical to programmatically determine which buttons are which under certain cricumstances
<mjg59> 4 and 5 will always be the wheel, but 6 and 7 might be side buttons or a horizontal wheel
<bryce> asac, okie
<asac> ;)
<Chipzz> bryce: when will hardy have xorg 1.4? soon after opening or late in the cycle?
<bryce> soon after opening
<Chipzz> btw
<Chipzz> are serial mice autodetectable?
<bryce> once the tree opens I'll make that my top priority
<Chipzz> serial mice or getting xorg 1.4 in hardy?
<mjg59> Chipzz: Not trivially
<bryce> Chipzz: xserver 1.4
<slangasek> evand: bug #123425 is still only 'fix committed', not 'fix released'?
<ubotu> Launchpad bug 123425 in ubiquity "[gutsy]  Passwords intead of Full Names" [High,Fix committed]  https://launchpad.net/bugs/123425
<slangasek> lamont: bug #63175 - eww, do we really still have issues with timezones and fsck?
<ubotu> Launchpad bug 63175 in e2fsprogs "fsck on every (re)boot" [Medium,New]  https://launchpad.net/bugs/63175
<mneptok> slangasek: at least we don't leave New Zealand in the wrong timezone because "tzdata is not a security issue" ;)
<Hobbsee> mneptok: bah.  new zealand.  are you telling me that they're whining for gettign australia's eastern timezone?
<mneptok> Hobbsee: no, Debian won't push the new daylight savings tzdata to Etch as it's not a security issue
<slangasek> mneptok: you might be well advised to not get your information about Debian from Slashdot
<Hobbsee> but mneptok lives for slashdot!
<StevenK> Like Slashdot would talk about Debian - it doesn't happen within 3 blocks of CmdrTaco's house
<mneptok> slangasek: it's still an issue that's unaddressed until a point release instead of a rolling update. which seems silly.
<mneptok> slangasek: it's tzdata. we push this stuff out every week. why does Debian need to wait for a point release?
<slangasek> mneptok: anyway, I don't think this is a conversation you want to have with me; I don't think much of governments who make changes to their timezones with less than a year's notice, because regardless of whether Debian happens to be able to accomodate them, such changes are expensive for the IT industry and serve no purpose.
<slangasek> mneptok: so you're arguing that it should be pushed out as a "security" release when it's not security related?
<mneptok> slangasek: i agree. but pouting and refusing to make life easier for users isn't helping. what's done is done, for good or ill. address it.
<slangasek> mneptok: this would be the part where you're getting your information from Slashdot...
<mneptok> slangasek: i'm saying it doesn't need to be either/or
<mneptok> slangasek: the fact that others have coped is ample evidence of this.
<slangasek> there are four update channels available for fixes to Debian stable.  security.d.o, volatile.d.o, proposed-updates, and point releases.  The tzdata fix is *already available* in two of these, is targetted for a third but can't be made available yet for practical reasons, and doesn't belong in the fourth
<mneptok> slangasek: but i can understand why production server admins might be put off by "volatile"
<slangasek> mneptok: proposed-updates contains only those changes which have been accepted by the Debian stable release managers for the next point release; from etch forward, production server admins can reasonably make use of p-u
<mneptok> i don't see it in p-u
<slangasek> it's definitely there.
<mneptok> http://ftp.debian.org/debian/dists/proposed-updates/tzdata_2007f-1etch1_amd64.changes
<mneptok> august 17
<mneptok> wait, no, July 31
<mneptok> we con get a release done in the time it takes Debian to fix a timezone. :P
<ajmitch> ah, the tzdata fun
<ajmitch> slangasek: don't worry, we don't think much of our government either
<StevenK> Hah
* bddebian loves Australia's government :-)
<StevenK> bddebian: Why? And, ajmitch's quip was pointed at New Zealand's government.
<bddebian> I know :-)
<bddebian> Because Howard (I belive his name is?) is like Hey, it's Australia, love it or leave it. :-)
<StevenK> Yes, (John) Howard.
<RAOF>  Not the actor :)
<mneptok> isn't that sorta antithetical to a penal colony? i mean, prisoners choosing to leave?
<lifeless> mneptok: even prisons have standards
<mneptok> lifeless: explains my rejected visa application :/
<lifeless> mneptok: I thought you were usian?
<mneptok> lifeless: the UN has asked that all nations require a visa in my case. they ... just want to be sure.
<lifeless> I'd have though a GPS ankle collar would be safere
<Hobbsee> he never said that he didnt have one of them either, though
<lifeless> he didn't have one last time I saw him
<mneptok> lifeless: it's a genital cuff
<Hobbsee> who said it was on his ankle?  if it was on his ankle, it coudl be cut off...
* mode/#ubuntu-devel [+o mneptok]  by ChanServ
* mneptok was kicked off #ubuntu-devel by mneptok (nasty, dude)
<lifeless> Hobbsee: it can still be cut off
<lifeless> with the added benefit of no-breeding
<Hobbsee> lifeless: good point.
<mneptok> lifeless: now you sound like my girlfriend
* Hobbsee was intending her statement *before* mneptok's, incidently.  damn uni lag.
* bddebian knows that StevenK wants to help him with his brightside issue :)
<mneptok> Unilag would be a great name for a Cisco competitor
<lifeless> mneptok: sensible lady:)
<bddebian> mneptok: heh
<StevenK> bddebian: Do I? I don't think I do.
<Hobbsee> lifeless: although insane.  being with mneptok, and all.
<lifeless> Hobbsee: there may be coercion involved.
<bddebian> StevenK: Suure you do :-)
<mneptok> lifeless: you may meet her at/around/adjoining All-Hands
<lifeless> Hobbsee: we should organise a rescue party
<Hobbsee> lifeless: indeed.
<lifeless> mneptok: somehow I'm amazed you didn't make that statement dirty. 'seeing her around all-hands' is just ripe for suggestive deviation
<mneptok> lifeless: after Hobbsee's comment this weekend i had to turn off those receptors. there was danger of circuit overload.
<Hobbsee> lifeless: he wished to live, methinks.
* cypher1 is away: I'm busy
* cypher1 is back (gone 00:00:40)
<Hobbsee> !away | cypher1
<ubotu> cypher1: You should avoid changing your nick in a busy channel like #ubuntu - it causes unrequired scrolling which is unfair on new users. The same goes for using noisy away messages : use the command "/away <reason>" to set your client away silently - See also !Guidelines
<wasabi> I am somehow missing how restarting NetworkManager can cause my keyboard to cease working.
<wasabi> Just not seeing the link.
<EvanCarroll_home> is anyone else having a problem with amd64 and nvidia with newest patch?
<EvanCarroll_home> gutsy*
<Hobbsee> EvanCarroll_home: you probably wanted #ubuntu+1?
<bddebian> Should glade files be in a binary package or data package?
<EvanCarroll_home> seems as if volatile/nvidia.ko, was renamed to volatile/new_nvidia.ko, without symlink
<EvanCarroll_home> Hobbsee: yes, i forgot about that chan
<ScottK> paran: Dunno if you noticed yet or not, but your gnupg fix got uploaded today.  Thanks for the heads up.
<nrdb> I have created a unionfs in initrd of the from the what was the root and another rw partition.  I have checked the unionfs and it appears ok.  The problem is that when I boot it seems to get stuck in a loop using 100% CPU and never actually boots, any ideas on how to find out what the problem is ?
<lamont> slangasek: fsck/timezone issues are fixed in -6ubuntu1
<lamont> maybe
<lamont> slangasek: see https://bugs.debian.org/443487
<slangasek> or http maybe :)
<lamont> yeah - that
<lamont> that's what I get for adding $mumble:// at the front
<lamont> :-(
<lamont> note the small amount of grumbling from the submitter.  also note who he is
<slangasek> so ok, it should be fixed in util-linux and this bug should be reassigned to there?
<lamont> yes
<lamont> and note that fixing it requires adding an installer question...
<lamont> so I'll leave that to TPTB
<lamont> slangasek: the only outstanding issue is if you have BIOS=localtime (presumably because you dual-boot), and live east of greenwich
<slangasek> lamont: you've lost me; why is an additional installer question needed?
<lamont> either "what time zone are you in" or "is time UTC or local" or some such.
<lamont> I really have no clue - just know that ted was grumbling
<lamont> slangasek: feel free to look at util-linux_2.13-8 in debian (just uploaded now).  if there's anything that we want for -6ubuntu2 (or if we want to do -8ubuntu1) say so: I don't think there's anything so pressing as to justify hitting gutsy now.
<lamont> hrm.. still uploading....
<dcode>  I want to build packages for amd64 from an unofficial repository that provide the original sources and patches, but only i386 binaries...when I do apt-get -b source foo, it downloads the version in the official repository...how do I fix this?  Do I need to pin the packages?
<lamont> dcode: apt-get source foo=1.2.3-1 is certainly an option
<dcode> thanks, lamont
<dcode> there's just so many way to use apt....I find new stuff all the time
<nrdb> with vmware and 7.04 the message "BUG: soft lockup detected on CPU#0!" means ?
<tepsipakki> slangasek: ok to upload a new discover-data (bug #133385)?
<ubotu> Launchpad bug 133385 in discover-data "[gutsy]  "nv" is not new enough to support my chipset (Quadro FX 570M)" [Medium,In progress]  https://launchpad.net/bugs/133385
<tepsipakki> it's not new upstream, but adds a number of nvidia pci-id's that the current driver supports (also some that the previous 2.1.x supported, but were missing)
<tepsipakki> debdiff attached
<slangasek> lamont: I'm confused, isn't gutsy already asking for the time on install?
<lamont> slangasek: dunno - like I said, I haven't paid any attention to that part of the issue....
<lamont> if we do, then it might make sense to bring back hwclockfirst.sh here too, OTOH, ISTR that comes from the rtc module getting loaded via udev rules now.
<lamont> slangasek: I've pretty much ignored hwclock.sh issues in ubuntu and let keybuk lead on that, since he did the udev conversion
<lamont> of course, the big diff is that ubuntu requires udev (or seems to?), while debian avoids depending on it.
<lamont> slangasek: and I wasn't in on the ted/whomever discussion that ted alludes to.
<lamont> hrm... eject spits the CD tray out... is there a command to pull it back in?
<lamont> slangasek: I'll break out a livecd and check tomorrow.
<lamont> and maybe poke keybuk et al here on the issue once I have more knowledge
<StevenK> lamont: Try eject -t <device> to pull the tray back in
<lamont> StevenK: cool
<lamont> I'll do that later - drives are kinda busy atm
<slangasek> tepsipakki: discover-data, looks fine
* lamont wonders if he can do a couple of no-change uploads (db4.5 and ncurses, to be specific)
<ScottK> If someone is looking into TZ and the installer, it'd be really nice to be able to use UTC after you admit to being in North America.
<lamont> ScottK: you mean you can't say NorthAmerica/UTC?
<ScottK> lamont: First it asks you where you are and then gives you a list of applicable TZ.
<ScottK> It doesn't consider UTC in North America.
<ScottK> This is D-I and a server install.
<ScottK> It's just not on the list.
<lamont> feh.  db4.5 is blocking python2.5
* lamont checks the rest of the packages he cares about tonight
<slangasek> you can specify that the system clock is in UTC
<lamont> slangasek: but not that the local TZ is NorthAmerica/UTC
<slangasek> correct
<tepsipakki> slangasek: thanks
<bryce> heya tepsipakki
<tepsipakki> hi bryce
<dholbach> good morning
<Hobbsee> hi dholbach
<dholbach> hey Hobbsee
<pitti> Good morning
<dholbach> mdke: do you plan to sync with gnome-user-docs 2.20.0 again?
<Hobbsee> morning pitti!
<pitti> hey Hobbsee, good morning
<Hobbsee> pitti: i discovered the morning today.  it wasnt good.
<StevenK> If mornings really exist, why are there only 12 hours on a clock...
* Chipzz denies the existence of mornings :P
<Chipzz> they're extremely late evenings, at best
<Hobbsee> heh
<StevenK> Chipzz: Heh
<stgraber> moin
<Hobbsee> hiya
<StevenK> pitti: Oh, libevolution2.0-cil can be NBS'd out if you haven't already done it.
<pitti> StevenK: ah, doing
<StevenK> pitti: Danke
<pitti> StevenK: I also ponder killing the other libs now, and thus break sear and silky
<StevenK> pitti: silky can die as far as I'm concerned. Upstream is dead, and getting it work with the new SILC looks to be a shedload of work. However, there is a bug about silky, so someone could be working on it.
<pitti> swoosh, killed them all; we should not ship gutsy with NBS packages
<StevenK> pitti: sear on the other hand is known about, and I keep bugging man-di in -motu in terms of where it's up to. He is fighting with the Debian maintainer, last I heard.
<StevenK> pitti: Agreed.
<soren> NBS?
<StevenK> Not Built from Source
<soren> Well..
<soren> How can you NBS something?
<StevenK> Okay, so you have a library package - libfoo, that builds libfoo1.
<soren> Uhuh.
<StevenK> libfoo's upstream releases a new version that bumps the SOVER, so now you build libfoo2.
<soren> Uhuh.
<StevenK> The binary packages still exist in the archive, and shouldn't be removed until nothing depends on it.
<soren> Yes...
<StevenK> The binary package libfoo1, that is
<soren> Let me rephrase..
<soren> When you tell pitti that a package can be "NBS'd out", what does he then do?
<pitti> soren: I remove it from the archive
<pitti> soren: we should not release gutsy with pacakges which are not built by any source, since that makes them unmaintainable
<soren> Oh...
<soren> Sure, sure.
<soren> I get it now.
<pitti> but it does not happen automatically, since with library soname changes, that would break hard
<dholbach> doko_: would it be ok, if you took a look at bug 139928?
<ubotu> Launchpad bug 139928 in cpio "[gutsy]  cpio segs on bad input" [Medium,Confirmed]  https://launchpad.net/bugs/139928
<soren> So "NBS a package out" doesn't mean "make it not build from source", but "remove it because it's already not built from any source". YEs, that makes perfect sense :)
<soren> pitti: Sure.
<StevenK> pitti: I'll hunt down that silky bug and comment on it when I'm on a link that isn't so dreadful.
<dholbach> Riddelll: bug 136425, bug 121872?
<ubotu> Launchpad bug 136425 in qt4-x11 "qtconfig-qt4 in Accessories?" [Undecided,Confirmed]  https://launchpad.net/bugs/136425
<ubotu> Launchpad bug 121872 in qt4-x11 "*-qt4 tools should be present in $QTDIR/bin" [Undecided,In progress]  https://launchpad.net/bugs/121872
<dholbach> calc: bug 135086?
<ubotu> Launchpad bug 135086 in unzip "zipgrep: exit code always 0" [Unknown,Confirmed]  https://launchpad.net/bugs/135086
<Mithrandir> dholbach: what's the policy you've been using for accepting or not accepting people for the telepathy team?
<dholbach> Mithrandir: none
<Mithrandir> dholbach: as in, just accept everybody?
<dholbach> Mithrandir: I directly subscribed them to the mailing list too :)
<siretart> asac: around? Wanted to ask you about NM/wpasupplicant integration
<soren> StevenK: Did you ever figure out why the dpkg output in gutsy sbuilders was in all upper case?
<RAOF> soren: Oooh, you're seeing that too?
<StevenK> soren: Nope. Mainly because I've not looked yet.
<StevenK> RAOF: Me three.
<soren> StevenK: Same here. :)
<StevenK> Between the three of us we should be able to sort it out. :-)
<soren> :)
* RAOF leaves for a dinner, so will be unavailable for fix-o-rama.
<soren> StevenK: Do you save your build logs from sbuild? Could you check when it happened to you the first time?
<StevenK> soren: I do. And what do you mean, the first time?
<mdke> dholbach: yes, I updated our branch from upstream trunk on sunday, if possible we could do another upload, yes
<soren> StevenK: Has your sbuilder *always* done it?
<StevenK> soren: Ah, no.
<pitti> \sh_away: did you have a chance to test the fix for bug 103291?
<ubotu> Launchpad bug 103291 in lilo-installer "lilo-installer fails on HP (Compaq) SmartArray controllers (/dev/cciss)" [Medium,In progress]  https://launchpad.net/bugs/103291
<dholbach> mdke: I'll look into it later
<StevenK> soren: Right, the first log I have with the upper-casing is courier_0.56.0-2ubuntu1_20070917-2341
<soren> StevenK: So mid-september-ish?
<StevenK> Looks like it.
<dholbach> mdke: I'll update the version number
<StevenK> I think the next step is to compare base tool versions between that log and the previous.
<mdke> dholbach: thanks. We haven't made any other changes except synching with upstream; which was a couple of extra translations, and upstream applying one of our patches
<dholbach> mdke: great
<dholbach> mdke: next time please update debian/changelog :-)
<dholbach> it's just a matter of   dch -i; debcommit   :-)
* dholbach shuts up now :)
<mdke> dholbach: yes, I would have done, sorry
<soren> StevenK: Interesting. You had schroot 1.1.5-1.1 synced on September 13th :)
* dholbach hugs mdke
<mdke> :)
<dholbach> mdke: pushed changes to my branch
<dholbach> hey thekorn
<thekorn> hi dholbach
<dholbach> mdke: uploading package...
<mdke> dholbach: thanks very much. for ubuntu-docs I'll be adding translations during this week... we are going to have to be careful with the package size when that happens... I'll ping you early next week if that is ok?
<dholbach> mdke: alrightie, you can also file a sponsoring bug, that's fine too
<mdke> ok
<pitti> \sh: good morning
<\sh> pitti, hey...good morning...:)
<geser> Guten Morgen \sh, pitti
<pitti> hi geser
<StevenK> soren: Hmmm.
<soren> StevenK: Hm, indeed.
<StevenK> soren: But schroot isn't installed inside the chroot, and my base machine is Feisty
<soren> StevenK: Oh.
<twb> What is dh_iconcache, why is it undocumented and why is it in Ubuntu's debhelper and not Debian's?
<pitti> twb: it is the old name of dh_icons
<pitti> twb: we had it first, Debian used a different name, so it's just a backwards compatibilty shim nowadays
<twb> I can replace it 100% with dh_icons in this package I'm re-building under Debian?
<pitti> twb: given that dh_iconcache just does system("dh_icons @ARGV");, I'd say yes
<twb> OK, thank you.
<dholbach> everything should use dh_icons
<twb> The package in question is vmware-server 1.0.3, from feisty-commercial.
<dholbach> twb: oh ok, I think in feisty we still had dh_iconcache - let me check
<twb> I would've used gutsy, but it has no -commercial yet.
<dholbach> yes, feisty still has dh_iconcache :-/
<dholbach> I think somebody is working on setting up gutsy-commercial
<twb> I hate non-Free software.  It's nothing but a PITA.
<twb> -commercial isn't listed on packages.u.c either, which confused me for days.
<tepsipakki> isn't it called something else nowadays?
<Mithrandir> cjwatson: is it possible to get user-setup-apply to set a completely blank password?
<tepsipakki> twb: it's being changed to "partner", but that doesn't exist yet
<TheMuso> Is the apport retracer for i386 running?
<pitti> TheMuso: seems it got stuck, I restarted it
<dholbach> hey mvo
<pitti> TheMuso: thanks
<pitti> hey mvo
<TheMuso> pitti: Thank you.
<mvo> hey dholbach, pitti!
<dholbach> hey seb128
<seb128> hello dholbach
<mvo> hey seb128
<seb128> hello mvo
<simira> morning guys
<simira> :)
<Mithrandir> simira!
* simira runs to school
<seb128> hey simira
<RicardoPerez> pitti: ping
<pitti> hi RicardoPerez
<RicardoPerez> pitti: hi! i have a problem with the openoffice.org menu entries... i'm talking with carlos, and he told me to talk with you
<RicardoPerez> pitti: the menu entries shows untranslated in my Spanish desktop
<RicardoPerez> pitti: i have the ooo-build.mo file with the translations
<pitti> RicardoPerez: the bubble help is untranslated, too?
<RicardoPerez> pitti: and I've add a line containing 'X-Ubuntu-Gettext-Domain=ooo-build' in the .desktop files
<RicardoPerez> pitti: the bubble IS translated
<RicardoPerez> pitti: but the menu entries isn't
<RicardoPerez> aren't
<dholbach> doko: where was the page that listed ubuntu-specific packaging decisions?
<pitti> right, same here
<pitti> RicardoPerez: it seems that they consider "OO.o writer" as a proper noun and thus do not translate it
<doko> dholbach: UbuntuPackagingChanges
<pitti> RicardoPerez: e. g. I never saw MS "Word" or "Excel" getting translated
<dholbach> doko: thanks
<pitti> RicardoPerez: (except in jokes :) )
<pitti> RicardoPerez: the desktop file does have some Arabic translations, etc., though
<RicardoPerez> pitti: oh, that's right, but the menu entries doesn't must be "OpenOffice.org Writer", but "OpenOffice.org Word processor"
<pitti> hm, no, that's just the GenericName
<RicardoPerez> pitti: "OpenOffice.org Word processor" => "OpenOffice.org Procesador de textos" (in spanish)
<RicardoPerez> pitti: oh
<pitti> RicardoPerez: we do not show this by defautl
<RicardoPerez> pitti: but shows in that way in Feisty
<RicardoPerez> pitti: in Feisty, it shows "OpenOffice.org Procesador de textos"
<pitti> hmm
<RicardoPerez> pitti: and not "OpenOffice.org Writer"
<pitti> seb128: did we change anything wrt. the display of GenericName in menus?
<seb128> The openoffice menu item are translated on my gutsy
<seb128> pitti: GenericName is not used by GNOME
<seb128> it uses Name= for the item
<pitti> that's what I thought, too
<seb128> and Comment= for the tooltip on mouseover
<seb128> and that has always been the case
<carlos> seb128: the problem is that it's not using the .mo files
<pitti> right, but that's something entirely different
<carlos> and even adding the translation domain
<pitti> (oo.o needs to add X-Ubuntu-Gettext-Domain:)
<carlos> the entries are still untranslated
<carlos> pitti: we added it by hand
<carlos> restarted the session and still the same problem
<RicardoPerez> carlos: me too, without luck
<carlos> RicardoPerez: we == you and me ;-)
<seb128> carlos: do you have the correct .mo file installed?
<seb128> carlos: and the .mo has the translations?
<RicardoPerez> carlos: sorry :)
<seb128> works fine in french so I don't think the system is b0rked
<carlos> seb128:  RicardoPerez said that we do
<carlos> I didn't check it
<seb128> k, I think you don't
<RicardoPerez> seb128: I have the .mo file
<carlos> seb128: well, I doubt you are using the same unless you added the translation domain too
<RicardoPerez> seb128: and strings ooo-build.mo shows translated strings
<carlos> seb128: there is a bug with the package that is not adding the translation domain to the .desktop file
<seb128> carlos: it works for other menu items, didn't try openoffice but the panel has no reason to behave differently for it
<carlos> seb128: so you use the translations inside the .desktop file
<pitti> carlos: however, since OO.o does not use gettext, it does not have an obvious place where to put them
<carlos> seb128: yeah, I know, that's why I was so confused
<carlos> pitti: it does
<carlos> ooo-build
<carlos> pitti: we had a template specific for it and it's included in language packs
<seb128> carlos: oo-build.mo doesn't contain the menu item strings there
<seb128> $ msgunfmt /usr/share/locale-langpack/en_GB/LC_MESSAGES/ooo-build.mo | grep Writer
<seb128> $
<pitti> ah, indeed
<RicardoPerez> seb128: It isn't Writer, but Word Processor
<carlos> hmm
<carlos> indeed
<carlos> RicardoPerez: but the .desktop uses Writer
<RicardoPerez> carlos: not in Feisty...
<carlos> RicardoPerez: aren't you using Gutsy?
<RicardoPerez> carlos: I don't know if this is intentional
<pitti> carlos: so, calc should add the X-U-G-D: field
<RicardoPerez> carlos: yes, I'm in gutsy
<carlos> RicardoPerez: then, why do you mention Feisty?
<RicardoPerez> carlos: because in Feisty shows "OpenOffice.org Word Processor" (in English) and in Gutsy shows "OpenOffice.org Writer"
<cjwatson> Mithrandir: sure, casper does it, look at scripts/casper/10adduser
<Le-Chuck_ITA> Hi there, I just tried to install openssh on feisty from main archive (ubuntu.com) and it said it was _not_ authenticated, while taking it from an italian mirror went fine!
<carlos> pitti: yeah, I just got confused because the translations were not appearing and it was weird because it works for others (as seb128 already noted)
<cjwatson> lamont: it's just the "is your clock in UTC" question that we haven't wedged into ubiquity yet
<carlos> RicardoPerez: that just means that the different packages use different strings
<cjwatson> Le-Chuck_ITA: sometimes happens transiently due to minor glitches; wait an hour and 'sudo apt-get update' again
<seb128> carlos: works fine for me
<seb128> carlos: I did that
<RicardoPerez> carlos: mmmmm.... i'm confused
<Le-Chuck_ITA> ok so if you're not worried about that I've done my job :)
<seb128> - edit /usr/share/applications/ooo-writer.desktop, change the french translation
<RicardoPerez> carlos: ooo-build didn't change from feisty to gutsy... contains the same strings
<seb128> - add X-Ubuntu-Gettext-Domain=ooo-build to it
<seb128> - sudo touch /usr/share/applications/ooo-writer.desktop,
<carlos> RicardoPerez: which is the problem you are having
<seb128> and the menu item has the mo translation now
<carlos> RicardoPerez: the .desktop file did change
<seb128> not the modified one
<Mithrandir> cjwatson: no, that gets you a hash in /etc/shadow.  I want it to be ume::1000... in /etc/passwd.
<Chipzz> Le-Chuck_ITA: normal install, or debootstrap?
<carlos> RicardoPerez: so the .desktop file needs to be updated
<seb128> carlos: works fine for me
<RicardoPerez> carlos: mmmmmm wait, please
<seb128> carlos: read what I just wrote
<carlos> seb128: yeah, thanks, as said got confused with what RicardoPerez said, and didn't check the content of the .mo file
<Mithrandir> seb128: is it a known bug that you get reasked for your keyring password when you resume from hibernate?
<seb128> Mithrandir: yes
<pitti> erm, 'bug'?
<cjwatson> Mithrandir: are you disabling shadow passwords?
<pitti> shuoldn't this be a feature?
<Mithrandir> cjwatson: no.
<Chipzz> pitti: heh. I was thinking the same thing ;)
<cjwatson> Mithrandir: then no, you can't
<Mithrandir> pitti: no?  I have my machine protected by a screensaver and login password.  Having me enter the login password again so I can connect to the wlan doesn't gain me any kind of security.
<Mithrandir> cjwatson: I could, if that makes it easier, though
<cjwatson> Mithrandir: regardless of what you preseed in user-setup, having shadow passwords turned on will hash it anyway
<pitti> Mithrandir: ah, so the screensaver should unlock it again, right
<pitti> Mithrandir: I just mean, putting the unencrypted password on disk during hibernation would be "eww"
<cjwatson> Mithrandir: ah, user-setup-ask won't allow it though
<Mithrandir> cjwatson: I'm preseeding and using -apply, though
<cjwatson> Mithrandir: so preseeding an encrypted password is the only way to do it
<cjwatson> you're using -apply directly rather than going via user-setup/
<cjwatson> ?
<Mithrandir> pitti: I think that's fine.  If people don't want that, use encrypted swap.
<Mithrandir> cjwatson: yes, I've basically copied what's in casper, but I want you to be able to log in using "ume" without even having to press enter for password.
<Mithrandir> but I guess I can live with having the user press enter.
<cjwatson> Mithrandir: um
<cjwatson> Mithrandir: if you set an empty encrypted password, they don't have to press enter for the password
<cjwatson> Mithrandir: try 'exec /sbin/getty 38400 tty1' at a vt on the live CD
<cjwatson> oh, hang on, that's not quite right
<Mithrandir> cjwatson: http://paste.ubuntu.com/539/ shows what I'm seeing
<cjwatson> Mithrandir: ok, sorry, I guess I'm confused
<cjwatson> Mithrandir: does pam handle the ume:: case specially then?
<Mithrandir> cjwatson: it seems so, yes.
<cjwatson> (empty password in /etc/passwd)
<Mithrandir> but if it's hard, I'll just document the password to be blank and people will have to live with that.
<Mithrandir> pitti: saving passwords on disk during hibernate> or are you advocating that ssh-agent should drop all keys when hibernating and all encrypted devices should be torn down?
<cjwatson> Mithrandir: ok, disable shadow passwords then
<cjwatson> you can reenable them afterwards if need be (I don't remember if shadowconfig calls pwconv, but I don't think so)
<Mithrandir> cjwatson: same problem
<Mithrandir> http://paste.ubuntu.com/540/
<pitti> Mithrandir: hm, certainly not; ah, ssh-agent doesn't use gnome-keyring?
<cjwatson> how did you disable shadow passwords?
<cjwatson> oh, I see
<Mithrandir> (I ran a deluser in between)
<Mithrandir> pitti: my ssh-agent doesn't use gnome-keyring at least.
<Mithrandir> (my ssh-agent is gpg, but that's slightly beside the point here. :-)
<cjwatson> Mithrandir: ah, it checks for the length of user-password-crypted
<cjwatson> Mithrandir: TBH, I'd just do it by hand rather than using user-setup if I were you
<Mithrandir> cjwatson: yeah, I can do that.  Or do user-setup-apply and then sed.
<cjwatson> I don't think it's buying you much
<Mithrandir> it's setting up sudo and putting the user in the right groups and such.
<Mithrandir> which is nice.
* pitti does a test installation with 'LVM/encrypted' and hopes for the best now
<cjwatson> Mithrandir: then sed sounds reasonable
<ringe> What program provides the password dialog when using update-manager? I need to adjust the Norwegian translation.
<mvo> ringe: gksu and libgksu
<seb128> carlos: why did you change the po export to use the application-po naming?
<carlos> seb128: you mean translationdomain-languagecode.po ?
<seb128> carlos: yes
<seb128> carlos: that was much nicer before
<seb128> carlos: to update the po of a package you just had to copy the po, now you have to script rename everything
<carlos> seb128: we got many complains about people not knowing for which translation was each file
<seb128> couldn't you use the domain as a directory?
<carlos> seb128: even with a single file download
<carlos> ?
<seb128> carlos: no, just when downloading the tar.gz for a package
<carlos> seb128: yeah, that should be doable. Could you file a bug report, please?
<seb128> carlos: will do, thanks
<pitti> carlos: ah, dapper delta langpack  export seems to have worked fine
<carlos> pitti: well, that's the idea of moving it to production servers ;-)
<Nafallo> why does trackerd eat one of my cores?
<Fujitsu> Nafallo: Because it is hungry, and seems incapable of not reindexing everything on boot.
<Nafallo> :-(
<seb128> Fujitsu: did you open a bug about that?
<carlos> pitti: are you going to upload that update to Dapper's -updates archive?
<pitti> carlos: no, to the PPA first
<Fujitsu> seb128: No, I presumed it was vaguely intended behaviour or I was doing something wrong. I fixed it with the usual apt-get remove :P
<carlos> pitti: ok
<pitti> carlos: when it has gotten some testing, to -proposed
<seb128> Fujitsu: ok, not really an useful comment nor behaviour
<carlos> and then to -updates, yeah, I was talking about the standard procedure :-P
<Nafallo> I've had this laptop on for quite some time though... I have no idea why it started chewing now.
<carlos> seb128: there is a bug about trackerd performance problem already
<carlos> Fujitsu: do you have latest version installed?
<seb128> carlos: it's about io though, no?
<Fujitsu> carlos: I removed it about a week ago.
<seb128> carlos: and not about reindexing everything at every reboot
<Fujitsu> I might try again, as the laptop isn't doing much useful at the moment.
<carlos> seb128: well, for me was a problem of IO and CPU with older versions
<carlos> I though the problem was that it was eating a lot of CPU
<Nafallo> I use latest (ofcourse)
<carlos> not that is reindexing everything
<seb128> carlos: if it's still doing it you should open a bug
<carlos> ok
<carlos> sorry
<Nafallo> I don't see much I/O either
<seb128> that's alright
<carlos> mixed Nafallo problem with Fujitsu one :-(
<Fujitsu> It's understandable that it would eat CPU initially, but not each time it starts.
<mjg59> It needs to rescan your home directory on every startup
<carlos> seb128: no, it's not doing it anymore with latest update
<mjg59> Otherwise it has no way of knowing whether new files have been created in between
<carlos> at least for me
<Nafallo> mjg59: you mean when the laptop has been off? it should detect that somehow...
<mjg59> But it should just scan, not actually re-index anything
<mjg59> Nafallo: How?
<Nafallo> mjg59: have no idea yet, but it would be damn nifty :-)
<carlos> time to leave, see you later
* carlos -> out
* Nafallo ponders how it checks if something has been changed.
<Nafallo> stealing one core, bringing me CPU to 100% scaling and 54C isn't really good...
<seb128> Nafallo: is it chocking on a file maybe?
<seb128> Nafallo: look at the running processus?
<Nafallo> hmm
<Fujitsu> I also noe that it didn't respond to SIGTERM when I tried to get rid of it.
<Fujitsu> *note
<Nafallo> ehrm... should `lsof | grep tracker` show /usr/share/locale-langpack stuff?
<Nafallo> I thought it would be in my homedir, not on the whole system
<seb128> Nafallo: yes, you can try with other applications as well they do the same
<Nafallo> hmm
<Nafallo> .evolution. my INBOX/summary.
<Nafallo> that should not bring the systems to it's knes though. can't be more then 15k mails...
<mjg59> Nafallo: tracker will have langpack stuff open in order to allow its messages to be localised
<Nafallo> mjg59: including rhythmbox.mo, eog.mo, serpentine.mo?
<mjg59> Nafallo: Oh, interesting. No clue in that case (and I don't see it here)
<Nafallo> hal, rhythmbox, eog, update-manager, gnome-control-center-2.0, serpentine...
<Nafallo> gnome-screensaver, glib20, tracker
<Nafallo> I can understand the last two... ;-)
<Nafallo> ofcourse they doesn't ship some debugtool...
<seb128> Nafallo: you can install tracker-utils
<Nafallo> ah, just noticed :-)
<Fujitsu> Or run trackerd with -v.
* Nafallo swipes his finger to sudo ;-)
<Nafallo> mjg59: I love that thinkfinger btw. we should have it OOTB in next release ;-)
<slangasek> bdmurray: bug #105682 - do we know the minimum memory requirement yet for LiveCD?
<ubotu> Launchpad bug 105682 in casper "[gutsy]  Tribe 5 amd64 needs more than 256MB of memory" [Medium,Confirmed]  https://launchpad.net/bugs/105682
<cjwatson> slangasek: the CD sleeves had to be finalised before beta, and we've put 384MB on them
<ogra> slangasek, it should still be 256M, the problem is shared vide ram here
<cjwatson> ogra: that's not clear
<ogra> at least i can install on 256M virtual machines here
<cjwatson> on the basis that if we had to blow past 256MB, going to 384MB wasn't much worse than 320MB
<ogra> with no probs ... (just slowness)
<slangasek> cjwatson: hum, ok. move to "wontfix"?
<cjwatson> slangasek: well. I'd like to fix it for hardy ...
<slangasek> ok
<slangasek> but for now it's not a milestoner
<cjwatson> right
<cjwatson> ogra: that's good to know, but it's pretty close to the wire and I think things like having firefox running are enough to push it over
<cjwatson> which is pretty hard to explain to users
<ogra> cjwatson, yeah, if i install on one of my thin clients with shared video ram it usually drops to 192M free ram or so that doesnt work
<ogra> (some of the via ones i have haven no acessible BIOS to change the values)
<cjwatson> humph, where did my post to the unionfs list go
<StevenK> cjwatson: It's waiting for another post to link it to.
* StevenK ducks
<cjwatson> hah
<StevenK> :-)
<slangasek> nah, unionfs has changed to strikefs for the day in solidarity with the DeutscheBahn workers
<ogra> LOL
<StevenK> Muahahaha
* Nafallo does not think tracker has an easy way of figuring out what file it is at ;-)
<Fujitsu> Nafallo: Running it with -v 3 or so tells you what it's doing.
<Nafallo> Fujitsu: that would mean I have to kill it, and from what I've seen so far I don't want to risk another re-index ;-)
<slangasek> pitti: how's the size on amd64 CDs at this point? (bug #134565)
<ubotu> Launchpad bug 134565 in ubuntu-meta "[tribe 5]  The installation CD does not contain full support for your language? (english-us dvorak)" [Medium,Confirmed]  https://launchpad.net/bugs/134565
<Fujitsu> Nafallo: True.
* Nafallo changes some options in the conf for next time.
<Nafallo> Fujitsu: any idea where it logs stuff if I bump -v in the conf?
<Fujitsu> Nafallo: No idea.
<Fujitsu> Probably still to stdout, so probably /dev/null.
* Nafallo has no /var/log/tracker :-P
<Nafallo> yea. a bit silly.
<pitti> slangasek: almost full; I had a look at putting it back yesterday, but it's still overflown
<pitti> slangasek: erm, I mean, it would be if we put it back
<slangasek> right
<pitti> slangasek: ATM I think we should look into OO.o downsizing
<pitti> slangasek: in particular, sanely drop ooo-base from the CDs and keep out lots of Java stuff that comes with it
<slangasek> could I assign this bug to you then?
<slangasek> hmm, does dropping portaudio out of OOo make much of a size difference? (bug #140673)
<ubotu> Launchpad bug 140673 in espeak "Espeak + portaudio v19 causes undesirable lock-ups." [Medium,Confirmed]  https://launchpad.net/bugs/140673
<TheMuso> slangasek: No, as there will be a version of portaudio around on the disk, for espeak's use.
<pitti> slangasek: nope, 40KB or so
<slangasek> TheMuso: ah, didn't realize it was there already, ok
<slangasek> pitti: so how much do we have to trim?
<slangasek> (to fit lang-mumble-en back on)
<ogra> cjwatson, will bug #22930 be fixed in libgtk or do you only work around it in ubiquity ?
<ubotu> Launchpad bug 22930 in gtk+2.0 "Newly-sensitive button ignores clicks until cursor re-enters it" [High,Confirmed]  https://launchpad.net/bugs/22930
<cjwatson> ogra: I've worked around it
<ogra> i imagine just fixing up the button click events centralized would make sense
<pitti> slangasek: 20.3 MB
<cjwatson> ogra: look at the upstream bug, it's nowhere near that simple
<ogra> hmm :/
<pitti> slangasek: that would be the full language-support-en; we can just install subsets, of course
<cjwatson> 110 comments and counting with a substantial design discussion
<cjwatson> ogra: and yes, it would make sense; however I don't know about you but I don't feel like overriding the design judgement of GTK+ upstream
<slangasek> pitti: so what's needed to make the dropping of ooo-base "sane"?
<cjwatson> :-)
<ogra> indeed, we wont fix the design now ...
<[miles] > hi
<ogra> i was more thinking about a general wrapper function
<pitti> slangasek: calc has details, but one thing I know of is to make writer say "please install -base" isntead of crashing when you try to open the bibliogrpahy
<slangasek> oh fun
<ogra> but i'm not much enough into gtk to judge it ...
<[miles] > I'm using kvm-45 and doing a boot on a ubuntu kernel image and initrd (off the CD), as /usr/local/kvm-45/bin/qemu-system-x86_64 -m 384 -hda gusty.img -cdrom /home/miles/Documents/isos/xubuntu-7.04-alternate-i386.iso -kernel /mnt/install/vmlinuz -initrd /mnt/install/initrd.gz -append "framebuffer=false" -std-vga
<[miles] > but it seems to ignore the append ....
<\sh> pitti, keescook , jdstrand : could you review #129771 and upload?
<[miles] > I actually need vga=791
<[miles] > or similar
* Nafallo ponders how often trackerd should IN REALITY check /proc/acpi/ac_adapter/AC/state
<[miles] > when booting the vmlinuz can I not use the same options as I would if I was booting from the menu?
<pitti> siretart: I updated bug 144390 with new data after testing the current daily alternate
<ubotu> Launchpad bug 144390 in cryptsetup "use entire disk with lvm/encrypted partitioning fails to boot" [High,Confirmed]  https://launchpad.net/bugs/144390
<Nafallo> jamiemcc: hi. are you here? I'm seeing oddities.
<pitti> slangasek: 20.3 MB is at least what apt-get install l-s-en wants to download on a freshly installed amd64 alternate
<[miles] > -append "install fbcon vga=791"
<[miles] > that neither
<[miles] > :-\
<pitti> slangasek: to be a 100% sure, I could just put it back and create new alternate images, so that we'll see what is left (some packages are already pulled in as dependencies of other packages, I figure)
<pitti> slangasek: doing that now
<slangasek> pitti: ok. and is alternate as full as Live?
<siretart> pitti: can I see somewhere which version of partman-crypto is on the alternate cd installed?
<pitti> slangasek: traditionally, alternate has more pressing space problems
<slangasek> ok then
<pitti> siretart: yes, in the .list files on cdimage
<pitti> siretart: however, I already checked that it is current
<siretart> pitti: and is /dev/mapper/ubuntu-root an LVM? didn't we agree that LVMs must not be UUID mangled?
<jamiemcc> Nafallo: hi whats up?
<siretart> wait. there is more fishy.. hmm
<pitti> siretart: yes, it is; sda5 is an encrypted partition with an LVM on it (swap and root)
<pitti> siretart: right, the udev update was supposed to not use UUIDs for lvm devices in fstab, AFAIUI
<Nafallo> jamiemcc: trackerd steals one of my cores at 100%, setting the cpufreq to 100% and temp to 54C. I'm trying to figure out why :-)
<siretart> pitti: hm. it would have worked if you wouldn't have named the LV ubuntu-root, but ubuntu-root_crypt
<cjwatson> ogra: not a good plan IMO
<pitti> siretart: maybe, but I didn't name them
<Nafallo> jamiemcc: tracker-status says indexing, attaching strace only shows LOTS of open("/proc/acpi/ac_adapter/AC/state", O_RDONLY|O_LARGEFILE) = 39
<siretart> cjwatson: is there some what we can enforce that naming?
<pitti> siretart: it's what partman-auto-crypt chose
<siretart> pitti: I see. I'd suggest then to fix partman-auto-crypt then..
<pitti> siretart: and we don't want to generally disable using UUIDs for LVM LVs?
<siretart> pitti: was that a statement or question?
<pitti> well, I figure the labels are much less unique than an UUID
<pitti> two parallel Ubuntu installations would clash
<pitti> siretart: a question, but I think I  just answered it myself
<cjwatson> siretart: um, if detecting it by name is unreliable then perhaps there's a better way
<slangasek> pitti: can the kernel successfully handle two VGs/LVs with identical names, anyway?
<siretart> what really fishy here is this:
<slangasek> (it would certainly be a pain to manage after the fact...!)
<pitti> slangasek: hm, I guess not
<siretart> the /etc/fstab was mangled from /dev/mapper/ubuntu-root to UUID, while according to /etc/cryptab, it should be /dev/mapper/sda5_crypt
<cjwatson> siretart: how about checking for the existence of the crypt_active file in partman's devices directory?
<pitti> slangasek: and I hope that the autopartitioner checks if a name is already present
<siretart> cjwatson: I didn't really understand yet how partman works in total. - need to look further at it
<cjwatson> though it does seem odd that the device isn't _crypt; partman-crypto seems to enforce that in some places at least
<pitti> well, the LV is *not* encrypted
<pitti> that might confuse it
<pitti> the PV is
<siretart> oh
<pitti> sda5 is a LUKS encrypted device which hosts the entire LVM
<siretart> good point
<pitti> and within that LVM there are just normal LVs
<siretart> pitti: how did you manage to boot the system then?
<pitti> i. e. from LVM's standpoint, not even the PV is encrypted
<pitti> siretart: just with the workaround mentioned in the bug: calling cryptsetup manually
<pitti> siretart: with this setup you already need to enter the passphrase during initramfs time, of course
<siretart> ok
<pitti> it's just a bit silly that the init script asks for it again
<Whoopie> Nafallo: the open("/proc/acpi/ac_adapter/AC/state") is a new feature that disables indexing while on battery.
<siretart> ok, so probably partman-crypto is fine then, and perhaps only the cryptroot hook that's broken
<TheMuso> ogra: Re edubuntu and accessibility/speech etc, as you said, portaudio isn't capable of whats required, and as it is, we have to go back to v18, due to some headaches v19 is causing. I'm hoping to spearhead some movement towards using something more uniform upstream, relating to how gnome-speech works. Either that, or Orca may use a different speech framework in the future. Either way, I'd like to keep the thin client framework in mind.
<Nafallo> Whoopie: I know. I was more amazed at the one per second poll ;-)
<ogra> TheMuso, well, if it would use the libasound2-plugins stuff that would suffice already for thin clients
<TheMuso> ogra: Right. I'm actually trying to push for a nice way for users to select which sound device is used for speech from the sound preferences.
<TheMuso> Or something along those lines.
<Whoopie> Nafallo: oh, that's quite counterproductive for battery saving ;) if it's also polling 1 per sec on battery.
<ogra> TheMuso, i suspect it reads /proc/asound/cards somehow instead of leaving that kind of stuff to alsa
<ogra> TheMuso, the virtual cards dont show up there
<Nafallo> Whoopie: didn't come that far ;-)
<ogra> we have a similar prob with kmix
<siretart> pitti: do you have the system still around and can do some tests for me?
<TheMuso> ogra: Right, nice to know, as I'd really like to get this done properly.
<pitti> siretart: I do
<pitti> siretart: yeah, happy to
<TheMuso> Its not right that thin clients miss out, particularly when accessibility is a big thing for education.
<ogra> yeah
<ogra> i would have at least esound support or something ... we have not many apps in ltsp that dont work since the sound system was switched
<TheMuso> Luckily, just about all hardware synths support callbacks, passing audio data directly back to the calling app, so its just a matter of making this all easy for the user.
<siretart> pitti: first please look at this file: http://codebrowse.launchpad.net/~ubuntu-core-dev/cryptsetup/ubuntu/annotate/siretart%40tauware.de-20070927173931-61pmahu54rhwhjri?file_id=readme.ubuntu-20070908164419-gq3j3r0yhc0bkymq-1
<ogra> s/have/have expected/
<siretart> the first tweak is in /etc/lvm/lvm.conf, please add a types line like in that file
<siretart> please check if the system boots with that change only
<mjg59> jamiemcc: If you don't have time to switch to using hal to determine battery events before release, could you change the g_timeout_add to g_timeout_add_seconds?
<pitti> siretart: booting... (it takes a while due to the 60 second timeout until I get the initramfs shell)
<TheMuso> ogra: I don't know whats planned at this point, but all I can do is keeep you posted about upstream's plans speech wise.
<siretart> pitti: you can shorten the timeout
<jamiemcc> mjg59: we use libhal in svn
<siretart> pitti: use rootdelay=10 for a 10 sek timout
<ogra> TheMuso,  that wuld be nice
<pitti> siretart: ah
<mjg59> jamiemcc: And that's going to make final?
<jamiemcc> we will release in next few days along with bug fixes and applet
<mjg59> bryce: Any chance of a fix in dexconf?
<siretart> pitti: if the lvm.conf change isn't enough, please also adapt /etc/crypttab like in the README.ubuntu
<mjg59> bryce: Rather than disabling horizontal edge scrolling with HorizScrollDelta, it should be using HorizEdgeScroll
<pitti> siretart: update-initramfs after changing lvm.conf?
<siretart> pitti: yes
<pitti> siretart: not sure whether that lvm.conf change makes sense; after all, I only need to cryptsetup luksOpen in initramfs; as soon as I do that, /dev/mapper/ubuntu-root etc. is created automatically
<siretart> pitti: you have a point somewhere
<siretart> pitti: perhaps the 2nd change is the important one then? 'lvm=sys-root'?
<pitti> trying
<siretart> pitti: it should be this for you, I think: "sda5_crypt /dev/disk/by-uuid/cfb63807-6da8-4dc9-93da-892e336c2fb7 none luks,lvm=ubuntu-root"
<pitti> siretart: that's what I added
<pitti> siretart: I updated initramfs, booting now
<pitti> siretart: it didn't help, and it would have been surprising, too
<pitti> siretart: after all, the initramfs cannot see *anything* LVMish at all until it luksOpens sda5
<siretart> pitti: okay. did you edit /etc/crypttab as well?
<siretart> read, append ',lvm=ubuntu-root'?
<pitti> ATM, root=/dev/mapper/ubuntu-root, but nothing tells the initramfs that this is actually on /dev/sda5?
<pitti> siretart: yes, that's what I did
<pitti> siretart: oh, I didn't do the lvm.conf change
<siretart> ok
<pitti> siretart: but crypttab is not in the initramfs
<siretart> not as crypttab, but it shoudl be as /conf/cryproot.conf or something
<pitti> siretart: does the initramfs script have code to invoke luksOpen and thus ask for the password?
<pitti>  /conf/conf.d/cryptsetup just has "KEYMAP=y"
<siretart> err, sure. thats the point of the cryptroot hook
<siretart> ok, this means the cryptroot-hook didn't find the root volume then
<siretart> I need to look deeper in the cryptroot hook then, perhaps the output of dmsetup looks different in ubuntu to debian or something
* Fujitsu wonders why it doesn't work for us, when it does for Debian, and has for at least a year.
<pitti> siretart: shall I try mangling fstab to use /dev/mapper names instead of UUIDs?
<pitti> Fujitsu: no UUIDs in Debian
<Fujitsu> pitti: Ah, that'd do it.
<pitti> siretart: trying
<pitti> slangasek: http://cdimage.ubuntu.com/daily/20071002.1/
<pitti> slangasek: so yes, we indeed need 20.3 MB
<slangasek> ok
<siretart> try it, but I haven't understood yet how the cryptroot hook is supposed to find a crypted pv
<pitti> slangasek: I wonder why it is so much bigger than the i386 one...
<slangasek> pitti: because every pointer or long takes up twice as much space in each binary? :)
<pitti> slangasek: well, yes, but I don't remember that the size differences were that drastic
<StevenK> I thought devmapper names weren't UUID-converted ...?
<pitti> slangasek: hm, it just occured to me: traditionally the i386 alternate had much more language pack stuff on it
<pitti> StevenK: apparently they are
<siretart> StevenK: I'm surprised, too
<slangasek> pitti: looks like a 2% difference in size between amd64 and i386 alternate, that doesn't seem out of line with what I'm familiar with
<pitti> siretart: oh, update-initramfs complains about "invalid line in cryptsetup"
<seb128> StevenK: could you look at bug #148049? That has been introduced with your update
<ubotu> Launchpad bug 148049 in gimp "[Gutsy]  Please, add the 'X-Ubuntu-Gettext-Domain=gimp20' line into the .desktop file" [Undecided,New]  https://launchpad.net/bugs/148049
<pitti> slangasek: right; it's just because gutsy is the first release without any langpacks on the alternates
<pitti> yay @ growth
<slangasek> (hey, at least it's not alpha, which is 64-bit /and/ RISC instruction set... :)
<siretart> pitti: that'll be the bug
<siretart> pitti: I'm currently installing a similar system on real hardware right now, but that will take some time (a few hours, I'd expect)
<pitti> siretart: ah, in the recipe you gave me, the crypttab line mentions the real HW partition, I think
<StevenK> seb128: Shall do.
<seb128> StevenK: thanks
<asac> siretart: ... what kind of integration of NM/wpasupplicant do you mean?
<pitti> siretart: hm, it still considers "sda5_crypt /dev/sda5 none luks,lvm=ubuntu-root" as invalid
<slangasek> pitti: what's the 'lvm=' option for?
<pitti> slangasek: just following the recipe on http://codebrowse.launchpad.net/~ubuntu-core-dev/cryptsetup/ubuntu/annotate/siretart%40tauware.de-20070927173931-61pmahu54rhwhjri?file_id=readme.ubuntu-20070908164419-gq3j3r0yhc0bkymq-1
<siretart> asac: I had a strange behavior before: I moved to my office, where I have wired, and no wireless
<siretart> asac: so I switched the wifi kill switch on
<siretart> asac: NM was complaining in daemon.log that it couldn't scan, and wouldn't use my wired interface
<siretart> asac: however, it was complaining that wpasupplicant wouldn't respond. no suprise, since there was no wpa_supplicant daemon running
<siretart> asac: ah, that was right after a resume
<siretart> asac: my question now is: why doesn't nm detect that there is no wpa_supplicant running anymore?
<asac> siretart: good question ... why did wpasupplicant die in the first place?
<slangasek> pitti: well, at least under Debian I had no need for an "lvm=" option in my crypttab, and it's not documented in crypttab(5)
<slangasek> (incl. in gutsy)
<pitti> right, trying to remove that now
<pitti> WTH? It still complains about "sda5_crypt /dev/sda5 none luks"
<asac> siretart: did it crash?
<siretart> asac: I don't have a crashreport for it, but I'm not sure if it crashed or not
<pitti> ah, it might stumble over the two different plaintext dm devices that I used: 'mylvm' in initramfs, and sda5_crypt in crypttab
<asac> siretart: but suspend/resume usually works for you?
<pitti> siretart: right, if I use "sda5_crypt" in the initramfs cryptsetup call, then I don't get asked again, and things seem to be a bit saner
<pitti> siretart, slangasek: yay! works now
<jono> are other people experiencing trackerd taking up the majority of CPU time?
<jono> its hammering my system
<pitti> ok, I'll reinstall the system from scratch, do a vmware snapshot this time, and investigate further
<StevenK> jono: The queue starts over -----> there
<jono> StevenK: right :)
<TheMuso> StevenK: heh
<StevenK> seb128: I see what's going on with gimp. Just firing off a test build.
<pitti> siretart: wow, that even works with usplash now, although it's dark blue on black and hard to read
<StevenK> pitti: Security through making you squint and guess?
<pitti> StevenK: the entire initramfs scripts chain is still miraculous to me
<StevenK> Hah
<pitti> StevenK: well, it can't get more secure than in current gutsy - nobody *at all* can access the HD :)
<StevenK> "So Martin, how does an Ubuntu system boot?" '*shrug* Magic!'
<pitti> but I guess we should poke a hole for the legitimate user
<Keybuk> StevenK: I have to keep some people in awe of me, otherwise everyone would be able to boot Ubuntu by hand and I'd need a new party trick
<StevenK> Keybuk: :-)
<Keybuk> (more seriously, I'm happy to answer to answer any questions you might have)
<ogra> StevenK, Keybuk prepares for later ... if he once stops at canonical he'll sell support for upstart users ;) indeed that requires some eastereggs to generate enlough :)
<StevenK> Bwahaha
<siretart> pitti: what?!
<Fujitsu> Wasn't the usplash patch dropped?
<pitti> siretart: (just kidding with StevenK)
<siretart> asac: suspend does work
<siretart> pitti: so what's wrong in the end? what change is needed now?
<pitti> siretart: hold on, I'll find it out and comment in the bug; new install is running (I screwed up too much without making proper backups, and I want to be sure)
<ogra> siretart, lucky you ... i'd be happy if nm-applet would actually survive switching networks here
<asac> siretart: do you still have the daemon.log of that incident?
<pitti> siretart: I think we only need to put the right physical device into crypttab
<asac> ogra: bug?
<pitti> siretart: lvm.conf and even fstab might be just fine
<pitti> siretart: it would be cool to leave the lvm UUIDs in fstab, just for general compatibilty with handling of non-LVM devices
<asac> ogra: does nm crash? or applet?
<ogra> asac, none yet, i just discovered that nm-applet doent want to connect to a new one if the network i'm currently connected to gets out of reach
<pitti> siretart: just need to find out whether get_root_device() etc. in /usr/share/initramfs-tools/hooks/cryptroot get along with UUIDs
<ogra> asac, after about 20 min manual fiddling with iwconfig i get online with the network i want but n then vanishes from the panel after some time
<ogra> s/n/nm/
<asac> ogra: can you show me your syslog?
<ogra> ogra@laptop:~$ ps ax|grep nm
<ogra> 22171 ?        S      0:00 nm-applet
<ogra> btw ...
<siretart> asac: http://paste.ubuntu.com/544/
<ogra> it just doesnt show up
<asac> ogra: thats likely because NetworkManager has crashed
<siretart> pitti: yes, that function is critical here..
<asac> ogra: please paste the log so i can verify
<asac> siretart: ok is that reproducible?
<siretart> asac: I'll investigate. right now I'm a t work, and have no wireless
<asac> siretart: this might be fixed by patch in bug 145683
<ubotu> Launchpad bug 145683 in network-manager "Network manager crash with WPA" [High,Incomplete]  https://launchpad.net/bugs/145683
<ogra> asac, http://people.ubuntu.com/~ogra/nm-syslog
<siretart> asac: I fixed it by manually restarting nm: /etc/dbus*/event.d/2{6,5} {stop,start}
<asac> ogra: same for you: would be great if you could test patch from bug 145683
<siretart> asac: the patch looks promising, indeed
<ogra> i use WEP btw
<siretart> pitti: with the right physical device, you men /dev/sda5 instead of /dev/disk/by-uuid/dead-beef-...?
<pitti> siretart: it would be a step backwards, yes :/
<pitti> siretart: I'll have a deeper look at those scripts
<siretart> still installing my test machine
<pitti> siretart: add_device() in the hook is responsible for translating crypttab and fstab into a /conf/conf.d/cryptroot option in the initramfs; if we could get that to work with UUIDs, we would have won
<siretart> slangasek: how about introducing a new release goal for lenny: "make /etc/fstab use UUID by default"? ;)
<siretart> pitti: yes, I was looking at that part before, but I abandoned it by rethinking the case. that's the part that assumes that /etc/fstab and /etc/crypttab are in sync
<asac> ogra: siretart: just uploaded a test package with that patch to my ppa: https://edge.launchpad.net/~asac/+archive ... should show up there soon
<asac> ogra: yes WEP or WPA doesn't make a difference ... both use wpasupplicant
<ogra> asac, will test it, thanks
<lamont> cjwatson: and yet I would guess that we're more likely to have dual-booters than debian...
<seb128> pitti: what do you think about moving gimp-gnomevfs to the desktop seed?
* ogra knows what pitti thinks first :) "how big is it ?" 
<pitti> indeed :)
<soren> |<------->|  This big.
<soren> (not to scale)
<ogra> soren, at what DPI ?
<pitti> 384 kB
<soren> ogra: All of them.
<ogra> whee
<ogra> thats tiny then :)
<soren> That's what she said :(
<ogra> lol
<pitti> well, given that we are 20 MB oversized, nothing is tiny
<seb128> and most of it is NEWS and changelogs
<soren> \o/
<seb128> the plugin itself is 13k
<cjwatson> lamont: Ted is mistaken if he thinks I ever claimed this wasn't a bug
<cjwatson> he is simply confusing "haven't done it yet" with "refuse to do it"
<asac> pitti: are we really going to release oversized?
<cjwatson> asac: no
<lamont> cjwatson: ah, ok
<seb128> pitti: bug #146290 for some context
<pitti> asac: of course not; we'll need to chop off some things from OO.o
<ubotu> Launchpad bug 146290 in gimp "gimp "open from url" doesn't work" [Low,Triaged]  https://launchpad.net/bugs/146290
<cjwatson> asac: oversizedness (at least of certain images) is a release blocker and MUST be fixed
<ogra> asac, we'Re working on it, but the bad pitti always interferes
<pitti> Also, we could take off language-support-en from amd64 alternate again
<asac> cjwatson: yes ... i hoped so. Was just a bit confused
<lamont> cjwatson: so does that mean that there will need to be an upload that adds back in hwclockfirst.sh?
<pitti> I just added it because usually we'd want it to be there
<cjwatson> lamont: I don't understand
<seb128> pitti: so about gimp-gnomevfs?
<pitti> seb128: TBH I'd put a ban on seed additions until we sort out the existing overflow
<seb128> ok
<pitti> also, we are well past FF and everything
<seb128> pitti: well, that's a binary from the gimp source
<seb128> and it'll create regressions on upgrade
<seb128> it was not splitted in feisty
<seb128> opening a location
<seb128> or clicking on an image from nautilus in a non local directory will not work
<lamont> cjwatson: hwclockfirst is setting the clock according to UTC prior to mounting root, so that fsck isn't b0rked wrt mounting it.
<seb128> which is something users probably expect to work correctly
<lamont> specifically, users east of Greenwich, who keep BIOS in localtime (because of dual boot), are the affected class.
<jdstrand> \sh thanks for the debdiff for #129771
<cjwatson> lamont: I don't understand enough of this (by which I mean I don't have enough state because I haven't spent enough time with it) to claim anything with certainty. Somebody who does understand it needs to propose the correct fixes, which may or may not involve installer changes (although new UI is out of the question at this point).
<cjwatson> lamont: but anyone asking me what to do about this issue is on a hiding to nothing. :-)
<Whoopie> asac: Hi, latest update to network-manager-openvpn breaks my VPN. I get :"Oct  2 12:47:41 gutsy nm-openvpn[3523] : script failed: shell command exited with error status: 139" in syslog. Any ideas?
<Whoopie> seb128: could we fix bug 144122? I could make a patch if needed.
<ubotu> Launchpad bug 144122 in pidgin "Pidgin 2.2.0 Forgets Plugin Selections (Ubuntu Gusty x86 Tribe 5)" [Undecided,New]  https://launchpad.net/bugs/144122
<seb128> Whoopie: could you summarize the issue, I'm sort of busy and the comments go on several pages there
<Whoopie> seb128: sure, let me make a patch. It's a two-liner. problem is in the default prefs.xml.
<asac> Whoopie: maybe ask pkern who uploaded the last update
<asac> Whoopie: and open a bug
<asac> Whoopie: #147941 looks like your bug
<Whoopie> seb128: http://en.pastebin.ca/722882
<Whoopie> seb128: type must be changed to "pathlist" and the docklet doesn't exist anymore.
<Whoopie> asac: ah, right. thanks
<StevenK> seb128: gimp fixed, I'll upload shortly.
<seb128> StevenK: thanks
<lamont> cjwatson: without the "UTC or local" quesiton in ubiquity/gutsy, we're looking at hardy to fix the issue for ubuntu --> no need to upload a new util-linux at this point;
<cjwatson> lamont: I've added it to my UDS agenda in progress
<cjwatson> lamont: can't we make it better for those east of Greenwich all the same?
<cjwatson> lamont: actually, bear in mind that d-i often still does ask the UTC/local question
<lamont> cjwatson: ok.  with the question, it's a trivial fix (add hwclockfirst.sh back in - already done for debian, just need to stop dropping that change on merge...
<cjwatson> lamont: so given that that's there, can we do better for d-i?
<lamont> ah, ok
<lamont> if the question is there, then we can certainly do better for those who were able to answer 'local' (those saying 'UTC' already win)
<cjwatson> in fact, our d-i asks the question under slightly *more* circumstances than Debian does
<cjwatson> we ask it (defaulting to UTC) even if we appear to be the only OS on the system
<cjwatson> cf. bug 28961
<ubotu> Launchpad bug 28961 in clock-setup "installer assumes system time is UTC" [High,Fix released]  https://launchpad.net/bugs/28961
<lamont> so.. the question the becomes: after reviewing the change log for 2.13-8 in incoming, would you prefer -6ubuntu2, or -8ubuntu1 ?
* lamont kinda expects -6ubuntu2, but is happy with either
<pkern> I got an apport crash dump and I need a retrace. apport-retrace chokes on me, what should I do?
<cjwatson>      - mount: doesn't drop privileges properly when calling helpers
<cjwatson> lamont: is that a security issue?
* lamont isn't sure, looks at the diff
<cjwatson> lamont: anyway, release team's call
<lamont> doh
<lamont> -		 setuid(getuid());
<lamont> -		 setgid(getgid());
<lamont> +		 if(setgid(getgid()) < 0)
<lamont> +			 die(EX_FAIL, _("mount: cannot set group id: %s"), strerror(errno));
<lamont> could be.
<lamont> (there's more, chopped for brevity)
<lamont>     {,u}mount calls setuid() and setgid() in the wrong order and doesn't checking
<lamont>     the return value of set{u,g}id(() when running helpers like mount.nfs.
<lamont> for the longer commit comment part
<lamont> we probably want that one...
<\sh> jdstrand, np
<pkern> pitti: How could I file a bug having only a .crash file for a different architecture to request a retrace?
<pitti> pkern: Can you please try /usr/share/apport/apport-gtk -c /path/to/crash/file?
<Whoopie> pkern: Hi, just fyi, I'm also affected by latest nm-openvpn update. If you need any testing...
<pitti> pkern: it might complain about a few things, the tag will be wrong, and the backtrace entirely unusable, but once we fix the need-$arch-retrace tag, things should work
<Kopfgeldjaeger> hi
<seb128> Whoopie: thanks for the patch, I've uploaded a new package revision with it now
<pkern> pitti: apport-cli refuses to work (see https://bugs.edge.launchpad.net/ubuntu/+source/network-manager-openvpn/+bug/148088)
<ubotu> Launchpad bug 148088 in network-manager-openvpn "[apport]  need retrace" [Undecided,Invalid] 
<pkern> pitti: i.e. it reports a bug but does not attach s.th. sensible
<pkern> And apport-gtk reports "obsolete" packages (for which I have reported a seperate bug...)
<pitti> pkern: that does not have a core dump, hmm
<pitti> pkern: obsolete packages> hm, that's kind of a feature
<pkern> pitti: But I need an override for this.
<pkern> pitti: My gutsy is current.
<pitti> pkern: you cannot retrace the crash file on the system where it crashed?
<pitti> pkern: oh, I almost forgot: congratulations for becoming an official dev!
<pkern> pitti: I got it submitted via a bugreport. They were vary because of private information (but then still posted it... meh.)
<pkern> pitti: Thank you. (:
<pitti> ah
<pitti> pkern: which arch?
<pkern> pitti: i386
<pitti> pkern: so someone on i386 could just manually use apport-retrace on the crash file
<pkern> pitti: ACK
<Whoopie> seb128: great, thanks!
<seb128> Whoopie: thank you for working on the patch ;)
<pkern> *debootstrap --arch i386 gutsy /opt/gutsy-i386 http://de.archive.ubuntu.com/ubuntu*
<jdstrand> pitti: re bug #119075
<ubotu> Launchpad bug 119075 in mysql-dfsg-5.0 "Root password policy for mysql" [High,Confirmed]  https://launchpad.net/bugs/119075
<jdstrand> pitti: what are your thoughts on a retroactive fix back to dapper?
<pitti> jdstrand: so, the root of all evil from what I can see, is that mysql needs a root password in the first place
<jdstrand> pitti: yes
<pitti> jdstrand: so the Debian packages both set a root password and also install this weird system user which somehow circumvents the auth mechanism for upgrades, etc. (not sure about the details)
<jdstrand> pitti: and dapper through feisty one is not created, as the user is never prompted
<pitti> jdstrand: I'm not so sure about a retroactive fix; once this is set up, it's hard to upgrade that setup to a new system
<jdstrand> pitti: I haven't gone through all the debconf in great depth, but feisty has a mechanism to get the password
<pitti> but for new installations that shuold be fixed
<jdstrand> pitti: it just never happens
<jdstrand> pitti: dapper has only a note about needing to set it, but it is never seen
<pitti> jdstrand: so for dapper to feisty we should just reactivate the root pw question, I think
<pitti> jdstrand: and for hardy I think that the root pw should disappear entirely
<pitti> jdstrand: and instead the daemon should allow passwordless connections from the root user
<pitti> jdstrand: since root can mangle all the db files anyway
* lamont does a few more trigger-uploads.  sigh.
<pitti> lamont: out of interest, why don't give-backs work?
<jdstrand> pitti: re hardy, that is fine by me, assuming it doesn't introduce any other problems, but those can be ironed out
<lamont> pitti: no build record.  go launchpad
<pitti> jdstrand: I just envision "allow root without password" (with unix socket peer credential checking), drop that system user, don't set a root password; simple and robust IMHO
<jdstrand> pitti: my concern for now is dealing with existing and new installations on releases (and possibly gutsy-- haven't looked at it yet)
<lamont> OTOH, if we're lucky, we'll get the fix in LP shortly.
<pitti> jdstrand: for those, I think we should just appropriately bump the debconf questino priority so that it will actually be seen
<lamont> these uploads get us debootstrapability
<jdstrand> pitti: it may be more complicated than that in feisty-- I think there may be a timing issue of when mysql is started and the passwordless check is made
<jdstrand> pitti: but bottom line is that you think that new installs should be fixed, and existing should not be touched, correct?
<pitti> jdstrand: hm; sorry, I never actually used mysql, so I'm not sure about the details
<pitti> jdstrand: well, if we can fix existing passwordless installations in a sane way, I'm all for it
<jdstrand> pitti: I am only just diving into the issue myself
<jdstrand> pitti: alright.  as you know, I have several mysql updates anyway.  so I'll work on it, submit for peer review, and roll it into those updates if appropriate
<pitti> jdstrand: thanks; I'm happy to take a look at the patches; keescook will be as well, I figure
<pitti> jdstrand: soren also already looked into those packages, he might have some ideas in his head still
<jdstrand> pitti: thanks.  yes keescook is always helpful.
<pitti> jdstrand: thanks for looking into that long-standing wart
<jdstrand> soren: re bug #119075.  I'd like to retroactively fix the passwordless root user issue.  Thoughts?
<jdstrand> pitti: np
<ubotu> Launchpad bug 119075 in mysql-dfsg-5.0 "Root password policy for mysql" [High,Confirmed]  https://launchpad.net/bugs/119075
<siretart> pitti: did you mean before that all what's necessary is to fix the 2nd column in /etc/crypttab?
<superm1> mvo, you here?
<mvo> superm1: yes
<superm1> hi mvo, just wanted to touch bases with you regarding our discussion last week
<superm1> i checked our old disk (from around 08-30), and it had an older python-apt installed when it was functional
<mvo> superm1: nothing new from my side unfortunately. could you please check what version of python-apt was installed so that I can review the debdiff?
<superm1> so i upgraded python-apt after it booted and upgraded ubiquity to current, and the stalling problem didn't appear to occur
<superm1> so i was leaning towards it indeed being unionfs related
<glatzor> ping bryce
<superm1> mvo, you were however saying that the cache.open(None) call probably wasn't necessary at that point anyhow though, correct?
<mvo> superm1: if it is only used to check for broken packages, then no, that will be detected during the installation and InstallProgress.error() is called
<superm1> mvo, well i think i'll just do a ppa build of ubiquity with those disabled, and discuss further with cjwatson before committing it to trunk.  i can at least release the beta disk with the ppa/ubiquity then
<StevenK> pitti: So, I'm going to look at getting the -mobile stuff promoted from universe to main - I had a few questions, have you got a few seconds?
<soren> pitti, jdstrand: I don't think it's a very good idea to change the priority of the debconf question in dapper->feisty.
<soren> pitti, jdstrand: It could potentially automatic install procedures people have set up.
<soren> pitti, jdstrand: Er... It potentially *break* ...
<jdstrand> soren: right.  IMO this a serious problem though, and a fix needs to be done.  Yur argument, while valid, would really mean we have no way to retroactively fix the problem
<jdstrand> soren: because no matter what we do, we will change the process
<soren> jdstrand: "the problem" is bug #119075 ?
<ubotu> Launchpad bug 119075 in mysql-dfsg-5.0 "Root password policy for mysql" [High,Confirmed]  https://launchpad.net/bugs/119075
<jdstrand> s/process/install process/
<soren> jdstrand: I'm a bit short of context here..
<jdstrand> soren: yes.  the 'problem' is that all dapper-feisty (and maybe gutsy) installs default to passwordless mysql root user.  any local user can simply do 'mysql -u root -p', press enter and have full access to the db
<jdstrand> soren: remote users could get to that via scripts too
<soren> jdstrand: I know, I know.
<soren> I have a patch that fixes this differently, though.
<jdstrand> soren: do tell
<soren> pitti rejected it at first, but given we don't have time for the "right" solution, it might make sense anyhow.
<soren> gah.. phone call.
<soren> back
<soren> It (ab)uses the debian-sys-maint user to implement a "/etc/init.d/mysql reset_passwd" kind of thing.
<soren> I don't recall the details.. I'll find it. Hang on.
<soren> found it. Hang on, I'll upload it somewhere.
<soren> http://people.ubuntu.com/~soren/mysql_rootpw_draft_fix.diff
<jdstrand> soren: reading...
<jdstrand> soren, pitti: why was it rejected? (I'll admit that it is a little odd that configuration is happening in sysv, but might be worth another look for a retroactive fix)
<jdstrand> soren: it seems mysql will not start if /etc/mysql/warn_on_startup exists
<dholbach> calc: bug 135086?
<ubotu> Launchpad bug 135086 in unzip "zipgrep: exit code always 0" [Unknown,Confirmed]  https://launchpad.net/bugs/135086
<jdstrand> soren: that would need to change
<dholbach> Riddell: bug 136425, bug 121872?
<ubotu> Launchpad bug 136425 in qt4-x11 "qtconfig-qt4 in Accessories?" [Undecided,Confirmed]  https://launchpad.net/bugs/136425
<ubotu> Launchpad bug 121872 in qt4-x11 "*-qt4 tools should be present in $QTDIR/bin" [Undecided,In progress]  https://launchpad.net/bugs/121872
<soren> jdstrand: True, that seems to be the case now.
<jdstrand> soren: but the basic idea of setting a random password and letting the users know about it seems like a good one
<Riddell> dholbach: still on my todo
<dholbach> it'd be nice if you could at least let the patch author know about that
<dholbach> I know that you're busy
<soren> jdstrand: Right. I believe pitti rejected it because he wanted to entirely get rid of the debian-sys-maint user.
<jdstrand> soren: I can understand that, and like the ideas for moving forward with hardy.
<soren> jdstrand: Yeah.
<jdstrand> soren: as this user exists in dapper-feisty (and have to check gutsy), then this may be the way to go
<soren> jdstrand: We should get someone with strong C++-fu to do it.
<soren> jdstrand: I was actively working on this when it was dropped. The patch you see there is a snapshot of what I found lying around in my source directory.
<soren> jdstrand: It needs a thorough looking at.
* soren goes to fetch a cup of coffee.
<jdstrand> soren: right.  as you know, I am working up several updates
<jdong> can anyone comment on the sanity of replacing syslogd with syslog-ng in an Ubuntu install, or otherwise doing filtering on syslog entries?
<jdong> some noisy apparmor rulesets are making messages.log grow by like 25MB/day
<jdstrand> soren: I'll will go through this and, like I told pitti, submit the work for peer review
<jdstrand> soren: thanks *so* much for the patch.  It'll be a great start!
<cjwatson> mvo: in superm1's tests, removing cache.open(None) causes ubiquity's broken_packages function immediately following to return incorrect results
<cjwatson> mvo: broken_packages is http://paste.ubuntu.com/549/
<pitti> siretart: sorry, I didn't have time yet to continue debugging; will do in a bit
<siretart> ok
<pitti> StevenK: go ahead with the questions about mobile
<pitti> soren: raising  debconf prio in stables> I agree; that's why I said if it can be fixed sensibly, I'm all for it
<pitti> jdstrand, soren: another possibility is to disable empty root passwords on upgrades
<StevenK> pitti: I'm going to file a bunch of bugs about stuff that should be promoted, who should I subscribe, and do I need to put any details in the bug itself apart from "<blah> needs to be checked if it can be promoted" ?
<jdstrand> pitti: my initial thoughts were on upgrade, use a variation of soren's patch and just change the password, and be noisy in the logs about it
<mvo> cjwatson: I will look in a bit (phonecall)
<cjwatson> thanks
<jdstrand> pitti: but under no circumstances keep mysql from starting
<soren> jdstrand: ..my patch logs the message and outputs it on the console, too. That should make it pretty obvious for most people.
<jdstrand> soren: right
<jdstrand> soren: I liked that
<pitti> jdstrand: yeah, sounds good; I rejected the patch back then since we had loads of time in gutsy to fix it properly
<soren> jdstrand: Agreed. That's an artifact of the fact that I dropped it in the middle of development/testing.
<soren> pitti: Yeah, those were the days. :(
<pitti> StevenK: does the mobile stuff need to go into gutsy main?
<StevenK> pitti: Yup
<pitti> eww
<soren> jdstrand: How's your C++?
<pitti> StevenK: so yeah, I think a bug with appropriate tasks will do
<StevenK> pitti: Right, one bug, with a whole bunch of tasks.
<jdstrand> soren: good enough to read and patch, but probably not good enough to do what you are thinking of asking me.  ;)
<soren> jdstrand: Me neither. C++ scares the shit of me.
* soren is deeply ashamed that C++ was designed by a Dane.
<jdstrand> soren: I wouldn't mind revisiting it if noone steps up, but my plate is pretty full atm
<StevenK> Hahah
<jdstrand> soren: haha
<StevenK> pitti: Subscribe both you and iwj to it?
<jdstrand> soren: I assume you are talking about for hardy?
<soren> jdstrand: Oh, yes.
<pitti> StevenK: that would be good
<StevenK> pitti: Okay, cool. I'll look at it tomorrow. Er, later today. :-)
<lamont> pitti: any chance of processing bug 144364 today?
<ubotu> Launchpad bug 144364 in expect "Please sync expect (main) from Debian unstable (main)" [Undecided,Confirmed]  https://launchpad.net/bugs/144364
<soren> jdstrand: I'm not even that comfortable getting the patch I wrote into gutsy.. Anything more intrusive than that will keep me awake at night(!).
* lamont isn't sure whether to close that as a dup of bug 137837 or the other way, or just leave both open and close the latter once the former is closed
<ubotu> Launchpad bug 137837 in expect "expect ftbfs on ia64" [High,Fix committed]  https://launchpad.net/bugs/137837
<jdstrand> soren: well, ping me post-UDS and maybe we look at it more
<soren> jdstrand: or during UDS, perhaps.
<pitti> lamont: doing
<jdstrand> soren: you're not going to make me pack my C++ books are you?
<soren> jdstrand: I looked at the mysql code back in the day to figure out how difficult it would be. I think I know what it takes, but... it's c++.
<soren> jdstrand: No, please don't.
<soren> jdstrand: We need all the good karma we can get .
<jdstrand> heh
<pitti> lamont: done
<lamont> pitti: does the processing auto-close 144364? or should I do that?
<pitti> lamont: I closed the bug already
<pitti> it's part of the sync ceremony
<lamont> doh
<bddebian> Heya
* lamont marks 137837 as dup of 144364
<jdong> am I being retarded, or is there no way in sshd to disable port forwarding by user?
<jdong> some sites reference this AllowTcpForwardingUsers style option but I don't think it exists?
<cjwatson> jdong: you can use PermitOpen within a Match block
<cjwatson> oh, actually, you can use AllowTcpForwarding within a Match block, which is better
<cjwatson> so e.g.:
<jdong> cjwatson: what is a match block?
<cjwatson> Match user cjwatson
<cjwatson> er
<cjwatson> Match User cjwatson
<cjwatson>         AllowTcpForwarding no
<cjwatson> jdong: I trust you know about sshd_config(5) ...
<jdong> I'm reading the manpage
<jdong> but don't see this Match syntax in there
<jdong> OH
<jdong> pfft
<cjwatson> version of sshd?
<jdong> I feel retarded
<jdong> was searching halfway down the page :)
<cjwatson> hah
<iwj> So if I find someone has erroneously marked some bug a duplicate of some other bug and I would like to point it out to them, how should I do this ?  Their LP profile does not appear to show any email addresses.
<pochu> you can comment on the bug they marked as a dup, maybe?
<iwj> No, because it's all irrelevant and they're not subscribed.
<iwj> And anyway that's just noise for the other subscribers.
<pochu> True that (though for the first you can subscribe someone else ;) )
<jdong> cjwatson: that worked great, thanks. Just to clarify, there is no way to end a match block other than EOF or a second match block right?
<cjwatson> jdong: not as far as I know
<dobey> how does one get dpkg-buildpkg to create a -dbg package?
<lamont> dobey: one adds the necessary steps to debian/rules
<iwj> What I want is https://launchpad.net/~spqr1/+filebug :-)
<dobey> do you have to also add stuff to debian/control for it?
<dholbach> dobey: you can install pkg-create-dbgsym and just run debuild
<dholbach> dobey: it will create -dbgsym.ddeb
<dobey> rock
<lamont> dholbach: cool
<pochu> iwj: lol, I knew people had bugs, but I didn't knew they could be fixed
<pochu> s/knew/know
<dholbach> pitti: is bug 90286 on your list?
<ubotu> Launchpad bug 90286 in hal-info "USB flash drive recognized as a music player" [Medium,Confirmed]  https://launchpad.net/bugs/90286
<pitti> dholbach: I'll get to it, thanks
<asac> ogra: no idea how long i386 in ppa will take ... if you don't have amd64 to test, please get the sources from http://ppa.launchpad.net/asac/ubuntu/pool/main/n/network-manager/
<dholbach> pitti: thanks
<ogra> asac, will do ... i had a weird behavior before where NM was flipping networks all the time
<ogra> right after upgrading to the latest oe from the archive
<asac> ogra: oe?
<ogra> it doesnt do that after a reboot anymore though, but i didnt mover through the house yet
<ogra> *one
<asac> ogra: ok, please test then asap ;)
<ogra> will do, though my machine is currently doing a virtualbox install ... will take a while until i can compile
<asac> ogra: virtual box? did you manage to finish normal CD install? Last time i tried I had issues with writing the boot record.
<bdmurray> slangasek: No, I'm not certain what the minimum memory is.  My primary testing system has Compiz enabled by default so my results may be skewed.
<ogra> asac, i always do my first tests in vbox ... usually that works fine here, but the default CD for edubuntu isnt -desktop so my HW requirements are way lower
<asac> pitti: NN has sigaction for SIGSEGV for example. Is a raise(sig) enough to produce proper core-dumps?
<pitti> asac: should, yes
<pitti> asac: if you reset to SIG_DFL properly, of course :)
<asac> pitti: right ... though i am inclined to stop NM to catch those signals at all. It just tries to create a backtrace which is obviously useless for us.
<pitti> asac: right, at least without debug symbols
<seb128> pitti: do you have some ideas about what's going on there, bug #145866
<ubotu> Launchpad bug 145866 in gnome-session "system sounds do not play" [Undecided,Invalid]  https://launchpad.net/bugs/145866
<seb128> pitti: bug comment 8
<glatzor> ping bryce
<pitti> siretart: \o/ I made the cryptsetup initramfs hook work with uuids, I just got hte first working boot
<pitti> siretart: not perfect yet, but getting there
<siretart> pitti: w00t!
<siretart> pitti: so I assume you're going to upload cryptsetup soon?
<pitti> siretart: ugh, that cryptroot script is a mess
<pitti> I hope so
<siretart> indeed
<pitti> give me some more time
<siretart> no hurry
<siretart> ideally, we rethink the cryptsetup hook, and integrate it better with udev
<siretart> then we can get rid of the script
<pitti> *nod*
<pitti> siretart: hm, it doesn't find resumedev yet, I think it should
<Nafallo> 16:52  * ^i^ wonders what package to file a bug against if uname -i goes  "unknown" instead of x86_64
<ogra> seb128, i'd ask for ~/.asoundrc.asoundconf
<seb128> ogra: feel free to comment on the bug ;)
<ogra> looks a bit like he ran asoundconf set-pulseaudio
<Nafallo> anyone?
<Nafallo> should be the kernel?
<asac> ogra: ppa has i386 now ;)
<ogra> yay
<asac> siretart: ^^
<ogra> my vbox just crashed :P
<pochu> Nafallo: coreutils?
<Nafallo> pochu: I have no idea what sets that :-)
<Nafallo> pochu: so you're guess is as good as mine ;-)
<pochu> Nafallo: emilio@kiko:~$ dpkg-query -S /bin/uname
<pochu> coreutils: /bin/uname
<Nafallo> already reported apparently.
<pochu> Nafallo: uname -p also shows 'unknown'
<Nafallo> anyway. I need to get on with more important things :-)
<ogra> asac, nice, the first nm upgrade that went just flawless for me ...
<asac> ogra: wow :)
<asac> ogra: please roam now ... and try to reproduce the issue
<ogra> it switched off shortly and came up proper again :)
<pitti> seb128: hm, seems that guy configured his system to work with pulse, but doesn't have the packages installed
<seb128> pitti: ok, so NOTABUG
* ogra applauds asac 
<ogra> asac, seems to work just fine :)
<asac> ogra: please test extensively
<asac> ogra: or did it always fail?
<ogra> i will, but its way better than before already
<ogra> not always but after changing the net several times
<ogra> i changed 2 times between the three cells i have in my house (6 changes) ... it didnt choke yet
<asac> ok ... please observe ;)
<ogra> will do
<ogra> but it looks better already
<ogra> in any case
<stgraber> asac: NM is rock solid here now, suspend/resume works fine, moving from an AP to another too, it only crashed once in a week (its old average being thrice a day :))
<asac> stgraber: well one crash too much
<asac> stgraber: the average user probably cannot cope with a crashed NM
<asac> stgraber: but anyway ... thanks. i would really like to do another session with hidden networks before RC ... you think we can do that?
<stgraber> yes, I have a test AP I can use it to test hidden networks a bit
<pitti> siretart: hm, I fixed the resumedev thing, too
<stgraber> and don't have much to do before RC (waiting for a new server for qa.ubuntu.com (let's hope it's before RC))
<pitti> siretart: ATM I'm unsure, though, whether it is necessary at all to supply the "lvm=" option to the initramfs /conf/conf.d/cryptroot; I can fix the script, but I'm not sure why it is necessary at all... after all, the devices are created just fine without it
<pitti> can anyone tell me how to get an initramfs prompt? (a magic kernel boot option, I figure?)
<ogra> break=top
<siretart> pitti: add 'break=top'
<pitti> ah, thanks
<siretart> or break=bottom
<ogra> otr bottom or premount
<siretart> depending on where you want it to break ;)
<pitti> I need to find out whether 'readlink -f' works in the initramfs environmentt
<siretart> pitti: if /etc/crypttab doesn't need to be touched at all, that would be even better. in this case, we need to update README.ubuntu
<pitti> siretart: I fixed the hook script for update-initramfs, but i still need to fix the local-top/cryptroot script (maybe; maybe this entire manual stuff isn't necessary in the first place)
<pitti> siretart: no, with my current script fixes, both crypttab and fstab are just fine
<pitti> siretart: i. e. fully using UUIDs
<pitti> siretart: I guess you could back out your recent modifications to udev even
<seb128> pitti: http://people.ubuntu.com/~seb128/xdg-user-dirs.changelog http://people.ubuntu.com/~seb128/xdg-user-dirs.debdiff http://people.ubuntu.com/~seb128/xdg-user-dirs.diffstat
<seb128> pitti: what do you think about the update?
<pitti> slangasek: ^
<pitti> seb128: looks bugfixish to me
<seb128> pitti: yes, I'm not sure if I should ask for UVFes nowadays or just upload bug fix versions
<pitti> UVF has ceased to exist
<pitti> seb128: so that's fine
<seb128> ok, I'll do the update then
<seb128> thanks ;)
<mjg59> mvo: What's the compiz situation like?
* pitti does the Gutsy Dance
<pitti> siretart: w00t! everything works, including suspend to disk
<mvo> mjg59: I'm preparing a mail about it
<mjg59> mvo: Ok, thanks
<pitti> siretart: seems that this entire messing with lvm= options isn't necessary at all, it's all done dynamically
<pitti> siretart: so I'll just remove the lvm=UUID=... madness from the cryptsetup hook to avoid the scary "failed to set up lvm foo" messages, and we should be good
<seb128> mjg59, mvo: if you guys look to compiz issue you might want to point that there is still some integration issues (it's still not possible to change the number of workspace under compiz using the GNOME applet, though that should be fixed soon, dnd of windows to the applet don't work correctly, tooltips are not updated correctly, etc)
<mjg59> seb128: How much of that do you think will be fixed by release?
<stgraber> asac: unabled to connect to WPA protected hidden network (WPA supplicant seems to set the key but can't find the AP), I'm trying with same settings but visible to check that's not a WPA issue
<siretart> pitti: sounds excellent!!
<asac> stgraber: its known that ipw3945 cannot connect to hidden
<asac> stgraber: i need a driver log :)
<stgraber> asac: ok
<seb128> mjg59: I'm too busy to work on that, mvo and MacSlow are working on some of those bug seeing how they are busy and how fast issues are fixed I would say not a lot
<mjg59> seb128: Ok, thanks
<stgraber> asac: WPA or open ? any preference ?
<asac> stgraber: at best a full driver log ... i am not sure what to look for.
<asac> stgraber: i am not sure ... i think both don't work, but i am sure for wpa
<siretart> pitti: I need to look at your changes. have you already committed then to our branch?
<asac> stgraber: maybe you can test if open fails?
<mvo> mjg59, seb128: after the upload that is scheduled for today I do not expect that a lot more will happen, we are too close to release
<pitti> siretart: no, I'm still editing it inline in vmware and do a few cleanups
<pitti> siretart: ah, cryptsetup is in bzr? I'll keep it in mind
<pitti> siretart: I'll give you the diff for eyeballing anyway
<asac> pitti: i have a question about dbus :) ... sometimes nm cannot acquire the dbus name service as PRIMARY_OWNER ... on next restart it usually works. Do you think iterating on startup with a sleep might make sense then?
<mvo> mjg59: I think that the session management regression will not get fixed, nor the regression with the window focus changes with orca
<mvo> mjg59: and glx window of course not as well
<pitti> asac: ugh; I think that's above my head
<asac> pitti: its the well known bug 85113
<ubotu> Launchpad bug 85113 in network-manager "[apport]  NetworkManager crashed with signal 5 in main()" [High,Confirmed]  https://launchpad.net/bugs/85113
<mjg59> mvo: Ok
<asac> pitti: hmm ... ok i think i will just try and listen to bugs :)
<asac> because i never see that bug :(
<mvo> mjg59: some integration issues should get nailed down, some keybinding issues, this is the kind of stuff I expect to get fixed in the remaining days. plus a problem with the stack ordering on session-managment that is currently being debugged
<mjg59> mvo: And the crashers?
<seb128> pitti: can we make translations not being stripped for a package?
<siretart> pitti: yes, just 'debcheckout cryptsetup'
<pitti> seb128: in general? not advisable, CDs would explode
<seb128> pitti: xdg-user-dirs has the list of standards folders (music, pictures, etc)
<mvo> mjg59: some yes, some no. upstream is actively working on them, but we will not be able to fix all of them. and it seems like a lot of them happen in custom configurations
<seb128> pitti: and that creates issues for intallation without internet connection to download the language packs, the english directory are created
<pitti> seb128: ah, just for one package? sure, set NO_PKG_MANGLE=1 in debian/rules
<seb128> pitti: ok, thanks
<cjwatson> you have to export it too don't you?
<pitti> right
<pitti> seb128: ^ sorry if that was unclear
<seb128> pitti: that was clear, thanks ;)
<stgraber> asac: Looks like I can't turn the debug mode on, was it disable in current gutsy module ?
<pitti> siretart: http://people.ubuntu.com/~pitti/tmp/cryptroot.diff
<pitti> siretart: pretty simple after all, I reduced it to the minimum;
<pitti> siretart: I don't dare to do bigger changes now to avoid the warning, but it's just cosmetical
<siretart> waah, I didn't think about readlink. this makes things a lot easier :)
<siretart> that patch indeed looks pretty nice, let me test it
<asac> stgraber: he? no it should still work
<ion_> pitti: There arent ""s around all variables inside [ ] . Id be paranoid about that, no matter how unlikely it is the variables would contain spaces.
<pitti> ion_: rightly so; patch updated
<pitti> siretart: ^ please reload
<pitti> siretart: I also noticed another bug, btw: nodes="${nodes#/dev/mapper/}" does not DTRT for multiple nodes, you need to iterate the substitution over the words
<siretart> grml, my test machine doesn't have internet. test is going to be hard :/
<pitti> siretart: manually do the changes in the patch? It's not quite much
<pitti> siretart: if you do that, you could drop the third hunk, it's not essential to make it work; I just fixed it for completeness
<siretart> internet restored
<pitti> erm, no, that was bogus, it is necessary
<siretart> I test the complete patch
<pitti> I already dropped the non-necessary bits
<pitti> siretart: is that the test machine you installed a few hours ago?
<siretart> yes
<pitti> siretart: did you use the partman-auto-crypto lvm/encrypted/full disk schema, or manual?
<siretart> it is really virgin
<siretart> I used partman-auto-crypto
<siretart> on a 120gb disk. that's why it took so long ;)
<pitti> but well, since you only ever have one root partition, support for multiple nodes is not that essential, I think
<pitti> ah
<pitti> siretart: I managed to flip the 'erase' switch to off, so it was pretty quick
<siretart> I reinstalled it
<siretart> pitti: how?
<siretart> aborted right after the recipe was running? or by preseeding?
<pitti> siretart: say 'no' to the question of whether to apply the changes, then you'll get the manual partitioning dialog with all the setup already done
<siretart> aaah, that's nice
<pitti> cjwatson: ^ I wonder whether we should make this the default
<cjwatson> we don't normally in Ubuntu partman
<cjwatson> and I intentionally changed partman-auto-crypto to match
<cjwatson> is there a strong reason to revert to the Debian behaviour?
<cjwatson> if so, please file a bug with the reasoning - I've only been skimming the discussion above
<pitti> the Debian behaviour is to not erase the device before mkfs?
<cjwatson> the Debian behaviour is to show the manual partitioning dialog after applying autopartitioning
<pitti> cjwatson: oh, then we misunderstood each other
<cjwatson> you mean flip the erase flag by default?
<pitti> cjwatson: I meant, not erasing the disk by default before mkfsing it
<cjwatson> I'm not sure about that, isn't it an appropriate paranoia measure?
<pitti> it takes hours on large disks
<pitti> yeah, it is
<pitti> I see why it is done, but it's quite a pain
<pitti> it does not make a difference with protecting the new data, just to erase the data that was on the disk previously
<siretart> Isn't it only to make sure old data is overwritten?
<pitti> right
<cjwatson> I'm not sure. Perhaps bring it up with partman-crypto upstream
<pitti> siretart: how long did it take for your 120 GB?
<cjwatson> I don't feel confident to judge
<pitti> cjwatson: ok; do you think a Debian wishlist bug is an appropriate forum?
<siretart> pitti: I think about 2.5 hours
<cjwatson> pitti: Debian #381898
<ubotu> Debian bug 381898 in partman-crypto "Partition erase should be possible to cancel" [Wishlist,Open]  http://bugs.debian.org/381898
<pitti> ah, Debian bug 381898 proposes something even better
<pitti> cjwatson: heh, you beat me to it
<cjwatson> pitti: cdebconf has support for that (via the progresscancel capability, see e.g. netcfg), so somebody just needs to plumb it into blockdev-wipe
<pitti> Debian #400034, too
<siretart> pitti: before I'm booting, I'm sneaking into conf/conf.d/cryptroot
<ubotu> Debian bug 400034 in partman-crypto "partman-auto-crypto: please allow waiving erase operation during guided partitioning" [Wishlist,Open]  http://bugs.debian.org/400034
* cjwatson -> dinner
<siretart> pitti: http://paste.ubuntu.com/557/
<siretart> is that intended?
<pitti> siretart: looks good
<pitti> siretart: one is root, the other is swap
<siretart> aah
<siretart> ok
<pitti> siretart: as I said, it would be sufficient to have one line and skip the lvm= bit
<siretart> rebooting now
<pitti> siretart: since udev magic dynamically sets up all LVs
<pitti> siretart: so you'll see a warning during boot ('could not set up lvm'), but *shrug*
<pitti> siretart: if I fix the initramfs top script to set it up itself, then I risk breaking the udev magic, and I'd rather not do that
<siretart> cryptsetup: failed to setup lvm device
<siretart> that one?
<pitti> exactly
<pitti> since it doesn't get along with the UUID= bit
<pitti> siretart: I think I'll add code to inhibit the warning if it starts with UUID
<pitti> siretart: that's a Gross Hack (tm) for Gutsy, just for cosmetics
<siretart> pitti: well, your patch works really wonderful for this virgin installation
<pitti> but it's much less scary on boot
<siretart> pitti: I think we should upload it with README.ubuntu removed, since it is obsolete information in gutsy
<siretart> pitti: and I wanted to merge the new debian upload as well, there seem to be a lot of good fixes, which we might want to have in gutsy
<pitti> siretart: cryptsetup doesn't have a README.ubuntu
<siretart> pitti: the source package has in the branch, which accidentally isn't installed
* pitti reads http://packages.qa.debian.org/c/cryptsetup/news/20070926T104703Z.html
<siretart> right
<siretart> but your patch is absolutely necessary
<pitti> siretart: right, the Debian changes look good to me
<pitti> siretart: do you want to merge this or shall I?
<siretart> pitti: the merge is on my todolist anyway. I can do it later today
* iwj rotfls at oo.o
<iwj> iwj@cadmium:~$ grep 'ERROR: No Fallback found for language en-US' adt-play/tmp/_log_raw | wc -l
<iwj> 5319835
<iwj> and it's still building ...
<iwj> -rw-r--r-- 1 iwj warthogs 266M 2007-10-02 18:12 adt-play/tmp/_log_raw
* siretart beams home for dinner - cu later!
<iwj> I'm sure it really needs to generate a 0.25GB build log.
<pitti> siretart: ok, thanks
* siretart hugs pitti! :)
<broonie> OO.o is sponsored by Sun to sell their high end hardware as a build systems.
* pitti hugs siretart back, thanks for your help
<pitti> I'm happy, crypto-lvm by default is great
<stgraber> asac: strange, can you recall what was the debug number I had to send it ? it's something like 6152 but I'm not that sure (I tried with 6152 and 65536)
<Kmos> bug 148197
<ubotu> Launchpad bug 148197 in ubuntu "winscp fails randomly when copying files to ubuntu box" [Low,Incomplete]  https://launchpad.net/bugs/148197
<nosrednaekim> how would I diagnose a suspend failure?
<Riddell> seb128: do you have an opinion on bug 137701 ?
<ubotu> Launchpad bug 137701 in mono "UVF Exception - Mono 1.2.5" [Undecided,New]  https://launchpad.net/bugs/137701
<jdong> Keybuk: I just cut my GNOME login time significantly by readahead-watch'ing a login session , then doing a readahead-list during Xsession.d/00readahead... And cut down my login time by nearly half by calling the readahead in rc.local while the system idles at gdm.... I think an optimization like this is worth looking into for the next release :)
<Keybuk> err, so which works better
<Keybuk> readahead-list in Xsession.d or in rc.local?
<jdong> Keybuk: well rc.local works beter provided the user waits for it to complete before logging in....
<jdong> Keybuk: Xsession.d works better in the case the user rushes to log in
<elmo>  /go thom
<jdong> Keybuk: a combination of the two is the most optimal throughout
<jdong> (as a redundant readahead has almost no cost)
<seb128> Riddell: no real opinion on mono, maybe ask slomo or ajmitch when they are around
<slomo> Riddell: well, i want 1.2.5 in gutsy... definitely :) but it's probably far too late now and at the time it wasn't too late i was too busy
<Keybuk> jdong: a redundant readahead can have a monumental cost on low-memory systems
<slomo> Riddell: and of course monodoc 1.2.5 and libgdiplus 1.2.5 is needed too then, the latter making pitti happy because no longer a private copy of libcairo ;)
<jdong> Keybuk: ah, good point..... Can we have Xsession.d have a hook that stalls bootup waiting for the init.d readahead to complete then?
<Kmos> bug 148205
<ubotu> Launchpad bug 148205 in ubuntu "TouchPad crash when press caps lock " [Undecided,New]  https://launchpad.net/bugs/148205
<Kmos> what controls the touchpad ?
<Kmos> package?
<Kmos> kernel ?
<Keybuk> jdong: I was vaguely hoping for the kernel readahead patches that the SoC student did
<jdong> Keybuk: hmm never heard of this. what do those patches do?
<Keybuk> http://code.google.com/p/prefetch/
<jdong> Keybuk: what is the difference between prefetch and the existing preload stuff in userland?
<Keybuk> err
<Keybuk> it works better :)
<nosrednaekim> How would I procede to diagnose wireless-caused suspend failures in gutsy?
<slomo> Riddell: and of course it contains many new features, many of them making it a more complete implementation... and also many many bugfixes, some of them rather major *shrug*
<jdong> Keybuk: good answer. Better is always good. :)
<MacSlow> re
<pitti> good night everyone
<MacSlow> cu pitti
<Chipzz> some thing I've been wondering
<Chipzz> the live cd has a pulsating usplash progress bar when booting the kernel, the final system doesn't
<Chipzz> any reason?
<mjg59> Because otherwise the progress bar wouldn't progress much on the live cd
<cjwatson> Chipzz: historically, the live CD's initramfs was less easily predictable than (and certainly very different from) the normal system's, and so it was changed to pulsate as the easiest way not to confuse people
<cjwatson> Chipzz: I have a patch from mdz to make it always pulsate in the initramfs
<cjwatson> which I think may make more sense these days - there are a couple of long pauses there
<Keybuk> err, there are?
<cjwatson> but I didn't get round to it before beta and I think now is probably the wrong time to make that change
<Keybuk> well, I guess there's the big spinning bit :p
<cjwatson> exactly
<cjwatson> we don't really know how long some of that is going to take
<Keybuk> "less than three minutes" :p
<cjwatson> and it would be better to pulsate than to make it look like we've locked up
<Keybuk> cjwatson: btw, did I ever mention that I figured out the d-i udev rules bug?
<cjwatson> Keybuk: I followed up to the bug
<cjwatson> please change udev-udeb kthxbye :)
<Keybuk> it seems silly to have a patch just for the udeb
<cjwatson> Keybuk: I don't really see why we can't just let udev have a standard path on our system
<Keybuk> it does?
<cjwatson> busybox is quite entitled to implement [ as an external program
<Keybuk> that PATH cannot include /usr though
<cjwatson> Keybuk: so why doesn't it work? :)
<Keybuk> otherwise seb would get grumpy
<cjwatson> oh, is busybox's [ in /usr? odd
<Keybuk> yes
<Keybuk> /usr/bin/[
<cjwatson> wow, freaky
<cjwatson> ok, in that case I misunderstood
<Keybuk> that's where it is in the real system too
<cjwatson> I thought you were saying that it had PATH=/lib/udev
<cjwatson> yeah, doesn't matter in the real system though
<Keybuk> it's arguably a bug for write_net_rules to use [ at all
<Keybuk> since it's inherently relying on it being a built-in
<Keybuk> but then test is in /usr too
<Keybuk> so that pretty much buggers all shell logic
<cjwatson> technically not since you can use case
<cjwatson> but I'll move test in busybox-udeb now that I understand the problem
<cjwatson> does it need to be moved in the initramfs too?
<asac> stgraber: try https://wiki.ubuntu.com/DebuggingNetworkManager
<cjwatson> actually, it's not there as a separate program in the initramfs, so that's ok
<cjwatson> 17:06 <iwj> It ought to take a list of strings for exec then.
<cjwatson> 17:06 <Keybuk> it basically does
<cjwatson> 17:06 <iwj> This is hardly rocket science.
<cjwatson> 17:06 <Keybuk> with a PATH of /lib/udev only
<cjwatson> 17:06 <iwj> Err, why doesn't it use exec[lv] p[e]  then ?
<cjwatson> 17:07 <Keybuk> /lib/udev is the only thing you should "by default" guarantee exists
<cjwatson> Keybuk: that IRC transcript is why I misunderstood
<Keybuk> "basically"
<cjwatson> I thought it corresponded to reality :)
<Keybuk> it's actually even more insane than that
<dobey> hey keybuck
<Keybuk> if path[0]  != '/' then it prepends "/usr/lib/" onto it
<Keybuk> uh
<Keybuk> "/lib/udev/" onto it
<Keybuk> which is even more sick
<Keybuk> dobey: hi
<cjwatson> Keybuk: right, but that's only the actual content of RUN rules
<dobey> how's it goin?
<cjwatson> not programs called from things listed in RUN rules
<Keybuk> yeah
<Keybuk> programs called from RUN rules inherit whatever PATH udev has
<Keybuk> (which is often none, depending on how featured the calling shell is)
<Keybuk> most of the scripts set it to /bin:/sbin
<cjwatson> makes sense
<cjwatson> Keybuk: uploaded, thanks for correcting my misconception
<cjwatson> you can probably close the udev side ...
<Keybuk> :)
<Keybuk> I'm not completely insane
<Keybuk> I wouldn't have forwarded it on to you if I didn't honestly think it was right to fix elsewhere
<cjwatson> I did think that setenv("PATH", "/lib/udev") would have been a bit odd
<Keybuk> (forwarding on to other people is, of course, a different matter <g>)
<cjwatson> but I wouldn't actually have been shocked, only a bit surprised :)
<cjwatson> Keybuk: I've taken to reading my bugmail again recently, so I guess I stupidly assumed everyone did :)
<cjwatson> (despite the fact that I didn't for months)
<Keybuk> I attempted to read it again
<Keybuk> and gave up after less than a day
<Keybuk> there's just too much ofi t
<cjwatson> it wasn't too bad when I resolved to ignore the old stuff
<cjwatson> I did only catch up by virtue of an insomniac night waiting for other stuff to happen though
* ScottK finds bugmail very helpful when I have other stuff to procrastinate.
<slangasek> siretart: pfff, why do people keep trying to turn normal development activity that needs to be discussed and resolved among a handful of maintainers into "release goals for lenny"?
<elmo> slangasek: because it bypasses the discussion
<slangasek> if it worked, which I don't think it has yet :)
<__mikem> Hey, I heard that the windows ubuntu installer is going to be an official installer in the next release, is this true?
<cjwatson> __mikem: we tried, but it looks like it isn't quite going to make it for 7.10; there were just too many problems to fix in time
<cjwatson> __mikem: now that we've laid most of the groundwork, though, it should be possible to finish it off for 8.04
<__mikem> cjwatson, it worked fine for me
<cjwatson> __mikem: the upstream one did, sure, but the internals weren't in a state that we could maintain
<__mikem> oh I see
<cjwatson> in order to get it merged into Ubuntu we had to rewrite some of that
<__mikem> what specifically was going wrong?
<cjwatson> the last straw was a mysterious hang when trying to mkfs the loop filesystem that we still haven't really tracked down
<cjwatson> up to then it was just a succession of teething troubles; wubi requires an awful lot of weird stuff that was difficult to make work concurrently with Ubuntu's normal boot and install processes
<superm1> cjwatson, that mysterious hang, was that similar to the type of hang that we were encountering on the mythbuntu live disks?
<cjwatson> superm1: no
<cjwatson> (as far as I could tell)
<__mikem> cjwatson, in the merged version of the software, does windows get booted up before you start making the fs
<cjwatson> __mikem: you launch wubi from Windows, then it reboots into the Ubuntu desktop CD and does an automatic install there, including making the filesystem
<cjwatson> switching over to the Ubuntu desktop CD clearly produces a better user experience but unfortunately it had its own problems
<__mikem> okay, I did you try running defrag on the machine before you tried the install?
<cjwatson> __mikem: no, but it was a fresh install of Windows, and multiple people have encountered the same problem ...
<__mikem> okay, did you make sure the FS wasn't compressed
<cjwatson> I find it a bit implausible that that would break ntfs-3g, too
<__mikem> cjwatson, there is a problem with the upstream version of wubi where if the fs is fragmented, it will cause problems
<cjwatson> er, dude, it may not be the best idea to try to debug something you haven't tried yourself yet :-)
<cjwatson> Agostino has been spending some time on this
<cjwatson> so it's not just me
<cjwatson> the upstream version of wubi creates the filesystem in Windows
<cjwatson> so I expect it's vulnerable to that sort of thing
<__mikem> cjwatson, Okay, I understand, its just that I used the current wubi installer and I figured I might try to help
<cjwatson> we just run ntfs-3g and have it treat it as a normal Unix-like filesystem though
<cjwatson> __mikem: if you can figure out what's wrong with the current code, that would be great; there are executables on http://wubi-installer.org/devel/minefields/
<cjwatson> that you can try to use in conjunction with a current daily build of gutsy
<__mikem> I don't currently have a box that I can test that on, but I might be able to see if USF is willing to hand over an old box that they are not using
<cjwatson> __mikem: ago suggested that upgrading ntfs-3g may help, so we'll probably try that out ASAP
<cjwatson> it hasn't quite bubbled up to the top of my list yet though
<__mikem> what is ntfs-3g anyway?
<__mikem> I know ntfs is the file system type windows uses
<cjwatson> http://www.ntfs-3g.org/
<superm1> cjwatson, did you happen to discuss more with mvo earlier today while i was away about why that apt cache wasn't showing broken dependencies?
<__mikem> "Most POSIX file system operations are supported, with the exception of full file ownership and access right support." <-- This might cause a problem
<cjwatson> superm1: no, he said he was on the phone and would look in a bit, but I think may have forgotten
<cjwatson> __mikem: shouldn't be an issue for wubi
<cjwatson> it only needs a small number of honking big files :)
<superm1> cjwatson, ah okay.
<cjwatson> the problems we encountered weren't permissions problems
<__mikem> cjwatson, one more question. I had a hell of a time getting ubuntu to run on my HP pavilion. (Now bare in mind that this is a true dual boot setup I am talking about here). Basicly, the nvidia card that it comes with isn't supported by default so I have to instal the binary drivers manually. Now thats something I can live with. What I can't live with is the fact that the HP pavilion is the only machine on which I have seen lin
<__mikem> ux hang randomly and intermitantly fail during boot
<__mikem> Its quite apparent that that the <sarcasm>fine</sarcasm> people at HP specificly designed their box not to run anything but windows, so I am wondering if any steps have been taken in the next version of ubuntu to get around this
<cjwatson> __mikem: I have no idea about that, I'm afraid; you'd need to track it down with the kernel folks
<cjwatson> __mikem: it's more likely just a straightforward kernel bug than any kind of conspiracy at HP, though :-)
<siretart> slangasek: yeah, you're right, I'm sorry. It was rather meant as a joke
<__mikem> cjwatson, well if thats the case then why doesn't it happen on any of my other boxes that run ubuntu
<cjwatson> __mikem: kernel bugs are often hardware-specific
<slangasek> siretart: ah, that wasn't clear because people really /do/ try to propose release goals like that in Debian. :)
<nosrednaekim> speaking of kernels and hardware problem,how would I diagnose a suspend failure related to wifi?
<__mikem> Perhapse, but either way, I am not buying any more $h!+ from hp
<cjwatson> __mikem: if I boycotted every manufacturer on which I'd experienced some kind of kernel problem at some point, I don't think I'd ever buy a computer again. :)
<nosrednaekim> cjwatson: OLPC ;)
<__mikem> lol, cjwatson, its not just that. I tried getting tech support once, and it was a nightmare, the potential kernel bug (and I still have my suspicions on the order of a conspiracy theory, and I usually try to avoid those) is just icing on the cake
<__mikem> I will say though, I am very happy with the printer I got from them
<slangasek> Riddell: libelf is on the list for syncing today still (bug #136986)?
<ubotu> Launchpad bug 136986 in libelf "autopkgtest gutsy libelf: erroneous package!" [High,Fix released]  https://launchpad.net/bugs/136986
<Riddell> slangasek: no, it already has been
<slangasek> ok, cheers
<keescook> I know this is crackful, but is there a way to force apt to download the Packages file for a repo that doesn't match the current arch?  (i.e. to see lists of files for i386 when I'm on amd64)  I don't care if they're uninstallable, I just want them to show up in apt-cache madison.  :)
<Mithrandir> keescook: you know of rmadison, right?
<Mithrandir> keescook: http://chistera.yi.org/~adeodato/blog/106_fakeapt is another alternative.
<keescook> Mithrandir: I do, yes, but I need this for bulk automation, which makes it less useful.
<Mithrandir> keescook: you know of madison-lite too? :-)
<keescook> hm, I saw mention of it while digging in rmadison's CGI but maybe I need to look at it more.  :)
<Mithrandir> apt-get install madison-lite
<keescook> ah, hm, so I'd need to sync the Packages files manually for madison-lite.  Well, that's what I was trying to avoid with some arcane sources.list syntax, so I'm back to square one.  :)
<Mithrandir> well, fakeapt + madison-lite should do what you want, though
<Mithrandir> or just something nice-ish in cron
<rockets> Out of curiosity, and assuming KDE4 is released on time, is KDE4 going to be included in the Hardy Heron?
<__mikem> The kubuntu people really need to make more customizations to kde come kde 4. Their current setup is almost exactly like a default kde setup
<ScottK> rockets: Yes, but not as the default.
<rockets> ScottK, why not? I thought ubuntu always uses the newest availible stable revision of gnome/kde
<ScottK> Because Hardy is an LTS release meant for long term/stable use by people more interested in stability than the latest/greatest.
<__mikem> Scott, are they going to at some point actually make an attempt to customize kde by default in kubuntu at some point in the future?
<ScottK> It will provide both the latest KDE3 and KDE4, just use KDE3 by default.
<rockets> okeydokey :-D
<ScottK> __mikem: Not sure what you mean.  It's customized now?
<__mikem> No, for one thing, in kubuntu, the icon for the "start menu" is the same as it is in default kde, the general layout of the bar at the bottom looks almost exactly like the origonal kde, (with the exception of a very subtile background) and the colors are blue instead of brown
<rockets> __mikem, but you're essentially arguing that they should make customizations just for the sake of customization.
<__mikem> rockets, they customized gnome just for the sake of customizations
<__mikem> heck they even customized xfce just for the sake of customization
<rockets> __mikem, when you say customize are you referring to features or just the appearence?
<rockets> __mikem, yes but *they* is not one group of people, you're talking about three different groups here
<__mikem> appearence
<rockets> oh ok
<rockets> thats different
<rockets> yeah whatever. . . . who cares though really
<cjwatson> the blue in Kubuntu is intentional; it's supposed to have a different look from Kubuntu
<cjwatson> er, from Ubuntu
<cjwatson> (AIUI; I'm not a Kubuntu developer)
<__mikem> okay, I will give that, but why can't you atleast make the menu icon different
<ogra> ist Kubuntu lilac ?
<ogra> *isnt
<Riddell> ogra: it's gone more blue in gutsy
<LaserJock> ogra: I think they went back to blue for gutsy
<ogra> ah
<anthony> Is Gutsy built to work with IPv6 out of the box, or will users need to change something for it?
<slangasek> Linux pretty much autoconfigures IPv6 out-of-the-box at the kernel level now
<__mikem> It would also be nice if xubuntu could be obtained through shipit
<ogra> so kwwii's violet phase is over now eh ? :)
<Riddell> __mikem: we make significant customisations to KDE, sometimes to the annoyance of upstream, the default panel quite difference.  obviously if you have specific requests we can look at those
<stgraber> anthony: inet6 addr: fe80::219:d2ff:fe26:e216/64 Scope:Link <-- Looks like ipv6 is loaded :)
<anthony> slangasek: I've heard some applications would need minor changes.
<anthony> stgraber: :)
<slangasek> at the application level, most packages have IPv6 support inherited from Debian.  There are some packages I can think of that require tweaks for IPv6.
<__mikem> Riddell, if you could atleast customize the menu icon it would be nice since you customize the menu icon in every other ubuntu derivitive
<Riddell> why would that be nice, we've very happy to have KDE branding
<Riddell> there is a kubuntu logo in the system menu icon
<ogra> scatter more of them everywhere :)
<__mikem> what ogra said
<ogra> yay for overbranding
<__mikem> I think I am going to give xubuntu a spin next release
<ogra> Riddell, btw, did you ever check if kmix works with virtual devices now ?
<ogra> (i.e. in ltsp)
<__mikem> heh, it looks like come kde4 time he ubuntu devs are going to have no choice but to make their own custom scheme http://mywheel.net/blog/wp-content/uploads/2006/01/Full_Render_View.png
<mdke> ogra: pong
<ogra> mdke, i wanted to ask about the TOC in yelp for the edubuntu handbook, but LaserJock already talked to you i think
<mdke> ogra: yes, it should be fixed now actually, Seb uploaded the fix today
<ogra> yeah, i didnt have time to upgrade yet, i saw a changelog entry that made me want to test :)
<ogra> the handbook is over 50 ages now, would be a shame if it were hidden
<ogra> *pages
<mdke> i tested the patch, it works
<__mikem> I will tell you what, with all the cool ways to create the interface for kde4, if they don't put some real thought into how they make kde4 look for kubuntu, me and half the userbase is going to be very p!$$ed off
<LaserJock> yep, works here as well
<LaserJock> mdke: thanks a lot for that
<mdke> np
<ogra> mdke, fix confirmed :D
* ogra is dancing
<thully> are any devs around who have experience with suspend/power management issues.  I have a few that have been sitting in Launchpad a long time without much response that are annoying to the point of being showstoppers in daily use...
<Riddell> ogra: I don't have anything to test it with
<Riddell> __mikem: that's not KDE 4
<mneptok> siretart: ping
<siretart> mneptok: pong?
<mneptok> siretart: is dm-crypt+cryptsetup+d-i supposed to work in the 10-02 daily?
<siretart> mneptok: not yet, I uploaded a fixed cryptsetup package 2 minutes ago
<siretart> mneptok: make sure that cryptsetup_1.0.5-2ubuntu1 is installed on the alternate cd
<mneptok> siretart: cool. then the 1s and 0s spewing out of the side of this certification laptop are expected
<mneptok> siretart: i told cjwatson i'd use our cert equipment to track it through release. so i'll just wait for tomorrow's daily.
<mneptok> thanks for the info. if you have known b0rkeness, i'd appreciate a ping.
<siretart> mneptok: the install is already fine with current daily
<siretart> mneptok: the installed system will drop out to initramfs during boot
<siretart> mneptok: in order to boot the system, you need to do the cryptsetup luksOpen dance by hand. the next cryptsetup package which is currently building will fix that
<mneptok> siretart: not here. the 10/02 daily dies when d-i goes to configure the newly encrypted volumes.
<siretart> mneptok: thats fisy. I installed successfully on my test machine with the test image from today
<siretart> fishy, even
<mneptok> it just died on a machine here. i have another machine doing a media ovrwrite that should die in ~60 minutes ;)
<siretart> :(
<mneptok> same behavior as the beta. after zeroing and passphrase choice, d-i dies and the framebuffer gets wonked (repairs itself with a switch to another console)
<siretart> mneptok: that doesn't sound like an issue in dm-crypt nor cryptsetup
<siretart> good night!
<thully> Anyway, I have a few laptop regressions from Feisty that haven't received much Launchpad love...  Coud mjg59 or some of the other Ubuntu laptop gurus take a look?
<thully> The bugs would be 137738 and 137598
<elmo> www.ubuntu.com is going down for emergency maintenance, ETD is 5 minutes or less
<gnomefreak> ty elmo :)
<anthony> Did Xubuntu have a Beta release?
<cjwatson> anthony: http://cdimage.ubuntu.com/xubuntu/releases/gutsy/beta/
<elmo> (back)
<anthony> cjwatson: ty - I was looking on xubuntu.org and releases.u.c
<cjwatson> anthony: releases.ubuntu.com has a link to cdimage/xubuntu/releases/
<cjwatson> from which you go -> gutsy -> beta
<anthony> cjwatson: I was just modifying URLs... :S
<cjwatson> nope :)
* anthony notes to navigate the way they want you to
<anthony> on a similar note, has there been any talk yet about Xubuntu being available through ShipIt?
<bluefoxicy> Should I file a bug for something failing to protect against man-in-the-middle attacks on ssl/tls implementations
<bluefoxicy> or something
#ubuntu-devel 2007-10-03
<slangasek> asac: bug #147913 is still shown as 'in progress'; surely the copyright update should be straightforward, so is it really in progress?
<ubotu> Launchpad bug 147913 in gnash "[gutsy]  gnash shipped with GPLv2 debian copyright even though upstream uses GPLv3 since 0.8.1" [Critical,In progress]  https://launchpad.net/bugs/147913
<cjwatson> "first reported 22 hours ago"
<jdong> so Launchpad doesn't have a 1-hour delivery service like my local pizza shop?
<jdong> (sometimes it can't even load a page before the pizza arrives.... :D)
<cjwatson> damn, now I'm hungry
* jdong feeds cjwatson green hand-cranked laptops
<asac> slangasek: yes ... its in progress ;)
<asac> slangasek: meaning its about to be uploaded
<slangasek> ok :)
<TheMuso> cjwatson: Re the problem with germinate and the ubuntustudio meta not treating ubuntustudio-desktop as a dependency, I'm just wondering whether its worth adding ubuntustudio-desktop as a hard-coded dependency in the meta package for now as a workaround?
<slangasek> cjwatson: that's still a lot of progress! :)
<asac> slangasek: i use in progress to show you (RMs) that you don't have to bother ;)
<cjwatson> TheMuso: it's OK, I'll fix it tomorrow
<cjwatson> shouldn't be hard
<slangasek> asac: noted :)
<TheMuso> cjwatson: Ok.
<lamont> slangasek: could you be so kind as to move libgcc2/gutsy/hppa to universe?
<lamont> FWIW, that package gets sucked in by debootstrap, but need not.
<lamont> and yes, that'll make lots and lots of main not installable without universe, until the buildd catches up with things
<lamont> OTOH, debootstrap now workd
<lamont> works, even
<slangasek> lamont: done, I think
<lamont> heh.  thanks
<lamont> hrm... why is gcc-3.4 still in main?
<slangasek> for libg2c0 apparently?
<lamont> if gcc-3.4 is supposed to still be in main for gutsy, then oops.  libgcc2 and gcc-4.0-base need to be in main for hppa (gcc-3.4 depends libgcc2 which depends gcc-4.0-base)
<lamont> or if you don't mind, I'll kick a no-change gcc-3.4 build to get hppa current, and we'll see if that removes the libgcc2 depends...
<lamont> I think the latter is actually the correct answer
* lamont looks at the source, assuming it finishes downloading in the next 2 minutes before I run out the door to my 7PM meeting.
<lamont> anyway, I'll prepare an upload once I get back in a couple hours, if it makes sense
<lamont> after all, the rest of the compilers got rebuilt this last week... doko just doesn't love gcc-3.4 anymore, it seems. :=)
<slangasek> heh
<lamont> rebuilding it might work.  gone
<lamont> and I'll pester you when I'm back home
<lee_pepper> could any one offer any insight in to this error in a LiveCD build by livcd-rootfs > $ ubiquity gtk \n sudo: must be setuid root
<christian> hellp
<christian> hello
<christian> anybody in
<Hobbsee> no
<christian> ??
<christian> no
<christian> jeje
<christian> hello
<christian> where r u from hobbse
<bddebian> Hobbsee: shh ;-)
<christian> hobsee
<Hobbsee> christian: australia.  you may be looking for #ubuntu-offtopic
<christian> no
<christian> i'm looking
<christian> for something
<christian> is putting me out
<christian> and i cannot solve
<Hobbsee> !enter
<ubotu> Please try to keep your questions/responses on one line - don't use the "Enter" key as punctuation!
<pwnguin> you know, complete sentences in a single line aren't that hard. even I can pull those off
<christian> could u help me
<christian> ??
<Hobbsee> christian: please read the /topic
<christian> i'm lookin for how could i run a c++ application
<christian> in gnome terminal
<Hobbsee> then you want #ubuntu
<RAOF> christian: By asking in a support channel, such as #ubuntu.
<christian> ok
<christian> no problem
<StevenK> Damn it, I hate it when debmirror is right.
<pwnguin> aww crap. bryce actually responded to a bug report
<pwnguin> now i have to go forth and regather the relevant data =/
<Hobbsee> you could just close the bug :P
<pwnguin> im sure it still exists
<pwnguin> its just that using displayconfig-gtk tends to destroy xorg.conf
<Hobbsee> pity
<lamont> slangasek: any objections to a gcc-3.4 upload?
<slangasek> lamont: nope
<lamont> uploaded
* StevenK whimpers at autotools
<lamont> mlton:                  10:21:54 (1 entry, sigma 00:00:00)
<lamont> efh
<lamont> feh
<StevenK> It *seems* like every directory of this source bar one deals with -fPIC -DPIC
<RAOF> Yay autofoo!  What is it?
<lamont> RAOF: it's spelled autocrap
<lamont> StevenK: ouch
<StevenK> It's a guess on my part.
<StevenK> I see -fPIC -DPIC in other parts of the build, and it seems like one object isn't getting -fPIC'd and when it comes time to link the whole thing together, it blows up.
<lamont> how does it blow up?  and what arch?
<ScottK> How big are the flames?
<Hobbsee> |------------------|  <-- that big.  (not to scale)
<StevenK> lamont: amd64
<lamont> and the error?
<bddebian> hehe
<RAOF> Because amd64 *really* cares about PIC.
<RAOF> i386, not so much.
<StevenK> lamont: I'm getting there, my machine is building. :-)
<lamont> ah, ok
* lamont takes a typing break
* StevenK pushes this build uphill
<StevenK> /usr/bin/ld: ../libtinymailui-gnome-keyring/libtinymailui-gnome-keyring.a(tny-gnome-keyring-password-getter.o): relocation R_X86_64_32S against `a local symbol' can not be used when making a shared object; recompile with -fPIC
<StevenK> lamont: ^
<lamont> yeah - you need -fPIC, and probably -DPIC if that's what the rest of the build says...
<StevenK> lamont: If I hack libtinymailui-gnome-keyring/Makefile and add -DPIC -fPIC to the LIBTINYMAIL_CFLAGS, it works. I'm just uncertain how to fix it with autobork
<lamont> which gets us to why I hate autocrap
* lamont is not the right person to ask
<RAOF> StevenK: You could patch Makefile.am to add -fPIC to the CFLAGS.
<lamont> look at Makefile.in in a directory that works?
<lamont> or possibly Makefile.am, depending on which exists...
<lamont> .am if present, then .in, then Makefile
<RAOF> StevenK: But isn't autofoo meant to do that automatically for shared libs-on-amd64?
<StevenK> -fPIC exist in none of the Makefile.{in,am}
<lifeless> StevenK: its either something settings CFLAGS that should set AM_CFLAGS
<lifeless> or similar on a per-target pasis
<lifeless> StevenK: -fPIC is set by autoconf at configure time, it only ever exists in Makefile and config.status
<StevenK> Ah ha.
<lamont> so something in a Makefile.am or config* is causing it to not set it in that directory - grepping for that dir and a working one through the tree might bear fruit.
<lamont> and lifeless knows far more about auto* than I ever want to
<StevenK> Hum. -fPIC only appears in 3 makefiles
<StevenK> The broken directory's Makefile.am sets INCLUDES without including AM_CFLAGS
<thully> I've got an issue with gnome-power-manager that has been nagging for some time
<thully> I've found a source of the problem, but am unsure of the exact solution (I'm not exactly a C whiz...)
<thully> The bug is bug #137598
<ubotu> Launchpad bug 137598 in gnome-power-manager "Screen brightness resets to default (maximum) on idle with AC plugged in" [Undecided,Confirmed]  https://launchpad.net/bugs/137598
<ScottK> thully: This is a pretty quiet time here.  Most devs are sleeping.
<ScottK> thully: Are you sure it's a regression?
<thully> OK - I guess I figured that they were scattered across many time zones...
<ScottK> They are, but the concentration is in in US/Europe.
<thully> It may not be a regression per se, but in any case Feisty didn't do it with the AC plugged in
<ScottK> I'm not sure what that means.
<ScottK> What did Feisty do wrong?
<thully> When I had the AC adapter plugged in, the screen didn't "dim" to full brightness on idle
<thully> That's what it does on Gutsy
<thully> However, I've pinned it down to the idle/dim logic in gpm-backlight.c
<ScottK> OK.
<ScottK> I'll call that a regression.
<ScottK> What I recommend you do is add your findings to the bug in as much detail as you understand it.
<ScottK> I'm going to milestone the bug for RC since it's a regression (I think I have sufficient power to do that).
<thully> OK - I'm looking at the code to see if I can fix it.  I understand the problem fairly well, but i'm no C expert
<ScottK> thully: It's now milestoned for RC due to being a regression.
<thully> thanks
<ScottK> OK.  If you can figure a patch, your odds go way up.
<ScottK> In any case take it as far as you can.  If you figure a patch, then subscribe ubuntu-main-sponsors to the bug.
<Hobbsee> ScottK: you do, but dont be surprised if it gets dropped
<Hobbsee> but if i'ts with a patch, then that'll elp it significantly
<ScottK> Hobbsee: Sure.  No guarantees, but if it's a regression, I think an RC milestone is fair.
<thully> I did have a few other regression issues, as well...
<Hobbsee> ScottK: true.  assuming people have time to fix it.
<ScottK> Which is why having a patch helps hugely.
<thully> Those would be bugs 127101 and 137738
<ubotu> Launchpad bug 127101 in xserver-xorg-video-intel "laptop hangs when switching video mode" [High,Confirmed]  https://launchpad.net/bugs/127101
<ubotu> Launchpad bug 137738 in ubuntu "[gutsy]  suspend / hibernate works fine, but after resume, I get a "Failed to suspend" popup" [Undecided,New]  https://launchpad.net/bugs/137738
<ScottK> Hobbsee: On that basis, what do you think about milestoning Bug #127772?
<ubotu> Launchpad bug 127772 in linux-source-2.6.22 "CPU fan no longer runs after upgrade to Gutsy" [Medium,Triaged]  https://launchpad.net/bugs/127772
<Hobbsee> ScottK: i'd check with the kernel team
<Hobbsee> ScottK: they get hit real soon nwo by kernel freeze anyway
<ScottK> thully: The xserver one is assigned to the Ubuntu X maintainer, so I think your odds there are as good as they get already.
<Hobbsee> ScottK: ah, there is a starting point on that one.
<ScottK> thully: The suspend/hibernate one really needs to be narrowed down to the affected package before I'd feel confortable milestoning it.
<thully> ScottK/Hobbsee: I see they're working on it, but I really think they should revert intel driver to i810 for supported cards if the fix doesn't make it
<ScottK> Well we aren't the people to have that argument with.
<thully> who would be?  I mentioned it on the bug itself...
* ScottK goes to clean the refrigerator some more.
<ScottK> The person to whom it's assigned.
<thully> ScottK: regarding the suspend one, I almost certain it's gnome-power-manager being uber-sensitive
<thully> as my machine suspends/resumes fine
<ScottK> OK.  I'm a Kubuntu kind of person, so I'm not going to weigh in on that one.
<ScottK> thully: Good luck figuring the patch.
* ScottK REALLY goes to clean the refrigerator some more.
<thully> I guess I'll look at the diff from feisty - it works OK there...
<thully> Honestly, I can't believe this gnome-power-manager is an actual upstream release - it is uber-buggy in a glaringly obvious way
<RAOF> thully: It's possible that no-one else has their display brightness set < max when on AC? :)
* Hobbsee is one of those people
<Hobbsee> but then, i don tuse gnome, so i think it's a bit brighter anyway
* Hobbsee --> uni
<lifeless> ha!
<thully> no one - that's mind of unbelievable, as many screens are EXTREMELY bright at full brightness
<thully> kind
<RAOF> thully: Ok.  No-one from the g-p-m team?
<Amaranth> RAOF: the g-p-m team is ogra
<RAOF> Amaranth: Heh.  Ok, that *ogra* has his brightness set to 100% on AC.
<Amaranth> RAOF: What is a sane default if not 100?
<RAOF> Indeed.
<Amaranth> Just push the button on your keyboard to turn it down and it'll be remembered
<Amaranth> or use the panel applet, or gconf-editor
<RAOF> But that's not quite the bug, though.
<Hobbsee> asb
<Hobbsee> asac: btw, my wifi works at uni too now!  well done!  (ipw3945, unencrypted)
<lifeless> Hobbsee: does NM work for you?
<RAOF> lifeless: Works for me (ipw3945/iwl3945, WPA2/WEP/unencrypted)
<lifeless> I have a iwl3945
<lifeless> crashes for me
<Hobbsee> lifeless: yes, fully now
<lifeless> hmm, I'll update and try again
<Hobbsee> lifeless: it didnt used to connect on open networks
<RAOF> Worked, most of the time, with iwl.  Definitely works with ipw
<lifeless> Hobbsee: 'kernel panic'
<Hobbsee> lifeless: ouchy.  never had that from wifi
<lifeless> indeed
<StevenK> I've had ipw2200 cause kernel BUG and an Oops, but never a panic
<RAOF> lifeless: Does ipw work, though?
<lifeless> RAOF: I haven't tried replacing the driver; massively short on time to fiddle. I just nuked NM and ran up /etc/interfaces
<RAOF> The iwl3945 have still got their pciid's patched out to ensure you deliberately load it, right?
* lamont has found that "NM" and "works" tend not to fit in the same sentence when he's creating it.
<lamont> then again, having disabled it, I find that my multi-homed-laptop life is much happier
* RAOF has found NM generally works delightfully, even with crappy UniWide VPN stuff.
<StevenK> I don't have many problems with NM on Feisty
<lamont> I have no problems with it either, since I killed it... :-)
<lamont> it was its decision to switch networks for me, or re-up an interface and route lots of stuff down a default path that was currently bogus that caused me to decide that it must die
<lamont> I suppose I should try enabling it in gutsy and see if it's any better
<slangasek> lamont: "NM inspires in me a great capacity for hurling fire works at the people who thought it up"? ;)
<StevenK> Hahaha
<lamont> slangasek: you know I would never do that.
<Hobbsee> fireworks would be too painless.
<StevenK> lamont: What, not personally, anyway? :-)(
<StevenK> s/(//
<lamont> I think I would like NM more if it believed that there was more than one use-case
<slangasek> I thought you weren't a volunteer firefighter anymore, it's no longer a conflict of interest ;)
<lamont> Hobbsee: the trick is to get the right kind....
<StevenK> Like napalm
<lamont> slangasek: I did retire. makes it much harder to get useful fireworks. :-)
<StevenK> Hah
<StevenK> lamont: The one use case being "You are using only one of wired or wireless with DHCP" ?
<RAOF> StevenK: And possibly using some form of VPN
<StevenK> Actually, I think the one use case of NM is "You want to spend hours debugging network issues while I 'help' you, right?"
<lamont> StevenK: "you only have one interface active ever, and you never manually set it up to anything other than what I think the default is."
<lamont> for bonus points, postrm downs the interface
<lamont> so never remove networkmangler remotely
<liw> I'm a lucky member of the one NM use case (now that I figured out you mean NetworkManager and not the Debian thing :)
<RAOF> Heh.  My use case is "my laptop moves around, and I'd like networking to work"
<StevenK> lamont: Hah
<lamont> StevenK: I guess the logic is that you don't want networking, since you removed network-mangler
<lifeless> lamont: NM won't get better, its intended to be stupid
<StevenK> So it kills networking on upgrades, too?
<StevenK> This just smacks of dbus, "You can't restart the dbus daemon, you HAVE to reboot"
<RAOF> Not that I've noticed.
<lifeless> upgrades have been interesting on this laptop
* RAOF full-upgrades his remote box, just to see.
<lifeless> given that upgrades *start* NM
<lifeless> and NM *stops the box*
<StevenK> And then dpkg says, "Network Manager broke your upgrade. Let me start it for you."
<lamont> bind9 is the only thing missing from ubuntu-standard/hppa... /me goes bug-report scanning
<Hobbsee> soren: why is cups-pdf required to have the root's p/w now?
<lifeless> say what
<lifeless> *nothing* gets my root password
<lifeless> thank you very much
<Hobbsee> [16:20]  <Hobbsee> Setting up cups-pdf (2.4.6-3ubuntu7) ...
<Hobbsee> [16:20]  <Hobbsee> Password for root on localhost?
<Hobbsee> [16:20]  <Hobbsee> Password for root on localhost?
<Hobbsee> [16:20]  <Hobbsee> lpadmin: Unauthorized
<Hobbsee> [16:20]  <Hobbsee> dpkg: error processing cups-pdf (--configure):
<Hobbsee> [16:20]  <Hobbsee>  subprocess post-installation script returned error exit status 1
<slangasek> ...eew?
<lifeless> fuckoffanddie
<liw> ugh
<Hobbsee> during a dist-upgrade in a chroot from feisty--> gutsy.
<Hobbsee> slangasek: that was my thought.
<lifeless> what was soren thinking
<Hobbsee> i'm surprised it hasnt been picked up in update testing bfeore
<StevenK> Yes...
<lamont> especially since root doesn't have a password
<soren> lifeless, Hobbsee: Huh?
<LaserJock> ajmitch: ping?
* lamont finds himself totally lacking in comprehension of what the user is talking about in bug 147731
<ubotu> Launchpad bug 147731 in bind9 "This package prevent .local adresses to work" [Undecided,New]  https://launchpad.net/bugs/147731
<Hobbsee> soren: just doing a kubuntu dist-upgrade in a chroot from feisty--> gutsy, and getting the above ^
<StevenK> Hobbsee: Can you edit the postinst in /var/lib/dpkg/info/cups-pdf.postinst and add 'set -x' as the second line.
<StevenK> Hobbsee: Then run 'dpkg --configure -a'
<soren> Hobbsee: ...and how is that my fault?
<Hobbsee> soren: (that's your domain, isnt it?)
<lifeless> lamont: my roots do
<soren> Hobbsee: cups-pdf? Heck no.
<lamont> lifeless: mine too
<Hobbsee> soren: drat, i'm sorry - i thought you were the last uploader, for some reason!
<lamont> but that's just so I can deal with bad times during boot
<Hobbsee> looks to be pitti's fault, or till's, or keescook
<lifeless> sorry soren !
<soren> :)
<soren> You sure had me confused for a second there :)
<lamont> ScottK: I'd be interested in seeing a patch fo rbug 42463
<Hobbsee> StevenK: as in, a seperate set -x, or a set -ex?
<soren> Hobbsee: Somehow I'd be a bit surprised if pitti or kees made anything ask for your root password..
<Hobbsee> (there's already a set -e there)
<StevenK> Hobbsee: Either is fine, latter prefered
<Hobbsee> soren: that's what i woudl have thought.  which leaves q-funk.  'nough said.
<soren> quite
<Hobbsee> StevenK: pastebinning.
<lamont> Hobbsee: you're sync-capable, yes?
<Hobbsee> lamont: me?  hell no, i dont work for canonical.
<lamont> nm.  /me isn't patient enough to wait for it to actually get _into_ sid.
<Hobbsee> lamont: slangasek may be at this point.
<lamont> he is.
<Hobbsee> if rt has done his request
<StevenK> lamont: If it's in Incoming, it can be sync'd
<lamont> ah, true enough... and there's already a bug, so I can do it that way
<Hobbsee> StevenK: http://rafb.net/p/XYd3ck61.html
<lamont> Hobbsee: I
<lamont> 'm a buildd-admin team member, and not a canonical emp.
<Hobbsee> lamont: how the heck did you manage that?
<lamont> history
<StevenK> lamont has been a Debian porter since, well '.'
<Hobbsee> lamont: ah right, you're thru debian, so get more privs.  that makes sense.
<lamont> I _was_ canonical... and well, we decided that I could still be one of the cool kids, even though I left.
<Hobbsee> oh right.
<Hobbsee> that explains even more then.
<lamont> nothing to do with debian, actually
<StevenK> lamont: You went from HP to Canonical and then back again?
<Hobbsee> no, but if you were at canonical, it would explain everything - not enough people have access to them to fix it as it is.
<Hobbsee> hi Spads
<lamont> StevenK: yes
<Spads> hullo
<StevenK> lamont: Interesting.
<lamont> StevenK: well... actually that was HP IT -> unemployed -> Canonical -> HP Linux Division
<lamont> which makes it much more understandable
<StevenK> Ah, way cool. So now you're under Bdale?
<lamont> I could be wrong, but I don't believe bdale actually has anyone reporting to him.
<lamont> but he is Linux CTO
<lamont> or some such
<StevenK> lamont: Sounds about right.
<StevenK> Hobbsee: Okay, it looks like the people to blame are Till Kamppeter or pitti
<ion_> Blame Canada.
* StevenK headdesks at #d-d
<soren> If I don't get asked for my root password when I upgrade cups-pdf, am I doing something wrong?
<slangasek> StevenK: ?
<StevenK> slangasek: ari being, well, ari
<slangasek> well, yes
<torkel> soren: No. You probably already have the cups-pdf print queue before upgrading
<StevenK> Where as Hobbsee probably doesn't
<Hobbsee> print queue?
<calc> davidm: hi! :) (yea you are probably asleep i should be too)
<StevenK> Hobbsee: cups-pdf adds a "Print to PDF" queue on upgrade.
<StevenK> Hobbsee: That's what that lpadmin command is trying to do.
<Hobbsee> right
<realist> That reminds me, printing a pdf from evince didn't work last week, yet piping pdf2ps output to lp worked - should I try and reproduce on a default install?
<liw> realist, you should always try to make a bug reproducible :)
<liw> http://www.debuggingrules.com/ -- I don't think I've mentioned this anywhere today :)
<realist> liw: what if I can only reproduce the bug with said pdf file?
<liw> realist, if you can share (privately) that pdf with evince maintainers (Ubuntu/upstream), that would be great, but if not, things may get difficult, unless you can debug it yourself
<StevenK> I can remember wiggy complaining that OpenOffice always used to crash when he was playing with documents under a NDA
<Spads> liw: that poster reminds me of the Reading Rainbow posters we used to have at school in the 80s.  They had Levar Burton on them and said "Reading.  It's not just FUN: It's FUN-damental!"
<soren> torkel: Oh, right.
<realist> Fortunately this isn't under NDA, but it may have personally identifiable information in it :-(
<realist> I'll try on another machine first, then from gutsy.
<Mirv> cjwatson: if you have time, bug 147612 links to remaining installer i18n problems besides being a bug itself. especially I'd really like to have the final "Install" button translated.
<ubotu> Launchpad bug 147612 in ubiquity ""Advanced..." button untranslated" [Undecided,New]  https://launchpad.net/bugs/147612
<mdke> iwj: around?
<lamont> slangasek: still awake?
<mdke> I need to batch rename a substantial number of files from filename-LANG.po to LANG.po, does anyone know how I can do that?
<lamont> for f in filename-*.po; do mv $f ${f#filename-}; done
<lamont> I imagine someone has crafted some special command to do that, but why bother? :-)
<Mithrandir> rename s/filename-// filename-*.po ?
* mdke tries
<mdke> Mithrandir: do you think "svn rename" supports that too?
<Mithrandir> it doesn't
<mdke> ok
<Mithrandir> but lamont's version could work with svn rename
<lamont> Mithrandir: given tac-nukes...
<lamont> s/given/once you have/
<mdke> I replace "mv" with "svn mv"?
<lamont> or mv with svn rename
<Mithrandir> lamont: to you, everything smaller than a tac-nuke's not worth having.
<lamont> or whatever svn wants
* mdke tries :)
<Mithrandir> s/everythin/anything/
<lamont> heh
<lamont> I will admit that it's not uncommon for people to scratch their heads when they have occasion to watch me type in a "one-liner" shell command that's a few hundred characters long, including some semi-complex regexps in sed or so...
<StevenK> lamont: Hey, that happens to me too!
<slangasek> lamont: sadly
* lamont fails to understand why they should think that strange...
<lamont> slangasek: since Mithrandir admitted to being awake, I figured I'd abuse him for the sync. :-)
<slangasek> ok then
<Mithrandir> sync, schmynk?
<lamont> Mithrandir: I have to actually upload it to debian first...
* lamont is fixing some bind9 bugs
<slangasek> calc: how's OOo doing?
<Mithrandir> lamont: ahkay
<lamont> they're all either trivial, or at least interesting in LP
<mdke> lamont: I've tried http://paste.ubuntu-nl.org/39431/ (I've just put in one filename, "about-ubuntu" to test). Can you see where it's wrong?
<lamont> I knew it was dangerous to answer that question... :-)
<mdke> perhaps I haven't got the paths right
<mdke> ok, if you're too busy, please don't worry
<mdke> i'll try and play with it
<mdke> lamont: yeah, sorted, sorry
<slangasek> lamont: wrt the "BIOS clock" question - surely if there isn't such a question today, there's an assumed answer to this question?
<lamont> for i in about-ubuntu ; do for x in $(cd $i/po && echo $i-*.po); do echo $x ; echo svn mv $i/po/$x $i/po/${x#$i-}; done ; done
<lamont> slangasek: "utc"
<slangasek> lamont: so what's the problem with going with that answer?
<lamont> which, if you're dual-booting, tends to be wrong
<lamont> since windoze insists that the BIOS clock == localtime
<lamont> it's not like windoze gives you the option
<slangasek> ok, so this is the "system assumes UTC, Windows resets to local time, fsck gets the time wrong on reboot" case
<lamont> so the solution is to set BIOS==localtime, and always make sure that windoze is running when daylight-savigs time changes happen
<lamont> this is the "kernel assumes UTC, we don't fix it, then we do (ntpdate), and now the timestamp on the about-to-be-checked FS is in the future, because you have the misfortune of living east of Greenwich" thing
<slangasek> I have to say I'm a bit worried about changes in this area so close to release, because I'd believed this whole thing was sorted twice before now
<lamont> slangasek: where as I knew it wasn't sorted... the last time I came close to it, there was no answer that worked... and then they made /etc/localtime not a symlink to /usr/ (which is frequently not on the root partition - major mess)
<slangasek> hrm, "kernel assumes UTC" - at what point are you saying that's a problem, does the system even know the timezone at that point? .... or does it know the timezone because of the last fix?
<lamont> and then Ted was kind enough to file a very detailed explanation
<lamont> at the kernel boot time, it doesn't know the TZ, assumes UTC
<lamont> as long as we get the time corrected before we mount /, then we haven't screwed over e2fsck
<slangasek> ok, so... isn't that the same bug as always?
<lamont> so we need to fix the clock before we mount -oremount,rw /
<lamont> yep
<slangasek> so is it *really* fixed this time? :)
<lamont> picky picky.
<lamont> for non-ubiquity installs, yes
<slangasek> ok.
<lamont> "we deeply regret any inconvenience this may cause ubiquity users in the eastern hemisphere who use BIOS=local"
<lamont> we regret it so much that we might change ubiquity to let them fix it before hardy ships
<slangasek> s/BIOS=local/Windows/
<slangasek> ;)
<lamont> nah - I use windoze with localtime==UTC
<lamont> because, dammit.  BIOS==utc
<slangasek> heh
<lamont> so windoze gets to think we live in the UTC TZ
<realist> That's how I would resolve it, if I used Windows, that is.
<lamont> many users get very confused if they see UTC times
<sladen_> so storing the timezone offset in the filesystem (with one of the offsets being "unknown"
* slangasek vomits politely
<sladen_> then anything within 24hours of unknonwn can be discounted
<sladen_> and then in that case, the generic case could be to discount a timeout +/-12hours of the considered time
<lamont> ew
<lamont> hrm.. when did debootstrap become arch:any?
<sladen> well that's actually the fix isn't it.  to turn a timeout of 180days into  179days +/- 1 day
<lamont> no.  the hack solution for gutsy was to have e2fsprogs pick up a config option that says to ignore the fact that the filesystem time is in the future
<slangasek> lamont: it... didn't?
<lamont> distinguish between a system whose clock is off by two hours, and one that is in +0200
<sladen> (...in the future /by less than 24hours/)
<lamont> slangasek: ah... it's been arch:any for _quite_ sometime... my bad.
<lamont> anyway, mind if I do 1.0.3build1
<slangasek> lamont: er, what?
<lamont> https://edge.launchpad.net/ubuntu/+source/debootstrap/1.0.3
<slangasek> $ apt-cache show debootstrap|grep Arch
<slangasek> Architecture: all
<fabbione> slangasek: just to trigger a no-change rebuild
<lamont> you'll note build records for far more than the i386 one would expect for arch:all
<slangasek> yes, a no-change rebuild of /what/?
* lamont looks a bit more
<slangasek> ah, the udeb is arch: any
<slangasek> wtf?
<lamont> ah. of debootstrap-udeb
<lamont> --> debootstrap source
<lamont> once I get bind9 in, ubuntu-standard is installable from ports.u.c
<lamont> OTOH, installing from ports.u.c is b0rked because of (so far) debootstrap
<slangasek> lamont: ok, go for it (mutter binary udeb for arch: all deb grumble)
<lamont> it appears to have been that way since antiquity, if that makes you feel any less sick
<slytherin> seb128: ping
<mdke> Mithrandir: lamont: all working fine, thanks a lot for the help
* Hobbsee beat the traffic, for the most part.
<lamont> Hobbsee: what TZ you in?
<seb128> slytherin: if you let some context with the ping you have a higher chance to get a reply ;)
<slytherin> seb128: Ok. Waiting for your take on bug 145334
<ubotu> Launchpad bug 145334 in libtheora "[Freeze Exception]  Please sync libtheora 1.0 beta 1 from Debian" [Undecided,New]  https://launchpad.net/bugs/145334
* Mithrandir tickles Hobbsee, then runs off.
<Hobbsee> lamont: sydney
* Hobbsee runs after Mithrandir, and stomps on his feet
<lamont> ah.  makes sense then
<seb128> slytherin: why my take? I don't know anything about libtheora
<lamont> Mithrandir: you should have had me hold Hobbsee down before you tickled.
<lamont> then your feet would hurt less
<Hobbsee> hm
<slytherin> seb128: You are the uploader, right? That is what Riddell said
<Mithrandir> lamont: I run faster than her, so she's just _claiming_ to have stomped my feet.
<Hobbsee> lamont: i fight fairly hard when held - so, you may be putting yourself up for a lot of pain with that.
<Mithrandir> lamont: also, have you ever tried stomping the feet of somebody who's running?
<lamont> Mithrandir: I find that tripping them first helps
<StevenK> Usually, you end up either tripping, or tripping them
<slytherin> seb128: That bug has some test packages I have created. Riddell has commented, but I am waiting for your comments too.
<Hobbsee> hehe
<seb128> slytherin: I did the sync with Debian for whatever reason but I'm not maintaining the package
<lamont> Hobbsee: we call it ground-work at my dojo. :-)
<Hobbsee> lamont: dojo?
<StevenK> Place one goes to do karate
<StevenK> Well, martial arts
<slytherin> seb128: That complicates the matter. :-(
<Hobbsee> oh right, yes
<seb128> slytherin: BTW you can't sync this one Debian, there is Ubuntu changes required
<slytherin> seb128: I will be very happy if you can find some time stating what changes. I will recreate the package accordingly. I am new to the packaging thing. :-D
<seb128> slytherin: I'll have a look today don't bother
<seb128> slytherin: better to start on some universe packages for you ;)
<slytherin> seb128: Ok. Thanks a ton.
<seb128> you're welcome
<slytherin> seb128: will do when hardy repos open up.
<seb128> cool
<slytherin> seb128: I wanted to test theora beta, that is why I created the package. There seems to be no breakage and performance is good. :-)
<seb128> do you notice any difference with the alpha version we have?
<slytherin> performance improvement (less CPU usage), encoding as well as decoding.
<lamont> Mithrandir: feel like reviewing 82178
<lamont> and oops.  my bad on 131415
<lamont> both are closed,  but the changelog is only in 82178
<lamont> (I waited for the 'accepted' mail from debian.. see, I can be good... :-)
<Mithrandir> lamont: did you time it for the 13-14-15 bug? :-P
<lamont> no
<Mithrandir> lamont: looks fine to me.
<lamont> pure serendipity
<lamont> syncage, por favor
<Mithrandir> file sync bug, then. :-)
<slytherin> Mithrandir: Are you currently maintaining bluez-utils package?
<Mithrandir> slytherin: yes
<lamont> I was told that we should just use existing bugs for the sync requests
<lamont> if you want a separate one, I'll file it
<Mithrandir> lamont: just make sure the existing one says "plz sync" and sub ubuntu-archive then
<lamont> 82178 has that/.
<Mithrandir> indeed.
<lamont> OTOH, I simply subscribed ubuntu-archive to 131415, because I suck
<slytherin> Mithrandir: I believe there is a problem with XSBC-Original-Maintainer field, currently it is specified as XSBC-Maintainer.
<lamont> two bugs.  I had a 50-50 chance of hitting the right one when I subscribed u-a the first time...
<Mithrandir> lamont: meh, syncing from incoming sucks, it'll be done friday.
<lamont> Mithrandir: but... my patience.....
* lamont considers a build1 upload, just to save Mithrandir's efforts
<lamont> OTOH, I'll be good and wait
<Mithrandir> slytherin: thanks; fixed.
<lamont> actually, it'll hit sid in about 10.5 hours-ish... it could be done Wed. :-)
<lamont> filing sync requests for things in incoming sucks, too, btw.
<StevenK> Filing sync requests for things when packages.debian.org hasn't updated to have the new changelog sucks too.
<slytherin> Mithrandir: Also, the homepage url should be changed to http://www.bluez.org because the old sf.net url doesn't work anymore. :-D
<lamont> StevenK: I think that's the more general case of the pain I was referring to
* lamont notices the clock
<StevenK> lamont: Yeah, but Incoming will sort itself out - in my experience packages.d.o sorts itself out much much slower
<lamont> StevenK: but the reason filing the sync req for incoming-stuff is painful is because p.d.o isn't curent
<lamont> current, even
<stgraber> Has anyone be able to make crypted LVM to work on USB HDD with today Ubuntu alternate ? (even without splash, I see the kernel detecting the HDD, then nothing)
<stgraber> hmm, after a while I have the initramfs prompt and "/dev/mapper/ubuntu-root does not exist" message :(
<Fujitsu_> stgraber: A fix was uploaded about 11 hours ago.
<Fujitsu_> It works, too.
<stgraber> weird that it isn't in today daily then
<Fujitsu_> stgraber: To boot it manually, just run `cryptsetup luksOpen /dev/sdaX something', and hit Ctrl+D.
<stgraber> ok
<Fujitsu_> Erm, hit Ctrl+D after entering the password and hitting enter, that is.
* Starting logfile irclogs/ubuntu-devel.log
<slytherin> Does nautilus really require libbeagle for compilation? Or does it work with libtracker?
<seb128> slytherin: it requires libbeagle to work with beagle for users who decide to use this indexer
<slytherin> seb128: Thanks for info.
* Hobbsee wonders just how hard she can hammer her connection.
<seb128> slytherin: you're welcome
<seb128> slytherin: I think I'll not do the libtheora update, I'm not comfortable enough with the SVN changes to apply them and I don't want to upload a version that crashes on powerpc
<slytherin> seb128: Will do it then if they release beta 2? I had a conversation on #theora yesterday and they said they will release beta 2 if that is important for Ubuntu.
<slytherin> seb128: So ball is in our court. :-)
<seb128> slytherin: that will need another approval from slangasek or pitti but would make things easier
<StevenK> elky!
<slytherin> seb128: I am not a developer. All I can do is help (read as 'push'). :-)
<Mithrandir> lifeless: are you still seeing bug 79666?
<ubotu> Launchpad bug 79666 in bluez-utils "hcid crashdump" [High,Confirmed]  https://launchpad.net/bugs/79666
<Hobbsee> morning Keybuk
<Keybuk> morning
<Keybuk> eurgh, that coffee was nasssty
<Hobbsee> Keybuk: drink coke.  fixes everything.
<Keybuk> except one's teeth
<Hobbsee> not *that* much coke.  sheesh!
<iwj> mdke: How can I help ?
<elkbuntu> StevenK, hi :)
<Riddell> seb128: how come trackerd autostart is OnlyShowIn=GNOME;KDE;XFCE; ?
<Riddell> and if I remove KDE from there, will it still start when someone runs whatever the tracker application is?
<seb128> Riddell: it should start, yes, the autostart is only to automatically start it
<seb128> I mean when starting your session
<seb128> the issue is that people will not open the preference dialog to run it at every session
<Riddell> seb128: so ok for me to remove KDE from that list?  seems daft to have two disk indexers running
<seb128> yes
<Riddell> seb128: done
<Riddell> seb128: New queue is almost empty but for packages I've touched, if you could look at those today it would be good
<seb128> Riddell: ok, will do
<seb128> StevenK: hi, could you have a look to bug #148380?
<ubotu> Launchpad bug 148380 in gimp "Zooming to 150% makes image transparent.  New package please" [Undecided,Confirmed]  https://launchpad.net/bugs/148380
<seb128> mdke: around?
<mdke> seb128: (In case I'm not around at the moment, please provide a bit of information about what you want and I will respond when I get back)
<seb128> mdke: nice autoreply ;) Should the "manpages" item be in the "advanced topics" with the info pages?
<Whoopie> hi asac, could you have a look at bug 96260 (https://bugs.launchpad.net/ubuntu/+source/network-manager-openvpn/+bug/96260/comments/5)? this fixes one of my openvpn issues.
<ubotu> Launchpad bug 96260 in network-manager-openvpn "n-m-openvpn: resolv.conf is erased if endpoint does not push DNS servers" [Low,Triaged] 
<ubotu> Launchpad bug 96260 in network-manager-openvpn "n-m-openvpn: resolv.conf is erased if endpoint does not push DNS servers" [Low,Triaged]  https://launchpad.net/bugs/96260
<seb128> mdke: oh, they are ;)
<ScottK> lamont: I'd love to see a patch for Bug 42463 too, but it's beyond me to produce it (you asked me about it ~ 5 hours ago)
<ubotu> Launchpad bug 42463 in bind9 "rndc hangs if lo iface is down, affects other packages" [Medium,Confirmed]  https://launchpad.net/bugs/42463
<ogra> ScottK, i always wondererd if it wouldnt make sense to hardcode lo anyway
<ogra> and to not tear it down at all (wrt to your bug)
* ScottK doesn't know enough to have an opinion.
<StevenK> seb128: Right, the patch looks a little big.
<StevenK> seb128: I shall sort out a patch and a test build, and come up with a large image to test.
<seb128> carlos: could you look at bug #148509 opened by TomaszD?
<ubotu> Launchpad bug 148509 in language-pack-gnome-pl "The "Extra effects" string is not translated [gutsy] " [Low,New]  https://launchpad.net/bugs/148509
<carlos> sure
<TomaszD> that's a weird one, yes
<carlos> seb128: I guess that's gnome-control-center, right?
<seb128> carlos: yes
<TomaszD> I was under the impression that a conflicting accelerator key might be the culprit, so I changed the string today
<seb128> TomaszD: nothing check conflicts for you
<seb128> TomaszD: if you have one you will just a bug when using the accelerator in the dialog
<TomaszD> uhuh, so that couldn't be a problem then
<carlos> TomaszD: please, send me the file /usr/share/locale-langpack/pl/LC_MESSAGES/gnome-control-center-2.0.mo (carlos.perello@canonical.com)
<seb128> carlos: the french one doesn't have the strings so I think they have not been exported (yet)
<carlos> seb128: as far as I know, gtk+ handles well duplicated accelerator keys
<carlos> seb128: hmm, latest export was on Saturday night
<carlos> around UTC midnight
<seb128> carlos: when has the current template being imported?
<carlos> I'm checking it
<TomaszD> carlos, sent
<carlos> seb128: 28-09-2007
<carlos> before latest update
<seb128> carlos: looks like the export is buggy then
<carlos> anyway, yesterday night we exported an update language pack so I guess today it should end in the archive (if pitti's scripts work well)
<carlos> seb128: aren't those strings Ubuntu specific?
<seb128> carlos: they are, why?
<carlos> seb128: well, I guess there is a delay between the .pot file being imported and people translating it
<seb128> carlos: TomaszD said he translated those
<TomaszD> yes, all in one go
<carlos> TomaszD: when ?
<TomaszD> umm, let me check
<carlos> in fact...
<carlos> update to latest language packs
<carlos> the ones exported yesterday are already in the archive
<carlos> unless you translated it today or late yesterday this update must include your translations
<TomaszD> checking now
<carlos> hmm, there is a .pot file pending of being imported into gnome-control-center
<TomaszD> hmm update doesn't show language-pack-pl
<carlos> so another possible problem is that the string was updated with that other upload to the archive and thus, Launchpad is still missing it
<TomaszD> last time I've updated was a few hours ago, there was a language-pack-pl and I've reloaded the session and then noticed that bug
<carlos> TomaszD: I think is last thing I told you. I have the same problem in Spanish
<carlos> so Launchpad is missing that concrete string
<carlos> and thus, is not able to export it
<carlos> or offer it for translation
<TomaszD> but it does offer it for translation
<carlos> once the import queue handles that pending .pot file the problem will be fixed
<TomaszD> I've changed the string today to fix the accelerator key
<carlos> TomaszD: are you 100% sure is that exact string?
<TomaszD> 100% sure
<TomaszD> E_xtra effects: blah blah blah
<carlos> any comma, dots or accelerator changes will make it different
<seb128> TomaszD: the string changed
<seb128> it used to use computer
<seb128> and not graphic-card
<carlos> so that's it
<TomaszD> ah! so the template is out of date
<seb128> "Requires faster computer."
<seb128> "Requires faster graphics-card."
<seb128> yes
<seb128> <carlos> hmm, there is a .pot file pending of being imported into gnome-control-center
<TomaszD> the changelog didn't mention any string changes, it's already late into the game
<carlos> seb128: that's what I just said
<seb128> I didn't know about it
<seb128> MacSlow did the change while cleaning the glade changes
<seb128> that was not documented in the changelog
<TomaszD> oh well, will have to wait for the new template and then translate it, dang keeping up with all the changes is hard
<carlos> aren't we in string freeze?
<MacSlow> seb128, ups... sorry :/
<seb128> carlos: dunno, freezes are not announced and I didn't look at the schedule recently
<seb128> carlos: let me look
<TomaszD> that's what I wanted to say. :]  no problem though, as long as I know these things...
<MacSlow> seb128, ehm... wait... that is documented in the changelog
<carlos> seb128: seems like we don't have a string freeze
<carlos> we used to have one, though
<seb128> MacSlow: ""trimmed down diff against capplets/appearance/data/appearance.glade
<seb128>       (restricting it to just the "Visual Effects"-tab) in order to fix
<seb128>       http://bugzilla.gnome.org/show_bug.cgi?id=480667""
<ubotu> Gnome bug 480667 in Appearance "gnome-appearance-properties doesn't resize the notebook widget" [Normal,Resolved: notgnome] 
<seb128> MacSlow: that's the description you gave me
<MacSlow> seb128, wasn't that enough or not verbose enough?
<seb128> MacSlow: I though that you dropped the extra glade-3 changes to fix the resizing issue
<seb128> MacSlow: not that you changed the wording of the options, which breaks translations
<seb128> MacSlow: that's ok but we should really stop changing strings now or those items will not be translated for gutsy, it's already late for translators
<MacSlow> seb128, ok
<jdstrand> pedro_: are the backtraces for bug #146330 helpful?
<ubotu> Launchpad bug 146330 in evolution "evolution addressbook crashes when selecting a 'Show' category" [Medium,Incomplete]  https://launchpad.net/bugs/146330
<Keybuk> jamiemcc: ah, just the man I was looking for :-)
<jamiemcc> hi Keybuk whats up?
<Keybuk> jamiemcc: trackerd is hammering my disk sufficiently hard that things like evolution are almost unresponsive
<Keybuk> tracker-status says it's Indexing
<Keybuk> but none of the numbers in tracker-stats are increasing
<jamiemcc> with latest version 0.6.3?
<Keybuk> and, most strangely, EvolutionEmails remainds at 0
<Keybuk> yes
<Keybuk> (and rebooted after install)
<jamiemcc> Keybuk: do you use imap with evo?
<Keybuk> yes
<jamiemcc> or is t pop
<Keybuk> imap with local folder caching
<jamiemcc> Keybuk: is it wqriting to disk or constantly reading?
<Keybuk> how would I tell that?
<jamiemcc> strace
<Keybuk> strace on the second thread is all lseek() and read()
<Keybuk> first thread is in futex(
<jamiemcc> or check diskstats in proc
<Keybuk> master is in poll(
<pedro_> jdstrand, looking at it now
<jdstrand> pedro_: I believe the first is not useful
<jamiemcc> Keybuk: other thread? (there are 3)
<Keybuk> there are two
<Keybuk> wing-commander scott% ps Hax -L | grep track
<Keybuk>  5770  5770 ?        SNl    0:02 trackerd
<Keybuk>  5770  5912 ?        SNl    0:00 trackerd
<Keybuk>  5770  5913 ?        DNl   16:23 trackerd
<Keybuk> well, two threads and what I called the master :p
<jamiemcc> yeah
<pedro_> jdstrand, not at all, the second one is useful, thanks
<jdstrand> pedro_: ok great :)
<jamiemcc> Keybuk: second thread is constantly reading?
<Keybuk> the reason I say it's weird that it's not counting evolution mails is that through strace, I've seen it looking at them
<Keybuk> lstat64("/home/scott/.evolution/mail/imap/scott@imap.netsplit.com/folders/Sent/779.", {st_mode=S_IFREG|0600, st_size=222301, ...}) = 0
<Keybuk> access("/home/scott/.evolution/mail/imap/scott@imap.netsplit.com/folders/Sent/3586.", F_OK) = 0
<Keybuk> etc.
<StevenK> seb128: Gimp built, just about to test.
<Keybuk> (I have just upgraded to 0.6.3, so I'm willing to believe it's just catching up with things)
<jamiemcc> Keybuk: it should write out every 200 emails indexed for imap
<Keybuk> the numbers are going up now
<Keybuk> could it have been rewriting its index or something?
<jamiemcc> Keybuk: 0.6.3 reindexes automatically
<Keybuk> every time I login, or just once?
<jamiemcc> keybuk: just once when upgrading from prior versions
<jamiemcc> Keybuk: new/deleted mail will be indexed at startup of course
<Keybuk> EvolutionEmails : 19099
<Keybuk> and climbing now
<Keybuk> so maybe it was just upgrade blues
<Keybuk> it's certainly noticing the mails now :)
<Keybuk> and the disk is less hammering
<jamiemcc> Keybuk: yeah or you had some bug file attachments
<jamiemcc> big
<StevenK> seb128: gimp patched, and built, and tested sucessfully. I'm uploading it now
<seb128> StevenK: cool, thanks
<StevenK> To be honest, the image being transparent was very cool.
<seb128> StevenK: ;)
<soren> mjg59: I see you disabled the reference to the pm-utils website in gnome-power-manager.. Would it perhaps make sense to collect the information from the gutsy users so we have everything ready and shiny for hardy?
<mjg59> soren: Which information?
<soren> mjg59: AFAIR they're redirected to that page in order to get them to gather information about what it would take to make their system suspend/resume properly?
<soren> Is this where you're going to point out that those instructions of course rely on the presence of pm-utils?
<mjg59> Yup
<soren> THought so.
<soren> Never mind, then. :)
<mjg59> I'm really hoping that we can migrate over to pm-utils by hardy
<soren> Me too.
<soren> Especially due to how easy it makes it for users to help discover all the quirks needed for their specific system.
<Ng> am I right in thinking that the difference between booting the livecd and booting it with safe graphics is that the latter uses vesa?
<cjwatson_> Ng: yes
<cjwatson> Ng: "safe graphics mode" translates to the xforcevesa command-line option
<Ng> ok
<\sh> moins
* lamont notes that enigmail/dapper-proposed is doing the lather-rinse-repeat thing over missing/not-missing build-deps
<Hobbsee> dear thunderbird, you are on crack!  please get *off* it.  kthxbye.
<lamont> Hobbsee: what's thunderbird? :-)
<Hobbsee> lamont: :)(
* lamont uses apt-cache since Hobbsee won't tell him.
<lamont> I _thought_ it claimed to be a mail reader
<lamont> MUA, rather
<lamont> based on the depends, it's GUI-based, though, so it can't possibly really be an MUA.
<_MMA_> cjwatson: re: Germinate. Thanx. We'll get right on it.
<bddebian> Heya
<cjwatson> _MMA_: np
<cjwatson> sorry it wasn't straightforward to do centrally
<_MMA_> Yeah. Its ok. At least we have a solution.
<_MMA_> We'll get the fix do today so it hopefully hits the next daily.
<_MMA_> s/do/done
<tkamppeter> doko, Riddell, ping
<doko> tkamppeter: pong
<Keybuk> ext3 so needs an "undo" feature
<Spads> so that you can restore your nethack save files
<Spads> ^-- Enterprise-level feature.
<dobey> Keybuk: mc has undelete
<dobey> mc the file manager that is
<dobey> i think you need to know the inode info though
<Keybuk> I was more thinking of "rm -rf /*" ... D'OH! UNDO! UNDO! UNDO!
<Spads> that has some interesting security implications, of course
<dobey> heh
<StevenK> In terms of "Damn! So the Federal Police *can* see my kiddie porn!" ?
<StevenK> ... Or something.
<Keybuk> Spads: go I have a goatee?  am I wearing a Serenity t-shirt?
<dobey> StevenK: well, even if you write all 0s to the disk 3 times, they can still find stuff.
<jdong> nothing like a massive network of LVM snapshots for fun
<Spads> Keybuk: You are zippy and I claim my non-sequitur.
<Keybuk> security's all well and good, if you like that kind of thing
<Keybuk> but I'd rather know what files I just accidentally deleted
<Keybuk> so I can put them back
<jdong> dobey: I've been told that you can never really wipe a magnetic medium to the point of impossible recovery... just make it increasingly difficult.
<Keybuk> I'm kinda hoping it just got stuck in to evolution's cache before I hit ^C
<StevenK> I think burning the disks platters would make it nigh on impossible.
<jdong> dobey: and encryption/wiping is a complete nonissue when you've got criminal charges against you for something.... they'll jst slap on charges for failing to provide the secret key or destroying/concealing evidence anyway.... :)
<dobey> jdong: well, there is certainly a point. however, the number of times you have to write 0s to the disk to actually make everything be 0 again, can be pretty high
* jdong wonders if using reiser4 on /var/log counts as concealing or destroying evidence ;-)
<dobey> jdong: there's a reason there are encryption export laws in the US
<dobey> jdong: "if the NSA can't hack it, it can't be legal."
<jdong> dobey: considering the urgency that they are switching to elliptic curve, I cannot help but suspect they've made significant headway on that.
<dobey> jdong: and if you're on the defendent end of a case with the US vs. You, and the NSA is poking through your data, you're already screwed.
<jdong> dobey: agreed :)
<tkamppeter> doko, riddell, another try, my box crashed and afterwards it fsck for half an hour.
<Riddell> ouch
<Riddell> tkamppeter: doko ponged, or I'm here
<doko> <tkamppeter> doko, Riddell, ping
<doko> * RAOF_ (n=chris@123-243-65-41.tpgi.com.au) hat #ubuntu-devel betreten
<doko> <doko> tkamppeter: pong
<tkamppeter> Riddell, doko, can one of you upload my system-config-printer packages (see your mail), as pitti is celebrating the reunification of Germany
<Riddell> doko: shall we fight for it?
<doko> Riddell: you won ;p
<jdstrand> pitti, keescook, soren, and anyone else who wants to weigh in: I am close to having a fix for bug #119075 for dapper -> feisty
<ubotu> Launchpad bug 119075 in mysql-dfsg-5.0 "Root password policy for mysql" [High,Confirmed]  https://launchpad.net/bugs/119075
<Riddell> ok
<jdstrand> pitti, keescook soren: but I am not sure how to let the user know that the change was made
<jdstrand> wrt string changes
<tkamppeter> Riddell, doko, can you also upload hplip which fixes bug 147369 (see mail)
<ubotu> Launchpad bug 147369 in hplip "MASTER: Printing via HPLIP does not work any more" [High,Fix committed]  https://launchpad.net/bugs/147369
<jdstrand> the fix is based on soren's work, and will just generate a random password if the mysql password is determined to be blank.  There is also a mechanism in the init script to reset the password.
<jdstrand> I could just document it in the REAMDE as well as the changelog, but wanted some feedback
<Riddell> tkamppeter: system-config-printer uploaded
<soren> I'm really not all that keen on randomly setting passwords on people's existing installations.
* Hobbsee blames soren for all the bugs in ubuntu
<soren> Hobbsee: Again?
<Riddell> tkamppeter: where is hplip?
<tkamppeter> Thanks, Riddell, this eliminates 9 bugs.
* Hobbsee assigns them all to soren, and tells him to fix them before next tuesday.
<tkamppeter> Riddell, you should have gotten another e-mail. Otherwise at http://www.linux-foundation.org/~till/tmp/ubuntu/gutsy/hplip/  (the usual place)
<jdstrand> soren: another option is to just detect the password is blank, and then alert the user whenever mysql is started until it is not blank
<cjwatson> Spads: nethack save files> so are you an evil savescummer? :P
<Spads> cjwatson: no, but I was when I ran DR-DOS
<jdstrand> soren: but I don't think the intent was to ever have it be blank, so I think there is something to the argument that it should be changed.  It is a real vulnerability that just was never fixed
<jdstrand> soren: though I understand what you are saying
<soren> Hobbsee: /me cries
* Hobbsee hugs soren
<Hobbsee> soren: get to it :)
<soren> jdstrand: I like that idea much better (telling the user he should be setting a password real soon)
<Hobbsee> bwah?
<Hobbsee> ookay?
* Hobbsee peers up at her light
* soren sucks it up and gets to work.
<slangasek> seb128, MacSlow: wrt string freeze, pitti reorganized things so that this is subsumed in the UserInterfaceFreeze -- so yes, /long/ since frozen
<slangasek> (https://wiki.ubuntu.com/UserInterfaceFreeze, Sep 13)
<tkamppeter> Riddell, also thanks for uploading hplip, eliminating a high-priority bug
<Riddell> you're welcome
<mathiaz> keescook: so for the apparmor parser revision number, what about creating just one package for the parser ?
<keescook> that could work -- having a totally separate source package for the old parser?
<mathiaz> keescook: that way we'll have apparmor-parser-2.0.1
<mathiaz> keescook: yes. And then apparmor, apparmor-profiles with a revision number of 2.1+993
<keescook> it might be more painful that just mod'ing the orig.tar.gz (since we'd need to put all the abstractions and man pages into the new one)
<keescook> oh, you mean literally _just_ the parser.
<mathiaz> keescook: yes.
<keescook> looks like the man page is the same between 2.1 and 2.0.1
<keescook> mathiaz: okay, yeah, I like this.  I think it's the cleanest solution.  We can add a Depends for it to the "apparmor" package.
<keescook> and drop the parser from "apparmor".
<mathiaz> keescook: yop. However, there is a correlation between the profiles and the parser.
<mathiaz> keescook: the kernel provides a apparmor-modules-2.0
<keescook> mathiaz: how about this, instead of a new source package, why not just make a new orig for the current apparmor, and add the old parser tree to the root directory?
<keescook> then we can change the build to just build out of the old parser dir instead of the new one.
<mathiaz> keescook: hum.. How about revision number then ?
<mathiaz> keescook: the reason to create a separate source package for the parser is that we can have an appamor-parser-2.0.1
<mathiaz> keescook: if we don't really care about revision number, I would just drop the old parser code in the bzr tree.
<keescook> well, I was thinking about the profiles syntax version
<keescook> true.
<keescook> maybe that's the best way to deal with it.
<mathiaz> keescook: OTOH the revision number would indicate that we have 2.1, but we really have 2.0.1
<keescook> just drop the entire old parser in.
<keescook> right, but the utils will still be 2.1
<mathiaz> keescook: that may confuse users that try to add profile.
<keescook> either way, we'll have confusion either the profiles won't be 2.1 style or the utils won't be the 2.0 versions.
<keescook> I think the bulk of the interaction for people is with the utils, so we should try to keep those at 2.1.
<mathiaz> keescook: yes. The later is less confusing.
<mathiaz> keescook: hum... 2.1 has lots of new feature on the kernel side.
<keescook> mathiaz: yeah.
<Keybuk> why does pbuilder have to be run as root?
<mathiaz> keescook: moreover I think that the 2.1 utils should work well with a 2.0 module.
<mathiaz> keescook: the other way around doesn't work at all.
<mathiaz> keescook: now I wonder if the utils would generate incompatible profiles.
<keescook> mathiaz: oooh.  hmmm.  wait, no I think it builds them based off the hints from the kernel, which would do the right thing, right?
<mathiaz> keescook: yes. I hope so.
<mathiaz> keescook: but then there is the new file vs directory change.
<keescook> mathiaz: hmm
<mathiaz> keescook: I'll go through the changelogs to see if there is something related to it.
* keescook nods
<mathiaz> keescook: what would be needed to realease an updated version of apparmor with a revision number of 2.0.1 ?
<cjwatson> mathiaz: either an epoch (but personally I'd be cautious about that), or else 2.1+993+really2.0.1-0ubuntu1 or similar
<keescook> how about a new orig.tar.gz, where the version is 1:2.0.1+2.1utils-0ubuntu1 ?
<keescook> cjwatson: why "really" vs epoch?
<cjwatson> keescook: if there's anyone else providing the package, you have to go round and persuade them to bump the epoch too
<cjwatson> but if that's not the case here I guess it's not a big deal
* keescook nods
<cjwatson> either way, be careful about shlibs on libapparmor
<cjwatson> did libapparmor1 2.1 introduce any new symbols?
<keescook> cjwatson: no, it's virtually a stub.  :)
<cjwatson> I notice the shlibs seem to just say "libapparmor1"
<cjwatson> ok, you dodge that bullet then ...
<cjwatson> (versioned shlibdeps break if you want to wind versions backwards)
<mathiaz> hum... So if we choose to use 2.0.1 where should we start the the revision number ? 0ubuntu26 ?
<mathiaz> (0ubuntu25 was the last one used for 2.0.1 - and feisty has 0ubuntu4)
<mathiaz> keescook: hum... we could actually use 2.0.1+993
<cjwatson> you should definitely never reuse a previous version number
<mathiaz> cjwatson: 2.0.1+993 has never been used.
<mathiaz> cjwatson: feisty has 2.0.1+510.dfsg-0ubuntu4
<mathiaz> cjwatson: and gutsy has 2.1+993-0ubuntu2:
<mathiaz> cjwatson: 2.0.1+993 has never been used.
<cjwatson> I wasn't saying it had been, it was just a general comment
<MacSlow> re
<Whoopie> cjwatson: Hi, re bug 36964, it's just a driver to support these Ricoh SD/MMC reader? it doesn't work perfectly, but better then nothing.
<ubotu> Launchpad bug 36964 in linux-source-2.6.22 "[dapper]  Asus sd/mmc card reader not working" [Low,Confirmed]  https://launchpad.net/bugs/36964
<cjwatson> Whoopie: I'm not a member of the kernel team
<cjwatson> Whoopie: I'm just pointing out (as a member of the release team) that it's *two weeks* before release and thus not generally a good time to insert new untried code
<cjwatson> that could e.g. crash systems that previously worked fine even though the reader wasn't supported
<Whoopie> cjwatson: ok
<jdong> cjwatson: how's the unionfs thing look nowadays? Is it still random or is it resolved?
<slangasek> still random
<jdong> yikes...
<jdong> do we have any idea what might be causing it?
<slangasek> idea perhaps, but no patches; kernel team is talking about rolling back to a previous version of unionfs
<cjwatson> (which also involves rolling back apparmor)
<cjwatson> unionfs upstream is also looking at it
<keescook> mathiaz: I think we should call it 2.0.1+993-0ubuntu3 for now, and if we need to roll back everything, use the "really" version suffix.
<mathiaz> keescook: hum... 0ubuntu3 or 0ubuntu1 ?
<keescook> er, sorry, I totally mis-typed
<keescook> 2.1+993-0ubuntu3
<mathiaz> keescook: you'd really stick with 2.1 ?
<mathiaz> keescook: I think it's misleading.
<keescook> mathiaz: for now, yes.  once we figure out what combination of things will work, we can resolve the version number for real.
<mathiaz> keescook: If you look at http://en.opensuse.org/AppArmor/Changes_AppArmor_2_1, half of what's written there is not supported.
<mathiaz> keescook: ah ok. So just as a temporary solution, we use 2.1.
<keescook> right
<mathiaz> keescook: but for the final release we'll update the version to the correct number.
<keescook> mathiaz: right.  I think we'll need to do a lot of testing first anyway.  version really is the least of our problems.  :)
<mathiaz> keescook: ok. WFM.
<alesan> does anybody have an idea if it is possible to ship a Ubuntu cd with a hardware product? do we need to ask canonical first?
<cprov> seb128:  hi, who is driving apport atm ?
<siretart> Keybuk: can you please comment on https://bugs.edge.launchpad.net/upstart/+bug/62751/comments/91?
<ubotu> Launchpad bug 62751 in cryptsetup "Upstart doesn't activate luks volumes (also non luks) in cryptsetup" [High,Confirmed] 
<Keybuk> siretart: what would you like the comment to say?
<siretart> is env a built-in in busybox?
<Keybuk> which busybox?
<seb128> cprov: "driving"?
<siretart> err, that one in initramfs
<cjwatson> siretart: no
<Keybuk> siretart: yes
<seb128> cprov: you mean hacking on it?
<siretart> lol
<Keybuk> CONFIG_ENV=y
<cjwatson> siretart: it's provided as a command. it's not a built-in
<Keybuk> yeah, what cjwatson said :)
<siretart> ok
<cjwatson> though, actually, it makes little difference, because the initramfs uses CONFIG_FEATURE_SH_STANDALONE_SHELL=y
<cprov> seb128: not exactly ;) but I've received reports that apport crashes when it tries to report a bug in a PPA package.
<cjwatson> so in the initramfs Keybuk is right and it is effectively a builtin
<cjwatson> in busybox-udeb it's an external command
<Keybuk> yes
<Keybuk> it's a not-builtin builtin thingy
<seb128> cprov: the program crash, the kernel intercept it and call apport
<Keybuk> maaaagic
<cprov> seb128: yes, I know, the problem is that apport reports the bug as if the PPA package was in ubuntu.
<cprov> seb128: uhm, doesn't it already happens for packages installed from other repositories ?
<seb128> cprov: it should not report bugs for non official packages, I'm not sure of what the logic to detect that is though, you want to speak to pitti he's the one writing apport ;)
<cprov> seb128: yup, he's out, I will file a bug for now, thanks
<seb128> cprov: alright, you're welcome, sorry for not being really useful there ;)
<seb128> time for diner now, bbl
<cprov> seb128: no worries, you did great ;)
<slangasek> iwj: bug #145231 seems to be waiting for info from you?
<ubotu> Launchpad bug 145231 in pidgin "cannot restart pidgin" [High,New]  https://launchpad.net/bugs/145231
<mdke> iwj: still around?
<slangasek> seb128: can I assign #145231 to you, so you can press iwj for details when you're both awake? :)
<bdmurray> tkamppeter: my printer prints blank test pages until I change the printout mode
<tkamppeter_> bdmurray, which model, which PrintoutMode gives blank pages, which one works? Please file a Launchpad bug.
<tkamppeter_> Riddell, doko, can you also upload cups-pdf and cupsys for me (see mail). Note that cups-pdf needs the new cupsys (AppArmor fix).
<seb128> slangasek: I'm assigned it to me, thanks for pointing it
<bdmurray> tkamppeter_: Should the bug be filed about cupsys?
<bdmurray> Or some other package?
<jdong> is it safe in Ubuntu to isntall syslog-ng? (I see that it kicks off ubuntu-minimal)
<carlos> nixternal: ping
<mdke> iwj: ok, I'll leave a message. I wanted to check something re: https://wiki.ubuntu.com/DapperFirefoxStartPageTranslation. In the last section, is it correct that where a language is already in the list of translatable locales, but a translation isn't yet shipped in (e.g.) ubuntu-docs, the translation can simply be added without applying the procedure there? (example, en_GB)
<tkamppeter_> bdmurray, it should be filed against the driver you are using, usually HPLIP for HPs, Gutenprint for most Epsons, ... See in system-config-printer which driver is used for your printer.
<Keybuk> oh, that's right, before I got distracted by starting another round of daily tests, I was replying to an e-mail
<slangasek> bug #125220 calls for adding default iocharset options to cdrom mounting; does it make sense for this to be a kernel default instead?
<ubotu> Launchpad bug 125220 in hal "Question symbols (????) in filenames on CD" [Medium,New]  https://launchpad.net/bugs/125220
<slangasek> Amaranth: is there still more info you're waiting for on bug #133609?
<ubotu> Launchpad bug 133609 in compiz "No window decorations on compiz session statup" [Undecided,Incomplete]  https://launchpad.net/bugs/133609
<minghua> slangasek: Does the kernel iocharset setting differentiate different filesystems?
* minghua is not sure all fs support iocharset=utf8 option.
<Amaranth> slangasek: that bug should be closed, i guess
<minghua> Actually, I'm pretty sure some of them don't, NTFS for example.
<slangasek> I'm pretty sure ntfs supports iocharset=utf8, you just don't want to use it because it interferes with case-insensitivity
<slangasek> at least that's the case for vfat
<slangasek> though hmm, I guess I don't know if ntfs-3g supports it
<jdong> slangasek: apparently you can do it but windows will hate your guts....
<jdong> at least that's the gist I've heard
<slangasek> er, why would that be? iocharset only controls how the filenames are exposed upwards, not how they're represented on disk
<ion_> If an NTFS partition is mounted with a non-unicode charset and there are filenames in another encoding than the iocharset, they are hidden entirely.
<slangasek> well, that's one instance of the same general problem of 125220
<slangasek> i.e., a problem when iocharset != utf8
<nixternal> carlos: pong?
<minghua> slangasek: Last time I checked, the option for NTFS is "utf8", not "iocharset=utf8".
<minghua> vfat, on the other hand, uses "iocharset=utf8"
<carlos> nixternal: hi
<minghua> I also vaguely remember that there were some changes from kernel 2.4 to 2.6.
<carlos> nixternal: I wonder whether I should approve/reject the kubuntu/khelpdesktop/kubuntu/po/systemdocs.pot  template for kubuntu-docs package in Launchpad
<carlos> nixternal: mdke told me I should ask you
* lamont wants to know what is turning down the backlight on his laptop when on battery....
<lamont> g-p-m isn't iit (unless it's ignoring gconf)
<nixternal> it needs to be translated...should I just send the po file to the list maybe?
<nixternal> carlos: ^^
<carlos> nixternal: I was not sure whether it was a mistake or not so it was not yet approved
<carlos> nixternal: it should be available in Launchpad in next minutes
<cjwatson> slangasek: with ntfs-3g, it's supposed to use the locale instead
<cjwatson> i.e. it does character set interpretation based on the locale of the ntfs-3g process, which is typically inherited from /etc/default/locale
<nixternal> carlos: you rock! if we ever meet, remind me that I owe you a drink of your choice :)
<cjwatson> the old utf8, iocharset=utf8, nls=utf8, etc. options are ignored
<carlos> nixternal: no need for that, but thanks ;-)
<jdstrand> slangasek: I am working on fixes for bug #119075 for dapper -> gutsy.  dapper -> feisty will be handled simply by informing the user that the root account does not have a password, and provide a means to set it.
<ubotu> Launchpad bug 119075 in mysql-dfsg-5.0 "Root password policy for mysql" [High,Confirmed]  https://launchpad.net/bugs/119075
<jdstrand> slangasek: I noticed your last comment, and I can very easily set a random password for gutsy
<jdstrand> slangasek: with the same mechanism for changing it that I used in dapper -> feisty
<carlos> nixternal: https://translations.launchpad.net/ubuntu/gutsy/+source/kubuntu-docs/+pots/systemdocs
* nixternal does a happy dance
<jdstrand> slangasek: what do you think?
<carlos> nixternal: hmm, that's a .desktop file...
<jdstrand> slangasek: I can also just as easily use the same 'fix' for gutsy as for the other releases
<carlos> nixternal: did you add the needed tag to get updates from language packs?
<nixternal> carlos: dunno if I did or not...I am not 100% familiar with getting those done...I followed a tutorial somewhere I think
<nixternal> but, since it doesn't sound like something I did, then I would have to say no
<carlos> All .desktop and .directory files should have an: X-Ubuntu-Gettext-Domain=systemdocs line (although this should be kdesytemdocs so it's not so generic, maybe kubuntusystemdocs...
<nixternal> hrmm
<carlos> nixternal: with that, you will get translation updates even after release time
<nixternal> OK, don't know if it is to late to work that out now, if not I will fix it in trunk so that gets straightened out for hardy
<carlos> well, not you, but Kubuntu users
<carlos> nixternal: if you change the translationdomain (the filename for that template, tell me it, I must change it in Launchpad too)
<nixternal> I could go ahead and fix that, in our repos and then reupload if that is cool?
<Keybuk> cjwatson: I've tested every combination I can think of, and I cannot replicate #139230
<carlos> nixternal: yeah, that's it
<nixternal> carlos: I will take a look at it here in a bit..I am finishing up some stuff here before my lovely evening class on "how to make a myspace website" :) just kidding, but it is javascript, so that is close enough :)
<carlos> :-P
<carlos> ok
<cjwatson> Keybuk: get back to the submitter for details?
<Keybuk> cjwatson: yup, am doing so; am going to remove the milestone as well since it works out of the box
<lamont> mdz: you around/
<lamont> ?
<Keybuk> cjwatson: the other person who reported it definitely has the "/var/run and /var/lock don't exist on the root filesystem" bug
<Keybuk> (which we have a cunning hack for in gutsy)
<Kopfgeldjaeger> i cant find the bug about encryption@install (alternate cd, gutsy).. can somebody give me the bug number (maybe bookmarked?)
<Kopfgeldjaeger> found it, its #144390
<Kopfgeldjaeger> good night
<glatzor> pign bryce
<bryce> heya glatzor
<glatzor> bryce: hello, have you made a decision about the temporarily fail safe mode?
<bryce> yeah, I've got a new xorg package that I'm testing now
<bryce> I expect to have it uploaded today
<mjg59> bryce: Any chance you can change dexconf a touch?
<mjg59> bryce: Rather than generating  "HorizScrollDelta" "0" it ought to be "HorizEdgeScroll" "0"
<mjg59> Otherwise there's no sane way to enable edge scrolling
<glatzor> bryce: would you then also upload displayconfig-gtk?
<glatzor> please
<bryce> mjg59: sure I can put that change in
<glatzor> bryce: should I apply the patch, that I sent you this morning?
<mjg59> bryce: Sweet, thanks
<slangasek> jdstrand: in discussion, the conclusion was that setting a random password is a bad idea because it's non-obvious to users how to recover access
<bryce> glatzor: yes please do
<bryce> glatzor: I've not had a chance to test that patch myself, but it looks good
<lamont> slangasek: now that it's in sid... could you sync bind9 for bug 82178 and bug 131415?  kthxbye
<ubotu> Launchpad bug 82178 in bind9 "idnconv manual page exists, but no binary" [Low,Fix committed]  https://launchpad.net/bugs/82178
<ubotu> Launchpad bug 131415 in bind9 "part of nslookup manpage not visible" [Undecided,Fix committed]  https://launchpad.net/bugs/131415
<lamont> :-)
<jdstrand> slangasek: agreed, but I was thinking I'd let them know via debconf how to change it
<slangasek> jdstrand: personally I don't think that's very user-friendly
<jdstrand> slangasek: ala 'if you press Enter, a random password will be generated.  you can reset this by..."
<jdstrand> slangasek: that's cool.  I'm fine with the high priority message.  pre-gutsy it was medium and hidden
<lamont> slangasek: would you be annoyed if the ppc, amd64, and sparc buildds went manual mode for a little bit?
<lamont> I'll assume that's a "YES"
<jdstrand> slangasek: just thinking out-loud basically
<glatzor> bryce: done. you can now upload it
<lamont> slangasek: details for the bind9 sync are in 82178
<bryce> glatzor: ok
<slangasek> lamont: bind9: looking then
<slangasek> lamont: on manual: is this the bootstrappery you were discussing with cjwatson earlier?
<bryce> glatzor: actually I've not rolled a displayconfig-gtk package before - is there a make dist-like procedure, or do we just make a snapshot?
<lamont> turns out that I have to add a key to the real root on the buildd for the bootstrappery to not kill all builds that happen with that chroot there...  so my choices are to manually make everything wait on starting the builds of mlton, or go add the &*(^ key on all of the affected architecture buildds
<glatzor> bryce: Good question. I have never uploaded one :)
<lamont> so, I'll go do the add-it-everywhere thing... I was just kicking a little on the way down
<bryce> hmm; perhaps we should ask mvo to do it this time, and write down the process for us?  ;-)
<glatzor> bryce: you could use bzr bd --source
<slangasek> lamont: so the fix for 82178 is to drop the manpage?
<lamont> yeah
<lamont> or rather, to be specific about what man pages we deliver, instead of delivering all of man1
<slangasek> good, I like it when packages get smaller
<lamont> otherwise, it's typo fixes in manpages and that one fix at the very bottom, which is low-risk
<lamont> (changes from call something that might assert to "if (this condition that's perfectly OK but will cause an assert does not exist) { call }
<lamont> )
<slangasek> lamont: the sync howto isn't working for me, and I'm not keen to poke things randomly to figure out why
<lamont> slangasek: you are a wise man.
<lamont> so... should I just upload -2build1 then?
<slangasek> if you like
<cjwatson> lamont: hang on
<cjwatson> slangasek: what's going wrong?
<lamont> cjwatson: it's about an hour from now before I get to that step
* lamont is dealing with mlton right now
<cjwatson> lamont: you don't need the chroots prodded?
<lamont> cjwatson: I was gonna have cprov do that once he's back.  Unless you want to do it now
<cjwatson> lamont: no, I'm off to bed in a moment
<lamont> cjwatson: so I have things were I'm nearly certain that I won't break anything except maybe PPA builds on virtual machines during the time between pushing the bootstrap-enabled beast, and the bootstrap-disabled beast
<lamont> on the bright side, I can retry stuff if I do break it. :-(
<cjwatson> lamont: which version of bind9 were you trying to get bind9 to sync?
<cjwatson> er, "were you trying to get slangasek to sync"
<lamont> oh.  bind9_1:9.4.1-P1-2
<cjwatson> where is that?
<lamont> should be in sid.
<cjwatson>      bind9 | 1:9.4.1-P1-1 |      unstable | source, alpha, amd64, arm, hppa, hurd-i386, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc
<cjwatson> isnae
<cjwatson> oh, only JUST landed in sid
<cjwatson> if you give things a chance to propagate, it'll be syncable just fine ...
<lamont> bind9_9.4.1-P1-2.dsc	2007-Oct-03 05:02:01	0.8K	application/octet-stream
<lamont> ah, ok
<lamont> so it needs rmadison to be done and aware of the upload...
<lamont> I suppose we can forgive a few hours more..
<cjwatson> no
<cjwatson> it needs whatever mirror we're using to have it
<cjwatson> p.s. would help if my link to drescher would stay up
<cjwatson> slangasek: workaround:
<cjwatson> slangasek: wget the .dsc and .diff.gz from wherever, maybe best grab the .orig.tar.gz for good measure, into ~lp_archive/syncs/
<cjwatson> slangasek: dpkg-scansources > Debian_incoming_main_Sources
<cjwatson> er, dpkg-scansources . /dev/null > Debian_incoming_main_Sources
<cjwatson> sync-source -b lamont -S incoming bind9
<cjwatson> flush-syncs # if that worked
<cjwatson> my link to drescher is too flaky to attempt it at the moment, and it's bedtime
<cjwatson> oh, and probably sync-source.py not sync-source
<bryce> elmo: deb with patch is up + caveats; see bug 86072
<ubotu> Launchpad bug 86072 in xserver-xorg-video-ati "ATI ES1000 515e not recognized" [Medium,Confirmed]  https://launchpad.net/bugs/86072
<slangasek> cjwatson: the part where I got stuck was with sync-source not being executable? :)
<cjwatson> slangasek: yeah, it's apparently sync-source.py this week
<cjwatson> sync-source was our forked version which is clearly not kosher at the moment
<cjwatson> but looks like sync-source.py ought to work well enough
<cjwatson> I didn't know about the non-executability until I tried it - when I have time I'll look into the diff and merge
<cjwatson> night folks
<slangasek> heh, ok
<thully> hi - I was on this channel last night regarding bug 137598 - a regression from Feisty.  Anyway, I do have a patch for that, and it is attached to the bug report (diff against the source file in question).
<ubotu> Launchpad bug 137598 in gnome-power-manager "Screen brightness resets to default (maximum) on idle with AC plugged in" [Medium,Confirmed]  https://launchpad.net/bugs/137598
<lamont> slangasek: later, I'll want you to sync mlton from sid.  I think that was the motu decision
<thully> The patch may not be the prettiest in the world (basically, what it does is check the appropriate "idle_dim" setting in the idle callback and doesn't call the brightness adjust function if it isn't set)
<thully> One may want to stop the callback from happening altogether, but that involves gscreensaver and may not be desirable (in case other things are being done on idle)
<thully> Anyway, I hope the devs can look at Ubuntizing this fix for the Gutsy release.  I think it would look bad to have this kind of bug (screen brightness adjusting on idle, no matter what the setting is) in Gutsy final...
<thully> I've been taking a peek at Ubuntu-related code, and I must say I've noticed an incredible amount of flaws in gnome-power-manager.  This one is quite glaring, but I've also stumbled upon another regression in 63543
<thully> I posted a patch for that in the bug report, but it still will change the brightness on exiting idle - even if the brightness is < the idle brightness on idle...
<thully> g-p-m 2.18 was fine in all these respects - it's just that g-p-m 2.20 has apparently fscked up the handling of idle and brightness with a rewrite of most of the relevant code...
<Keybuk> thully: 63543 is a pretty old bug, so has been present for at least one release
<thully> actually, I just reopened bug 63543 - it wasn't in Feisty, but is back in Gutsy since they rewrote most of the relevant code in g-p-m
<ubotu> Launchpad bug 63543 in gnome-power-manager "Error in automatic diminuition of brightness when idle" [Undecided,Confirmed]  https://launchpad.net/bugs/63543
<Keybuk> thully: have you talked to hughsie about your patches?
<thully> no - I guess I probably should - do I need to file upstream bug reports first?
<Keybuk> if it's the upstream code that's regressed, it's probably better to talk directly to him
<Keybuk> since it seems like you know what you're talking about
<Keybuk> and get it fixed upstream :)
<thully> I think so, but I know there is a UVF in Gutsy that would seem to block said changes from being integrated from upstream
<Keybuk> GNOME is in the same UVF right now :)
<Keybuk> though if hughsie acks the patches, they're much more likely to be applied
<Keybuk> since we'll know they're going upstream and can be dropped for our next release
<kylem> win 34
<Keybuk> lose 89
<elmo> draw 23
<Keybuk> hoot
<kylem> right.
<pwnguin> i do wish i could figure out why screen blanking doesn't work on nvidia
<Keybuk> pwnguin: binary driver or free one?
<pwnguin> rather, it does, but the backlight's still on =/
<pwnguin> binary i think
<pwnguin> i remember one was affected and the other wasnt
<lamont> slangasek: so does that mean that bind9 didn't get synced and I should upload, or that it's inbound and I should STFU and wait like a good little boy?
<Keybuk> pwnguin: we can fix one, but not the other
<pwnguin> Keybuk: vbetool works, but not xset
<lamont> Keybuk: any clues on why my backlight dims on battery, even though g-p-m has been told to 1) not dim, and 2) 100% is a good dimlevel, via gconf-editor?
<Keybuk> lamont: sodomy non sapiens
<lamont> is ATI M56P
<Keybuk> I know next to nothing about g-p-m
<lamont> heh
<lamont> ok
<slangasek> lamont: my attention drifted elsewhere, if you want to upload go ahead otherwise I'll look at it later on (at a point where the mirrors should have synced)
<Keybuk> lamont: I didn't even know until just now that it does stuff with brightness
<Keybuk> so I'm now curious whether it's the cause of my bug that the Dell's light sensor doesn't seem to work anymore
<lamont> slangasek: well, as long as it's done before fabbione wakes up in about 7 hours
<lamont> I have it spewing debug crap on my laptop for me to stare at later
<lamont> hrm... with g-p-m _NOT_ running, unplugging the AC still dims backlight... I think that's pretty conclusive that gpm is not to blame.
<Keybuk> that's probably BIOS :)
<Keybuk> unplug power, increase brightness, plug power back in
<lamont> how do I increase brightness, I wonder...
<Keybuk> Fn+Something? :P
<pwnguin> lamont: maybe there's an option in BIOS to twiddle
<Ng> something keeps resetting my brightness to 100%, which I'd assumed was g-p-m
<Keybuk> hmm
* lamont hugs Keybuk 
<Keybuk> gpm doesn't seem to be involved in brightness on my laptop at all
<lamont> (switch to something other than vt7, and use FN brightness up)
<pwnguin> theres gpm and the backend
<mjg59> Keybuk: I suspect your Dell is one generation too old
<Trewas> brightness is some kind of a strobo now that intel driver always sets it to maximum with anything interesting happening (any xvideo/opengl app starting, going to console etc) together with g-p-m or something munging it when idling :)
<mjg59> Yeah, I've got a patch for that
<Keybuk> mjg59: it's ICH7
<mjg59> Keybuk: It's BIOS-dependent, not chipset dependent
<Keybuk> could be then
<Keybuk> though it's weird the sensor has stopped working
<pwnguin> what defines idle for the g-p-m "dim display on idle" feature? cuz id really like to turn that higher =/
<thully> pwnguin: I think idle is your screensaver idle setting
<Keybuk> (I blame keithp :p)
<thully> Regarding the g-p-m idle situation, it has really seemed quite ugly in 2.20 - I have seen brightness randomly increase in many places...
<pwnguin> thully: it says 15 minutes
<pwnguin> feels closer to 15 seconds
<thully> pwnguin: I guess I was wrong, it's a gconf key
<thully> gconf-editor, and then open apps/gnome-power-manager/backlight
<pwnguin> hmm
<pwnguin> 30 seconds
<pwnguin> sounds about right. any documentation on what this dpms_method_foo does?
<Keybuk> almost certainly in the schema
<Keybuk> ("click on it")
<pwnguin> well, it's "default"
<pwnguin> =/
<thully> Regarding the dim on battery despite this being disabled, I just found the problem in the code...
<pwnguin> capitol work
#ubuntu-devel 2007-10-04
<pwnguin> (or is it capital?_
<thully> the battery brightness is subtracted from 100 and then used as the brightness - thus, setting battery brightness to 100 causes brightness to be set to 0
<thully> Offending line in gpm-backlight.c: scale = (100 - value) / 100.0f;
<thully> should be scale = value / 100.0f;
<pwnguin> you sure?
<Keybuk> thully: I've just worked out why nobody's replied to your bug
<Keybuk> you Confirmed it yourself
<pwnguin> heh
<Keybuk> we used Confirmed to mean that a developer's looked at it
<Keybuk> so everyone would've just skipped past it assuming someone else was looking at it
<thully> I didn't see that - Launchpad is so very confusing to me (I'm used to bugzilla)
<pwnguin> thully: g-p-m's frontend says "dim display brightness by"
<pwnguin> I'd agree that it's confusing
<thully> OK - so then battery brightness should be set to 0 to not dim
<pwnguin> yes
<thully> Kybuk:  I was under the impression that "confirmed" was simply to indicate that there is enough info to pinpoint the issue to something...
<pwnguin> not exactly intuitive if you're expecting symmetrical interface
<pwnguin> thully: even if you feel there was enough evidence, you shouldn't confirm it yourself. confirmation bias and all that
<Keybuk> thully: generally speaking, the reporter should always leave their own bugs at New
<thully> the gconf key has a bad description in that case: "The brightness of the display when on battery power. Possible values are between 0 and 100"
<pwnguin> i think the basic problem is that the dim on battery will cut by a percentage
<pwnguin> and dim on idle will simply set a new value irrespective
<thully> Keybuk: sorry about that, I tried to figure out what "confirmed" meant, but I obviously got the wrong definition.  I figured that it was just to say "there is enough evidence to confirm a problem here" and that devs would basically ignore it until it reached this state.
<thully> Obviously I was off by a mile.
<pwnguin> Keybuk: there's some gconf keys in apps/gpm/ambient that might be interesting for you if you're looking at for software regressions.
<Keybuk> at this point in the release cycle, we're looking for "my laptop explodes" regressions
<pwnguin> its your laptop with the sensor, i figured you might be interested anyways
<thully> Yes - I just hope that this g-p-m is not shipped with these kind of bugs.  Brightness seems to do all kinds of funky things in this release of g-p-m...
<Keybuk> these bugs aren't release critical though
<Keybuk> pwnguin: tbh, I suspect that it's the -intel driver that's causing the sensor to not work
<thully> Gutsy seems good in my experience, except for 1) NetworkManager keeps crashing (but it's really a madwifi issue) 2) intel X driver randomly crashes on restart 3) gnome-power-manager is FUBAR
<Keybuk> thully: I reject the last statement, g-p-m appears to be working quite normally most of the time
<thully> Keybuk: on a laptop, with dimming enabled?
<Fujitsu> thully: Where `crashes' means on a VT-switch you get massive screen corruption with flashing gray blocks?
<Keybuk> there's a lot more to g-p-m than just dimming
<thully> Fujitsu: yes, but it also happens on suspend-to-RAM
<thully> which changes the VT as part of its process
<thully> Also happens when X is restarted
<Fujitsu> thully: Yep, there was a bug on that, which I think was fixed. But I still get it after latest updates.
<sladen> thully: something is broken is the gpm ac/battery brightness at the moment
<sladen> thully: do have the bug numbers etc?  (I know there's at least one dup ... the one I filed!)
<thully> the Ubuntu ones or the upstream ones (I just filed them upstream)...
<thully> Also, what problem do you mean in particular?  I've identified about 5 with the idle dim logic in 2.20...
<sladen> thully: if you have links to either, we can start plugging them together...
<sladen> thully: the one I noticed is that the AC brightness is /always/ used since about 2 days ago
<sladen> thully: rather than even switching to the battery at all
<thully> I'm not seeing that here - though it may be awaiting me in the next dist-upgrade...
<mjg59> sladen: No, the change now is that the firmware won't change the brightness
<mjg59> g-p-m will
<sladen> mjg59: some logic is broken then.  the AC slider adjusts the brightness, even on battery
<mjg59> sladen: That sounds like gpm is missing the transition, then
<sladen> mjg59: however, the gpm applet shows the correct state
<mjg59> immediately, or after some period of time?
<thully> well, the issues I noticed with g-p-m are bugs 137598 and 63543 (reopened as a regression from feisty)
<ubotu> Launchpad bug 137598 in gnome-power-manager "Screen brightness resets to default (maximum) on idle with AC plugged in" [Medium,New]  https://launchpad.net/bugs/137598
<ubotu> Launchpad bug 63543 in gnome-power-manager "Error in automatic diminuition of brightness when idle" [Undecided,Confirmed]  https://launchpad.net/bugs/63543
<sladen> mjg59: seems to be a lag;  so it's waiting until the next proactive battery-status event comes in
<sladen> that 64xxx bug is too old to be this recent change
<mjg59> sladen: If the AC slider is changing brightness on battery, that's a failure of function rather than of logic
<mjg59> Could well also be a hal issue
<thully> I figure that it sounds like a hardware-specific issue - I don't see that here (though the dimming is messed up in many other ways...)
<sladen> acpi is seeing 'ac_adapter' events;  hal isn't reporting them
<mjg59> Is hal-addon-acpi running?
<sladen> nope, if there an FDI file somewhere that dictates whether that should be run?
<sladen> is there
<mjg59> No, it should be started at startup
<mjg59> hal startup, that is
<sladen> ah ha.  ist does get started, but the first acpi event kills hal-addon-acpi
<Keybuk> SIGCHLD as IPC :)
<mjg59> sladen: Sweet.
<mjg59> sladen: You win the prize!
<mjg59> The prize is debugging hal
<Keybuk> yikes, what's the prize for the loser?!
<sladen> asynchronous over abstracted soup
<mjg59> Keybuk: Fixing hal and g-p-m
* Keybuk steps back quickly
<sladen> wonder how trackerd is monitoring the AC status;  surprisingly it's actually the only thing that /is/ responding to the power status
<mjg59> sladen: Polling /proc/acpi/ac_adapter/*/status
<Keybuk> *blink* it doesn't use D-BUS?
<Keybuk> isn't that the eleventh commandment now?
<mjg59> It does in svn
<Keybuk> :)
<thully> speaking of g-p-m and HAL, I have another issue unrelated to the brightness saga - on resume in 2.20, I keep getting "suspend failed" and "Action forbidden" messages.
<thully> I tried the debug options, but I still don't see what is causing these messages to appear
<thully> The system suspends fine, so obviously something is being oversensitive
<sladen> thully: welcome to asynconous event soup;  if even one thing times out (eg. pulling back swap containing the end point in question) then the suspend will appear to "have failed", even if it worked just fine
<thully> The bug report would 137738
<thully> bug 137738
<ubotu> Launchpad bug 137738 in ubuntu "[gutsy]  suspend / hibernate works fine, but after resume, I get a "Failed to suspend" popup" [Undecided,New]  https://launchpad.net/bugs/137738
<sladen> and a million others
<thully> is there a way to figure out what the event is that is causing this?  g-p-m debug output wasn't that helpful to me...
<mjg59> Yes. Read the source and determine every way you can reach that point.
<Amaranth> race condition?
<thully> mjg59 - :)
<thully> Well, this didn't happen in feisty, once again...  Kind of frustrating that every time I attempt to use Linux as my main OS, I am frustrated to heck with random power management issues and feel like bashing my head into the wall...
<sladen> thully: regressions;  spawn of the evil doers
<Keybuk> thully: power management is hard
<Keybuk> and made harder by the hardware manufacturers
<sladen> however, we WILL win.  one day
<thully> Feisty had its own issues, though... In any case, I'm about to stick to keeping Ubuntu in a VM, get a *desktop* for Linux in the future, and avoid g-p-m hell forever
<thully> I guess I feel like that would be cheating, though :)
* lamont heads home
<thully> I actually went to OS X from Ubuntu 3 years ago because suspend issues were driving me nuts...  Now, I'm somewhat bored with OSX (I want to actually look at the code :)) and loading Ubuntu on my MacBook
<thully> The issue that was most annoying 3 years ago was ATI radeons commonly used in Thinkpads eating battery like crazy in suspend...
<thully> I think mjg59 was working on that way back in the day...
<Keybuk> you know you've been in this business too long when you start getting sentimental about bugs
<lamont> Keybuk: heh
<Keybuk> "I remember the day when Lamont wrote his name in the Release Critical bug list"
<thully> I will say that it has remarkably improved since then, though binary drivers are still a PITA (darned Atheros driver seems to be crashing NetworkManager all the time!) and g-p-m is a royal pain
<thully> I tried ath5k for fun (though it seems to be know more for license wars than anything), but it doesn't like my card...
<thully> I guess I'll log off for now - thanks for all the feedback about these bugs!  I may just end up cheating in my situation (by putting Ubuntu in VMware), but I'm happy some work is being done here.
<zul> heh kernel breakages in breezy was fun
<donspaulding> I'm having trouble googling for docs on how to use python-apt, anyone in here have any decent resources on the topic?
<lamont> Keybuk: dude.  it was just my initial.
* lamont continues to stall while his mirror bandwidth-enhancement device freshens
<Keybuk> donspaulding: it's a python module, of course there aren't docs
<donspaulding> Keybuk: heh, so if I'm looking to develop a server-only, in-house, "automatix-ish" package manager python-apt isn't the way to go?
<Keybuk> it probably is
<Keybuk> it's just like any python module that binds something else
<Keybuk> non-existant docs
<Keybuk> look up the docs for the ordinary apt lib, compare with dir()/help()
<donspaulding> oh, good, then I'm just up a creek (albeit, the right creek)
<donspaulding> will do
<Keybuk> also look at things like synaptic, update-manager, etc.
<Keybuk> any bits that are similar to what you want
<Fujitsu> Or look at Automatix
* Fujitsu ducks.
<zul>  /kick Fujitsu
<donspaulding> Automatix is really the functionality I'm looking for, but I want it server-side and I want to extend it to include some new ways of installing things
<donspaulding> s/server-side/no X
<sladen> 0Automatix is *never* what you're looking for
<kylem> sladen, what if you're looking for the wrong answer?
* Fujitsu wonders if there's an Automatix Server Edition with Advanced `killall -9 dpkg' Technologies.
<zul> donspaulding: when I was doing that at work I crated a metapackage much more easier
* RAOF still can't believe they thought that was a good idea.
<StevenK> Yup. Because killing dpkg won't create any problems.
<Fujitsu> RAOF: But, but, but it sometimes doesn't quit itself, remember!
<RAOF> What could possibly go wrong :/
<donspaulding> you guys are ruthless
<donspaulding> zul: hmm, I'll have to look at the metapackage thing, I assume deb's can run arbitrary commands in them?  Like I could create my own repo with metapackages that are dependent on ubuntu packages, then run commands to configure them after install?
<Keybuk> yes
* Keybuk does the same thing
<donspaulding> Or would I have to create my own full debs?
<donspaulding> interesting... off to google again
* StevenK waits for Keybuk to start talking about "Autokeybukix"
* StevenK ducks
<Keybuk> heh, just keybuk-meta
<Keybuk> http://www.netsplit.com/bzr/keybuk-meta/
<Keybuk> cf. the postinst for one of them
<StevenK> Way cool, now I can make fun of what you install by default. :-P
<Keybuk> :)
<StevenK> Keybuk: *Why* is figlet in keybuk-base? :-)
<Keybuk> because it's mandatory
<donspaulding> holy crap, what a great idea!
* donspaulding realizes he's the last one to the party
<Keybuk> donspaulding: it makes installing computers easy
<Keybuk> dpkg --unpack *.deb
<Keybuk> apt-get install -f
<lifeless> whateverhappened to debtakeover?
<StevenK> There's something I not heard of for a while.
<StevenK> I've, even
<Keybuk> StevenK: just figlet? nothing else to make fun of? :p
<StevenK> Keybuk: Sadly, yes.
<Keybuk> yes there is, no there isn't?
<StevenK> Heh, sorry. There's nothing else in there that looks crazy enough to make fun of.
<Keybuk> lol
<StevenK> Actually, yes there is.
<StevenK> Hah, autobork by default on desktop development systems!
<Keybuk> ?
<ajmitch> sure, why not?
<StevenK> Actually, it seems to be almost every version of auto* we ship.
<ajmitch> some upstreams are a bit behind the times
<Keybuk> always reautoconf with the version upstream used
<StevenK> Except if you're CDBS. Twitch.
<CarlFK> as long as ya'll talking bout auto and install, is "d-i     partman-auto/disk       string /dev/discs/disc0/disc"  doesn't seem to work for gutsy preseed.  anyone know what it changed to?
<Keybuk> CarlFK: well, the disc spec isn't valid
<Keybuk> but that might be ok, d-i is verrrry strange
<CarlFK> the installer stops and asks me to pick a disk
<CarlFK> I think I saw that  partman-auto/disk changed, but can't remember where I saw it.  something like partman-auto/disk-select
<Keybuk> the person you need is in bed
<CarlFK> yup.
<ion_> keybuk: Ooh, what a great idea.
<Keybuk> ion_: I can't claim credit for it
<Keybuk> though I also can't remember who I copied it off
<Keybuk> mdz I think
<lamont> slangasek: if you could be so kind as to put bug 148804 to bed tonight, that'd be wonderful
<ubotu> Launchpad bug 148804 in mlton "Please sync mlton (universe) from Debian unstable (main)" [Undecided,Confirmed]  https://launchpad.net/bugs/148804
<lamont> slangasek: (or whoever) is icedtea-java7 going to be accepted?
<lamont> if it is, please be so kind as to toss it in universe for the moment, for my bootstrapping happiness
<lamont> if it's supposed to go in main, I'd vote to move it there after it's bootstrapped.
<lamont> likewise, if it's not going in gutsy, that's fine with me too.
<StevenK> lamont: I'm quite curious how you actually bootstrap something like that depends on itself
<lamont> StevenK: with a sledge hammer
<lamont> you'll notice that there's another repository besides ftpmaster.internal mentioned in the mlton build logs
<StevenK> For the code, or upstream? :-P
<lamont> sadly, for the code.
<RAOF> What was the actual fix for "LVM-on-crypt doesn't boot" again?
<Fujitsu> RAOF: Hit cryptsetup's initramfs hook hard with the sledgehammer lamont currently has, until it works with UUIDs.
<lamont> it's understandable why they build-dep themselves with compilers... if you're crazy enough to write a new language, you probably are lost enough in love with it to want to _write_ the compiler in that language
<RAOF> Fujitsu: The bug suggests that it *should* work with uuids, now.
<Fujitsu> RAOF: It does, yes.
<StevenK> lamont: Heh
<Fujitsu> Mine boots as of yesterday's crypsetup upload.
<Fujitsu> *cryptsetup
<lamont> StevenK: the archive on sanae has a version of the binaries built by "lamont the human autobuilder" according to a set of pedantic lets-make-this-work-right rules
<RAOF> Fujitsu: Mine still doesn't, and I'm recalling a conversation along the lines of "we won't fix it for people who've already done it, they should know how anyway"
<StevenK> lamont: My question was more along the lines of how do you make the package build at all if the Build-Depends can't be satisified.
<lamont> StevenK: that's like right now, hppa is building gutsy using gutsy-stage0 to satisfy build-depends, etc.
<lamont> oh. the actual real original bootstrapping...
<StevenK> Yes.
<lamont> generally, you cross-compile
<StevenK> Ew.
<Amaranth> vala has this problem too
<Amaranth> it's annoying
<lamont> so you abuse the source to build you an i386 binary that produces powerpc output.  Then you use that to build the original debs
<StevenK> But you only use the cross-compiled code to truly ruly build the version for the archive.
<Amaranth> if you use the released version it comes pretranslated to C but if you follow svn you have to hop  along to certain key commits so you have a compiler that can compile itself
<lamont> then you install those and build the source natively on ppc
<StevenK> lamont: Yup
<Fujitsu> RAOF: If you've been booting manually, make sure the name of the currently opened crypto device and that in crypttab  match, then rerun update-initramfs -u.
<lamont> likewise, if you're lucky, then there's something sane to build from
<lamont> for example, flex includes 'lex.l' in its source... and yes, that's a flex file.
<StevenK> Yay!
<lamont> it also includes lex.c though, so you don't need to build-depend flex
<StevenK> I always found it amusing for packaging systems - like rpm.rpm or dpkg.deb
<lamont> heh
<RAOF> Fujitsu: So, the currently opened crypto device will be... /dev/mapper/sda5-crypt, yes?  And the crypttab line should be "sda5-crypt /dev/sda5 none luks"?
<StevenK> Hrm. Must ask Keybuk what his quit message is.
<Amaranth> I had the answer once...
<Amaranth> babelfish says something about absurdity
<Fujitsu> RAOF: Something like that, yeah (sorry about the lag time, a new lyx upstream tarball ate my upstream)
<StevenK> Why do I have this feeling it's "This is laughter for chickens" or something like that, from Serenity
<Amaranth> firefly?
<StevenK> Serenity is the movie following on from Firefly
<Amaranth> I know :P
<StevenK> I couldn't stand the series, my wife loved it.
<RAOF> Yay firefly.
<lamont> StevenK: how unfortunate.
<RAOF> StevenK: Really?  Strange person! :P
<lamont> "this food is problematic"
<StevenK> RAOF: It just didn't ... click. I was dragged along to see Serenity twice, though.
<lamont> saw Serenity, tracked down the DVD set
<lamont> "Take me sir.  Take me hard."
<StevenK> I don't remember that bit
<ajmitch> ah, "River Tam kills everyone"
<lamont> end of the episode where Mal and Wash are "guests" of the episodes villan
<StevenK> RAOF: Admitedly, the second time was because Joss Whedon was fielding questions after the movie.
<lamont> StevenK: it's in the series, not the move
<lamont> movie, even
<StevenK> lamont: Ahhh
<StevenK> RAOF: So, if you have the .au DVD release, my wife and I are in the Q&A session on the bonus disc
<lamont> "go back to the part where Jayne gets his butt kicked by a 90 pound girl.  Because I don't see that getting old"
<lamont> StevenK: there - that's from the move
<lamont> movie. sigh
<RAOF> StevenK: Wicked.
<lamont> StevenK: rock
<StevenK> lamont: Now that bit I remember.
<lamont> hrm... s/don't/just don't/
<StevenK> RAOF: Oh, and the Firefly box set we have is now autografed by Joss
* RAOF reiterates his previous "wicked"
* lamont mutters something about his wife being on Extreme Makeover, Home edition in november
<StevenK> And I can't spell, sigh
<zul> lamont: wha?
<StevenK> lamont: Remind me what Extreme Makeover is? It's ringing a vague bell.
* StevenK adds "Brutally murder auto* upstream and make it look like an accident" to his todo list.
<zul> StevenK: its where people with like 15 foster kids get their home torn down and get rebuilt everybody happy blah blah
* StevenK wipes the sarcasm off that
<lamont> http://abc.go.com/primetime/xtremehome/index
<lamont> zul: sounds about right
<lamont> mitzi gets to be on-air talent with Rib and Paige - I'd expect it's < 5 minutes of actual airtime.
<lamont> after all, we only spent 3 hours filming it
<StevenK> Hah
<CarlFK> in the next batman movie, look for me playing a hospital patient with oriele's CSS  book. that took 16 hours, and I'll be happy if I get 3 min
<CarlFK> extra happy if CSS shows up at all
<lamont> yeah - my teenager found it very disillusioning when we went up for the reveal
<StevenK> CarlFK: Heh
<slangasek> lamont: I'm not really in the loop on icedtea
<lamont> yeah - I poked doko about it
<lamont> he sent me email with the info I need for bootstrapping it... can't really bootstrap it until the source is actually _IN_ the archive though
<StevenK> lamont: It isn't in NEW?
<lamont> yeah
<StevenK> lamont: You can grab it manually from the NEW queue using LP
<lamont> right... now have launchpad build it
<lamont> that part requires that it be in the archive, not NEW
<StevenK> Ah
* StevenK idly wonders if slangasek can be sweet-talked
<lamont> it also requires a canonical sysadmin, which means that it'll be tomorrow morning -0600 before I even think about playing with it, by which time someone will have done something with it in NEW, I expect
<ScottK> StevenK: Just upload whatever it and when someone complains say, "Oh, sorry,  Thought that was in Universe."
<lamont> it would just save me considerable pain if it happened to take a trip through universe on its way to its final destination
<slangasek> StevenK: I'm not going to be sweet-talked into accepting something on the basis that someone else somewhere may have made a decision to accept it. :)
<StevenK> slangasek: Awwww. :-)
<lamont> StevenK: you have to get him _really_ drunk first
<StevenK> That's one way to make Debian release on time.
<slangasek> which is hard, because I'm a cautious drinker
<lamont> drunken archive admins make it release slower...
<lamont> slangasek: that does make it more challenging, true.
<kylem> will accept things for single malt.
<slangasek> lamont: 20-byte .diff.gz files make me cross
<lamont> then again, there is always Mao
<lamont> slangasek: you're kidding...
<slangasek> -rw-r--r-- 1 lp_archive lp_archive      20 Oct  4 02:32 mlton_20070826-1.diff.gz
<StevenK> Way cool
<slangasek> it's like that in the current version too, so
<StevenK> Isn't that just a gzip header?
<slangasek> yes
<lamont> so it's packaged to allow the debian mainainer to modify things down the road without uploading an entire tar.gz
<lamont> most likely, the debian/ directory is in upstream
<StevenK> It's ... native without being native ... Ouch
<lamont> depending on the size of orig.tar.gz, that can be a wonderful thing
<slangasek> yes, the non-wonderful is having debian/ in the orig.tar.gz :)
<StevenK> Heh
<StevenK> How big is this orig tarball?
<lamont> well, if that's how upstream releases .tar.gz......
<StevenK> I'm curious if the maintainer is a big wuss
<slangasek> 5.3MB <shrug>
<lamont> small
<lamont> 5MB
<lamont> it's not X
<StevenK> Argh, take it like a man! I've uploaded three rc's of gimp, with orig and the tarball is bloody 26Mb
<wasabi> i dont suppose at some point in the future somebody is going to store uid numbers in /etc/group.
<wasabi> sillyness
<slangasek> lamont: mlton synced, now what's the convention for documenting this in the bug seeing how that's not in the howto? :P
<lamont> close the bug with a comment saying that you synced it, I guess
<StevenK> slangasek: You can either reply with 'Synced' and close it.
<StevenK> slangasek: Or, paste part of the output of sync-source.py and close it
<StevenK> slangasek: I can dig up an example fairly easily
<lamont> woot.  rmadison shows bind9_1:9.4.1-P1-2
<lamont> wink. wink.  nudge. nudge.
<StevenK> I wonder if that's code for "Sync it or I won't love you any more."
<slangasek> StevenK: well, I've just pasted some output from sync-source.py, good enough :)
<lamont> StevenK: you should watch more monty python
<slangasek> photographs, eh, he asks him knowingly
<lamont> slangasek: there are no photographs.
<StevenK> lamont: Probably. I've only seen Holy Grail
<StevenK> "He's not the Lord, he's a very naughty boy!"
<lamont> OTOH, if slangasek's wife recognized the skit, she'd be likely to beat me to a pulp.
<slangasek> erm
<lamont> so lets go with that being code for "please sync.  kthxbye.  love you anyway."
<lamont> slangasek:
<lamont> thansk
<StevenK> libtinymail. You. Are. Going. To. Build. Correctly.
<lamont> StevenK: tiny problem?? :-)
<StevenK> lamont: Yes. It's called -fPIC and automake
<lamont> oh. that thing
* StevenK needs more downstream bandwidth, or ports.u.c. needs to be faster.
<lamont> what are you doing that requires ports?
<StevenK> Sync'ing lpia
<lamont> ah
<ajmitch> solved by moving out of .au?
<StevenK> I can only find one .au mirror that carries lpia, and it's *hopelessly* out of date. :-/
<lamont> many things can be solved that way
<StevenK> ajmitch: Like .nz is any better
<ajmitch> we have advanced stuff like local loop unbundling that'll finally happen :)
<StevenK> ajmitch: I'm not certain if we have that yet.
<StevenK> I'm looking at ADSL2+, I just can't afford the initial outlay
<ajmitch> ADSL2+ is still a planned feature for us
<RAOF> StevenK: What initial outlay?  Doesn't someone want to sign you up for a 18 month contract for free?
<StevenK> RAOF: I'm with Exetel, and I want to stay with them.
<StevenK> RAOF: Moving from ADSL1 to ADSL2+ requires having to move the ADSL terminating on Telstra's equipment, and moving it to Powertel's
<ajmitch> you're currently limited to 1.5Mbps?
<RAOF> StevenK: Right.  Gah, stupid Telstra.
<StevenK> I could switch to 6Mb down, I just haven't
* ajmitch has approx 5.5Mbps down
* Fujitsu laughs, having 10Mbps.
<ajmitch> which is useful when I sync from a fast NZ mirror
<RAOF> StevenK: What!  Telstra will allow you to use more than 1.5 Mbps down?
<ajmitch> nz2.a.u.c updates every 4 hours, which is quite good
<Fujitsu> RAOF: We have 8Mbps on ADLS1 at work.
<Fujitsu> pacific's mirror seems to update very regularly now.
* StevenK hugs the 2Mbps SHDSL he still has root access too
<StevenK> Funny. I left there last week, you'd think they'd fix it
<RAOF> Fujitsu: That must have changed since I was on a Telstra rimm.  They used to only allow 1.5 down.
<Fujitsu> RAOF: That changed recently, IIRC.
<StevenK> RAOF: Right, it changed very quietly recently
<RAOF> Yay Telstra being not quite so totally stupid!
<StevenK> Maximum speeds: Up to 8192kbps Down/384 kbps Up **
<Fujitsu> RAOF: Not possible!
<StevenK> To be honest, 384 kbps up isn't enough
<Fujitsu> I have 256kbps, and dputting anything significant kills the rest of my connections... I must work out how to throttle it.
* RAOF strokes his adsl2+.  It's nearly possible to use raw X over ssh!
<StevenK> Fujitsu: Your firewall is Linux?
<Fujitsu> StevenK: It is.
<StevenK> Fujitsu: /sbin/tc qdisc replace dev ppp0 root tbf rate 22kbps latency 50ms burst
<StevenK> 1540
<StevenK> Sorry, that should be one line
<StevenK> Fujitsu: tc *sucks* *HARD* to use, but once it works, it's great
<StevenK> -rw-r--r-- 1 steven users 2.1M 2007-10-04 12:18 libtinymail_0.0.2-0ubuntu1_amd64.deb
<StevenK> HAH!
<StevenK> Take *that* automake
* RAOF man tc's.  Cool, I never knew that!
<Fujitsu> StevenK: I'll try that, thanks!
<StevenK> RAOF: If you can figure how to remove a pfifo_fast, I'll love you long time
<ajmitch> RAOF: I'm surprised that you're bothering with its manpage
<StevenK> Indeed.
<StevenK> tc's documentation is poor at best, the source code at worst
<donspaulding> so to make my metapackage depend on apache2, what would I put on the Depends line of debian/control ?  Is there an apache virtual package?
<RAOF> ajmitch: Well, it tells me roughtly what it does, at least :)
<StevenK> donspaulding: Depends: apache2
<lamont> donspaulding: there is an apache2 metapackage that should fit the bill
<lamont> it, in turn, Depends: apache2-mpm-worker (>= 2.2.3-3.2build1) | apache2-mpm-prefork (>= 2.2.3-3.2build1) | apache2-mpm-event (>= 2.2.3-3.2build1)
<lamont> or so
<StevenK> ajmitch: Indeed, Exetel charge for moving from ADSL1 to ADSL2+. $88 AUD, which is about half of what I saw last time I checked
<donspaulding> StevenK: I'm also looking for a more general answer, so I'm not constantly asking "what should my Depends line look like?"   I see that the Source package depends on debhelper (>=5).  So does that translate to apache (>=2)?
<donspaulding> or anyone really
<StevenK> donspaulding: Nope, the package for Apache 2 is apache2. In the general case, find the packages you want to install and list them all on the Depends line.
<donspaulding> excellent, thanks
<StevenK> Hrm. I shall keep that in mind. It looks to be $143 to switch, as opposed to the $300-odd I saw when I looked last time
<donspaulding> what does ${shlibs:Depends}  do??
<lamont> donspaulding: the >=5 is specifying that versions of debhelper before version 5 are insufficient to the package's needs
<lamont> man dh_shlibdeps
<lamont> for ${shlibs:Depends}
<StevenK> donspaulding: For a metapackage, you don't need it.
<lamont> actually, reading through the debhelper docs should be a good starting point
<donspaulding> lamont: ok
<LaserJock> I wonder if it'd be worth it to pull the debhelper man pages, etc. into an HTML page for people to read
* lamont really finally makes it out the door to head home
<StevenK> LaserJock: man2html does exist, and has for a while
<LaserJock> StevenK: yes, I'm wondering if it'd be worth using it and sticking it somewhere
<StevenK> http://xgen.iit.edu/cgi-bin/man/man2html?7+debhelper
<StevenK> Third hit on Google
<LaserJock> oh, that is good
<LaserJock> I didn't think it'd have links to all the dh_*
<fedaraoti> what does ubuntu use to redhats src.rpm
<fedaraoti> src.deb?
<donspaulding> dh_make created a few extra files for me, I removed the .ex and READMEs, can I do the same with compat, copyright, dirs, docs, and files?
<RAOF> fedaraoti: .dsc, .orig.tar.gz, and .diff.gz
<donspaulding> sorry, I also meant to mention this was for a metapackage
<fedaraoti> RAOF: will any of them register as a installed package with the other installed debs?
<RAOF> fedaraoti: No, because they're not packages.
<fedaraoti> ok
<fen_> can anyone tell my why when i change ~/.gconf/desktop/background/%gconf.xml and logout/back in it does utterly nothing?
<fedaraoti> is there any way like with apt
<RAOF> We don't have "package containing the source of the package you can build from this source" package :)
<RAOF> fedaraoti: apt-get source packagename :)
<fedaraoti> like rpm -i bla.src.rpm then rpmbuild --rebuild bla.src.rpm
<fedaraoti> will list it with the other installed rpm
<fedaraoti> rpm's
<fedaraoti> RAOF: cool
<RAOF> fedaraoti: "apt-get source -b packagename" will get the source & build it.
<ajmitch> note that apt-get source will download & unpack into your current working directory
<fedaraoti> RAOF:  and could that be a .dsc, .orig.tar.gz, or .diff.gz
<fedaraoti> ?
<fedaraoti> see
<fedaraoti> my main queston was do the nvidia module come in a source package
<fedaraoti> and would they compile against the kernel?
<fedaraoti> say
<fedaraoti> apt-get source -b nvidia
<dobey> fen_: because the file gets overwritten by what's in memory from the daemon?
<dobey> because you aren't supposed to edit those files by hand
* lamont waves
<holycow> oh i was wondering what its quiet in here
<holycow> i'm in -devel
<holycow> hehe :)
<mekius> Ok, custom gutsy live cd, custom sources.list in /etc/apt/, for the past two months it has been copied verbatim during install, no issues, but just updated today and now it is not copied, but seems to be replaced by a default sources.list
<mekius> is this expected behavior?
<mekius> and if so, what's the best way to override this?
<donspaulding> the debian new maintainers guide mentions the debian/conffiles file that can specify files not to overwrite if the user chooses not to, is that what files is for now?  dh_make didn't create conffiles
<dobey> donspaulding: i don't think dh_make is supposed to generate it. i think it's a list of files that you specify by creating the file
* lamont sleeps
<RAOF> Fujitsu: Thanks, that crypttab mangling did the trick.
<donspaulding> dobey: thanks, I've realized I don't need it.
<sladen> mjg59: what the heck did you do to override the hardware brightness control on thinkpads.  It is actually /really/ annoying;  backlight doesn't work on the console etc
<sladen> mjg59: it's perhaps a good idea, but I think g-p-m needs to selectively take control (such as when it's actually thj
<sladen> mjg59: the holder of the console)
<sladen> mjg59: (...and/or when it's actually *running* :)
<fabbione> morning
<Fujitsu> Hi fabbione.
<Whoopie> zul: morning, regarding bug 146987, tpb is started with /etc/X11/Xsession.d/90tpb. Don't know if it's now started twice.
<ubotu> Launchpad bug 146987 in tpb "tpb init script doesn't launch tpb" [Undecided,Fix released]  https://launchpad.net/bugs/146987
<dholbach> good morning
<sladen> Whoopie: tpb isn't really compatible with the provided ubuntu hotkey infrastructure
<desrt> you mean ubuntu will give me my hot serial keys directly instead of getting them from ThePirateBay?
<desrt> score.
<StevenK> Morning pitti
<pitti> Good morning
<pitti> hey StevenK
<slangasek> dholbach: hrrm, sorry about the maintainer field, I didn't even look as it was an ubuntu2 build
<dholbach> slangasek: don't worry - that's a mistake that's too easy to make
<mdke> dholbach, pitti: ping
<pitti> hi mdke
<mdke> hiya, morning
<stgraber> morning
<mdke> pitti: you remember that last cycle you added some stuff to ubuntu-docs to filter out translations less than a certain percentage of completion?
<mdke> pitti: i uploaded some translations to the repository yesterday, and tried a build, but I guess a massive barrage of error messages which I don't understand, I wondered if you or Daniel would be able to take a look
<mdke> I think they may be due to the stuff that was added for filtering
<mdke> s/guess/get
<dholbach> mdke: I can take a look after the dogwalk, if pitti hasn't tended to it yet
<mdke> dholbach: thanks a lot. the errors look like this - http://paste.ubuntu-nl.org/39514/ - over and over again
<dholbach> ugh
<dholbach> no idea what that might be :-/
<mdke> heh
<mdke> it's not stopping the build but it looks bad
<dholbach> you might want to bump the version to 7.10.1 and fix the tab problem in the changelog entry
<mdke> oh yeah, I have done that in my working copy
<mdke> I'm not planning an upload yet, i just wanted to sort this out for now
<pitti> dholbach: thanks; please let me know when you start, and if you have questions
<dholbach> pitti: it seems some doc-related thing; at least I haven't seen anything like it before
<mdke> given the quantity of the errors and the fact we haven't had it before, i think it must be related to the translations (i.e. to the msgfmt and related commands in debian/rules)
<\sh> moins
<pitti> doko: re your restricted-manager upload> what's the purpose of this? if "import gtk" does not work after a dist-upgrade, pre-depends vs. depends: will not change anything
<doko> pitti: define "after dist-upgrade", I have never seen this. the purpose was to have it available as soon as possible
<pitti> doko: right, but a lot of my bugs happened after a dist-upgrade, not in between
<\sh> I|m having problems with the gnome.settings-daemon as it looks like :*
<doko> pitti: after restarting restricted-manager, or with the running process?
<pitti> doko: there is usually no running process
<dholbach> pitti: I'm afraid, I don't understand what happens there
<pitti> I never got really great feedback about those crashes either, so I'm unsure about the exact circumstances
<doko> pitti: well, then please revert it then with the next upload. we could try tro reenable this in early hardy
<pitti> doko: I don't have a good idea how to handle that either; I know that mangling all the symlinks just in the postinst is tricky
<pitti> doko: unless, instead of removing the symlinks, the preinst would just write out a list of them on 'upgrade', and the postinst does the symlink setup in one atomic step?
<pitti> doko: it's certainly possible that all of these crashes happened due to incomplete upgrades
<pitti> i. e. one package failed to configure, and thus a lot of other packages weren't configured
<donspaulding> I listed several packages in my control file Depends: line, debuild'ed my package, then tried to debi it, but it says it depends on <one of my depends packages>, but it isn't going to be installed
<donspaulding> What am I missing?  I thought that was what the point of Depends was?
* donspaulding awaits geriatric diaper comment
<mrgenixus> hi y'all -- trying to install ubuntu onto second disk from within linux distro... is there a way to get a copy of either the text or graphical installer, standalone so that I can install from within linux?
<mrgenixus> (e.g. I don't want to burn a cd -- I just want to install ubuntu on an external drive)
<doko> pitti: well, that complicates things more, and doesn't seem to be sufficient for newly added files in the update, keeping the .pyc files during an updated could help, but that would require knowledge about the old .pyc file after the new package is installed
<donspaulding> mrgenixus: http://www.google.com/search?hl=en&q=install+ubuntu+without+cd&btnG=Search
<pitti> doko: but we don't need to keep the .pyc files, right? only the symlinks
<pitti> doko: without the .pyc, startup will be slower, but *shrug*
<pitti> doko: maybe python packages should be changed to have a common PYTHONPATH for version independent modules, instead of having symlinks to the version specific dirs? could that work?
<pitti> doko: i. e. we could add /usr/share/python-support/ to PYTHONPATH and find a solution for the per-package subdirectories
<mrgenixus> donspaulding: all of those results and most modifications of the search give me what I want, except I'm not running windows
<mrgenixus> I tried the google search first
<mrgenixus> your terms were different, so I tried that one -- but I get the same results I already didn't want/need
<mdke> pitti: can I leave it with you then? If you want I can file a bug report. The latest source is "svn export https://docteam.ubuntu.com/repos/branches/gutsy". It might be worth checking that nothing important has changed from what you did to the feisty package
<doko> pitti: keeping the .pyc files has the advantage that things will work without the .py files. keeping the symlinks requires knowledge of both the old and new files after upgrade, which we currently do not have (and files may move between different packages too)
<doko> messing around with PYTHONPATH is not a solution, you'll change the order of imports
<donspaulding> well, there goes my claim to most-helpful-irc-acquaitance-of-the-night
<donspaulding> :-)
<pitti> doko: hm, ok
<pitti> mdke: dholbach and I will figure it out
<mdke> pitti: thanks very much indeed
<mrgenixus> donspaulding: I was hping someone in here had done it
<mdke> pitti / dholbach: i'll be on email today if I can help at all
<doko> pitti: will apport be turned off in final gutsy?  for other applications which might run during an upgrade, the pre-depends on needed python modules could make things more robust
<pitti> doko: yes, we currently plan to turn it off for the final release
<pitti> doko: and on again in the live system, just like in feisty
<doko> pitti: ok, you don't upgrade that much in the live system =)
<pitti> right
<pitti> doko: on the live system it's still good to have apport, mainly for ubiquity
<donspaulding> mrgenixus: I've done it in the past, but only to switch between other linux distros, never to dual-boot with ubuntu
<donspaulding> the problem is that the livecd is just that, a livecd which you are meant to install from.  Essentially it's just a matter of getting grub to boot an installation kernel, which could probably be found on the alternate install CD
<dholbach> pitti: thanks a lot
<seb128> does anybody has a external usb disk using vfat? bug #133567 would be nice to debug for gutsy
<ubotu> Launchpad bug 133567 in nautilus "[gutsy]  long delay in nautilus on first access to vfat drive" [Medium,New]  https://launchpad.net/bugs/133567
<mdz> lamont: here now
<Hobbsee> hi LaserJock
<LaserJock> hola Hobbsee
<Hobbsee> LaserJock: good replies on the bug thread, btw.
<LaserJock> Hobbsee: maybe :-)
<LaserJock> I dislike email because it takes me forever and I always feel like it's not quite complete
<Hobbsee> LaserJock: still better than mine would be, in current form - but that's probably as i've actually been trying to use launchpad in places.
<Whoopie> sladen: yes, I know. but zul changed the package and I just wanted to let him know that tpb is started with the /etc/X11/... script
<Fujitsu> I don't particularly like the one-size-*will*-fit-all approach.
<pitti> mdke: where is that source package?
<LaserJock> Fujitsu: I don't think it's quite that though
<LaserJock> if LP guys are designing in one direction and we're using it in another then obviously problems will happen
<LaserJock> have a consistent standard vocabulary would at least help
<LaserJock> let alone "this is how we think the best way to use LP is, based on the way we've written it"
<Hobbsee> LaserJock: of course, the more we deviate statuses from other bug trackers, the more problems we get
<LaserJock> well, I was thinking more internally, but yeah ;-)
<Hobbsee> although i've got no idea if the LP guys are taking that into account
<Hobbsee> (disclaimer:  was a random thought, rather than based on what you said)
<LaserJock> I think they are as they have to figure out how to sync the statuses
<LaserJock> so it's more work for them if they go and make a bunch of statuses that they then have to figure out how to map from external bug trackers
<Hobbsee> true
<LaserJock> I wonder what would happen if they had a different set of statuses for distributions and projects
<Hobbsee> mass confusion, probably.
<ogra> seb128, cant confirm that here
<seb128> ogra: what?
<ogra> seb128, bug 133567
<ubotu> Launchpad bug 133567 in nautilus "[gutsy]  long delay in nautilus on first access to vfat drive" [Medium,New]  https://launchpad.net/bugs/133567
<seb128> ogra: ah, the usb slowness?
<seb128> ogra: ok, thanks for trying
<ogra> works just fine, tested on two machines
<ogra> one fresh and one upgraded ...
<seb128> ogra: how big is your disk? and it's using vfat?
<ogra> seb128, there are many USB keys out in the wild without proper partitioning, windows allows to format the device directly, we had many probs with that in ltsp, that might be related
<ogra> its using vfat (stock 2G disk, bought two weeks ago and untouched until now)
<seb128> ogra: ah, 2G is too small
<ogra> oh, ok
<seb128> ogra: read the recent comment, the guy says it's not noticable on a 2G drive
<seb128> but really noticable on a 300 or 500Go disk
<ogra> hmm
<cjwatson> lamont: icedtea will go via universe, but needs a licence check first, which is on my list.
<cjwatson> lamont: please do not attempt to persuade people to accept it before that!
<pitti> seb128, ogra: oh, I get that bug, too
<pitti> seb128: when I attach my 250 GB USB disk, nautilus hangs for a long time
<seb128> pitti: ah? what kind of drive do you use? Do you think you could have a look to the issue?
<pitti> seb128: happens to both of my USB HDDs (one has one vfat and one ext3 partition), and the delay scales with the size
<seb128> pitti: could you try to figure if gnomevfs-ls does the same or if that's specific to nautilus and what it's doing while it's hanging?
<pitti> seb128: and it does not just affect the first drive; when I attach the second one, I get another delay
<pitti> and entire nautilus (browsers and desktop) are hanging
<pitti> seb128: strace does not do anything while it is hanging
<seb128> right, when nautilus hangs all the window are affected, that's a known issue
<pitti> seb128: where do I get gnomevfs-ls? (and the bug reporter already noted that this works)
<seb128> pitti: libgnomevfs2-bin
<seb128> pitti: command-not-found should tell you that ;)
<pitti> seb128: gnomevfs-ls works immediately
<seb128> ok, that's what the comments on the bug were also saying
<seb128> so it's due to nautilus
<seb128> but I've no idea of what it's doing
<pitti> ok, so I close the kernel task, and I'll do some gdb'ing
<pitti> seb128: I'll first help dholbach with ubuntu-docs, then I'll look into this
<seb128> pitti: thanks
<pitti> this seems pretty important for the release to me
* Hobbsee actually does some uploads.  hooray!
<soren> Ok... ubiquity just crashed on my, and when I tell apport I'd like to report the problem, it shows me the info it claims to want to send. I click "Send", and nothing happens. Is the apport issue a known one?
<pitti> hm, no
<pitti> soren: do you get a progress bar for sending?
<seb128> pitti: yes, it is
<StevenK> Hobbsee: Heh
<pitti> soren: it first uploads the blob to Lauchpad, then it should open a firefox window
<soren> pitti: I think it might have uploaded the stuff, but ff never opens.
<soren> I can try opening firefox first and see if that helps. Hang on.
<pitti> soren: if you do /usr/share/apport/apport-gtk -c /var/crash/....crash, do you see any helpful output?
<Hobbsee> StevenK: has anyone yelled at pitti yet, btw?
<pitti> soren: shouldn't make a difference; in fact, it usually works *better* if ffox is not yet running; maybe you are experiencing it the other way round, though
<pitti> Hobbsee: hm?
<Hobbsee> pitti: cups-pdf was asking me for the root p/w when i was doing some upgrade testing in a chroot yesterday.
<pitti> Hobbsee: oh, it seems that's due to lpadmin
<Hobbsee> yeah
<pitti> Hobbsee: hm, did you have cupsys running?
<Hobbsee> pitti: dont think so - it was a chroot.
<pitti> if you install it as root, it shouldn't ask for a password
<soren> pitti: Hm... now it worked.
<pitti> Hobbsee: it should say 'connection refused' or something
<pitti> seb128: there is only ever one nautilus process which is responsible for both the desktop and all the windows, right?
<pitti> seb128: so if I start the one from my built tree, I can gdb this one
<Hobbsee> pitti: i dont think this was an install - it was an upgrade.
<seb128> pitti: yes
<pitti> seb128: so I just kick nautilus from my session, and then start it manually, I figure
<seb128> pitti: yes
<pitti> dholbach, mdke: ah, got it: /msgfmt: error while opening "ubuntu/windows/po/*.pot" for reading: No such file or directory
<pitti> dholbach, mdke: it tries to interpret that as statistics output
<soren> Someone was working on dm-crypted root and swap, right?
<pitti> soren: that works now?
<pitti> soren: i. e. it did after my cryptsetup initramfs script fixes
<soren> pitti: That was going to be my next question :)
<pitti> soren: today's daily should be good
<soren> pitti: It's only in the alternate installer?
<pitti> soren: yes
<soren> Alright.
<pitti> soren: in principle, the bits are there for desktop, too, but the UI bits are missing in ubiquity, I guess
<soren> pitti: Sure.
<seb128> carlos: is there a rosetta nautilus import waiting?
<carlos> seb128: yes
<pitti> dholbach, mdke: it just seems that the location of .pot files has been changed (from foo/po/foo.pot to foo/foo.pot); fixing
<soren> I know Ian said you could do the conversion on the fly, but that's a really scary thought to me :), so I'm doing a reinstall on my laptop.
<carlos> seb128: you can see it from https://translations.launchpad.net/ubuntu/gutsy/+source/nautilus/+imports
<dholbach> pitti: oh great
<seb128> carlos: do you know how long it's going to take?
<pitti> dholbach: ok, it built fine now; I'll send you a diff
<dholbach> pitti: if you send a debdiff to mdke, he can put it into svn again and I can roll the package and upload once he's happy with it
<dholbach> pitti: afaik he wanted to some other changes anyway
<carlos> seb128: well... it will still take a while, we have a huge delay :-( . We are preparing an announcement about that problem
<pitti> dholbach, mdke: http://people.ubuntu.com/~pitti/tmp/ubuntu-docs.fix-pot.patch
<seb128> carlos: ok :/
* dholbach hugs pitti
<pitti> dholbach: mailed him the patch
<dholbach> pitti: you ROCK
<pitti> np
<norsetto> anyone can give me a pointer about .la status? Should we or should we not include them in -dev packages....
<slangasek> "it depends"?
<norsetto> hehehe, thanks for the enligthment :-)
<seb128> norsetto: don't stop shipping one now or it'll require a rebuild of all the packages which have a .la mentioning it
<TheMuso> If a new bugfix release of gnome-orca were to be made upstream, what are the chances of getting it into gutsy?
<norsetto> seb128: its a new package
<seb128> don't ship it the, ;)
<seb128> TheMuso: that's a GNOME stable version? updates are ok
<norsetto> seb128: ok, any ref. I can use to convince upstream (beside the fact that .la are evil)
<Hobbsee> Thew
<Hobbsee> TheMuso: well, if you're happy with it...
<slangasek> norsetto: if your library has a .pc file, there is no reason to ship .la files except the binary compatibility seb128 mentions
<Hobbsee> TheMuso: you're one of the few people who will be using it, so... :)
<TheMuso> Hobbsee: It hasn't been made a release yet. Upstream asked me about getting it in.
<slangasek> norsetto: what do you need to convince upstream for?  if upstream uses libtool, libtool will still want to install the .la files; removing them from the package is a packaging decision
<norsetto> slangasek: just thinking prehemptily ;-)
<TheMuso> Ok thanks folks, I'll let them know.
* norsetto wished the debian policy would be amended on this already
* Hobbsee goes off to take over the world.
<norsetto> Hobbsee: hey, leave me nz!
<iwj> mdke: Yes, you can add the new translation straight away.  The complicated transition is to make the locale Translatable (as defined); once it's Translatable you can add (or indeed remove) the translation itself without further ado.
<iwj> The script provided by ubuntu-docs will provide the symlink iff the locale is Translatable but not translated.
<iwj> slangasek: I've replied to bug 145231 but I'll see if I can dig out some better information.
<ubotu> Launchpad bug 145231 in pidgin "cannot restart pidgin" [High,New]  https://launchpad.net/bugs/145231
<slangasek> iwj: cheers
<seb128> iwj: note that a new bug fix upstream version has been uploaded since and the bug might be fixed now
<pitti> seb128: meh, it is helpful that nautilus is in uninterruptible kernel sleep during that time, and thus you can't prace it
<pitti> ptrace, even
<seb128> :(
<iwj> seb128: Ah.
<pitti> seb128: hm, the multiload applet is hanging during that time as well; weird
<seb128> pitti: maybe gnome-vfs-daemon is hanging?
<tkamppeter> pitti, have you seen my mail about cups-pdf and cupsys? I have moved the PDF destination to ~/Desktop now and made the package installing even if CUPS crashes when cups-pdf's maintainer scripts restart it.
<pitti> tkamppeter: I saw it,  I'll get to it
<pitti> tkamppeter: however, that would require allowing cups-pdf to write into ~/Desktop
<pitti> well, it's not too bad, I figure
<pitti> I can forbid it to read files in Desktop/
<tkamppeter> pitti, for that I have already repackaged cupsys, modifying the apparmor profile
<seb128> don't hardcode ~/Desktop guys
<seb128> with xdg-user-dirs the directory can be translated now
<tkamppeter> pitti, these entries have only a "w", so this should mean that there is write-only access
<pitti> tkamppeter: why not just leave it as PDF?
<pitti> tkamppeter: as long as PDF printing requires this crackful 'go through root daemon and back', we should confine it as tightly as possible
<pitti> tkamppeter: also, I don't have a ~/Desktop at all (and many people don't)
<tkamppeter> pitti, this way users will see the files appearing. Many users do not know that they will get dropped in PDF
<pitti> tkamppeter: I use ~ as my desktop Dir (which is quite commonm)
<seb128> pitti: did you read what I just wrote?
<pitti> seb128: yes, that too
<pitti> and since Gnome has built-in PDF creation support, it only affects the non-Gnome apps
<tkamppeter> pitti, the default installation has a ~/Desktop dir and if the user simpy "rm -rf"s it not knowing fopr what it is good for cups-pdf recreates it.
<pitti> seb128: gnome-vfs-daemon is not hanging, it works fine
<seb128> pitti: hum, k
<pitti> [pid 19503]  <... futex resumed> )       = -1 ETIMEDOUT (Connection timed out)
<pitti> hmmm
<pitti> seb128: this was after a stavfs() call; that might be it, perhaps
<norsetto> pitti: I know it may not be the best time of the year, but, would you be available now to have a pupil?
<pitti> norsetto: what do you mean with 'pupil'?
<norsetto> pitti: you know, mentoring stuff: Me Mentor, you Pupil
<pitti> oh
<tkamppeter> There should be very few users modifying the Desktop's config to use another dir to display on the desktop.
<Mithrandir> tkamppeter: that's irrelevant, you should respect the user.
<pitti> norsetto: right, I'll have some more time at the start of Hardy, but if you have particular questions, or want a package to be reviewed, feel free to mail or IRC me
<pitti> tkamppeter: but for those who do we should not break that
<Mithrandir> tkamppeter: and by creating a ~/Desktop if that's not the user's desktop, you are not respecting the user.
<pitti> tkamppeter: I really think that at this stage of the release, we should just go with ~/PDF
<norsetto> pitti: thx for the offer :-) its not for me actually but I'll keep it in mind
<Mithrandir> pitti: just ~/, I'd say.
<pitti> Mithrandir: I'm nervous about giving cups-pdf any significant privileges in ~, TBH
<Mithrandir> pitti: then I don't think we should ship it by default.
<pitti> you could accidentally overwrite other PDF files you have, for example
<cjwatson> we've kind of already announced it
<Mithrandir> we're past beta and the security seems to be questionable, and the design not fully thought through?
<pitti> I read the code under the assumption that it would write into ~/PDF/, and designed the AA rules that way; I am fine with the current staus
<pitti> for moving it to ~, I'd need to re-review the code and rules
<pitti> it's not significantly worse, but it sounds like it could clash with other files from the user, etc.
<Mithrandir> heck, it shouldn't overwrite files in ~/PDF either without warning the user
<pitti> I just object to changing it to ~/Desktop at this stge
<pitti> Mithrandir: right, let me check
<Mithrandir> and the program should be safe to use without apparmor; having security depend on the program being constrained to not do anything wrong sounds.. wrong.
<Mithrandir> being constrained as opposed to having a safe and secure design
<pitti> Mithrandir: as I have always said, I do *NOT* trust cupsys to run as root without AppArmor protection
<pitti> and since the daemon calls cups-pdf, that transitively applies to cups-pdf
<pitti> cups-pdf itself is reasonable code-wise, and small enough
<pitti> but it's still called as root, thus it can get a forged user, etc.
<Mithrandir> this really doesn't sound like something we should ship by default to me.
<Mithrandir> announced or not.
<pitti> Mithrandir: cupsys?
<Mithrandir> cups-pdf
<pitti> what's the difference? Any other backend could equally well be exploited to ruin your ~
<Mithrandir> cups as such usually runs as non-root doesn't it?
<pitti> the problem is that cups runs as root, not cups-pdf
<pitti> Mithrandir: not any more
<Mithrandir> why not?
<pitti> our patches still had severe regressions, especially wrt. third-party drivers
<pitti> and upstream is absolutely uncooperative about even thinking about a new safe design
<pitti> so we eventually replaced the derooting patches with apparmor profiles
<pitti> with the effect that cups now actually works as it should
<pitti> Mithrandir: i. e. upstream does not say "Your patches suck", which I could understand
<pitti> Mithrandir: they say "dude, cupsys must run as root, go away"
<pitti> (without being able to tell a single reason why it has to)
<Mithrandir> *sigh* :-(
<pitti> indeed :/
<Mithrandir> what does other distros say?
<pitti> Mithrandir: we seem to be the only ones who care
<pitti> it just runs as root everywhere else
<pitti> and there's not even an official cupsd apparmor profile
<pitti> I recently saw the beginnings of it in opensuse's AA repo
<cjwatson> pitti: don't know if you noticed, but I committed a patch to apport to fix some of its Launchpad URLs for a milestoned bug; do you think you could review and upload?
<pitti> cjwatson: oh, absolutely; you committed to trunk?
<cjwatson> yes
<pitti> erk, apparently I forgot to push last time; I'll merge
<cjwatson> bound branches! :-)
<pitti> well, I explicitly don't bind for apport, since I often commit lots of small changes
* pitti admits to sometimes use uncommit, too
* Mithrandir sometimes uncommits on public branches too.
<pitti> cjwatson: ah, looks fine; is it important to explicitly use bugs.lp?
<cjwatson> pitti: I'm not sure, carlos filed a bug asking for it and somebody milestoned it
<pitti> I see; sure, no problem
<pitti> cjwatson: thanks
<cjwatson> I figured better safe than sorry in case it was on the LP roadmap to break the old URLs
<cjwatson> (which would be evil, but ...)
<cjwatson> if you'd rather not, I'd accept an argument that it can wait :-)
<carlos> pitti: it helps us to reduce the number of redirects for backward compatibility in Launchpad
<cjwatson> carlos: surely the old redirects can never go away
<carlos> pitti: though, the redirect needs still to be there
<cjwatson> it just reduces the number of hits you get on them
<pitti> cjwatson: no, that's fine; the new URLs work, I just always use https://lp.net for brevity
<pitti> cool
<carlos> cjwatson: we could do that once all distros using the old link are not supported anymore
<cjwatson> carlos: http://www.w3.org/Provider/Style/URI
<cjwatson> people's bookmarks don't stop being supported
<carlos> cjwatson: that's why we add 301 instead of 303 (or is the other way around...?)
<carlos> cjwatson: moved permanently redirects are supposed to update bookmarks or that's what I was told
<cjwatson> if the bookmark is followed, and if the browser supports it ...
<cjwatson> I'm happy to update the links in the browser but it's a terrible bug if Launchpad kills the old URLs at this point
<cjwatson> er, "in the distro"
<cjwatson> they've been publicised way too much
<pitti> seb128: ok, confirmed; the statfs("/media/PittiHD") takes about a minute
<cjwatson> +           [ -d $dir ]  || mkdir -p $dir
<cjwatson> Keybuk: silly, mkdir -p is enough on its own
<Keybuk> cjwatson: mkdir -p would fail if one of the intermediate paths was EPERM
<carlos> cjwatson: ok, anyway, kiko wants it there forever too, so don't worry, you will keep your old URLs in place :-P
<Keybuk> ie. if you were silly enough to have /var -x or something
<seb128> pitti: iz kernel bog? ;)
<cjwatson> Keybuk: huh, seriously?
<cjwatson> it doesn't just check -d first?
<pitti> seb128: maybe, I'll find the place where this happens and gdb over it
<Keybuk> wing-commander scott% mkdir -p foo/bar
<Keybuk> wing-commander scott% chmod -x foo
<Keybuk> wing-commander scott% mkdir -p foo/bar
<Keybuk> mkdir: `foo/bar': Permission denied
<cjwatson> loony
<pitti> seb128: I don't have a drive where I use ext3 exclusively, so it might indeed be specific to vfat
<cjwatson> oh, of course it can't check
<pitti> seb128: and I don't want to trash my 500 GB USB hard disk to try :/
<cjwatson> Keybuk: but then [ -d ]  would fail too!
<seb128> pitti: understable
<Keybuk> cjwatson: right, but silently and not enough to bail out a -e script
<seb128> pitti: comments on the bug suggests it happen also for disk partitions
<Keybuk> though I think that one's not -e anyway
<cjwatson> Keybuk: er
<cjwatson> Keybuk: you do [ -d ]  || mkdir -p
<Keybuk> yes
<cjwatson> Keybuk: [ -d ]  will fail and the mkdir -p will happen anyway
<cjwatson> so the [ -d ]  achieves nothing at all
<Keybuk> oh, damn
<Keybuk> you're right :)
<Keybuk> and here was me thinking I was being smart
<Keybuk> lol
<cjwatson> I'd just mkdir -p || true
<Keybuk> yeah
<Keybuk> doesn't make much practical different of course
<cjwatson> I have a change to make in sysvinit anyway, so I'll do that
<Keybuk> ok
<seb128> pitti: if that happened on ext3 I think we would have noticed
<cjwatson> Keybuk: you should have seen the wild constructions partman was using to avoid mkdir -p
<cjwatson> I found a place where somebody had decided to implement it by hand, including adding non-existent directories to a space-separated list and iterating over them in reverse order
<StevenK> cjwatson: As bad as mkdirhier?
<cjwatson> StevenK: pretty much
* StevenK shivers
<cjwatson> busybox has mkdir -p, so I ripped it all out
<StevenK> I wonder how many kittens that code cost. :-P
<tkamppeter> pitti, so I will move the PDF destination back to ~/PDF as this is a constant and not a user-specific value like ~/Desktop.
<pitti> tkamppeter: are there any other changes in the packages?
<tkamppeter> pitti, yes, especially making it configure whenthere are CUPS problems.
<mvo> could someone please translate "sistema de ficheros del archivo tar daado - archivo de paquete daado" for me (dpkg error msg)
<tkamppeter> The cupsys you do not need to upload, as it is only to make AppArmor allowing cups-pdf to write (not read) into ~/Desktop
<Mithrandir> mvo: msgid "corrupted filesystem tarfile - corrupted package archive"
<tkamppeter> pitti, another change is to preceed the file names of the PDFs by the job number, so that if the job title is always the same (and not the document name) that the files do not overwrite each other.
<mvo> Mithrandir: thanks !
<pitti> tkamppeter: we should rather teach cups-pdf to use a -N suffix
<pitti> tkamppeter: i. e. foo.pdf, foo-1.pdf, foo-2.pdf, etc.
<pitti> tkamppeter: starting at a random number might be too confusing
<tkamppeter> pitti, so I will stay only with the install issue and reopen all the other bugs: bug 147551, bug 134671, bug 134682
<ubotu> Launchpad bug 147551 in cups-pdf "cups-pdf fails to generate file" [Medium,Fix committed]  https://launchpad.net/bugs/147551
<ubotu> Launchpad bug 134671 in cups-pdf "[Tribe5]  cups-pdf do not overwrite existing pdf" [Medium,Fix committed]  https://launchpad.net/bugs/134671
<ubotu> Launchpad bug 134682 in cups-pdf "[Tribe5]  user don't know where are his pdf file" [Undecided,Fix committed]  https://launchpad.net/bugs/134682
<tkamppeter> pitti, all the rest we should not do on our own but let upstream redesign the appropriate parts of the tool.
<pitti> yeah
<tkamppeter> pitti, for file visibility they should do a D-Bus notification thingy instead of cluttering the user's desktop with files.
<Mithrandir> no, it should just ask the user where he wants to save the file.
<tkamppeter> pitti, for files not overwriting each other they should add date and time at the end of the file name as the job number is something strange for non-technical users. Also files with the same document name should stay close to each other.
<tkamppeter> Mithrandir, this would be the best. Can the backend pump the PDF through the D-Bus so that a tool running as the user is popping up and asking the user for saving the file?
<pitti> tkamppeter: upstream would not accept that, since it's bound to Gnome
<tkamppeter> pitti, or should we open a spec to start a new PDF generator project from scratch. Problem is to find the people to implement it.
<pitti> tkamppeter: I'd rather convert the remaining desktop apps to use libgnomeprint, or so; it should all be done on the client side, without the need to go through cups
<tkamppeter> pitti, what would upstream not accept? The use of D-Bus?
<pitti> tkamppeter: cups-pdf is specifically meant to work for non-Gnome apps
<asac> stgraber: did you post the driver log yesterday? I had issues and loosed my log of this channel yesterday
<tkamppeter> pitti, so then we leave cups-pdf as interim solution until the application developers will catch up and do not develop new features for it. We will simply sync with upstream and fix the bugs.
<stgraber> asac: no, I'll try to get one today (no idea why I can't get one with debug=1 and 65536 as debug value ...)
<pitti> tkamppeter: might be best; cups-pdf is and remains a nasty hack, regardless of how many bug fixes you apply to it :/
<tkamppeter> I will mark all open feature-requesty bug reports on it as "Wontfix"/"Wishlist" telling that it is an interin solution which will be removed as soon as all app developers are following the standards.
<pitti> tkamppeter: oh, please leave it open as wishlist; they might be justified
<tkamppeter> pitti, so I make them "Confirmed"/"Wishlist" so that upstream can decide on them.
<soren> pitti: You did the partman cryptolvm thingie?
<pitti> soren: I just fixed the cryptsetup initramfs hook to get along with UUIDs, so that a system installed with that partman-crypto-auto module actually boots
<soren> pitti: Do you know what the rationale behind the blockdev-wipe is?
<pitti> soren: just paranoia
<soren> pitti: No way to disable it?
<soren> pitti: It makes installing in vmware *a *pain*.
<pkern> soren: There is a file in /lib/partman (I think.)
<pitti> soren: if you randomize the entire drive prior to putting an encrypted partition on it, it is much harder to tell where it ends, and where the actual data is, etc.
<pkern> soren: You could add it to disable it, I did so too but it was weeks ago.
<pitti> (provided that you don't have a partition table that tells you, of course)
<pkern> s/add/modify/
<pitti> soren: you can disable it
<pitti> soren: have it setup the partitioning, say 'no' to the confirmation, and disable erasing
<soren> pitti: Ah... point!
<pkern> Oh there is a GUI way. Nice.
<tkamppeter> pitti, I have updated bug 134682 appropriately. Is it OK this way?
<ubotu> Launchpad bug 134682 in cups-pdf "[Tribe5]  user don't know where are his pdf file" [Wishlist,Confirmed]  https://launchpad.net/bugs/134682
<pitti> tkamppeter: fine for me, thank you
<pitti> seb128: I confirmed that it is really a kernel bug, updated the bug trail accordingly; sorry for the noise
<seb128> pitti: that's no noise but useful informations, thanks a lot ;)
* seb128 hugs pitti
<pitti> seb128: I just can't find any stat.*fs invocation in nautilus itself, so I don't know where to start gdbing
<soren> pitti: Gah.. I would have thought that going back from the "write changes to disk..." dialog would have the manual partitioner all filled in with the automatic values.
<seb128> pitti: likely gnome-vfs
<pitti> soren: not "go back", say "no"
<pitti> soren: "go back" doesn't work
<soren> pitti: I did say "no".
<pitti> soren: hm, it worked for me
<soren> pitti: You had all the values filled in? For me it just showed /boot and the other partition marked as crypto/"dont use" or something.
<soren> So I had to fill in the encryption config first, add a pv to it, create an lv and blahblah..
<pitti> soren: yes, I tried it in vmware; it required some more going back and forth, but it worked
<soren> I'll start over..
<seb128> pitti: file-method.c has some statfs calls
<seb128> also fstype.c
<pitti> seb128: ah, I'll have a look
<pitti> seb128: hm, I breakpointed both, no luck
<seb128> running nautilus under gdb, doing ctrl-C when it hangs and "thread apply all bt full" doesn't give any clue?
<pitti> seb128: that's the point; you can't ^C a program while it is in a syscall (uninterruptible kernel sleep)
<pitti> so I need to breakpoint it right before
<pitti> seb128: I have some more ideas, I'll report back
<soren> pitti: No matter how I go back and forth, I end up with a 255 MB primary partition on /boot and a 8.3 GB logical partition, type encrypted, "not active".
<pitti> soren: hm, weird
<pitti> soren: let me try it here
<pitti> soren: hm, indeed; no idea how I managed to do this back then
<soren> pitti: oh!
<soren> After it wipes the disks, it shows me everything.
<soren> Sorry, that's not entirely true.
<pitti> right, but that's too late
<viviersf> Which mirror has the most recent uploaded packages ?
<pitti> viviersf: archive.u.c.
<soren> I hacked the /lib/partman/crypt* script to not do the wipe. Now, when I allowed it to go on, it ended up on that "page"
<viviersf> pitti, ok cool thanks
<soren> I've always wondered... What's the point of lvm if it uses the entire lv by default anyway?
<soren> Er... vg, I mean.
<pitti> soren: not sure what you mean? we have one VG "Ubuntu" which holds all the partitions; doesn't that make sense?
<pitti> (except /boot, of course)
<soren> pitti: Yes, but why does the / lv have to use all the space in the vg?
<soren> pitti: What purpose does lvm serve in that case?
<pitti> soren: it's exactly like our standard setup; provide a reasonable swap, and the rest for /
<tkamppeter> pitti, Riddell has uploaded the new cupsys and cups-pdf (forgot to remove them from my server immediately) I will make new packaes of both.
<pitti> soren: the purpose is to combine / and swap into a single encrypted entity
<pitti> soren: if we wuold have swap with a random password, then resuming from suspend to disk would break
<pitti> soren: if we had two encrypted drives with / and swap, you'd need to passwords, or enter it twice
<soren> pitti: Ah, right in the encrypted case, I see a bit of an advantage, but if not, why would anyone want to use the autolvm thing instead of the regular partitions?
<pitti> tkamppeter: darn, they have already gone from accepted
<pitti> soren: no idea; maybe to have an initial start, or so; I don't see the advantage either
<pitti> tkamppeter: if you say that we don't need any changes, let me just reupload my current svn
<pitti> tkamppeter: so that I get immediate consistency with svn again
<blue|palm> if I have an idea to enhance gnome and I am able to implement it, but would like it to be included in the next ubuntu release, where do i go with my proposal?
<pitti> ah, right, no "accepted" for source packages any more
<soren> blue|palm: Depending on the nature of your enhancement, you can either register a blueprint on launchpad or talk to the gnome developers about it.
<soren> blue|palm: If it ends up in gnome, it lands in Ubuntu automatically.
<tkamppeter> pitti, in cupsys all changes can get undone. In cups-pdf the "does not install/upgrade" fix
<pitti> tkamppeter: right, please make a new cups-pdf which contain your other fixes
<tkamppeter> es have to stay in.
<cjwatson> blue|palm: or often just file a bug, if it's small - blueprints are for complex ideas which require design or coordination among multiple components
<blue|palm> soren, thanks, do you know what is the normal method of communication the gnome devs use? IRC, mailing list?
<tkamppeter> pitti, so a new cupsys is not needed? This you can roll back?
<pitti> tkamppeter: I'll upload a new one
<pitti> tkamppeter: but I use the svn for that
<blue|palm> cjwatson, its a small enhancement to an already working aspect of gnome... but i believe it will increase productivity... ill go with filing a bug report
<pitti> tkamppeter: cupsys done
<seb128> blue|palm: what is your idea?
<blue|palm> seb128, to improve the gnome file copy/move dialogue. I intend to add an 'advanced mode' to allow for pause/resume/speed limitation as well as queueing up file transfers... lastly to add a manager applet of some sort to easily manage your transfers (instead of having 5 copy dialogues open at once, you could hide them and instead monitor them as a list in the manager)
<blue|palm> seb128, I'd like to add this almost transparently to the current system, so that normal users can just copy files like usual, but power users/users copying large numbers/sizes of files can use this system
<soren> blue|palm: Shouting :)
<seb128> blue|palm: I think there is already some bugs upstream about that
<blue|palm> seb128, well, i'd like to implement the idea...
<seb128> nice ;)
<seb128> blue|palm: you might want to mail nautilus-list@gnome.org
<blue|palm> seb128, i'm just have no idea how to make it 'official' with gnome
<seb128> with your ideas, etc for discussion
<blue|palm> seb128, thanks, ill do that
<blue|palm> soren, what do you mean by 'shouting'?
<seb128> I'm subscribed to the list so I'll read about it there ;)
<soren> blue|palm: I was replying to your question about how to contact gnome developers. :)
<blue|palm> soren, ah ok :-)
<blue|palm> ugh, i personally hate lists... but here goes :-D
<cjwatson> blue|palm: you won't get far in free software development if you avoid mailing lists :)
<blue|palm> cjwatson, i've realised that
<blue|palm> can anybody tell me what tech is behind the network icon (i think its called the network manager applet; the thing that gives you a list of wifi networks/dialup connections etc.) that was introduced into ubuntu recently? is it written in python? or C/C++? and what library is it using? Im looking to create something similar...
<stgraber> blue|palm: it's the network-manager, it has two parts, a system daemon and a gnome applet. It's written in C, using dbus for communication between the applet and the daemon.
<blue|palm> stgraber, thanks
<tkamppeter> pitti, new cups-pdf is in place now, see mail. I have also updated all bug reports. So except urgent bugs printing is ready for Gutsy now.
<tkamppeter> Which day is RC freeze
<cjwatson> we'll freeze the archive at some point tomorrow
<cjwatson> at least that's the current plan
<Hobbsee> cjwatson: ARGH!
<Hobbsee> cjwatson: is that full freeze?
<Hobbsee> as in, fully frozen freeze for main?
<pitti> is it just me, or is LD_LIBRARY_PATH broken (i. e. not working at all) for everyone in gutsy?
<ogra> cjwatson, huh ?
<cjwatson> Hobbsee: yes, with exceptions as usual
<ogra> whee, thats quick ...
<cjwatson> ogra: I said what I said. The standard release candidate process is to freeze one week before release candidate; this is in fact relaxing that slightly
<cjwatson> pitti: you sure it's not a set-id binary?
<ogra> yeah, i was just confused since its not listed on the schedule
<pitti> cjwatson: yes, I am
<Hobbsee> cjwatson: crap.
* Hobbsee has more kubuntu stuff to shove.
<pitti> cjwatson: LD_DEBUG shows that it uses the path for the first resolution, and forgets about it afterwards
<pitti> this makes debugging a lot more painful that it has to be
<cjwatson> Hobbsee,ogra: compare https://lists.ubuntu.com/archives/ubuntu-devel-announce/2007-April/000274.html with https://wiki.ubuntu.com/FeistyReleaseSchedule, for example
<Hobbsee> cjwatson: i know you're probably right, but i still thought it was a little further away
<ogra> hmm, i didnt get that mail .. something is broken with my list setup it seems
<ogra> oh, wait april
* cjwatson checks ogra's clock
<ogra> heh
* Hobbsee checks her watch
<Hobbsee> cjwatson: us ubuntu people arent good at getting dates right.
<Hobbsee> oh cool, watch is only two minutes slow now.
* Hobbsee curses work.
<TheMuso> Hobbsee: tsk tsk tsk. You need to get it synced with an ntp server. :)
<ogra> Hobbsee, all fault of the clock applet
<Hobbsee> TheMuso: the dvd unlocking things actually slow our watches down.
<TheMuso> That doesn't surprise me actually.
<Hobbsee> TheMuso: we lose 15 mins or so for every 40 hours worked
<TheMuso> Since its a magnetic thing.
<Hobbsee> the closer we are to it, the more loss.
<Hobbsee> not kidding - we did an experiment on this, as the boss was always asking us why we were going early - where it was actually her watch being slow.
<Hobbsee> cjwatson: universe isnt freezing for ages, i tkae it?
<cjwatson> Hobbsee: technically though not by policy
<Hobbsee> cjwatson: great - manual shoves required, i take it.
<cjwatson> yes
<Hobbsee> cjwatson: cool, OK, i can ignore that queue for longer then.
<TheMuso> Hobbsee: heh. Gotta love procrastination.
<Hobbsee> TheMuso: procrastination is very useful.  and i've been catching up with uni stuff and friends (yes, i have some), as i cant spend all my time on ubuntu.
<TheMuso> Hobbsee: Yeah I know. :)
<TheMuso> _MMA_: So what do you say? Just ditch the multiple tasks for now, and make everything installed? If so, I have a very good idea of how this is to be done, and compared to what we've had to do so far, it is piss easy.
<cjwatson> TheMuso: blink, what?
<cjwatson> what's wrong with tasks now?
<Hobbsee> TheMuso: no, i can just assign the entire queue to you - no procrastination required.
<TheMuso> cjwatson: Sorry, wrong window.
* TheMuso blushes.
<TheMuso> cjwatson: Basically hard coding ubuntustudio-desktop to the seed deps causes recommends packages not to be installed, so we're just pondering making everything installed at once, saving us the headache of working this out till Hardy.
<cjwatson> TheMuso: that's easily fixed
<cjwatson> it's just because ubuntustudio-* is in the wrong section
<cjwatson> I can fix that in the archive right now
<TheMuso> chuck_: Oh ok. Wrong section
<TheMuso> cjwatson: Oh ok. What section?
* TheMuso has too many things happening at once here...
<cjwatson> TheMuso: metapackages
<TheMuso> oh
* _MMA_ hopes he brings enough $ for all the beers he owes Colin and Luke in Boston.
<cjwatson> well, universe/metapackages
<cjwatson> TheMuso: changed in the archive; feel free to change the source at your leisure
<_MMA_> *and BenC :)
<TheMuso> cjwatson: Oh ok. Since I took over maintanance of meta, I didn't even think to check that. :)
<Keybuk> pitti: have you seen the "Gutsy's HAL is broken" thread on devel-discuss
<Keybuk> the author replied with some fairly extensive attempt at debugging
<Hobbsee> he's on irc now, too
<pitti> Keybuk: I saw it, yes; still stuck in nautilus debugging, but I'll look at it
<Keybuk> :)
<Hobbsee> hm, until he walked away and decided that irc was pointless.
<Keybuk> intelligent man
<xjkx> "Ubuntu 6.06 LTS - Supported to 2011" that means you will keep updating and keeping it safe and cool until 2011 right?
<xjkx> i think i will give it a try
<jdong> xjkx: for main, yes, and by updating, we mean security and very very critical bugfixes
<jdong> xjkx: don't be like the mepis guy and assume we'd be putting GNOME 2.20 in Dapper by 2011 ;-)
<xjkx> hehe it means never getting new versions ;] 
<jdong> of course it confuses me why he went back to Debian stable releases....
<jdong> and backporting packages from sid.
<jdong> when he could've just backported from gutsy like what I do everyday...
<Fujitsu> jdong: Remember that the MEPIS guy seems convinced that Ubuntu is... erm... rebuilt almost from scratch each time, from Debian experimental.
<StevenK> Whadya mean it's not? :-P
<asac> carlos: ok how can i get the translations?
<carlos> asac: ?
<Keybuk> xjkx: 2011 on the server
<carlos> asac: I'm working on the code that would allow you to get them
<Keybuk> for, as pointed out, security fixes and critical bug fixes
<Keybuk> a little less on the desktop
<carlos> so it's not possible yet
<asac> carlos: ok ... how can i help then?
<carlos> asac: though, I'm leaving to have lunch now, and I have a meeting when I'm back from lunch, do you mind to have a meeting around 15:00 UTC ?
<asac> carlos: thats fine
<carlos> ok, thanks
<Mithrandir> seb128: can I have the applications menu, etc, have their text horisontal on a vertical panel?
<seb128> Mithrandir: no
<seb128> Mithrandir: that would make a really large panel
<Mithrandir> seb128: 100px or so?  Which isn't much when my display is 2560 pixels wide.
<asac> seb128: i always liked having the panel on the right/left ... but gnome panel appears to behave strangly; is there something planned for that upstream?
<asac> (especially the taskbar)
<seb128> Mithrandir: well, there is no option to configure that, and 200 pixels is a lot on a 1024x768 screen
<asac> seb128: ok it appears to have improved in this gnome-panel ... so don't bother for my comment
<Mithrandir> seb128: it could autorotate if the panel was wide enough that it made sense?
<seb128> asac: there is some bugs open for ages but nobody actively working on them
<seb128> Mithrandir: yes
<Mithrandir> http://err.no/tmp/panel.png looks kinda funny
<Keybuk> hurrah, my laptop appears to be tea-proof
<minghua> Mithrandir: Maybe you can try the menu with no texts but only the icon.
<amitk> Keybuk: upto how many meters?
<jdstrand> asac: re bug #138217
<ubotu> Launchpad bug 138217 in network-manager "NetworkManager fills log on start up until dhcdbd has started" [Medium,Fix released]  https://launchpad.net/bugs/138217
<jdstrand> asac: grep 'Oct  4 09.* dhcdbd not running' /var/log/daemon.log|wc -l
<jdstrand> asac: 46
<jdstrand> asac: woohoo!
<jdstrand> asac: thanks!
<norsetto> mvo: ping
<mvo> norsetto: pong
<norsetto> mvo: hi :-) Just wondering if you looked at bug 131166 recently?
<ubotu> Launchpad bug 131166 in apt "[gutsy]  apt-get update deletes local Packages.gz file" [High,Confirmed]  https://launchpad.net/bugs/131166
<mvo> norsetto: let me check, I was sure that this got fixed
<norsetto> mvo: well, it didn't ....
<mvo> norsetto: urghs, ok
<norsetto> mvo: but the last patch fixes it
<mvo> norsetto: thanks! I milestoned it now
<janimo> hello, in the daily xubuntu builds http://cdimage.ubuntu.com/xubuntu/daily-live/20071004/
<janimo> it seesm the manifest is still from sep 25
<janimo> and the iso I have tested did not have the latest packages
<janimo> (older xubuntu-desktop and usplash at least)
<Mithrandir> janimo: that was fixed today, iirc
<janimo> Mithrandir: was the build not reenabled afetr beta? ok, thanks
<Mithrandir> janimo: some problem on the buildds, afaik
<janimo> ok, I'll test tomorrwo
<Keybuk> cjwatson: did you rebuild d-i after fixing busybox?
<cjwatson> Keybuk: no
<cjwatson> Keybuk: I'm going to do it when the kernel ABI change lands
<Keybuk> ok
<Keybuk> Ng: ^ :-)
<cjwatson> which should be soon
<Ng> ah, ok
<Ng> thanks
<tepsipakki> just copying [ to /bin works for now :)
<cjwatson> yeah, that should be ok
<Kopfgeldjaeger> hi
<mantiena-baltix> hi all
<asac> jdstrand: thanks for confirming the fix
<jdstrand> asac: np :)
<MacSlow> brb
<lamont> doko: what was your bind9 change?
<jdstrand> soren: in looking at bug #119075 , I was thinking of simplifying things, and just do test_mysql_access right from /etc/init.d/mysql at the end of 'start'.  This will make it so I don't have to do anything to postinst
<ubotu> Launchpad bug 119075 in mysql-dfsg-5.0 "Root password policy for mysql" [Undecided,In progress]  https://launchpad.net/bugs/119075
* lamont thought upstream changelogs were supposed to be there for all packages... or should I only be delivering upstream changelog in the base (or doc) package?
<doko> lamont: not installing the upstream changelog in the library packages to save space on the CD
<lamont> ah, because -2 beat you out
<jdstrand> soren: it was prompted by the fact that even more changes would have to be made to postinst to get the message shown on upgrade
<jdstrand> soren: thoughts?
<doko> lamont: I don't think there's apolicy
<lamont> doko: got a diff for me?
<doko> lamont: http://paste.ubuntu-nl.org/39533/
<doko> lamont: or create a -common package and symlink the whole doc directories, will save even more space
<lamont> If an upstream changelog is available, it should be accessible as /usr/share/doc/package/changelog.gz in plain text.
<lamont> so, sounds like a symlink to share/doc/bind9/changelog.gz is in order
<doko> lamont: in this case, you need a common dependeny package, but your source package doesn't have this
<doko> and then, I would prefer a symlink to the doc directory
* lamont scratches his head
<lamont> your patch, as I read it, does the same thing that I did, only in 2 steps...
<lamont> first install it everywhere but bind9 and libbind-dev, then install it specifically in those two pacakges
* lamont hugs the word "should" :-)
<pitti> seb128: since I doubt that we can fix the kernel in time, the only workaround I can imagine is to not display the free space for VFAT drives in nautilus
<seb128> pitti: works for me, I think that's better than hanging
<lamont> so.. I'll deliver the upstream changelog in bind9-doc, with a note
<pitti> seb128: I confirmed that this fixes the hang at least
<pitti> seb128: but I'd do the hack in nautilus, not in gnome-vfs
<seb128> pitti: what did you change, where?
<seb128> pitti: right
<pitti> seb128: I don't want to break the actual call (gnome_vfs_get_volume_free_space())
<pitti> seb128: ./libnautilus-private/nautilus-file.c, nautilus_file_get_volume_free_space()
<pitti> seb128: I might do it one level above, in the filemanager view
<seb128> pitti: wherever you think it's the best place to do the change
<bddebian> Heya
<pitti> seb128: I'll make it so that the properties window hangs and returns the correct result, whereas the browser doesn't show it and hangs
<seb128> ok
<pitti> erm, s/hangs$/does not hang/, of course
<doko> lamont: dh_installchangelogs doesn't install the upstream changelog by default ...
<soren> jdstrand: Without seeing the actual code, I think I'd prefer it in the init script.
<doko> ohh, pasto, right, I should remove that ...
<doko> lamont: will you upload?
<lamont> doko: yes
<doko> thanks
<lamont> +       dh_installchangelogs -a -Nbind9 -Nlibbind-dev CHANGES
<lamont> +       dh_installchangelogs -pbind9 -plibbind-dev CHANGES
<lamont> that still looks like no change...
<doko> lamont: dh_installchangelogs -a -Nbind9 -Nlibbind-dev
<lamont> right.
<jdstrand> soren: yes.  it is slightly less efficient (ie its checked every time mysql is started), but really that is good-- in case the password is inadvertantly blanked via some other means
<lamont> I pasted what you pasted though...
<jdstrand> soren: it also makes the changes to the packaging less intrusive
<jdstrand> soren: thanks
<soren> pitti: If my fresh install with cryptlvm and stuff doesn't boot properly (installed from current daily alternate cd), is that because your fix hasn't hit the dailies yet, or is it just simply still b0rken?
<pitti> soren: hm, sounds like the latter; it did work with my locally applied patch
<pitti> soren: which cryptsetup version do you have on the CD?
<lamont> doko: http://paste.ubuntu-nl.org/39535/ look good to you?
* soren checks
<doko> lamont: yes
<soren> pitti: ./pool/main/c/cryptsetup/cryptsetup-udeb_1.0.5-2ubuntu1_i386.udeb
<pitti> soren: hm, that should have the fix
<pitti> soren: I'll do a test install as well to check what's going in
<pitti> on
<soren> pitti: Where's the config file supposed to be in the initramfs?
<soren> Or should the luks signature just be detected and prompt me for my password?
<pitti> soren: conf/conf.d/cryptroot should have one target with the correct 'outer' (encrypted file system name
<soren> no, that wouldn't be clever..
<soren> I only see resume in /conf/conf.d
<pitti> hm, that's wrong then
<soren> pitti: I'll get it booted and try update-initramfs'ing.
<pitti> soren: that was my patch which made it work: http://people.ubuntu.com/~pitti/tmp/cryptroot.diff
<pitti> soren: please try update-initramfs -u
<soren> Sure.
<pitti> soren: in the running system and check whether it makes any difference
<soren> Yeah, that's what I was going to do. I'm just waiting for it to boot.
<soren> Heh... It asks me for my luks passphrase, when it gets to early crypto disks...
<lamont> *** glibc detected *** /usr/bin/uic3: free(): invalid pointer: 0x0012484c ***
<lamont> I find that annouing
<lamont> annoying, even
<Keybuk> I still read that as "glibc detected" being the problem
<Keybuk> "OMG! DUDE! GLIBC!"
<Hobbsee> no glibc for you@
<soren> pitti: I get a couple of warnings about an invalid line in /etc/crypttab
<lamont> Keybuk: LOL
* lamont ponders the relative importance of wpasupplicant on hppa....
<pitti> soren: oh, that would be it
<pitti> soren: what's your crypttab?
<soren> sda5_crypt /dev/disk/by-uuid/<uuid of my sda5> none luks
<pitti> hm, that looks fine
<pitti> soren: ok, thanks; I'll do a test-install and fix it
<pitti> soren: I think we will have pretty much identical vms :)
<pitti> soren: siretart merged some other fixes from Debian along with my patch, so maybe they interfered somewhat
<soren> pitti: Wow.. There's massive differences between those two initramfs's.
<soren> pitti: I did not expect that.
<sladen> pitti: it'd be good to test the non-LVM code-paths
<sladen> pitti: creating three normal partitions (/boot, /, swap) setting each of those to be cryptoed
<pitti> right
<Hobbsee> people, is ubuntu-minimal supposed to depend on util-linux, or linux32?  L32 C/R/P's util-linux
<sladen> with your -dbgsym, where's it expecting to find the source code?
<sladen> pitti: ^^ ;  eg. somewhere under /usr/share  if I unpack the source code in the right place;  or is it looking in the current directory
<pitti> sladen: that doesn't work, I'm afraid; I guess it's something like /build/buildd/
<pitti> this stuff was designed ATM to get good backtraces
<pitti> not sure whether the paths can be mangled
<soren> It works if it's in $PWD, too.
<sladen> think RH do mangle the paths to be  /somewhere/package-name/foo.c
<soren> /usr/src would make sense..
<sladen> pitti: then their dbgsym package also includes the source code
<cjwatson> Hobbsee: other way round, util-linux C/R/P's linux32
<pitti> soren: which part of the search path does it strip off for $PWD?
<asac> carlos: will be here in 3 minuts ... maybe chat in #ubuntu-mozillateam?
<cjwatson> Hobbsee: I think sticking with util-linux there is fine
<carlos> asac: sure
<Hobbsee> cjwatson: oh, my bad.
<cjwatson> Hobbsee: and certainly util-linux is definitely needed anyway
<soren> pitti: No clue. I just remember I've used the debug symbols with the samba source in $HOME/src somehow.
<soren> pitti: I suspect it's gdb doing something clever.
<pitti> soren: apport-retrace just strips off the path and then tries to find the file name in the unpacked and patched source tree
<pitti> soren: (for generating the sourceful stack trace)
<Hobbsee> cjwatson: it's a 1am-ism, i think
<soren> pitti: I see.
<pitti> meh, I should have done a CLI installation; this one will take ages
<Hobbsee> doko: ping
<doko> Hobbsee: ?
<Hobbsee> doko: just letting you know, your upload has caused https://bugs.edge.launchpad.net/ubuntu/+source/gimp/+bug/148985
<ubotu> Launchpad bug 148985 in gimp "package gimp 2.4.0~rc3-1ubuntu4 failed to install/upgrade: trying to overwrite `/usr/share/doc/libgimp2.0/README', which is also in package libgimp2.0" [Undecided,New] 
<Kopfgeldjaeger> pitti: hum, i can only encrypt the whole hard disk with the daily alternate cd (qemu), if i try to manage my partitions myself, it tells me that i dont have chosen a root file system (i chose this "encrypt" option)
<doko> Hobbsee: lookling
<doko> Hobbsee: looking
<Hobbsee> cool :)
<soren> pitti: You say apport strips off the path... How does that work, actually? It uses gdb to generate the backtraces, I assume. Can you pass a special argument to gdb to pull that off?
* soren rather considers apport to be black magic
<pitti> soren: no, gdb doesn't support it, otherwise I would have used it; I just do it manually
<pitti> soren: i. e. get the gdb stack trace and augment it with the environments of the source file
<soren> pitti: Ah, clever, clever.
<soren> pitti: I just noticed the -d option to gdb, and thought that might do something like that.
<pitti> soren: I don't remember any more what was wrong with it
<pitti> speaking about ugly hacks:
<soren> pitti: It probably doesn't strip stuff of, just looks in a different place.
<pitti> seb128: http://people.ubuntu.com/~pitti/tmp/12_vfat_no_free_space.patch
<pitti> seb128: can you have a quick look on it? my gnome vfs fu is quite weak (as well as which strings I have to free, etc.)
<pitti> I'm not proud of it, but it avoids the hang
<soren> O.O
<cjwatson> could somebody have a look at bug 134404 and see what they think of my suggested patch?
<ubotu> Launchpad bug 134404 in mbr "mbr ftbfs" [High,Confirmed]  https://launchpad.net/bugs/134404
<pitti> oooh!
<cjwatson> pitti: gnomevfs> tab-damage, for starters
<mjg59> cjwatson: Did you make any changes to partman to fix the HFS+ resize refusal problem?
<cjwatson> mjg59: remind me of the bug number?
<cjwatson> I don't think so, though
<mjg59> Urgh. Bug number.
* mjg59 wonders whether he actually ever filed it
<cjwatson> the (possibly cleaner, but more effort) alternative to my mbr patch is to fix the testsuite to spot vm86 ENOSYS and bail out silently somehow
<cjwatson> or implement a do-we-have-vm86 helper program
<mjg59> Why's it being built in a 32-bit chroot?
<mjg59> There's the potential for other things to break in the same way
<cjwatson> mjg59: because our i386 buildds are really amd64, since I assume that's just what sysadmin had handy
<cjwatson> I know, but
<mjg59> Eh. The buildds are broken :)
<cjwatson> the amount of stuff that calls vm86 during builds has got to be tiny
<lamont> pitti: since you love syncing from incoming, please sync bind9_1:9.4.1-P1-3 from incoming, so that doko will be happy again.  If you require a bug, please make doko file it. love y'all. kthxbye
<cjwatson> I think it's OK to work around the odd few
<mjg59> Yeah, but it's also valid for it to
<cjwatson> IMO it's perfectly valid to try to build stuff in 32-bit chroots
<cjwatson> we certainly don't even begin to document that you can't
<mjg59> Well, no, because they don't have the full set of functionality provided by the architecture
<mjg59> There are other cases where things can blow up - the kernel still doesn't implement all the compatibility ioctls properly
<lamont> mjg59: those would be kernel bugs.
<mjg59> lamont: Yes, but nevertheless
<doko> mdke: did you see my email about the duplicated .xml files in ubuntu-docs?
<lamont> and besides, cjwatson said "try", which we all know means that failure is perfectly acceptable.
<mjg59> Ha
<doko> seb128: is evolution-data-server somewhat special, that it doesn't build anymore once you did build the package?
<carlos> pitti: do you have time to talk with asac and me  at #ubuntu-mozillateam ?
<lamont> doko: it better not be
<cjwatson> mjg59: since all our builds are done this way, it seems to me that we must already know about all the problem
<cjwatson> s
<pitti> carlos: I'm quite busy ATM, but I'll lurk
<cjwatson> because we're already encountering them all
<cjwatson> it's not like they're going to be hidden ...
<carlos> pitti: ok, thanks
<mjg59> cjwatson: Assuming that there isn't stuff in universe where nobody's noticed the breakage :)
<sladen> mjg59: event = "ibm/hotkey HKEY 00000080 00001011\n\0000\004\b=\0002%\000\000\000\000\000\000\000\000\020<H=t0\004\b\030\017l\025\031\205c\t \004\bH<\vL\a\031D=4P\024\000\231\234\030@o\214<\224P<Od<", '\0' <repeats 12 times>, "/\214<p=C\001\005\000"...
<mjg59> sladen: Looks broken to me
<cjwatson> mjg59: and in any case it's entirely moot because there's no chance of rearranging the buildds now before release, so we have to fix this *anyway*
<lamont> mjg59: that's a corollary to there being stuff in universe.
<mjg59> Well, "fix" - it disables a chunk of the test harness (which I'm happy to admit isn't likely to cause any problems)
<cjwatson> sure, I should have said work around
<lamont> mjg59: it could conditionally disable based on the platform...
<cjwatson> lamont: err, it does
<lamont> linux64 uname -m _should_ work, no?
<mjg59> lamont: The only place it can run is on real i386
<cjwatson> *blink* hadn't thought of that. is that a good idea in general?
<lamont> uh... nfc.
<cjwatson> it seems, um, a more exciting solution
<cjwatson> what does linux64 do on real i386?
<mjg59> cjwatson: the lm flag will be present even in an i386 kernel running on a 64-bit CPU, no?
<cjwatson> nothing much, apparently
* lamont only recently came to care about linux{32,64} since he kinda inherited them by obliterating the linux32 package
<cjwatson> mjg59: hmm, good point
<kylem> mjg59, ye.
<cjwatson> so linux64 is actually better
<mjg59> Yeah
<lamont> oh, and we can drop linux32 from main and/or seeds
<cjwatson> kerazy
<cjwatson> lamont: feel free to edit the supported seed
<cjwatson> lamont: do I need any kind of special build-dep to get linux64?
<kylem> wtf, why are we renaming it?
<lamont> uname -m; linux64 uname -m
<lamont> i686
<lamont> i686
<kylem> people probably have scripts which depend on this. ;-)
<lamont> kylem: util-linux 2.13 Conflicts/Replaces/Provides linux32
<cjwatson> kylem: we're not renaming it, it's borged into u-l
<lamont> so depends: linux32 is fine
<kylem> er, but now seems to be linux64 instead of linux32? :)
<lamont> versioned depends? not so much
<lamont> nah
<cjwatson> kylem: linux64 != linux32
<lamont> two different binaries
<lamont> linux32 ==> make me 32 bit
<lamont> linux64 ==> make me my native arch
<cjwatson> well, two different symlinks to the same binary that looks at argv[0] 
<kylem> ugh, that's poorly named.
* lamont disavows guilt
<lamont> I just accidentally hijacked it.  I didn't write it
<kylem> lamont, it'sok, i'll blame you anyways
<lamont> ok
<kylem> ;-P
<lamont> (and util-linux also Replaces: sparc-utils, just not completely)
<lamont> and maybe as early as hardy, we'll Replaces: e2fsprogs
<cjwatson> lamont: you're getting the fsck wrapper
<cjwatson> ?
<lamont> 2.14 will
<lamont> and e2fsck
<cjwatson> I have a truly ancient bug about that
<cjwatson> moving e2fsck out of e2fsprogs doesn't sound like a good idea
<lamont> and all fs probing code
<lamont> maybe that's not moving
<cjwatson> I'd go so far as to say brain-dead
* lamont would have to actually go read the discussion
<cjwatson> moving fsck out is good though
<cjwatson> though the Hurd folks will hate you
<lamont> what? both of them?
<lamont> there are even fewer hurd users than there are ubuntu/hppa users
<cjwatson> lamont: see Debian #111651 for "how to get fsck into a new Essential package safely" fun
<ubotu> Debian bug 111651 in e2fsprogs "fsck: split out from e2fsprogs?" [Wishlist,Open]  http://bugs.debian.org/111651
<lamont> cjwatson: ah, joy.  I will care about that one, I expect.
<lamont> otoh, util-linux is already essential
<cjwatson> it is, which may help
<cjwatson> I haven't thought about it carefully
<lamont> I haven't thought about it more than 2 seconds
<lamont> (as in, right now)
<cjwatson> the thing you need to ensure is that fsck (and e2fsck) are *always* there
<lamont> right
<lamont> kylem: linux64 as a name makes sense on 64-bit arch.  on 32bit arch, it's a no-op.  one could argue that not failing is either a feature or a bug.
<cjwatson> lamont: if we start using it to test the *real* architecture, it can't be made to fail
<lamont> right
<lamont> I don't see the success being changed
<cjwatson> ok, another attempt in bug 134404
<ubotu> Launchpad bug 134404 in mbr "mbr ftbfs" [High,Confirmed]  https://launchpad.net/bugs/134404
* Hobbsee edits one of the DO NOT EDIT pages
* Hobbsee hides
<seb128> doko: what do you mean? it doesn't build twice in a row? that would be a bug, there was a Debian discussion about that recently and quite some packages are buggy in that regard
<seb128> pitti: looking
<pitti> wb seb128
<seb128> pitti: the patch looks fine to me
<pitti> FSVO "fine", but it's better than the current state, I think
<pitti> seb128: ok, uploading; let's give this a whirl
<doko> seb128: do you think it's worth to symlink the duplicate .png files in evolution?
<Riddell> doko: wasn't there a licence problem with icedtea that was stopping it from being uploaded?
<doko> Riddell: cjwatson is reviewing the upload, b21 did resolve most of the outstanding problems, the outstanding header problems are mentioned in the copyright
<Riddell> ok, good luck :)
<seb128> pitti: it's not a patch for upstream so I'll no start discussing declaration in the middle of the code which break on C89 compilers, I expect we will get no ubuntu bug about that (upstream does though) ;)
<pitti> seb128: right
<seb128> pitti: no, otherwise the patch looks good to do the job it's supposed to do ;)
<pitti> seb128: I fully expect to drop it in hardy again, once the kernel bug will get fixed
<seb128> doko: how much space does that win? How much do we still need?
<seb128> pitti: right
* lamont struggles to remember what was faster than bzr clone sftp://...
<lamont> (rather than the sftp:// that is)
<Riddell> evand: what's the right branch for ubiquity? ~ubuntu-core-dev or ~ubuntu-installer ?
<doko> seb128: I have to check, but are symlinks to -png unsafe? I think if you ask pitti: it's still not enough =)
<evand> Riddell: ubuntu-installer
<lamont> doko: as you should have noticed, 9.4.1-P1-3 uploaded to debian, needs a sync to ubuntu
<evand> That's temporary while I'm not in core-dev, so I can do releases.
<mathiaz> lamont: bzr+ssh:// may be ?
<lamont> ah.  ssh+bzr didn't work. :-)
<seb128> doko: for documentation? dholbach said it doesn't work
<pitti> mathiaz: so the current 2.1 userspace tools do not work with the 2.0.1 kernel?
<mathiaz> pitti: well. Not the parser.
<Riddell> evand: recond I'd be elite enough to join the ubuntu-installer team?
<seb128> doko: <Nafallo> dpkg: error processing /var/cache/apt/archives/gimp_2.4.0~rc3-1ubuntu5_i386.deb (--unpack): trying to overwrite `/usr/share/doc/libgimp2.0/README', which is also in package libgimp2.0
<Riddell> s/d//
<mathiaz> pitti: you'll get invalid protocol error messages.
<evand> Riddell: hrmm, I don't know.  Apply and I'll consider it ;)
<mathiaz> pitti: however the utils (like genprof, logprof) work well.
<Riddell> evand: "Subscription request pending approval."
<doko> seb128: bug 148985
<ubotu> Launchpad bug 148985 in gimp "package gimp 2.4.0~rc3-1ubuntu4 failed to install/upgrade: trying to overwrite `/usr/share/doc/libgimp2.0/README', which is also in package libgimp2.0" [Undecided,Fix released]  https://launchpad.net/bugs/148985
<mathiaz> pitti: so I just swaped the parser code with the old one and updated the profiles to not use the new capabilities (like network and k permissions).
<doko> dholbach: what do you mean by "for documentation?"
<pitti> mathiaz: right, makes sense; the kernel messages look totally different
<seb128> doko: ok, thanks
<mathiaz> pitti: the kernel messages are correctly handled by the log parsing tools.
<evand> Riddell: approved
<mathiaz> pitti: upstream tries to be backward compatible.
<SLaPoet> can someone tell me how to handle forwarding a bug upstream with Launchpad? should it be closed in launchpad? it's more a feature request.https://bugs.edge.launchpad.net/ubuntu/+source/virtualbox-ose/+bug/148784
<ubotu> Launchpad bug 148784 in virtualbox-ose "[gutsy]  virtualbox does not configure usb devices" [Undecided,New] 
<Riddell> evand: ooh, thanks
<lamont> cjwatson: could you check to see if hppa ISO building works yet?  (server stands a small chance, alternate less so, live no way in hell)
* lamont will worry about livecd/hppa for hardy
<kylem> er.
<kylem> why?
<dholbach> doko: I tried replacing duplicates in gnome-user-docs, the pictures did not show up in localized help
<Riddell> evand: what's the ubuntu-core-dev branch for?
<lamont> kylem: livecd to a CLI, not to running gnome
<dholbach> doko: http://daniel.holba.ch/temp/gnome-user-docs.diff
<lamont> lazy-man's recovery CD
<evand> Riddell: I think we're eventually going to switch back to that.  cjwatson seems to be keeping it in sync.
<sladen> SLaPoet: file the bug upstream, add the upstream bug URL as an upstream tracker;  and launchpad will then (after 24hours) poll the status upstream
<cjwatson> Riddell: evand is correct
<sladen> SLaPoet: the situation you'll have is  (1) bug exists in foo (Ubuntu);  (2) bug exists in foo (Ubuntu) and foo (upstream), URL = ...  (3) bug exists in foo (Ubuntu), bug fixed in foo (upstream)  (4) bug committed/fix in both  foo (Ubuntu) and foo (upstream)
<evand> Is there a trick to installing tasks inside pbuilder, specifically getting past xorg?
<mjg59> sladen: Of course, having built it with debugging, I can't get the damn thing to crash
<Riddell> evand: rm the postinst?
<doko> dholbach, seb128: just a thinko in the patch, should work after the fix
<Riddell> oh, pbuilder, not chroot
<dholbach> doko: great, thanks for looking into it
<evand> well, it is a chroot when you use --login, right?
<evand> Riddell: I'll try that though, thanks
<pitti> doko, lamont: bind synced
<cjwatson> lamont: I've added hppa to cron.ports_daily again and have kicked off a new build. from here on you can check at http://people.ubuntu.com/~ubuntu-archive/cd-build-logs/
<lamont> thank you
<lamont> both
<SLaPoet> sladen: thanks i'll check it out.
<sladen> mjg59: something shortly after   else if (strncmp (acpi_path, "battery", sizeof ("battery") - 1)   craps on the stack
<mjg59> sladen: Yeah. With debugging symbols, I seem to be able to handle battery events fine
<doko> pitti: http://people.ubuntu.com/~doko/tmp/cupsys.debdiff
<sladen> mjg59:  dbus_error_free (&error);
<pitti> doko: thanks, I'll check it in
<iwj> doko: autopkgtest's oo.o build failed because it timed out after 100ks.  Is it really supposed to take that long ?
<pitti> doko: if you actually upload that, it'll be rejected (1ubuntu3 should be current), just FYI
<mjg59> sladen: Hm. Ok, there's a potential double free there, I guess
<mjg59> Though I thought dbus_error_free was smart about that
<iwj> (100ks =~ 27.8h)
<doko> iwj: which arch?
<iwj> doko: amd64
<doko> iwj: strange, the build did succeed on the buildd
<iwj> doko: Maybe the buildd has a longer timeout.
<elmo> the buildds timeout on inactivity
<elmo> if you're spewing stuff to the log, they'll keep going indefinitely
<sladen> mjg59: it's not going to be free itself, but the attempted recursive free (?) of whatever crap was left inside that structure
<iwj> doko: Also:
<iwj> -rw-r--r-- 1 iwj warthogs 3.7G 2007-10-04 08:28 log
<iwj> That's the build log.
<iwj> Surely that can't be normal ?
<doko> iwj: Finished:  	 2007-09-28  (took 5 hours 20 minutes)
<mjg59> sladen: Hmm, no, that would only happen on shutdown
<iwj> doko: Millions of lines like
<iwj> ERROR: No Fallback found for language en-US:
<doko> iwj: interesting log file, what's in there?
<mjg59> sladen: Only other thing I can think of is that there's no explicit init at the beginning of the loop
<mjg59> But I can't see the codepath that would result in it being inappropriately freed
<tkamppeter> pitti, I have put up a new hplip (2.7.7.dfsg.1-0ubuntu4), as the previous one only fixed the problem for privileged users (bug 147369).
<ubotu> Launchpad bug 147369 in hplip "MASTER: Printing via HPLIP does not work any more" [High,Fix released]  https://launchpad.net/bugs/147369
<iwj> doko: Seems to be output from eg
<doko> iwj: that's the export of the language data, which we only do on i386. so maybe this is a bug
<iwj> localize -e -l en-US,as-IN -f /root/adt-downtmp/dsc0-build/openoffice.org-2.3.0/debian/l10n/export/GSI_as-IN.sdf
<iwj> localize -e -l en-US,as-IN -f /root/adt-downtmp/dsc0-build/openoffice.org-2.3.0/debian/l10n/export/GSI_as-IN.sdf
<iwj> Oops, sorry.
<iwj> doko: I'll copy the log to chinstrap.
<sladen> mjg59: you need to call the same  dbus_error_init()/libhal_device_rescan()  that all the other cases are using  (which could be moved outside)
<pitti> soren: eww; there is no /conf/conf.d/cryptroot any more; siretart, any idea? did that break with the Debian merge?
<mjg59> sladen: It is?
<doko> calc: ^^^
<tkamppeter> pitti, the ususal e-mail
<iwj> doko: Looks like the webserver can't cope with large files.
<pitti> tkamppeter: ok
<doko> iwj: well, maybe just file a bug report, with an excerpt where it starts with these messages
<sladen> mjg59: the double free can be discounted as that would only occur on fgets() == 0
<iwj> elmo: Is there a sane way to copy a 3.7G file from cadmium to chinstrap ?  My rsync says it will take 3-4h.
<mjg59> sladen: Yes, that's what I said earlier
<tkamppeter> pitti, I hope with this Gutsy's printing subsystem is completed.
* sladen goes to look at the  dbus_error_free logic
<cjwatson> iwj: won't it bzip2 brilliantly?
<elmo> iwj: cadmium to chinstrap should be GB, combined with even normal ssh compression, it shouldn't take anything like that long
<elmo> (but yes, bzip2 would be another work around)
<cjwatson> mvo: do you think we could fix bug 149018 for RC?
<ubotu> Launchpad bug 149018 in gnome-app-install "stop depending on app-install-data-commercial" [Undecided,New]  https://launchpad.net/bugs/149018
<iwj> elmo: Oh, it seems to have sorted itself out and decided it's only going to take another 2-3 _minutes_.
<ion_> CUPS avahi support is so awesome. I plugged a laptop to the network (with a shared printer connected to the desktop machine), clicked print and it Just Worked.
<iwj> cjwatson: Yes, but IME on local networks compressing files before copying them is a waste of time.
<sladen> mjg59: dbus_free (real->name)
<iwj> doko: bug 149021, thanks.
<ubotu> Launchpad bug 149021 in openoffice.org "autopkgtest build took >100ks, generated 3.7G logfile" [Undecided,New]  https://launchpad.net/bugs/149021
<sladen> mjg59: so it's the attempted access, with the candlestick, in the library
<iwj> doko: NB there are a couple of things that seem to make autopkgtest often fail for slightly buggy packages: 1. it doesn't run debian/rules clean before building; 2. the build has no controlling terminal.
<mjg59> sladen: I'm still not seeing how dbus_error_free ever gets called without an error_init
<avoine> Someone know what the ^ do in apt-get? i.e apt-get install minimal^
<iwj> doko: chinstrap:~iwj/log has arrived FYI
<sladen> mjg59: error is never initialised;  error shows a false positive of being set at dbus_error_is_set();  error is freed
<cjwatson> avoine: install task
<sladen> mjg59: should happen in all cases where  event == ibm/hotkey, or event == unknown.  /shouldn't/ (needs verifying) in the case of even == ac_adapter or event == battery
<bdmurray> Keybuk: I saw you fixed 129612 - what would be a good test case for it?
<cjwatson> avoine: i.e. install all packages with Task: minimal
<avoine> ok thx cjwatson
<Keybuk> bdmurray: boot with break=top
<mvo> cjwatson: sure
<mjg59> sladen: I thought you said it happened through the battery path?
<Keybuk> does it say "can't access tty; job control turned off"
<Keybuk> :)
<tkamppeter> Anyone suffering bug 121566?
<ubotu> Launchpad bug 121566 in network-manager "no network with dhcp set up" [Critical,Confirmed]  https://launchpad.net/bugs/121566
<bdmurray> I figured it was quite easy but wasn't sure which kernel boot option would be best.
<cjwatson> mvo: I'll munge the seeds
<siretart> pitti: err, ups?
<mvo> cjwatson: cool, thanks
<cjwatson> mvo: I trust gnome-app-install doesn't really depend on app-install-data-commercial internally?
<sladen> mjg59: I think it's hitting  METHOD UCMS  and dying on that first   (acpi_listen and yank cable)
* sladen leaves it going for five minutes
<mjg59> Ok, plausible
<mvo> cjwatson: no, it was just added so that the data gets imported
<mvo> cjwatson: eh, that the package would land on the CD etc
* mvo can't type/write/spell anymore
<cjwatson> mvo: right
<cjwatson> mvo: I've made it a Recommends of ubuntu-desktop; kubuntu-desktop didn't have it anyway (which might or might not be a bug?); I'll add it to Edubuntu and Xubuntu (and the Xubuntu people can take it out if they want)
<sladen> mjg59: simplist fix should be   error == NULL;  at the top of the function
<mvo> cjwatson: I think initially adept did not support it, so it was not added. I'm not sure about the current state of affairs though
<mvo> cjwatson: that sounds appropriate, thanks
<mjg59> sladen: Do you mean memset it?
<mjg59> It's a struct, not a pointer
<mjg59> sladen: Just make sure it's been through dbus_error_init() in every path
<sladen> mjg59: including the no-match case
<mjg59> Yes
<sladen> mjg59: should be able to stick it on line 196 just before the glorified switch statement
<mjg59> Yes
<mjg59> Want to do that and see if it works?
<sladen> mjg59: In progress
<mjg59> Cool
<pitti> tkamppeter: eww, 666 for /dev printer devices? that sounds wrong
<pitti> tkamppeter: the user is not supposed to directly talk to those devices; only the daemon should do that
<cjwatson> evand: whoa, nobody had merged the gobuntu seeds in ages. that can't be helping
<evand> oh, I had intended to point that out to you
<evand> uh, whoops?
<cjwatson> not sure if it's the cause of your problem, but ...
<evand> worth a shot
<evand> want me to take care of it and then point you at the branch, or is it something that would be done significantly quicker by you?
<cjwatson> evand: I've just done it :)
<evand> heh
<tkamppeter> pitti, about HPLIPs permissions for /dev files. They need to be 666 so that normal users can use the hp-toolbox.
<pitti> tkamppeter: doesn't that talk though the hplip daemon?
<pitti> world-writeable USB device nodes is just plain wrong
<tkamppeter> pitti, the HPLIP daemons were removed with the last HPLIP 2.7.7 (generation "2").
<mjg59> tkamppeter: 666 device nodes really aren't acceptable
<pitti> even root:lpadmin 660 is evil enough
<tkamppeter> pitti, hp-toolbox is run by a normal user and seems to start hpssd which in turn accesses the /dev files.
<pitti> tkamppeter: the better fix then is (IMHO) to change the .desktop file to call it as root
<pitti> eww
<tkamppeter> pitti, so you thing the GUIs of HPLIP should run SUID root?
<pitti> no, I don't think they should
<pitti> they should talk to a sane daemon which manages the devices, locking, etc.
<cjwatson> 666 device nodes are just plain negligent, IMO
<cjwatson> I'm sorry, but ...
<tkamppeter> Perhaps we make hpssd SUID root so that it can access root.root 600 /devs. Should I do it this way?
<kylem> 666 device nodes are a security nightmare.
<pitti> tkamppeter: no, that would be even worse
<cjwatson> 660 + setgid <pick a group>?
<pitti> tkamppeter: do we need the hp toolbox for installing and using the printer at all, and do we install it by default?
<cjwatson> though that isn't great either
<pitti> lpadmin, if we need a group
<pitti> oh, no, "lp'
<pitti> lp is the group which the device nodes should have
<tkamppeter> pitti. hp-toolbox is a convenient feature for users to see ink levels, clean nozzles, see status, ... provided by HP and now users want to use it.
* keescook cries in the corner
<pitti> so it's at least not essential
<tkamppeter> pitti, so then I have two solutions:
<kylem> keescook, heh.
<pitti> we just cannot confine execution to group lpadmin *and* make it setgid lp
<tkamppeter> 1. (my preferred): lp.lp 660 permissions for /dev files and hpssd running SGID "lp"
<ubotu> Launchpad bug 660 in launchpad "Awful workflow for adding new email addresses." [Medium,Fix released]  https://launchpad.net/bugs/660
<tkamppeter> uboto, shut up!
<pitti> heh
<pitti> (and root:lp)
<Kmos> keescook: can you check bug 138819
<ubotu> Launchpad bug 138819 in wordpress "wordpress 2.2.3 is out: security release" [High,Confirmed]  https://launchpad.net/bugs/138819
<tkamppeter> 2. Say "Sorry, asking ink levels, cleaning nozzles, polling status, scanning with MF device are dangerous actions done by a normal user, they should be reserved to admins" to the reporter of bug 147369 and closing it with "Wontfix"
<ubotu> Launchpad bug 147369 in system-config-printer "MASTER: Printing via HPLIP does not work any more" [Undecided,Invalid]  https://launchpad.net/bugs/147369
<keescook> Kmos: sure, in a bit, I'm working on OOo and a few others at the moment.  Is there a merge diff in that bug?
<pitti> tkamppeter: I think for now it would be better to fix the .desktop file and run it through gksu; keescook, WDYT?
<pitti> and keep the device nodes as root:root or root:lp
<Kmos> keescook: nop.. but there is a backport request of it.. isn't better?
<Kmos> bug 141097
<ubotu> Launchpad bug 141097 in feisty-backports "Please backport wordpress from Gutsy" [Undecided,Incomplete]  https://launchpad.net/bugs/141097
<Kmos> for feisty
<cjwatson> backports are NOT a substitute for security updates
<keescook> Kmos: for gutsy, it should be okay.  for feisty, I'll leave that to someone else -- it's a lot of work.
<cjwatson> they will generally be rejected if that's their only purpose
<tkamppeter> pitti, this would mean that all HP GUI tools should ask for the privileged user password (and should be moved into "System"/"Admin" menu)?
<keescook> pitti: just so I understand, it's only a single app that needs root privs?
<tkamppeter> So this is 2. of my solutions?
<pitti> tkamppeter: I'm not happy with that solution, but fixing it properly is something that upstream should do
<pitti> keescook: it's the first time I hear about this either :/
<Kmos> cjwatson: in this case, it will bring new features and fix a lot of bugs (including security ones)
<Kmos> for feisty =)
<keescook> pitti: yeah, was reading the backlog...
<cjwatson> Kmos: then perhaps it should not be rejected, but it is still not a substitute for a security update. remember that many users legitimately do not have backports enabled (indeed, that's our default)
<tkamppeter> pitti, note that users are also not able to print according to bug 147369.
<Kmos> cjwatson: yeah.. i understand your point of view
<ubotu> Launchpad bug 147369 in system-config-printer "MASTER: Printing via HPLIP does not work any more" [Undecided,Invalid]  https://launchpad.net/bugs/147369
<cjwatson> Kmos: it is a policy statement, not a point of view :-)
<Kmos> cjwatson: yeah
<Kmos> today updates
<keescook> pitti: for that dev node, I'd say it's a toss-up for gksu vs setgid (lp) tool.  I too, lean towards the "ask for password" method.
<pitti> tkamppeter: that was the bug your upload was supposed to fix, right?
<pitti> tkamppeter: however, I don't understand this
<pitti> tkamppeter: isn't this run as a normal cupsys backend?
<pitti> tkamppeter: and, as such, as group 'lp' or 'root', depending on the backend permissions?
<pitti> neither of those modes requires world permissiosn
<Kmos> http://pastebin.com/d55e541a4
<Kmos> this is normal ?
<tkamppeter> pitti, I think the design problem of HP is that a call of hp-toolbox starts hpssd and then hpssd runs as the calling (unprivileged) user. hpssd stays running until a long timeout expires. So when the user printes afterwards CUPS will use the hpssd which was started by the user. And worse even if user A has triggered hpssd and afterwards user B accesses the device everything goes through user A's hpssd. So a very bad design by HP.
<cjwatson> Kmos: bug 146832
<ubotu> Launchpad bug 146832 in ubuntu-docs "ubuntu-docs: undefined "&rsquo;" in /usr/share/omf/windows/windows-C.omf" [Undecided,Fix committed]  https://launchpad.net/bugs/146832
<Kmos> cjwatson: thanks
<keescook> omfg.
<pitti> one would thing that the HP guys would know something about software design *sigh*
<mjg59> tkamppeter: What prevents someone launching their own hpssd and intercepting people's printing information?
<tkamppeter> So to get a little better security having hpssd running always as a non-root neutral user I suggest to set it SUID "lp" and SGID "lp".
<pitti> tkamppeter: then, since I guess you don't fancy rewriting this crack in a night, I think the 'run the tool through gksu' is the least evil thing
<keescook> besides hp-toolbox, what calls hpssd ?
<tkamppeter> pitti, then we take scanning away from normal users.
<pitti> first, samsung's printer driver makes openoffice setuid root; now hplip makes printers world-hackable; what next?
<keescook> lp: printer on fire.
<tkamppeter> keescook everything which accesses HP devices: Printing, Scanning, photo download, ...
<pitti> tkamppeter: well, that might be, but that's not something we can fix quickly
<pitti> tkamppeter: doesn't the cupsys backend spawn a hpssd, too?
<tkamppeter> pitti, thanks for that. I will iunform Samsung immediately about that security hole. Why are users switching from Windows to Linux?
<keescook> tkamppeter: I want to understand which tools would spawn hpssd (as the wrong user).  sounds like hp-toolbox and (I'm guessing) cupsd.  Are there others?
<pitti> tkamppeter: oh, that was a long time ago, and Samsung fixed it in the meantime
<pitti> tkamppeter: it just took a lot of bug ping pong to actually find that out :)
<pitti> keescook: since the cups backend runs either as root or lp, that one should be fine
<keescook> pitti: right, but are there others?
<tkamppeter> keescook, everything HPLIPish is spawning hpssd and the first caller wins, he is the owner of hpssd. Therefore I suggest running hpssd SUID "lp", so that no user can impose his personal rights onto it.
* pitti makes a clueless face
<pitti> hm, what about:
<pitti> tkamppeter: hm, when cupsys starts up, it won't start the backend, right?
<pitti> tkamppeter: what about starting hpssd in an init script then?
<pitti> argh, it'll time out, right?
<keescook> the reason for not making hpssd setgid lp is that it's an unaudit GUI tool that may give people "lp" group perms accidentally.  We're weighing this chance against the inconvience of prompting for a password.
<pitti> damn, this stuff is FUBAR
<calc> iwj: what is the main difference between the way you build and the buildds?
<tkamppeter> pitti, keescook, making hpssd SUID "lp" is no additional risk, as when a user prints it is run as "lp" anyway. So users are generally allowed triggering selected programs as "lp" and hpssd is already selected.
<keescook> tkamppeter: I don't know what tools are "HPLIPish", can you provide a list of the binaries?  so far it is cupsys, hp-toolbox.
<pitti> tkamppeter: with the difference that the user can control hpssd's invocation when he starts it directly
<iwj> calc: Err, I'm not sure there is a "main difference".  There are a few differences which occasionally cause trouble.
<tkamppeter> pitti, you are right, hpssd will time out and so starting it from an init script is no real protection.
<pitti> (i. e. set environment variables, pipe stuff into it, etc.)
<iwj> calc: The top one I suppose is that I don't do  debian/rules clean  first.
<iwj> calc: And the next one after that is that I'm a bit stricter about build-deps being unambiguous.
<pitti> tkamppeter: I think if we limit operation to lpadmins (i. e. the first user by default), it's not a too bad restriction for gutsy
<pitti> erm, I mean admins
<iwj> calc: Is this apropos of the oo.o build failure ?
<pitti> tkamppeter: and ask HP to fix their stuff
<tkamppeter> pitti, should we perhaps make an AppArmor profile for HPLIP, so that hpssd can only be started by HPLIP tools, CUPS, and SANE and not directly?
<calc> iwj: yea i am trying to determine why it would get forever on your build but not on the buildds
<iwj> calc: Other things that have caused trouble in the past include lack of a controlling tty and setting TMPDIR (would you believe some packages can't cope if you do).
<pitti> tkamppeter: that would be tricky, and not appropriate at this time of the release cycle
<mjg59> tkamppeter: The hplip tools run as the user? That wouldn't help.
<iwj> calc: Well, I think those millions of error messages might be related.
<pitti> apparmor can't rescue an inherently broken design
<norsetto> doko: you fixing gimp already?
<iwj> calc: You could diff a normal log and the autopkgtest-generated one.  Do you have a chinstrap a/c ?
<norsetto> doko: never mind, just saw the it, thx
<iwj> calc: doko said it ought not to have been trying to do that locale stuff on amd64 at all.
<calc> iwj: yes
<tkamppeter> mjg59, the HPLIP tools run really as the calling user. And making them SUID "lp" would be tricky, as files will be created with "lp" ownership. And users could reprint files from the print queues as their own jobs,
<mjg59> tkamppeter: Right, so that's not an option
<pitti> soren: still here?
<mjg59> tkamppeter: In any case, it wouldn't stop someone installing their own hpssd binary
<mjg59> If there's nothing to prevent a user-run hpssd binary from obtaining data from other users processess, we've already lost
<calc> iwj: i'll check it against a regular amd64 build and see what it shows
<pitti> soren: if I manually boot that encryption/lvm system, do update-initramfs -u, I get a valid conf/conf.d/cryptroot and a bootable system
<tkamppeter> pitti, I think HPLIP as current is a totally broken design. I will contact HP to fix it, perhaps even that they roll back to hpiod for security reasons.
<pitti> tkamppeter: they should have a permanently running small daemon which spawns the heavy programs on demand
<mjg59> tkamppeter: When did the design become this broken?
<pitti> tkamppeter: thanks
<tkamppeter> mjg59, with 2.7.7, HP's second generation of HPLIP.
<doko> iwj: not exactly, we don't build binary-indep on amd64
<mjg59> tkamppeter: Date-wise?
<iwj> doko: OIC.  Maybe that's what's broken.
<iwj> doko: That is, I do   debian/rules binary
<tkamppeter> mjg59, July 2007. The version numbers are generation.year.month.
<tkamppeter> pitti, mjg59 restricting HPLIP tools to privileged users wouls also mean that unpriv ileged users cannot scan on HP's MF devices.
<calc> iwj: yea localize isn't called at all on regular amd64 build on buildds
<mjg59> tkamppeter: Ok, which was uploaded in August. Hm. Shame we didn't notice the regressions then.
<mjg59> tkamppeter: Well, the alternative is security nightmare, so.
<pitti> tkamppeter: right, but I don't see any other solution ATM
<tkamppeter> And rolling back to 1.x.x would reintroduce tons of bugs.
<iwj> calc: And presumably on i386 it doesn't break.
<keescook> yay, arbitrary command execution as user running hpssd via network message handling and email delivery.  this is really bad code.
<mjg59> keescook: Oh, sweet.
<calc> iwj: yea it works everywhere when done via buildd (i guess i386 then) i should verify it was calling localize on the i386 buildd build
<mjg59> keescook: So, basically, we can't run hpssd ever?
<tkamppeter> So the best solution would even be remove HPLIP from the distro, mark all HPs "Paperweight" on OpenPrinting and tell that they are a big security hole ...
<keescook> well, perhaps this particular vuln could be fixed -- use subprocess instead of popen
<iwj> calc: I hope you agree that it ought to work when you do binary-indep on amd64.
<keescook> tkamppeter: I'd sure not like to do that -- there are a lot of HPs.
<mjg59> keescook: You have any faith in there not being others?
<keescook> mjg59: not really.  :)
<mjg59> tkamppeter: The alternative would be to roll back to 1.7.3
<sladen> mjg59: can you review  http://www.paul.sladen.org/ubuntu/upload/26-addon-acpi-fix-free-before-init.diff
<pitti> well, not sure if anyone ever reviewed that...
<keescook> mjg59: sure that version isn't vuln too?
<calc> iwj: yea it works on i386
<sladen> mjg59: that fixes hal;  gnome-power-manager is still broken
<calc> iwj: well it could be very well that it is completely broken on 64bit platform or something like that, sun doesn't support amd64 at all for OOo aiui, but I will look into why it doesn't work
<mjg59> sladen: You've got a potential use-after-free
<tkamppeter> keescook, mjg59, pitti, can you report all security holes in HPLIP as bugs on Launchpad, then I will CC these bugs to the HPLIP people so that they can redesign their concept?
<sladen> mjg59: where
<mjg59>  if (libhal_device_rescan (ctx, udi, &error)) {
<mjg59> +					if (dbus_error_is_set (&error)) {
<mjg59> +						dbus_error_free (&error);
<mjg59> +					}
<mjg59> Then you use error again immediately afterwards
<sladen> mjg59: read the comment at the end
<keescook> (at least it's only listening to localhost)
<mjg59> Oh, ok
<mjg59> Yeah, looks fine
<pitti> keescook: do you write your's about the popen? I'll write one about the daemon invocation
<tkamppeter> So pitti, mjg59, keescook, then the solution would be:
<mjg59> sladen: Upload that?
<keescook> pitti: yup, sounds good.
<keescook> pitti: btw, apparmor doesn't block this since the backend is run Ux
<pitti> right
<tkamppeter> 1. Leave the permissions as they are now: root.lp )or lp.lp) 0660
<sladen> gah, how do I get rid of the docbook churn
<keescook> do other distros ship hplip?
<tkamppeter> keescook: Every distro ships HPLIP
<tkamppeter> We should put up some
<tkamppeter> global security alert
<keescook> tkamppeter: okay, so I'll have to get a CVE for this as soon as I 'prove' to myself that it's real.
<mjg59> sladen: g-p-m won't work properly if hal is restarted underneath it, as far as I can tell
<tkamppeter> Back to my HPLIP solution:
<tkamppeter> Make hpssd root.lp 770, so that only members of the "lp" group can start it
<ubotu> Launchpad bug 770 in cryptsetup "Ask password twice on init" [Medium,Invalid]  https://launchpad.net/bugs/770
<tkamppeter> ubotu, you have a bug
<ubotu> Sorry, I don't know anything about you have a bug - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
<sladen> mjg59: mostly it crashes
<tkamppeter> or better 3. Make all hplip tools root.lp 0770, so that only privileged users can run them.
<ubotu> Launchpad bug 770 in cryptsetup "Ask password twice on init" [Medium,Invalid]  https://launchpad.net/bugs/770
<tkamppeter> 4. How do we tell unprivileged users clearly that due to a big security hole they are not allowed to do other things than plain printing on HP devices?
<pitti> tkamppeter, keescook: WDYT about bug 149045?
<ubotu> Launchpad bug 149045 in hplip "needs a proper daemon or cupsys integration" [Undecided,New]  https://launchpad.net/bugs/149045
<pitti> tkamppeter: root:lp programs are not for user invocation; no user should *ever* be in "lp"
<tkamppeter> pitti, so then the solution is that any access toi HP devices should be made root-only
<keescook> reads well; perhaps explicitly mention the 0777 dev nodes?
<keescook> pitti: ^^ (re: bug report)
<pitti> keescook: I did actually
<keescook> ah! sorry, yes, first bullet
<tkamppeter> pitti, for scanning one could perhaps run a saned SUID root and let users access the scanners in the HP devices by this saned.
<pitti> tkamppeter: right; if the desktop files are correct (X-KDE-SubstituteUID=true) then they will only appear for admins who can run them
<pitti> I'm afraid I know too little about the HP tools to give good advice how to fix them for scanning
<tkamppeter> pitti, this works also in GNOME?
<pitti> tkamppeter: yeah, it does; KDE had it first, so we adapted it
<pitti> adopted, even
<tkamppeter> pitti, mjg59, keescook: Anyone of you has a standalone scanner (no HP MF device)? How can normal users use suchg a scanner. SANE is completely running as the calling user, so it is completely insane.
<tkamppeter> And SANE does not use daemons at all.
<pitti> tkamppeter: scanner devices are root:scanner 0660
<tkamppeter> pitti, and all users are in the "scanner" group?
<pitti> the default user anyway
<pitti> and new ones created by users-admin with the 'desktop' profile
<tkamppeter> pitti, so we have the same security problem there.
<pitti> tkamppeter: not quite; it does not launch any daemons other users would share, and it does not require world-readable/writable device nodes
<tkamppeter> pitti, WDYT about making bug 147369 a duplicate of bug 149045?
<ubotu> Launchpad bug 147369 in system-config-printer "MASTER: Printing via HPLIP does not work any more" [Undecided,Invalid]  https://launchpad.net/bugs/147369
<ubotu> Launchpad bug 149045 in hplip "needs a proper daemon or cupsys integration" [High,Confirmed]  https://launchpad.net/bugs/149045
<pitti> tkamppeter: not sure; can admins/lpadmins use HP printers ATM? if no, then it's not a dup
<pitti> tkamppeter: we can hack hplip to fix (ish) 147369 while we cannot fix the root cause
<tkamppeter> pitti, admins/lpadmins can do everything with HP devices.
<keescook> hah, the sendmail arguments are wrong -- email notifications don't even work when NOT abused.
<pitti> tkamppeter: oh, if that already works, then fine; how are the dev permissions right now?
<tkamppeter> pitti, I can try to quickly find out whether hpssd really times out. If not, we run it by a startup script and give it permissions root.lp (or lp.lp) 0770 and we run it as the user "lp".
<tkamppeter> pitti, then all users will be able to scan.
<pitti> tkamppeter: lp.lp would be much better
<pitti> tkamppeter: 774, btw
<tkamppeter> And if it times out, disabling the timeout is probably a tiny unharmful patch (which I could perhaps even get quickly from HP).
<tkamppeter> pitti, why 774?
* pitti hugs doko for all the downsizing
<pitti> tkamppeter: no reason to make it unreadable; the binary itself is not a secret
<pitti> tkamppeter: 754, of course
<pitti> group-writeable would be wrong :)
<tkamppeter> pitti, yes, then normal users can security-audit it, then several users will feel much better using HPLIP.
<pitti> it's more a question of being able to run md5sums, etc.
<tkamppeter> pitti, you are right, 754.
<tkamppeter> pitti, so then let the solution be:
<tkamppeter> 1. Patch the timeout out of hpssd if it has one
<tkamppeter> 2. Make hpssd lp.lp 0754
<ubotu> Bug 754 on http://launchpad.net/bugs/754 is private
<tkamppeter> 3. Leave the UDEV rules as they are: root.lp 0660
<ubotu> Launchpad bug 660 in launchpad "Awful workflow for adding new email addresses." [Medium,Fix released]  https://launchpad.net/bugs/660
<tkamppeter> 4. Let hpssd be started by an init script to keep it permanently running as user lp
<pitti> tkamppeter: but then no user could run hpssd any more
<pitti> ah
<pitti> tkamppeter: with 4., 2. is not necessary
<pitti> tkamppeter: the binary should be a normal root:root 0755
<pitti> tkamppeter: and start-stop-daemon starts it as user lp
<tkamppeter> pitti, 2. is still needed as a user could start a second instance of hpssd by hand.
<pitti> tkamppeter: and 5. work with keescook to get the popen call fixed
<pitti> tkamppeter: no, they can't
<pitti> tkamppeter: they cannot access the device
<pitti> tkamppeter: 754 is *not* suitable for preventing anyone from running an executable
<pitti> tkamppeter: after all, you can copy it to somewhere else and run it from there
<pitti> tkamppeter: only 4754 and 2754 makes sense (s[ug] id)
<pitti> tkamppeter: (sorry, I misunderstood you earlier)
<tkamppeter> pitti, you are right, so 2. is really not needed. The solution is 1, 3, 4 from above.
<pitti> tkamppeter: right, and 5 :)
<pitti> tkamppeter: I'm fine with that
<pitti> tkamppeter: does the daemon continue to run if the device does not exist at all?
<tkamppeter> pitti, is 5 really immediately needed if access to the device is restricted?
<lamont> https://edge.launchpad.net/ubuntu/gutsy/+source/lsb/3.1-23.1ubuntu2
<pitti> tkamppeter: yes, since the problem with popen() is not the device permissions, but that the daemon does not sanitize its input
* lamont grumbles at the .tar.gz with the debian version
<pitti> tkamppeter: i. e. any user or malware sending stuff to the running hpssd could 0wn your printers, since they can run stuff as user/group 'lp'
<tkamppeter> pitti, I do not know whether hpssd will stop on unplugging the device. Also it must be assured that an hpssd gets started on plugging the device.
<pitti> tkamppeter: it could make sense to start the daemon from an udev rule?
<pitti> tkamppeter: anyway, that's just an efficiency thing
<tkamppeter> pitti, Donald Welch from HP has answered to bug 149045.
<ubotu> Launchpad bug 149045 in hplip "needs a proper daemon or cupsys integration" [High,Confirmed]  https://launchpad.net/bugs/149045
<pitti> tkamppeter: it would be nice if people who do not have HPs wouldn't have the daemon running
<tkamppeter> pitti, for USB devices this would be perfect, for parallel and network devices one must find what is the best solution.
<pitti> hm, so hpssd does *not* do the device access?
<tkamppeter> pitti, Donald says that the libmud library is accessing the devices and this one is directly linked to the user tools which would mean that the access is done with the user's privileges.
<pitti> bummer
<tkamppeter> pitti, so perhaps we should make the devices belong to the "scanner" group and let the CUPS backend run SGID scanner?
<pitti> tkamppeter: no setgidness, please
<pitti> tkamppeter: ideally we would make the device nodes accessible to both scanner and lpadmin
<dexem> if i would want to announce a new app for ubuntu, where should I sent an introductory email?
<pitti> erm, scanner and lp, I mean
<tkamppeter> Or then make the user "lp" member of "scanner"?
<pitti> tkamppeter: so, lp:scanner should work
<pitti> tkamppeter: does the cupsys backend run as root or lp? i. e. is it 700 or 755?
<tkamppeter> till@till-laptop:~/ubuntu/hplip$ ls -l /usr/lib/cups/backend/hp*
<tkamppeter> -rwxr-xr-x 1 root root 8388 2007-10-04 15:39 /usr/lib/cups/backend/hp
<tkamppeter> -rwxr-xr-x 1 root root 7919 2007-10-04 15:36 /usr/lib/cups/backend/hpfax
<tkamppeter> till@till-laptop:~/ubuntu/hplip$
<tkamppeter> The cupsys backend seems ro run as "lp"
<pitti> tkamppeter: so, having the device node be lp:lpadmin should fix it for lpadmins
<pitti> tkamppeter: which is usually not every user, but at least the default one
<tkamppeter> So at least the user "lp" and also all members of "scanner" would need access.
<pitti> right, that's better
<pitti> lp:scanner
<tkamppeter> pitti, let me try ...
<pitti> anyway, I need to leave
<pitti> tkamppeter: can we continue this tomorrow if lp:scanner does not work?
<pitti> tkamppeter: we should continue discussion on the bug report
<tkamppeter> pitti, yes, see you tomorrow.
<tkamppeter> pitti, on which of the two?
<pitti> tkamppeter: I added that comment to bug 147369
<ubotu> Launchpad bug 147369 in system-config-printer "MASTER: Printing via HPLIP does not work any more" [Undecided,Invalid]  https://launchpad.net/bugs/147369
* pitti waves
<mekius> bryce: ping
<iwj> calc: Thanks.  I'm nominally on holiday tomorrow but if you need to ask me questions email me and I may well check my mail mid-afternoon UK time tomorrow.
<dexem> I would like to announce a soon v1.0 release of this  --> https://forge.vodafonebetavine.net/frs/?group_id=12  which list should be the best for it?
<bryce> hi mekius
<rulus> Hi, can anyone tell me what's the difference between in effect between System > Preference > Screen resolution and System > Administration > Screens & Graphics, and why we still need the first one? Setting up your screen resolution in two places seems very confusing to me..
<mekius> bryce: hey, we have some via hardware that we are installing a customized ubuntu distribution on.  We have some drivers that we are loading onto the CD for their video, what is the best way to autodetect a VIA video card and setup X to use this instead of just VESA.  We would hard code it, but we plan on distributing the CD via the internet as well.
<gnomefreak> rulus: for support see #ubuntu+1
<rulus> ok
<bryce> mekius: the best thing is to key it off the pci id
<bryce> mekius: generally we've done this via the discover-data package
<bryce> mekius, it has an xml file listing video card pci id's and indicating the driver to use with them
<mekius> bryce: oh ok, that will be pretty easy to setup then
<bryce> yup
<mantiena-baltix> rulus, problem is, that Screens & Graphics is still very buggy, also it crashes a lot :(
<mekius> bryce: so do you think we should roll our own version of this package then?
<bryce> mekius: sure, that'd give you the most control.  And then if you give me the changes, I'll roll them into the official package
<Kmos> bug 132221
<ubotu> Launchpad bug 132221 in ubuntu-dev-tools "requestsync: Add latest debian version to the title of the bug" [Wishlist,Fix committed]  https://launchpad.net/bugs/132221
<Kmos> if someone wants to comment it out
<mekius> bryce: ok, only issue with that is that this is an inside driver atm so it needs some testing, it is essentially an updated version of VIAs official driver
<bryce> mekius: the xml file is pci-device.xml.  I think it's fairly self-explanatory
<mekius> bryce: so eventually they will probably release it
<bryce> mekius: the one other thing to do is run `make pci-26.lst pci.lst`, which uses the xml to update those lists
<mekius> ah ok
<bryce> ok no prob; let me know the changes once it is released
<mekius> i think for now we can just modify in place for testing :)
<bryce> cool
<mekius> oh, that's interesting, discover-data was not installed heh
<bryce> mekius, there is a second approach I'll give you as an alternate
<mekius> that might be a start :)
<bryce> dexconf is the tool that generates the xorg.conf for systems
<bryce> there is a spot in that code that looks up the driver to use from the debconf database
<bryce> you can insert an override at that point
<bryce> this alternate approach is rather hacky, but if you're doing something really chipset specific or just doing testing, it might be of use
<mekius> yeah
<mekius> is the debconf database editable?
<bryce> for instance, if you need to customize the xorg.conf beyond just setting the driver (e.g. flipping on various options specific to the device, etc.)
<MacSlow> mvo, I've fixed the issue seb128 mentioned... regarding the sensitivity (icon, label) of the effect-level entries in the visual-effects-tab of gnome-appearance-manager... but the problem with #145059 I've not located yet.
<evand> mekius: debconf-communicate
<mekius> evand: thx
<MacSlow> mvo, I would guess better wait with asking you or seb128 for uploading it until that RC-critical bug is fixed, right?
<sladen> mjg59: GetBrightness, UINT or INT this week?
<mekius> bryce: i might try updating the debconf database if it proves to be simple enough
* bryce nods
<mekius> bryce: as then in the future if we need to set options we will already be on the right track
<bryce> sounds good
<MacSlow> mvo, actually I would like to get #145020 done with the next update to gnome-control-center too
<mekius> bryce: thx for the help, i figured it was just some conf files of some sort but couldn't find any info online
<sladen> mjg59: g_value_set_int: assertion `G_VALUE_HOLDS_INT (value)' failed  etc
<bryce> no prob; good luck!
<mekius> thx
<mekius> evand: any elaboration on using debconf-communicate or something besides the man page for documentation?
<mekius> ah ok
<mekius> so i need to talk to it with the debconf protocol
<evand> echo GET console-setup/charmap | debconf-communicate
<evand> yes
<mekius> looks like i have some digging to do :)
<Whoopie> sladen: I made a patch for the UINT/INT issue:http://en.pastebin.ca/725879
<Whoopie> it was in one or two gnome bug reports
<sladen> Whoopie: rock;  there's more instances though;   there's the ones already in  debian/patches/73*.patch
<sladen> Whoopie: and then also in the brightness applet
<sladen> Whoopie: what's the background to it?
<Whoopie> sladen: this patch adds more instances then in 73*
<sladen> indeed;  and there's yet more on top of those
<Whoopie> sladen: ups, ok
<Whoopie> sladen: what do you mean by background?
<sladen> Whoopie: what's the upstream bug report that details all this churn
<sladen> Whoopie: how many other functions does it affect?
<sladen> Whoopie: do any of those fix the on-ac/on-battery handling?
<Whoopie> sladen: gnome bug 469748
<ubotu> Gnome bug 469748 in general "Brightness keys fail to set backlight brightness correctly" [Normal,Unconfirmed]  http://bugzilla.gnome.org/show_bug.cgi?id=469748
<Whoopie> sladen: hmm, I don't have problems with on-ac/on-battery. could you explain more?
<sladen> Whoopie: the on-battery brightness slider does not work
<mjg59> sladen: It works fine here.
<Whoopie> sladen: aha, works here
<mjg59> Ah. It seems potentially confused by "Dim on idle"
<Whoopie> sladen: just annoying DSDT bug with my Samsung P35 which generates an ACPI event event when I change the brightness through sysfs
<mjg59> Strongly tempted to just disable that. It's not going to get fixed in tiem.
<sladen> mjg59: and how did you disable Fn-Home/Fn-End from twiddling the hardware?
<mjg59> I didn't
<sladen> mjg59: I want to revert aswell
<mjg59> No
<sladen> what's stopping that;  xorg?
<mjg59> (a) It's in-kernel, so too late
<sladen> ffs.
<mjg59> (b) It breaks shit
<sladen> what this hard coded it can it be disabled with some module parameters
<mjg59> (c) You can poke it via /sys/module/video/parameters/no_automatic_changes
<mjg59> The default isn't changing. There's no way to make it work.
<sladen> I'd rather deal with the corner cases than have completely non-functioning brightness
<mjg59> You just need a daemon that listens for you
<mjg59> But no, we are not doing this in-kernel
<mjg59> It results in everything getting out of sync in horrific ways
<sladen> I don't want anything done in-kernel
<sladen> it worked great as it was
<mjg59> It was done in-kernel
<sladen> for the last 5 years it was done in kernel?
<mjg59> No, on most machines it was done in hardware
<sladen> even without any thinkgpad modules loaded... ?!
<mjg59> Yes
<mjg59> The Thinkpad driver never did it
<mjg59> video.ko did
<sladen> so what's the change that went in in the last fortnight that "broke" it
<mjg59> I removed the in-kernel policy
<mjg59> Because it was impossible to make it work right
<slangasek> bug #121566: is this really a reproducible problem with NM on upgrades from feisty to gutsy?  that seems unlikely, with only three follow-ups...
<ubotu> Launchpad bug 121566 in network-manager "no network with dhcp set up" [Critical,Confirmed]  https://launchpad.net/bugs/121566
<sladen> this is the innocent "alter default behaviour of ACPI video module" ?
<mjg59> Yes
<pwnguin> neat. cupsys is broked
<pwnguin> bug 149117
<ubotu> Launchpad bug 149117 in cupsys "cupsys fails to install" [Undecided,New]  https://launchpad.net/bugs/149117
<lamont> Setting up passwd (1:4.0.18.1-9) ...
<lamont> no matching password file entry in /etc/shadow
<lamont> add user 'root' in /etc/shadow? no matching password file entry in /etc/shadow
<lamont> add user 'daemon' in /etc/shadow? no matching password file entry in /etc/shadow
<lamont> add user 'bin' in /etc/shadow? no matching password file entry in /etc/shadow
<lamont> add user 'sys' in /etc/shadow? no matching password file entry in /etc/shadow
* lamont kicks passwd in the head
<slangasek> asac: as the NM scapegoat, do you have any thoughts on #121566? :)  is the syslog provided there sufficient to reproduce/debug this?
<asac> bug 121566
<ubotu> Launchpad bug 121566 in network-manager "no network with dhcp set up" [Critical,Confirmed]  https://launchpad.net/bugs/121566
<slangasek> lamont: what did you do to make it hate you? :)
<lamont> the chroot had a shadow file with just the user 'lamont' in it.  and passwd decided it'd be better to fail to install than to let someone have a bogus shadow file on their machine
<asac> slangasek: i will triage it ... but i don't think its critical
<slangasek> asac: sure, three reports of NM failing in 4 months isn't a lot :)
<asac> slangasek: lets keep it for rc, until i received the answers
<leh> has anybody of you recently experience problems with firefox on gutsy? i can't do "submits" anymore which is really strange :-)
<asac> slangasek: i assign it to me now
<leh>  i'd love to report this bug, but can't login to launchpad *g*
<lamont> leh: use lynx
<lamont> to file the bug, that is.
<pwnguin> or a second computer ;)
<lamont> :-)
<lamont> pwnguin: that'd be cheating
<pwnguin> does lp work with lynx?
<norsetto> leh: I'd check first in https://answers.launchpad.net/
* pwnguin 's irony detector explodes
<leh> norsetto: thx alot ;-)
<leh> ok, but i'll guess your ff is still working ok
<pwnguin> for the moment
<pwnguin> leh did you install firefox3 by chance?
<mdke> doko: yes, I got it
<gnomefreak> crimsun: can you ping me when you get time i need a code-dev to sponser flash backport from gutsy to dapper to fix md5sum, figured might as well upgrade it to latest stable. bug 147688 is the bug on it
<ubotu> Launchpad bug 147688 in flashplugin-nonfree "wrong md5sum" [Undecided,In progress]  https://launchpad.net/bugs/147688
<mvo> MacSlow: either way should be fine (uploading now to get testing or waiting for the other issue if that gets done reasonsable quick)
<nicolai__> gn8
<MacSlow> mvo, I think I can get the pending issues done tomorrow
#ubuntu-devel 2007-10-05
<mneptok> looks like cupsys_1.3.2-1ubuntu4_i386.deb is corrupted, at least on US mirrors
<Kmos> bug 149188
<ubotu> Launchpad bug 149188 in cupsys "[GUTSY BETA]  error when updating cupsys" [Undecided,New]  https://launchpad.net/bugs/149188
<mneptok> that's the one
<slangasek> not corrupted, just good and broken
<lamont> slangasek: semnatics
<gnomefreak> the cupsys error is on gb mirror as well
<mneptok> gnomefreak: looks like a patch has been pushed. testing now.
<gnomefreak> mneptok: ah ok im fixing mine locally like i have done all day
<gnomefreak> something is wrong this is 2nd or 3rd packages to do this today
<slangasek> mneptok: pushed where?
<mneptok> slangasek: to us.arch.
* gnomefreak wonders if its not a buildd causing this
<gnomefreak> mneptok: it cant be us mirrors
<gnomefreak> mneptok: than i wouldnt see it
<mneptok> and no, package is still b0rked in the us repos
<slangasek> mneptok: er, it most certainly hasn't, 1ubuntu4 is still the current version of the cupsys package in gutsy and the bug report is still open
<gnomefreak> mneptok: i am blaming buildds becasue this isnt the 1st one today so if they were built on same on and it corrupted the binaries there is your error
<slangasek> gnomefreak: no, it's not a buildd bug.
<slangasek> it's a "sloppy last-minute changes to package contents to try to reduce package sizes, upload without testing and disappear into the European night" bug
<mneptok> slangasek: your PDT is showing ;)
<gnomefreak> slangasek: for 3 of them?
<gnomefreak> eh maybe gimp and cupsys i thought a 3rd but maybe not
<slangasek> 3 of what?  I'm only talking about cupsys, I haven't heard about any other packages with this problem.
<cjwatson> gnomefreak: a series of uploads were made to reduce package size, in a manner which could cause this problem if got slightly wrong.
<gnomefreak> cjwatson: ah ok just seemed too easy to be single uploads
<cjwatson> gnomefreak: you can try to blame buildds but you will usually be wrong. :-)
<cjwatson> likewise, mirrors never cause this kind of corruption
<cjwatson> s/corruption/breakage/
<cjwatson> slangasek: are you working on a cupsys fix or should I?
<cjwatson> since I appear to be awake
<slangasek> cjwatson: probably quicker for you to do it, I'm still not clear what the intentions were given the mismatch between what was uploaded and what was discussed in mail
<cjwatson> gnomefreak: also, you should never blame buildds in the *first* instance because such a diagnosis means it can't be fixed in the package
<gnomefreak> true
<gnomefreak> ok gimp is still failing here
<cjwatson> gnomefreak: I don't see a bug report on gimp
<cjwatson> urgh, I don't think doko looked at this rules file before editing it
<gnomefreak> gimp broke earlier today i over-wrote deb now its failing again so im gonna assume it was --force-overwite that caused the fixed version to fail
<gnomefreak> but it broke in the last batch i got
<cjwatson> if you're on #ubuntu-devel, you should never use --force-overwrite without ensuring that a bug report is filed
<cjwatson> bug 148985
<ubotu> Launchpad bug 148985 in gimp "package gimp 2.4.0~rc3-1ubuntu4 failed to install/upgrade: trying to overwrite `/usr/share/doc/libgimp2.0/README', which is also in package libgimp2.0" [Medium,Fix released]  https://launchpad.net/bugs/148985
<gnomefreak> bug report was filied early today
<gnomefreak> they were marking dupes when i ran into issue
<cjwatson> it would have saved me time if you'd mentioned that here, then, rather than making me go look
<gnomefreak> sorry i didnt have bug number
<cjwatson> or mentioned that there was a bug at all
<cjwatson> sigh. whatever. I'll go finish fixing cupsys
<gnomefreak> point taken
<cjwatson> gnomefreak: yes, if you --force-overwrite and name the wrong package, chances are you'll have to --force-overwrite again to put it back
<cjwatson> I'll put a Replaces in libcupsys2 because I'm feeling nice
<gnomefreak> cjwatson: ty
<cjwatson> I don't think it's really obligatory to dig people out of that hole they dug themselves though :)
<gnomefreak> mneptok: i would do it before it happend
* mode/#ubuntu-devel [+o mneptok]  by ChanServ
* mode/#ubuntu-devel [+b *!*@AMarigot-102-1-9-150.w80-8.abo.wanadoo.fr]  by mneptok
<gnomefreak> cjwatson: i can fix it but ty for feeling nice
* mode/#ubuntu-devel [-o mneptok]  by mneptok
<jdong> mneptok: preventative, nice
* mneptok bows
<jdong> mneptok: gonna grab -motu? :)
* gnomefreak was just asking that
<mneptok> no access. i'll get Hobbsee to add me when she awakens.
<cjwatson> gnomefreak: it's been advised to everyone subscribed to the enormous pile of bug reports ...
<gnomefreak> ok ty
<Hobbsee> sladen: ping
<slangasek> soren: linux64... a... no-op on 32-bit? <twith>
<slangasek> <twitch>
<cjwatson> yeah, it's, er, a bit odd
<lamont> slangasek: "linux64" == "make my personality my native one.  kthxbye"
<slangasek> lamont: <twitch>
<lamont> it's not a no-op.  it changes your personality back to the native one... the fact that you didn't change it to something else beforehand is the strange part....
<slangasek> right... :)
<lamont> I didn't write it, I just accidentally hijacked it.
<lamont> it was maybe an unfortunate choice of name... but remember that the author was kinda focused on 64-bit architectures
<lamont>         PER_LINUX =             0x0000,
<lamont>         PER_LINUX_32BIT =       0x0000 | ADDR_LIMIT_32BIT,
<lamont> including in the kernel...
<slangasek> right
<lamont> and you'd give us different crap if we called the command /usr/bin/linux :)
<slangasek> pff, why couldn't it be sane like prctl
<lamont> if it helps, linux32's links were the final straw that convinced me it was time to move util-linux to debhelper
<lamont> and thereby make the Makefile readable again
<slangasek> heh
<slangasek> oh, hah, there is a generic "setarch" that it's a symlink to?  well, that's a bit saner
<cjwatson> well, the Debian bug has the appropriate variant of the patch now
<lamont> slangasek: setarch $arch options
<lamont> or $arch options
<lamont> slangasek: so what brought the subject up, anyway
<lamont> ?
<slangasek> lamont: the mbr ftbfs
<lamont> oh, right
<lamont> I also get an 'i386' symlink. :)
<cdm10> Hi, is there any known issue with Samba on Gutsy?
<slangasek> I want a "sparc32" symlink on amd64
<slangasek> cdm10: https://bugs.launchpad.net/ubuntu/+source/samba will show you any number of known bugs; would you care to be more specific?
<lamont> slangasek: submit a patch.
<cdm10> slangasek: Thanks, I didn't know where to look.
<lamont> the biggest samba bug is that it talks to windoze?
<bddebian> haha
<slangasek> lamont: there's a setting you can use to work around that
<slangasek> tkamppeter: so is bug #99372 something you're working on, or should I try to find a kubuntu person to take it on?
<ubotu> Launchpad bug 99372 in kdebase "MASTER: [Feisty]  KDE Printing Manager does not list the PPDs of Gutenprint" [High,Confirmed]  https://launchpad.net/bugs/99372
<Hobbsee> oh yay, cimmo's commented on that bug.
<slangasek> Hobbsee: ?
<Hobbsee> slangasek: sorry, you must have missed my sarcasm there.
<slangasek> I just have no idea who cimmo is
<Hobbsee> slangasek: (cimmo thinks that there are infinite developers, and that the reason all bugs arent dealt with immediately is because people are lazy)
<bddebian> Hobbsee: Yeah, get ta work ya bum ;-)
<Hobbsee> bddebian: now you get going on that universe queue, else you'll get poked with teh Long Pointy Stick of DOOM!!!!!!!!!!!!!!! 
* bddebian hides
<mpt> Hobbsee, in the old days the bugzilla.mozilla.org approach to those sort of people was to assign the bug to them
<Hobbsee> mpt: true that.  which people object to, for some reason :P
* Hobbsee --> uni
<mekius> http://pastebin.com/mb63fed2 <--known?
<gnomefreak> mekius: yes known
<gnomefreak> mekius: bug 149188
<ubotu> Launchpad bug 149188 in cupsys "[GUTSY BETA]  error when updating cupsys (dup-of: 149106)" [Undecided,Confirmed]  https://launchpad.net/bugs/149188
<ubotu> Launchpad bug 149106 in cupsys "package cupsys 1.3.2-1ubuntu4 failed to install/upgrade: trying to overwrite `/usr/share/doc/libcupsys2/CREDITS.txt', which is also in package libcupsys2" [High,Fix released]  https://launchpad.net/bugs/149106
<mekius> gnomefreak: thx
<gnomefreak> np
<mekius> working on a custom live cd, not a fan of debian based systems personally heh
<gnomefreak> freeze is today isnt it?
<mekius> custom ubuntu live cd that is
<mekius> no clue heh
<mekius> if it is that is good cause we've been running into packaging issues daily :/
<gnomefreak> i was thinking about trying to make a livecd
<mekius> guess that is what we get for basing on gutsy heh
<gnomefreak> i havent seen anywhere near the problems we had in dapper edgy and feisty, in gutsy to date
<mekius> that's good to hear :)
<mekius> it hasn't been too bad
<mekius> just in the last couple days
<mekius> maybe the rush to get packages in before freeze :)
<Mithrandir> asac: is it known that firefox seems unhappy if you change themes while it's running?
<mekius> Mithrandir: usually not too unhappy for me
<Mithrandir> mekius: I see it on both amd64 and i386 here
<mekius> don't use gnome though so that might be it
<mekius> what do you mean by unhappy?
<frostburn> anthropomorphized browsers, it's all the rage
<pitti> Good morning
<slangasek> morning
<pitti> hi slangasek
<mvo> hey pitti
<Mithrandir> locks up for a long time.
<StevenK> pitti: Do you have a moment? I've discussed the promotion list with Mithrandir, and I'd like you to take another look if you have time?
<pitti> StevenK: yeah, can do
<StevenK> pitti: http://wedontsleep.org/~steven/big-promotion
<StevenK> pitti: That list is the more important stuff for -mobile, with two simple apps
<pitti> StevenK: no frozen-bubble any more? :(
* StevenK chuckles
<StevenK> It'll come up, it's just not first.
<pitti> StevenK: this list looks absolutely appropriate to me
<StevenK> pitti: Okay, shall I sign it and submit it as a bug?
<StevenK> pitti: Or do you really want me to re-add frozen-bubble? :-)
<pitti> StevenK: pull the trigger
<Mithrandir> pitti: we figured that starting with a smaller list of less controversial items would be easier.
<pitti> StevenK: it needs some quite large dependencies, so maybe not for the initial rush
<Mithrandir> pitti: as for l10/i18n, that's something we want to discuss at UDS.
<StevenK> pitti: *nods* Understood
* StevenK hands Mithrandir the missing 'n' in l10n
<pitti> Mithrandir: is there a chance to avoid one of the two mozilla copies (xulrunner) and clamav?
<pitti> Mithrandir: i18n> yeah, good opportunity; I'm interested to learn how it works ATM, then I'm sure we can figure something out
<Mithrandir> pitti: yes, xulrunner will be going, and I'm not completely convinced of claws yet, so those can wait.
<StevenK> claws looks like a pig to me
<pitti> Mithrandir: oh, and sendmail? Is that just a wrong prefered dependency or so?
<StevenK> pitti: sendmail is due to clamav Build-Depend'ing on libmilter-dev
<pitti> Mithrandir: I just thought that if the devices we are talking about can digest firefox/midbrowser, then thunderbird shouldn't be too big either?
<Mithrandir> pitti: sendmail is a build-dep for clamav which has a milter plugin.
<pitti> eww
<Mithrandir> well, libmilter-dev is a build-dep
<Mithrandir> and comes from sendmail
<pitti> well, since clamav itself is pretty much a no-go for main, it doesn't matter that much
<Mithrandir> as for thunderbird, that's an option, but it haven't been hildonised by anybody TTBOMK.
<Mithrandir> StevenK: claws isn't hildonised in current lpia due to a bug; Adilson is working on fixing that.
<StevenK> How do I stop vim indenting stuff when I paste it in? It's very irritating.
* StevenK gets off the phone to his sister, after describing what an Ethernet cable is used for.
<StevenK> I was quite tempted to say, "I will use it to choke you."
<bryce> hehe
<Mithrandir> StevenK: :set paste
<StevenK> Hrm. I was trying :set noai
<pitti> StevenK: configure a pastetoggle key
<pitti> set pastetoggle=<F9>
<pitti> StevenK: ^ in your .vimrc
<pitti> StevenK: then I usually do F9 - middle click - F9
<StevenK> I like it.
<StevenK> pitti, Mithrandir: Bug 149275
<ubotu> Launchpad bug 149275 in tasks "First cut of source packages for -mobile promotions" [Undecided,New]  https://launchpad.net/bugs/149275
<pitti> ah, thanks
<pitti> I'll talk to iwj to coordinate and share the review
<StevenK> pitti: Thanks
<StevenK> The dropdown lists at the top look impressive
<pitti> "frightening" was what came to my mind
* StevenK grins
<kagou> Good morning
<calc> is it known that totem isn't descriptive on what it needs to play dvd's, iirc it is for other media types
<calc> i installed libdvdcss2 and it doesn't want to play but doesn't say what it needs
<pitti> calc: hello
<pitti> calc: hm, that should actually be taken care of by simple-codec-installation
<pitti> mvo: ^ ?
<calc> i don't see that if it is a package on my box
<mvo> ?
* mvo reads backtrace
<calc> mvo: i can't play dvd's with totem even with libdvdcss2 installed and it isn't very descriptive as to why
<calc> it says "Totem cannot play this type of media (DVD) because it does not have the appropriate plugins to be able to read from the disc."
<Mithrandir> calc: libdvdread?
<Mithrandir> it's not a codec, it's an access library
<calc> yep libdvdread3 is installed too
<mvo> calc: oh, no idea. I don't think this is done via gstreamer
<calc> i guess i can just install totem-xine but that is cheating
<mvo> or is it? if so, we should make sure that the easy codec install gets extended to understand about it
<mvo> calc: yes :P
<calc> mvo: I don't know how totem does the dvd playing stuff, never examined it before
<mvo> calc: seb128 probably has a idea, he should be around in ~1h
<calc> ok
<StevenK> Hrm. Compiz 0.6.0 finally released
<mvo> and already in gutsy
<StevenK> Heh, neat
* calc checks to see if bad/ugly plugins help
* StevenK chuckles
<RAOF> ...and already has patches from git applied to fix stuff :)
<StevenK> My cat was on my windowsill - until the dog next door starting barking.
<StevenK> She jumped a mile and ran off
<RAOF> With *hilarious* consequenses!
<StevenK> Well, she knocked over one of my speakers in her haste
<doko> cjwatson_: ouch, missed the debian/docs file, which installs CREDITS ...
<pitti> calc: btw, what's the current status on your local disk wrt. OO.o? do you plan another upload for gutsy?
<Burgundavia> calc: afaik, gstream still has no support for DVD menus
<calc> for whatever reason even totem-xine seems to not work either
<dholbach> good morning
<calc> huh i wonder if this is a disc that can't be played under linux
<calc> that would really suck :\
<calc> hah, i am going to have to pirate the movie to be able to play it, its a damn sony movie
<calc> it won't even play on most standalone dvd players
* slangasek chuckles
* calc kills sony
<calc> now i know why i hadn't rented this movie yet even though its old, i used to know which ones to avoid
<pitti> check for rootkits :)
* RAOF boggles at evolution dying entirely under it's own steam
<calc> heh
<TheMuso> c
<TheMuso> ugh
<kwwii> about half of my system is upgraded
<kwwii> and when I start adpet-manager to finish it is says that it cannot because it would break things
<slangasek> calc: so pitti had talked to me about needing some fixes to bibliography handling before we could consider dropping oo-base from the CDs; is this something you're working on, is there a bug number for it, and is there anything you could use help with?
<calc> slangasek: i don't have a bug number for it yet, and not sure what i should do as far as warning or just not crash, etc?
<calc> if i warn then i would need translations right?
<calc> also i am not even sure what all parts of the code will trigger crashes, at least bibliography and mail merge
<calc> maybe more
<calc> ooo upstream is considered to be one thing to install so they are intertwined quite a lot
<slangasek> translators wouldn't thank us for an additional string, but an error message in English would be better than an error message in "C++ backtrace"
<calc> yea
<mdke> there aren't any Ubuntu translations for ooo, I think
<calc> something really simple like "Install openoffice.org-base" would be fairly easy to understand across languages since it would be just one word to translate... ;)
<slangasek> so in what kind of timeframe would you be able to answer the question of which parts of the code will trigger it?
<mdke> it's all upstream
<calc> mdke: we're talking about adding another string to ooo
<calc> mdke: or a few probably all with the same basic message
<mdke> calc: right, my point was that since Ubuntu doesn't translate ooo, it can't be translated
<calc> mdke: ok
<calc> mdke: long term it will be but that is in hardy timeframe
<mdke> probably that helps, doesn't it, because you don't have to worry about notifying translators
<slangasek> because we're kinda supposed to have the CDs sorted, er, today
<calc> slangasek: i will try to have the list done today (Friday)
<calc> slangasek: oh shit, ok didn't realize that was today :\
<slangasek> mdke: well, just because the translations aren't primarily done in LP doesn't mean that the translation teams wouldn't have taken a stab at it had they been given a chance
<mdke> slangasek: ok, if there is translation activity in Ubuntu OOo then it becomes a consideration again :) still, I wasn't aware of such
<pitti> mvo: what's the status of bug 120957? it looks quite confusing
<ubotu> Launchpad bug 120957 in update-manager "UpdateManager fails to fetch dist-upgrade tarball" [High,Invalid]  https://launchpad.net/bugs/120957
<mvo> pitti: the original bug is fixed with 0.59.25, the last comment indicates that it got hijacked for something else
<pitti> soren: any news about bug 119908?
<ubotu> Launchpad bug 119908 in dovecot "Dovecot crashes on index files" [Undecided,Fix released]  https://launchpad.net/bugs/119908
<pitti> mvo: can you please update the gutsy and feisty tasks appropriately? (I think the import os issue is fixed in feisty, right?)
<mvo> yes
<pitti> mvo: if the last commenter has a different problem, he needs to file a new bug
<pitti> hijacking SRU bugs is way too confusing
<pitti> mvo: danke sehr! *hug*
<mvo> yes again :)
<pitti> I approved the feisty task
<calc> slangasek: oh another issue is if a document uses base for something already it will likely crash writer as soon as it is opened
<soren> pitti: No, I'm afraid it slipped under my radar at some point. I remember I found the diff for you, but it was something like 18k lines :/
<slangasek> calc: <sigh>
<pitti> it sounds like writer should actually Depends: -base, or so
<calc> pitti: yea more or less
<pitti> if someone uninstalls -base on his system, he'd get the same result
<calc> pitti: yep, that is why we have been installing openoffice.org which pulls it all in, in the past
<pitti> calc: doko also mentioned that we could make gij optional; do you know what that would chnage?
<slangasek> well, it's not just embedding databases in text documents either, is it?
<slangasek> you can embed spreadsheets in a text doc, or $mumble in a presentation?
<dholbach> debian bug 439843 fixes my evolution crashing on startup (and other occurences of crashers with other gnome apps) - is http://daniel.holba.ch/temp/libxml2.debdiff OK for upload?
<ubotu> Debian bug 439843 in libxml2 "libxml2: Version 2.6.30.dfsg-1 breaks Azureus and evolution (until now)" [Critical,Fixed]  http://bugs.debian.org/439843
<doko> pitti, calc: only if we can give the user a hint when opening the wizards in writer (i.e. opening a dialog box when we cannot find a jvm)
<calc> slangasek: true, also if you do envelope or bibliography related stuff it doesn't directly look like database stuff but would probably crash it as well, i haven't verified for the simple case with just those things though
<calc> doko: ah
<doko> dholbach: there is another libxml2 upload pending ...
<pitti> ah, seems doko managed to shove off 8 MBs from our alternates; thanks a lot!
<pitti> so, 10 MB to go
<dholbach> doko: since I don't have your changes to libxml2, would you mangle the fix into yours?
<dholbach> it seems to fix __xmlParserInputBufferCreateFilename() sort of crashers
<calc> so far with a manual gui inspection the only things that crash are related to envelopes and bibliography which I had found initially
<doko> dholbach: bug 147144, which includes your fix
<ubotu> Launchpad bug 147144 in libxml2 "xslt:copy element is broken in 2.6.29" [Medium,Confirmed]  https://launchpad.net/bugs/147144
<StevenK> pitti: If I could actually remember how to do /usr/share/doc links properly, libsnmp10 should kill another 1Mb
<doko> StevenK: where's the problem?
<StevenK> doko: I think the problem is me. :-)
<pitti> StevenK: most important thing to remember is that you need a preinst to replace a dir with a symlink
<dholbach> doko: is that a merge of 2.6.30.dfsg-2
<pitti> StevenK: (since dpkg won't do it)
<mdke> pitti: with the next upload of ubuntu-docs, there is an increase in the package size, just to warn you. It's due to adding translations
<dholbach> doko: ok, looks good then
<dholbach> yoohoo
<dholbach> no libxml2 breakage anymore
<StevenK> pitti: My problem at the moment is it won't stop shipping /usr/share/doc/libsnmp10
<dholbach> thanks doko
<doko> mdke: even when not shipping the not needed xml files?
<pitti> mdke: TBH, I'd like to do a ban of package size increase until we sort out the 10 MB we need to chop off
<Trewas> aren't all packages supposed to have changelog.Debian.gz? I am wondering why my laptop started failing to suspend and I suspect the recent xserver-xorg-video-intel upgrade but noticed that it has no changelog
<mdke> doko: yes, including those. Translations are very large
<pitti> Trewas: for native packagages they might just have a changelog.gz
<mdke> pitti: alright, it's your call.
<mdke> the package I built as a test was 2.1MB over about 1MB for the previous version
<doko> mdke: would it be possible to upload ubuntu-docs without new translations first?
<Trewas> pitti: it has only files "copyright" and "README.gz" (dated months ago) in its /usr/share/doc directory
<doko> pitti: want to have a look at 147144?
<mdke> doko: I presume so, although we might have to completely rework the package. It is always set up to ship translations if they are present in the repository
<pitti> Trewas: that's a bug then
<mdke> an alternative would be to slim down the package size by only shipping translations which have a very high percentage of translation
<pitti> doko: the changelog only has bug fixes, so it's not subject to freeze
<mdke> lemme see how big the package is with only 90% complete translations
<doko> pitti: ok thanks, uploading
<pitti> thank you
<\sh> doko, can you make a sense of this, while starting up oofice ??  ** (process:6067): WARNING **: Unknown error forking main binary / abnormal early exit ...
<Trewas> pitti: should I file a bug about it? and preferably for ubuntu or for debian (assuming they are missing the changelog too)?
<\sh> doko, I have it on two of my gutsy machines...(lt43 and a hp desktop)
<pitti> mdke: ah, would certainly be an interesting figure (although 90% is certainly a bit high)
<mdke> pitti: yes, I would not envisage releasing with that, it would be very unfair to translators
<pitti> Trewas: on Debian preferably, when it is missing there
<doko> \sh: restricted graphics driver?
<\sh> doko, nope...ati oss and compiz-fusion
<Trewas> pitti: ok
<pitti> mdke: also, if we can chop off enough, 1 MB for added translations is well worth the space
<\sh> doko, and on the second one ati oss and dual head setup without compiz
<pitti> mdke: so I'm not refusing the new upload at all, I just like to ask you to stall it a bit
<pitti> hi \sh
<\sh> moins pitti :)
<doko> \sh: no idea, please ask calc
<mdke> pitti: ok, but it has some important fixes too, so if we can upload at 90% now and then reduce it say on Monday, that would be good
<doko> \sh: or better file a bug report
<\sh> doko, will do :)
<calc> \sh: try without compiz and see if it goes away
<pitti> mdke: works for me, too
<calc> \sh: i've seen compiz do weird stuff with various other apps like firefox/thunderbird as well
* mvo refuses to believe that it might be a compiz problem
<\sh> calc, I don't have compiz enabled on the other machine :)
<calc> \sh: oh fun
<\sh> calc, same error
<mdke> pitti: ok, it's 1.3MB with >90%  translations (compares with 1.0MB for the current package in the archive)
<calc> \sh: i've seen someone mention an issue like yours (maybe it was you) but haven't been able to reproduce it
<pitti> mdke: that's fine
<mdke> ok, I'll commit the change and comment on the bug report
<\sh> calc, nope...I just wanted to start up ooO today to write my CV ...
<pitti> \sh: did you have a chance to test bug 103291 in gutsy? we need to put this into dapper soon for dapper.2
<ubotu> Launchpad bug 103291 in lilo-installer "lilo-installer fails on HP (Compaq) SmartArray controllers (/dev/cciss)" [Medium,In progress]  https://launchpad.net/bugs/103291
<mdke> pitti: that trick of yours with the translation percentage is very useful :)
<calc> \sh: both i386?
<\sh> calc, yepp
<pitti> mdke: \o/
<StevenK> \sh: Oh pfeh, CVs should be done in LaTeX. :-)
<\sh> pitti, thx for reminding me :) I wanted to update it :)
<calc> \sh: hmm :( whatever it is it must be uncommon since i don't have an inbox full of reports, file a bug report with as much detail as you can get about it
<pitti> \sh: oh, does it work now?
<\sh> pitti, well, works for me ;) I'm, updating the bug now :)
<pitti> cool
<\sh> StevenK, I have my CV ready on the web...I need to transform it properly into PDF...and push my other stuff as well in
* \sh has an appointment this afternoon for a job interview
<StevenK> \sh: Yes, so use LaTeX. :-)
* calc gone to bed
<\sh> calc, I'll file a bug against ooffice...what do you need to have good infos?
<pitti> calc: sleep well!
<calc> \sh: package version, arch, if you can manage to get a good gdb backtrace that would be helpful, but the other person wasn't able to get one
<StevenK> I thought OOo resisted debugging? :-P
<\sh> calc, I'm trying to get them..hopefully it works :)
<calc> \sh: maybe kernel version as well, not sure what would be causing it to not to fork
<calc> \sh: whatever the problem is its uncommon :-(
<calc> StevenK: heh yea a bit
<\sh> calc, will give you everything you want :) let's see what's coming out
* calc ZZzz..
<pitti> cjwatson_: do you have the dapper update for bug 103291 at hand for upload?
<ubotu> Launchpad bug 103291 in lilo-installer "lilo-installer fails on HP (Compaq) SmartArray controllers (/dev/cciss)" [Medium,In progress]  https://launchpad.net/bugs/103291
<\sh> calc, no backtrace possible....
<dholbach> MOTU Q&A session in #ubuntu-classroom in 10 minutes
<doko> mdke, pitti: currently looking at ubuntu-docs
<dholbach> doko: bug 149040?
<ubotu> Launchpad bug 149040 in ubuntu-docs "waste of disk space" [Medium,In progress]  https://launchpad.net/bugs/149040
<doko> dholbach: yes
* dholbach holds off on uploading it :)
<Hobbsee> hiya dholbach
<dholbach> hey Hobbsee
<doko> dholbach: no, please go ahead (if the package is smaller than the current one)
<dholbach> doko: it contains a lot of new translations, that's why it's hard to judge
<seb128> dholbach: is that you who do ubuntu-docs uploads?
<dholbach> seb128: ubuntu-main-sponsors does it, I did it all the time 'historically'
<doko> dholbach: ohh, right, and those get stripped for the binary ...
<seb128> dholbach: bug #146832
<ubotu> Launchpad bug 146832 in ubuntu-docs "ubuntu-docs: undefined "&rsquo;" in /usr/share/omf/windows/windows-C.omf" [Undecided,Fix committed]  https://launchpad.net/bugs/146832
<seb128> dholbach: the current version breaks update, would be nice if somebody could sponsor quickly
<dholbach> seb128: I'll do the upload then - bug 149040 and bug 146832 should be fixed that way
<ubotu> Launchpad bug 149040 in ubuntu-docs "waste of disk space" [Medium,In progress]  https://launchpad.net/bugs/149040
<ubotu> Launchpad bug 146832 in ubuntu-docs "ubuntu-docs: undefined "&rsquo;" in /usr/share/omf/windows/windows-C.omf" [Undecided,Fix committed]  https://launchpad.net/bugs/146832
<seb128> dholbach: thanks
<dholbach> seb128, doko: uploaded
<seb128> dholbach: danke
<dholbach> mvo: can you update command-not-found-data before the release again?
<mvo> dholbach: yes
<dholbach> mvo: gracias
<mvo> dholbach: that and a app-install-data-update is on my list
<mvo> dholbach: the list that is too long ,)
* dholbach hugs mvo
* Hobbsee staples dholbach to irc
<dholbach> hehe Hobbsee
<Hobbsee> dholbach: now stay there, or else it will be the duct tape :P
* Hobbsee cheers over the fact that the guys never ended up duct-taping her to the truss, ~20m into the air.
<dholbach> Hobbsee: gotcha :)
* Mithrandir puts something down on the todo-list for next uds with Hobbsee present.
* Hobbsee beats Mithrandir
<Hobbsee> Mithrandir: you'd have to get up there yourself!
<Mithrandir> Hobbsee: I have climbing equipment.
<Hobbsee> Mithrandir: depends how climable it is, though.
<Mithrandir> true
<Hobbsee> which, at least that one wasnt.
<Hobbsee> and, last i checked, you cant put a scissorlift into your suitcase.
<Mithrandir> you can rent one locally?
<Hobbsee> sure, if you have connections.
<Mithrandir> like, a phone and a bit of money? :-P
<Hobbsee> you'd have to know the number to ring :P
<liw> start with a random number and go from there
<slangasek> uh. why does acpi-support depend on finger? :)
<Mithrandir> special :-)
<seb128> dholbach, Mithrandir: any opinion on bug #131530?
<ubotu> Launchpad bug 131530 in bluez-gnome "'Browse device...' in the bluetooth applet is useless without gnome-vfs-obexftp" [Medium,Confirmed]  https://launchpad.net/bugs/131530
<Mithrandir> seb128: bluez-gnome should depend on gnome-vfs-obexftp?
<dholbach> seb128: yes, I agree with the bug report
<Mithrandir> it's about 160k, so I think we can safely do that.
<seb128> Mithrandir: that's what the bug suggests
<pitti> Riddell: do you want to seed hplip-gui to Kubuntu, or shall we demote it?
<Mithrandir> seb128: do you feel like doing it or should I?
<seb128> Mithrandir: if you could do it that would be nice, I'm in the middle of several other things at the moment
<Mithrandir> sure
<seb128> Mithrandir: but gnome-vfs-obexftp is an universe package which is slightly problematic
<Mithrandir> seb128: oh?
<Mithrandir> as in, what's problematic?
<seb128> as in need an MIR and pitti approval before adding a Depends? ;)
<doko> pitti: looking into libservlet2.4-java, libtiff, libsane to move the docs to another packge (-dev, or -doc), 5.5MB uncompressed
<Mithrandir> well, yes.
<tkamppeter> hi pitti
<pitti> doko: ooh, *hug*
<pitti> hi tkamppeter
<tkamppeter> pitti, do you know how the usblp kernel module gets loaded?
<pitti> tkamppeter: it has modaliases, so just via the usual module autoloading, I figure
<tkamppeter> pitti, thanks I have found the problem. I have "blacklist usblp" in /etc/modprobe.d/blacklist. Probably I have added that for testing the libusb-based CUPS backend.
<pitti> ah :)
<tkamppeter> And so subsequent boots did not load the backend.
<tkamppeter> pitti, another thing: bug 138776. It seems that on an update to Gutsy the privileged user(s) do not stay in the "lpadmin" group.
<ubotu> Launchpad bug 138776 in system-config-printer "[gutsy tribe 5]  a user with sudo privileges cannot change printer settings" [Wishlist,Confirmed]  https://launchpad.net/bugs/138776
<tkamppeter> problem most probably caused by bug 26338
<ubotu> Launchpad bug 26338 in gnome-system-tools "Adding a user to a group modifies other users' groups and passwords" [Critical,Confirmed]  https://launchpad.net/bugs/26338
<dholbach> soren: submittodebian is missing from the package, I guess it's not in setup.py - I can fix that; shall I also apply the patch from bug 148526?
<ubotu> Launchpad bug 148526 in ubuntu-dev-tools "submittodebian should follow Bugs/Debian/Usertagging" [Undecided,New]  https://launchpad.net/bugs/148526
<seb128> mjg59: could you look at bug #148291? That's another g-s-d crasher due to the synaptic changes
<ubotu> Launchpad bug 148291 in gnome-control-center "Unable to start the settings manager 'gnome-settings-daemon'." [Medium,New]  https://launchpad.net/bugs/148291
<slangasek> lool: do you know why gedit depends on iso-codes?  changelog only mentions build-depends
<asac> pitti: when you do your next NEW batch, there is lightning-extension-locales, xulrunner-1.9, firefox-3.0 in NEW ... if you want any infos on those let me know.
<pitti> slangasek: there are quite a few other reverse dependencies on iso-codecs on the CD, though (language-selector, oem-config, ubiquity, etc.)
<lool> slangasek: Looking at SVN history, I can tell you that HE added the dep at the same time he added the b-dep; no idea why yet
<slangasek> pitti: right, moving on
<slangasek> but yeesh, iso-codes is fat
<pitti> asac: does firefox-3.0 replace -granparadiso?
<asac> pitti: yes ... and it has a _small_ orig ... because it builds against xulrunner-1.9
<lool> slangasek: iso-codes is also used in totem and epiphany IIRC
<pitti> asac: \o/
<asac> pitti: build of firefox-3.0 takes about 2 minutes now :)
<pitti> rock
<lool> slangasek: totem is probably missing a dependency on iso-codes in ubuntu
<lool> slangasek: I think this is used to display the localized name of languages in e.g. DVD menus
<DktrKranz> could an archive-admin look at bug 112729 ? it should be already fixed
<ubotu> Launchpad bug 112729 in bootcd "[bashism]  /usr/share/bootcd/bootcd-run.lib: 144: Syntax error: "(" unexpected" [Medium,Fix committed]  https://launchpad.net/bugs/112729
<pitti> slangasek: we would win 0.5 MB by bzip2'ing it
<lool> slangasek: I confirm iso-codes is a required dependency for the gedit spell checking
<lool> slangasek: Presumably displaying localized names of languages to spell check against
<lool> At least it was required in 2.18.0
<slangasek> lool: that's pretty sad given that when I try to configure the spellchecker in gedit, all the language options it gives me are "English" :)
<lool> seb128: Do you agree totem-gstreamer and xine should depend on iso-codes?
<sladen> Hobbsee: !just ask
<lool> src/totem-menu.c will open #define ISO_CODES_DATADIR ISO_CODES_PREFIX"/share/xml/iso-codes"
<seb128> lool: yes
<Hobbsee> sladen: i've effectively hijacked -motu from you
<lool> slangasek: But please note that English is localized as English in your English locale
<Hobbsee> sladen: hope you dont mind :)
<lool> ;)
<lool> seb128: Should I open a bug with debdiff?
<sladen> Hobbsee: oh excellent, I wish somebody had done that a long time ago
<seb128> lool: feel free to open a bug or to upload a new revision somewhere (I'll sponsor it)
<Hobbsee> sladen: even better :)
<Hobbsee> sladen: it's the irc council's domain now anyway
<sladen> Hobbsee: even even better :)
<Hobbsee> :D
<fabbione> seb128: did anybody ever reported that the "Force quit" option kicks in waaaay to fast?
<fabbione> seb128: very often when I close an apps that takes more than 2 seconds (like.. OOo) bam.. i get immediatly the dialog
<seb128> fabbione: no, it takes like 10 seconds which is usually not too fast
<fabbione> is it a config option by any chance?
<seb128> fabbione: on gutsy? what arch?
<seb128> fabbione: no
<fabbione> it kicks much faster than 10 seconds..
<fabbione> gutsy/i386
<slangasek> pitti: by bzip2ing the .deb?
<fabbione> very latest..
<Amaranth> #define PING_TIMEOUT_DELAY 2250
<pitti> slangasek: right
<seb128> fabbione: right, it's around 3 seconds
<pitti> slangasek: well, data.tar.bz2
<doko> StevenK: do you have a proposed fix for the duplication in snmp?
<Hobbsee> doko: (he's gone)
<pitti> slangasek: I'll do that unless you want to?
<doko> StevenK, Hobbsee, ok, looking then
<slangasek> pitti: I don't think I even know how
<slangasek> (or could do it if I knew?)
<fabbione> seb128: would it be possible to increase that one just a bit like to 5/6 seconds?
<lool> seb128: Weird, how do you people build totem?  I get /usr/share/gnome-pkg-tools/1/rules/check-dist.mk:19: Unknown distribution: gutsy
<pitti> slangasek: dh_builddeb -i -- -Z bzip2 mainly
<Amaranth> In compiz the ping timeout is configurable but the default is 5 seconds
<slangasek> pitti: ah
<seb128> lool: unknown distributions don't stop the build
<lool> It makes "clean" fail here; I thought buildds would fail in this case as well
<seb128> lool:
<seb128> ALLOWED_DISTS ?= experimental
<seb128> DISALLOWED_DISTS ?= unstable
<seb128> # unknown distribution; warn
<lool> Ah no wait, it's not the error; I miss dpatch on this box but only read the first error
<lool> Sorry
<seb128> no problem ;)
<StevenK> doko: Thanks. I tried to sort it out, and failed.
<pitti> slangasek: uploaded; thanks for spotting this
<asac> doko: do you know if myspell-dictionaries is still the right virtual package to depend/recommend if you want myspell/hunspell dictionary?
<slangasek> pitti: cheers
<doko> asac: hmm, can't remember
<doko> seb128: do you know julian blaches nick?
<seb128> doko: the xsane maintainer?
<seb128> or somebody else with a similar name?
<tkamppeter> Is there any chance that bug 26338 will get fixed? It especially causes bug 148526.
<ubotu> Launchpad bug 26338 in gnome-system-tools "Adding a user to a group modifies other users' groups and passwords" [Critical,Confirmed]  https://launchpad.net/bugs/26338
<ubotu> Launchpad bug 148526 in ubuntu-dev-tools "submittodebian should follow Bugs/Debian/Usertagging" [Undecided,New]  https://launchpad.net/bugs/148526
<lool> doko: "jb"
<doko> ahh, ok
<slangasek> doko: "jb", but I don't know that he IRCs much these days?
<lool> doko: At least on oftc
<Amaranth> wow, idle almost a week
<slangasek> pitti: curious dependency from drdsl to libcapi20-dev insted of libcapi20
<doko> ok, not online.
<doko> slangasek: that seems to be wrong, but I didn't follow the debian changes recently
<slangasek> also, why does ubuntu-desktop pull in a bunch of perl libs that nothing else uses? :)
<slangasek> oh, my bad, it's the debconf gnome frontend
<mjg59> seb128: I /suspect/ that they've got an old version of the Synaptics driver
<mjg59> In any case, I'll work around it
<slangasek> 4 copies of libdb on the CD
<slangasek> what is this, Debian??
<seb128> mjg59: thanks
<StevenK> I daresay 2 or 3 of those libdb versions should bugger off to universe.
<pitti> slangasek: we cleaned up libdb from time to time, but at the rate new ones are introduced into Debian it's almost impossible to keep up to date
<pitti> slangasek: and of course there are always a few packages which use on-disk transactions, and are therefore stuck to one version
<slangasek> well, two of the versions of db are named explicitly in server-ship
<pitti> until someone figures out a way to upgrade those dbs in the postisnt
<slangasek> sure
<slangasek> well, db4.4 should be the lowest-hanging fruit; let's have a look at that
<pitti> slangasek: do you know checkrdepends?
<slangasek> yes, though it hadn't occurred to me
<pitti> slangasek: you can use it on rookery (~pitti/bin/checkrdepends) or drescher (as lp_archive)
<doko> tkamppeter: $ ls -l /usr/share/doc/cupsys-driver-gutenprint/samples/
<doko> total 592
<doko> -rw-r--r-- 1 root root 598930 Jul 19  2004 profile.jpg
<doko> can this be removed?
<dholbach> soren: I'll do the upload of ubuntu-dev-tools (patched submittodebian)
<slangasek> ok, so db4.4 isn't the low-hanging fruit it ought to be :)
<soren> dholbach: You ROCK!
<mjg59> seb128: Argh. Is gnome-control-center really not rebuildable more than once?
<mjg59> seb128: Write patch, test build, dpkg-buildpackage -S and then it fails to reverse-apply the autoreconf patch
<seb128> mjg59: might be, several packages are buggy in that regard
<MacSlow> ups... just updating and cupsys_1.3.2-1ubuntu4 tries to overwrite /usr/share/doc/libcupsys2/CREDITS.txt, which is also claimed by libcupsys2
<mjg59> The next patch, when reversed, would delete the file config.h.in~,
<pitti> MacSlow: fixed in ubuntu5
<Hobbsee> MacSlow: known, lots of bugs and dupes already.
<MacSlow> pitti, Hobbsee: so just rerun the update?!
<pitti> MacSlow: yep, with ubuntu5
<mjg59> seb128: How about if I just delete the ~ file from the autoreconf patch?
<seb128> mjg59: right *~ are removed during the clean target and should not be in the patches
<seb128> mjg59: that would be a good idea ;)
<seb128> we should teach cdbs-edit-patch to exclude those
<doko> pitti: about libsane, most of it is documentation about supported devices and configuration help/examples. split it out anyway into a libsane-doc package which doesn't land on the CD?
<pitti> slangasek: db4.5 does not look too bad; it's OO.o, pyhton2.5 and pam which affects CDs
<pitti> doko: sounds great
<pitti> slangasek: those could certainly go to db4.6
<mjg59> seb128: Yeah, that looks better
<doko> pitti, slangasek: OOo can use 4.4, python as well, but we do have existing databases (like spamassassin) which need to be converted
<doko> no db4.6 is not an option, it's too buggy
<pitti> ah, ok
<slangasek> pitti: libdb4.3 would need two rebuilds to drop it from alternate, exim4 and iproute.  iproute doesn't need any changes but a rebuild; exim4 I'm not sure about, the maintainer is doing some upgrade stuff but based on the changelog I'm not sure it's actually sensible
<pitti> but SA is perl
<mjg59> seb128: Uploaded
<seb128> mjg59: thanks
<slangasek> I don't know about "too buggy", but db4.6 is currently not one of the ones on the CD so rebuilding stuff for it isn't a win
<pitti> slangasek: exim4 is on the alternates?
<pitti> slangasek: iproute sounds safe
<slangasek> pitti: whoops, no -- so just iproute needs rebuilt
<pitti> deal!
<doko> slangasek: http://mail.python.org/pipermail/python-dev/2007-September/074522.html
<pitti> slangasek: doing
<pitti> slangasek: I'll rebuild it against 4.4 then? just in case we want to get rid of 4.5, too
<slangasek> doko: well, "can lockup a process" doesn't prove it's a bdb bug rather than an app bug, but ok, point taken :)
<slangasek> pitti: ISTR that db4.4 was a dud release and db4.5 would be the better choice
<pitti> slangasek: ok; so maybe we move over the 4.4 bits on the CD to 4.5 then?
<slangasek> the things that depend on db4.4 look harder to move
<pitti> meh @ archive.u.c. slowness; checkrdepends is slooooooow
<slangasek> apache, apt-utils, libedata-book1.2-2?
<doko> Hobbsee, Riddell: could you have a look at http://people.ubuntu.com/~doko/tmp/fdupes-kubuntu.out if there are some low hanging fruit (duplicates to remove for Kubuntu)?
<doko> mvo should know about apt-utils
<slangasek> perl depends on db4.4
<pitti> ISTR that seb128 and I already had the db discussion for e-d-s
<pitti> last time it just worked IIRC
<seb128> yes
<StevenK> pitti: Should we sync in new upstream version of clutter-perl?
<pitti> StevenK: would make sense, now that we have all the other bits
<StevenK> pitti: Yup. I'm not certain it builds, should I check first?
<pitti> StevenK: please
<StevenK> pitti: Aye, I shall let you know - I'm being called for dinner.
<pitti> slangasek: iproute uploaded
<pitti> StevenK: isn't postfix in ship?
<soren> StevenK: server-ship, isn't it?
<pitti> ah, no
<pitti> and that was directed to slangasek actually
<Riddell> doko: what does the figure on the left mean?
<pitti> slangasek: so that should drop libdb4.3 and give us another 440 kB
<slangasek> nice
<doko> Riddell: the size of all duplicates
<doko> Riddell: so installing these files into a kdebase-common package, which all packages can depend on, then it saves this amount of space (uncompressed), so looking at all dupes in kdebase this is abotu 3MB uncompressed
<slangasek> sigh, why is libgtkhtml2.0-cil still built against gtkhtml3.8?
<pitti> ah, I remember that discussion
<pitti> didn't get ported to 3.14 at that time
<slangasek> blah
<pitti> not sure aobut the current status
<pitti> asac: hmm, firefox-3.0 ships some transitional packages firefox-trunk-*, but they do not exist in gutsy
<slangasek> hahaha, pidgin depends on *zephyr*?
<dholbach> "This is the Project Athena Zephyr notification system 2000/04/21 snapshot."
<dholbach> Version: 2.1.20070719.SNAPSHOT-1 :-)
<dholbach> I remember some users requested gaim to be built with --enable-zephyr
<doko> dholbach, seb128: please check if the documentation in libbonoboui-common is really needed and suggest a package where it can be moved to
<torkel> is anyone _still_ using that? :-)
<seb128> doko: still not enough place on the CD?
<dholbach> doko: best to ask lool and seb128
<slangasek> there are still a few sites that use zephyr, yes
<doko> seb128: no
<seb128> doko: how much is still required?
<pitti> seb128: I guess we still need to chop off some 7 MB
<pitti> I'll build new CDs in the afternoon, once our current changes are in
<slangasek> I'm more amused because libzephyr depends on libhesiod, which is the last package I expected to see on the CD
<sladen> it shouldn't need to depend on it;  it's probably perfectly possible to have zephyr /support/ but not demand it's installed
<torkel> I thought it died with all krb4 cross-realm vuln. a couple of years ago
<asac> pitti: its a package we had in ppa (next to granparadiso)
<paran> is something wrong with security.ubuntu.com? I am getting invalid signature warnings for the latest feisty updates
<asac> pitti: both will be dropped for hardy
<pitti> paran: it's just hammered due to the current OO.o security update
<pitti> asac: ok, I see
<sladen> pitti: isn't squashfs already doing merging (of duplicate files) on the livecd;  so the -common work would only help the alternate CD and not the livecd
<pitti> asac: firefox-3.0 still contains .dlls; can we pretty please stop introducing more instances with those?
<pitti> sladen: that's the idea
<pitti> sladen: desktop CDs are fine, alternate amd64 is overflown
<sladen> pitti: it's the alternates which are over?
<pitti> asac: that bug was marked for gutsy beta AFAIR
<asac> pitti: yes, i still wait for upstream reply on those. i will bug him today again
<paran> pitti: ok
<StevenK> pitti: You need to stop confusing me and slangasek. :-)
<pitti> asac: I'll accept firefox-3.0 under the assumption that I can remove -granparadiso in exchange, so it's just moving the problem, not adding one
<pitti> asac: ok?
<asac> pitti: thats correct
<asac> pitti: just send a ping to mconnor
<slangasek> pitti: fwiw, Clint says db4.3 is the one that was the dud, not that it should matter much for something as straightforward as iproute
<asac> pitti: if i don't get a reply, I will start to strip the origs on my own.
<pitti> slangasek: I guess higher versions are generally more preferable, so I rebuilt it against 4.5
<pitti> slangasek: moving the remaining 4.4 stuff to 4.5 shouldn't be too hard?
<pitti> asac: danke
<slangasek> pitti: yes, higher versions are generally preferred, since there are other packages already built against db4.5 and I don't remember if we could cleanly rebuild them against db4.4 without a migration
<slangasek> pitti: db4.4 -> db4.5 is an on-disk log format change, so it would require a scan for transactional uses
<pitti> right
<pitti> as with every other db4.x update
<pitti> slangasek: I checked iproute, taht was fine (grep -r TXN)
<slangasek> well, in theory they could someday do an update w/o a transaction format change :)
<pitti> calc: any chance to build OO.o with an older compiler on sparc, or so? it pretty much ruins sparc installability
<pitti> "it" being the FTBFS
* pitti applauds doko for libservlet-java, minus 800 kB; NEWing
<asac> pitti: xulrunner needs to go in in order to build ffox ... just in case you missed that ;)
<slangasek> pitti: perl depends on db4.4 and appears to expose DB_TXN in its API
<slangasek> not that I think we've ever dealt with perl+db4 upgrades, but there it is
<doko> pitti, calc: I doubt it, and we don't have an older compiler anymore in main. maybe try with 4.2? I'll start a build over the weekend
<pitti> asac: already accepted
<pitti> slangasek: yeah, it's utterly hard to check
<asac> pitti: oh ... thanks have just received ffox mail
<StevenK> pitti: clutter-perl looks great, and there are no Ubuntu changes.
<pitti> StevenK: is there a sync bug?
<StevenK> pitti: There can be.
<sladen> pitti: if you're willing to accept a larger on-disk size;  there's probably a fair bit to be saved by repacking all the openoffice templates/jar files using zero-compression and letting the higher-level .deb and squashfs compression take care of it
<pitti> Riddell: I take it you noticed the kdeguidance FTBFS? (patch didn't apply)
<pitti> StevenK: synced
<StevenK> pitti: Great. Do you want a bug after the fact, or don't care?
<pitti> StevenK: nah, I just asked whether I need to close a task
<pitti> StevenK: it wasn't on the clutter meta-sync-bug from this morning
<slangasek> pitti: looks like perl DB_File doesn't have txn support after all
<pitti> ooh
<slangasek> that would still leave apache and apt-utils, I think
<pitti> apache is not a concern for the CDs, or is it?
<pitti> apt-utils, hmm, mvo?
<StevenK> And rebuilds of apt are a pain
<slangasek> apache2-mpm-worker is on alternate
<slangasek> StevenK: not apt, just apt-utils
<pitti> slangasek: I'll rebuild/test perl and wait with the upload
<pitti> StevenK: only for ABI breakages, right?
<slangasek> oh, apt-utils is from apt, n/m :)
<StevenK> I thought aptitude, adept had to be rebuilt if apt was played with?
<slangasek> StevenK: only if apt's soname changes
<slangasek> which it shouldn't on a simple rebuild
<slangasek> though apt's soname still changes in some cases it shouldn't, such as a glibc minor version bump
<pitti> ok, with the next one or two publisher cycles, gutsy_outdate should be under control again
<slangasek> pitti: ok, that's as much as I can do tonight; if we're still stuck on space when I wake up, I'll have another look
<pitti> slangasek: there are some changelog entries like "Update to DB_File to db4.4"; I'll try it, though
<pitti> slangasek: thanks
<pitti> erk, emacs21 is still in main
<pitti> is someone interested in doing some transitions? (mostly dependency changes and tests)
<StevenK> What transistions?
<elmo> what's wrong with keeping it in main, JOOI?  it's not on the CD is it?
<pitti> change deps of gnus, python-mode and calc, and check that they DTRT with emacs22 (most of them have alternative dependencies already, so it doesn't seem to matter much)
<pitti> elmo: general version duplication
<elmo> see, don't change gnus, that's TWTTD
<StevenK> pitti: You want to be able to kill emacs21?
<pitti> I accepted emacs22 to main and as default under the condition that 21 would be dropped
<pitti> StevenK: demote at least, if possible
<elmo> the version of gnus in emacs22 is >> the version in the package
* StevenK can't expand TWTTD
<elmo> the wrong thing to do
<StevenK> Ah
<elmo> will it was in my head, it doesn't actually work, but details
<elmo> if you're going to demote emacs21, demote gnus too
<StevenK> Heh
<StevenK> pitti: Way cool, we don't need to fiddle with gnus
<StevenK> pitti: I'll take python-mode if you'll take calc?
<pitti> StevenK: hmm, ok
<StevenK> pitti: Yup, I had to twist your arm. :-P
<pitti>  Emacs 22 has a newer version of this package, so the built in calc
<pitti>  should be used with newer versions of Emacs.
<pitti> StevenK: \o/
<cjwatson> pitti: lilo-installer done
<StevenK> Yay
<pitti> cjwatson: ah, thanks; I'll mangle it
<StevenK> pitti: * Do not install for emacs22, which has it's own incompatible python-mode.
<pitti> StevenK: oh, doko is the maintainer for python-mode
<pitti> debian bug #424973
<ubotu> Debian bug 424973 in python-mode "python-mode: please support emacs22" [Normal,Open]  http://bugs.debian.org/424973
<Riddell> pitti: hmm, missed that guidance problem, thanks
<pitti> StevenK: so, seems we should drop that, too
<Riddell> pitti: I added hplip-gui to the kubuntu seeds
<StevenK> pitti: Indeed.
<pitti> Riddell: thanks
<pitti> StevenK: seed changes committed, thanks
<StevenK> pitti: No problem
<doko> pitti, StevenK: yes, we could drop taht, there's another python-mode in emacs22
<tkamppeter> doko, I got an answer regarfing profile.jpg in Gutenprint. One can really remove it.
<seb128> doko:
<seb128> dpkg: error processing /home/buildd/build-403193-990906/chroot-autobuild/var/cache/apt/archives/libtiff4-dev_3.8.2-7ubuntu1_i386.deb (--unpack):
<seb128>  trying to overwrite `/usr/lib/libtiff.so.4.2.1', which is also in package libtiff4
<pitti> Riddell: http://people.ubuntu.com/~ubuntu-archive/component-mismatches.txt also has some binary-only demotions for KDE
<kwwii> doko: will the splash and about pics for OOo that I sent middle of last week be included soon?
<pitti> Riddell: can we walk though them quickly?
<kwwii> doko: Jane was asking about it
<dholbach> kwwii: probably best to ask calc?
<seb128> doko: do you test your changes before uploading? that's 3 conflicts you create in a day now
<doko> kwwii: I hope so, at least calc did look at them
<kwwii> calc: will the splash and about pics for OOo that I sent middle of last week be included soon?
<kwwii> doko: just thought I should check up on it in case it was forgotten
<Riddell> pitti: let me look
<pitti> ah, perl builds fine with db4.5
<pitti> Riddell: lines 3 to 5 of 'binary-only demotions'
<pitti> Riddell: we either need to demote them or seed them explicitly
<pitti> Riddell: the latter is preferable for innocent stuff, to not desync main/universe so much
<doko> seb128: confirmed, I have the new package installed, so this probably was a last-change before upload ...
<pitti> cjwatson: btw, new l-u-m for -13 has built everywhere, so I guess we could rebuild d-i now
<cjwatson> ok, I'm just catching up, I was up part of the night and then slept in :-/
<cjwatson> will take care of it
<pitti> thank you
<StevenK> pitti: When clutter-perl builds I think that all of libclutter* can be NBS'd
<pitti> ok
<cjwatson> gar, why did mbr still ftbfs
<cjwatson> elmo: what kernels are zirconium and rothera running? are they 64-bit kernels?
<elmo> cjwatson: 32-bit
<elmo> cjwatson: rothera is 32-bit hardware too, it _can't_ run 64-bit anything
<elmo> (modulo qemu or something)
<cjwatson> hmm
<cjwatson> elmo: what kernel version?
<cjwatson> oh, wait, the i386 failure isn't just "vm86 not supported
<cjwatson> "
<elmo> cjwatson: rothera == latest dapper, custom build, zirconium == latest edgy server (distro)
<cjwatson> nor is the lpia one
<cjwatson> they're both failing because efl |= 0x00200000 from what it should be
<bluefoxicy> is it just me or does synaptic not actually configure unattendend-upgrades
<bluefoxicy> Unattended-Upgrade::Allowed-Origins gets set; but the script needs APT::Periodic::Unattended-Upgrade set to actually run unattended-upgrades and thus install the packages
<bluefoxicy> strangely enough, my /var/log/unattended-upgrades is full of stuff; so I have no idea how this works :)
<bluefoxicy> oh it's in peridoic ok.  On the server it didn't actually create that file... wonder why.  Nvm ignore me.
* Hobbsee wondesr why apport doesnt force you to have the latest version before filing bugs.
<bluefoxicy> it does for me
<bluefoxicy> "Something crashed" duhrrrrr "SORRY NOT REPORTING BUG, YOU HAVE AN OBSCURE LIBRARY THUNDERBIRD MIGHT USE OUT OF DATE, THERE'S AN UPDATE AVAILABLE."
<pitti> Hobbsee: it does
<Hobbsee> pitti: oh, but it doesnt check the latest on a.u.c - it only checks on your mirror.
<Hobbsee> which is why we're still getting bugs like https://bugs.edge.launchpad.net/ubuntu/+source/cupsys/+bug/149384 i suspect
<ubotu> Launchpad bug 149384 in cupsys "package cupsys 1.3.2-1ubuntu1 failed to install/upgrade: trying to overwrite `/usr/share/doc/libcupsys2/CREDITS.txt', which is also in package libcupsys2" [Undecided,Fix released] 
<Hobbsee> pitti: when we're now up to ubuntu5 - even my au mirror only has ubuntu2
<Hobbsee> er, ubuntu3
<pitti> Hobbsee: it only checks apt-cache policy
<Hobbsee> pitti: perhaps it shouldnt
<pitti> Hobbsee: I don't want to do network checks, way too expensive and brittle
<Hobbsee> pitti: perhaps it should have to check rmadison -u ubuntuor something
<Hobbsee> pitti: hm
<pitti> nah
<pitti> we screwed up, now we just have to play whack-a-bug long enough
<doko> tkamppeter: ok, will remove it for gutsy, didn't have we our own test image, which can be used to test? (if this image is used at all)
<pitti> doko: we have test postscripts in system-config-printer
<doko> pitti: well, this is a 600k jpeg
<pitti> doko: right; I'm all for ditching it
<Kmos> elmo: archive.ubuntu.com is down ?
<pitti> Kmos: just hammered; it's known
<Kmos> :)
<mvo_> bluefoxicy: software-properties let you configure unattended-upgrades
<pitti> wb mvo_
<pitti> mvo_: did you see above question about migrating apt-utils to db4.5?
<RicardoPerez> pitti: ping
<pitti> !ask | RicardoPerez
<ubotu> RicardoPerez: Don't ask to ask a question. Just ask your question :)
<RicardoPerez> oh, sorry :)
<RicardoPerez> pitti: hi! the latest ubuntu-doc doesn't have the translations for the serverguide
<pitti> RicardoPerez: hm, mdke has prepared another upload, which might fix that
<RicardoPerez> pitti: great
<pitti> ah, it's that already
<pitti> RicardoPerez: we temporarily raised the bar to 'must be 90% translated' until we solved the space issues on CD
<pitti> RicardoPerez: it'll get dropped again
<RicardoPerez> pitti: but the serverguide is 100% translated into Spanish...
<pitti> RicardoPerez: hmm; please talk to mdke then
<RicardoPerez> pitti: ok... he appears to be away now
<pitti> RicardoPerez: yes, mail would probably work better
<RicardoPerez> pitti: i'll try later
<RicardoPerez> pitti: ok
<RicardoPerez> pitti: thanks!
<bluefoxicy> mvo_:  non-gui?
<cjwatson> mjg59: do you know anything about interactions of the ID flag and vm86?
<cjwatson> mjg59: mbr's tests are failing because the ID flag is mysteriously set
<cjwatson> mjg59: I'm wondering if I can just forcibly clear that in the test harness output and ignore the problem ...
<cjwatson> I can't reproduce it here, but it's probably processor-dependent
<mvo_> bluefoxicy: see the README
<bluefoxicy> nods.
<bluefoxicy> mvo_:  got fed up with CentOS5 so I dropped an Ubuntu Feisty Server onto a machine ;)
<bluefoxicy> better security that way
<bluefoxicy> i.e. I had over a dozen (and still going) packages hand-built (rpm-rebuild) and was like "No no no screw this bad patch management"
* seb128 hugs pitti for the esound fix
<tkamppeter> doko, we have our own Ubuntu test page in the system-config-printer package and for unsupported page sizes system-config-printer uses the standard CUPS test page. These test pages are small, as they are PostScript with vector drawing instructions inside (no bitmap images). So there is no problem removing profile.jpg.
<doko> tkamppeter: thanks for checking
<MacSlow> argl!
<MacSlow> can anyone confirm that the Viewports-section in the properties-dialog of the wnck-applet also shows up if you're running metacity atm?
<cjwatson> is the wnck-applet the pager thing?
<seb128> cjwatson: workspace switcher
<cjwatson> I don't see a Viewports section here
<cjwatson> running metacity
<seb128> cjwatson: he's speaking about this one, technically wnck-applet is also the tasks list applet also
* seb128 needs to update and will try
<seb128> cjwatson: did you restart your gnome-panel since the upgrade from yesterday?
<seb128> just to be sure
<cjwatson> oh, probably not
<Kopfgeldjaeger> pitti: could you have a look at bug #144390 any my comment?
<ubotu> Launchpad bug 144390 in cryptsetup "use entire disk with lvm/encrypted partitioning fails to boot" [High,Fix released]  https://launchpad.net/bugs/144390
<janimo> are the iso builds on manual? There are no xubuntu live for today
<cjwatson> janimo: the Xubuntu live build should only have started 13 minutes ago, according to the normal schedule
<cjwatson> actually, I'm reading it the wrong way round
<cjwatson> janimo: it won't happen for another 5 hours or so
<seb128> doh, the archive is so sloooow today
<janimo> cjwatson: ok, for some reason I thought they were done in the morning when the CD sanity report arrives
<cjwatson> you know, I should just go back to bed
<cjwatson> janimo: the health checks are asynchronous; but reading the crontab a THIRD time there may be a problem
<cjwatson> janimo: did you check the build logs before asking?
<cjwatson> http://people.ubuntu.com/~ubuntu-archive/cd-build-logs/
<cjwatson> looks like it got stuck on a lock
<janimo> cjwatson: no, I know yesterday's iso contained pakcages from 25th of sep or so and tollef said that there was a problem on the build servers
<cjwatson> that's already fixed
<cjwatson> you should always check the build log first, and then your questions can be better :)
<cjwatson> janimo: I've kicked off a new build now
<janimo> I thought it had just been fixed yesterday and was expecting to see the image today. And I thought it may be on manual as ubuntu and edubuntu have images today
<janimo> cjwatson: thanks
<cjwatson> it's not on manual
<janimo> cjwatson: re build logs, noted
<gnomefreak> i have dapper and edgy backport of flash to fix a couple of bugs. they were acked by jdong and uploaded by hobbsee, i was told to ping an archive admin for the push, is there a policy for doing this or just ping one of the admins?
<cjwatson> gnomefreak: it shouldn't need a manual ping, the queue should get processed on admins' archive days
<gnomefreak> ah ok ty ill let jdong know when i see him
* ogra joins seb128 in moaning about the archive
<cjwatson> pitti: just trying to get a kickseed fix in before d-i
<TheMuso> cjwatson: I don't know whether I missed something as to what you said about the metapackages being in the wrong section, as I changed ubuntustudio-meta to the metapackages section. Yet the same behavior exists, in that desktop gets installed as a dependency of the other tasks, but its recommends still don't get installed. Since we'd like to get some other testing done before we release, we've decided to install everything for now, and fix things
<Hobbsee> slangasek: dch -Ui
<StevenK> TheMuso: You got cut off "everything for now, and fix things"
<TheMuso> - fix things up for hardy
<TheMuso> cjwatson: We also have a concern that users don't want the entire desktop installed if they want to install video, audio, graphics etc stand-alone.
<ogra> seb128, does it work for you ? i dont even get the release files aymore
<Hobbsee> slangasek: and for the record, MOTU are not idiots.  thankyou.
<ogra> (i can ping fine though)
<seb128> ogra: no, timeouted
<ogra> worst day for that :/
<cjwatson> TheMuso: I'm just doing what I'm told
<_MMA_> cjwatson:  ie: If your a Ubuntu user and you gram our -audio meta, it pulld ubuntustudio-desktop as well. Users wont want that. So for this release we'll just remove the depend og ubuntustudio-desktop from the metas and blindly install all the tasks.
<cjwatson> _MMA_: well, it's what you told me to do *shrug*
<_MMA_> cjwatson: And thanx for all the help. Really.
<cjwatson> feel free to undo it, your choice
<_MMA_> cjwatson: Sure sure. We just realized after testing it that it doesnt work. :) at this point we cant spend any more time trying to fix it.
<Kopfgeldjaeger> hi
<seb128> ogra: I managed to get the update now ;)
<ogra> cool
<ogra> i got the release files but not te packages my pbuilder needs
<ogra> still hanging in "connecting" state
<pitti> Kopfgeldjaeger: looking (and yes, I know it's still broken)
* lamont scratches his head at http://launchpadlibrarian.net/9805079/buildlog_ubuntu-gutsy-ia64.gnome-control-center_1%3A2.20.0.1-0ubuntu3_FAILEDTOBUILD.txt.gz
<pitti> Kopfgeldjaeger: oh, that would be something else then
<MacSlow> cjwatson, hm... then I wonder if that's a left-over of my testing-around over the recent days.
<lamont> oh.  failed all arches.. cool
<seb128> MacSlow: the new gnome-panel seems to work correctly under metacity, no compiz options listed
<Kopfgeldjaeger> lamont: i guess there's no configure script ;)
<MacSlow> seb128, ok thanks
<lamont> seb128: you know about gnome-control-center b0rkage, I assume?
<seb128> lamont: which one?
<lamont> -0ubuntu3
<seb128> lamont: just curious, what changed on hppa that you need to rebuild that many packages?
<seb128> lamont: how does it break I mean
<lamont> seb128: launchpad
<seb128> ?
<ogra> seb128, http://launchpadlibrarian.net/9805079/buildlog_ubuntu-gutsy-ia64.gnome-control-center_1%3A2.20.0.1-0ubuntu3_FAILEDTOBUILD.txt.gz
<lamont> running CONFIG_SHELL=/bin/bash /bin/bash /tmp/gnome-control-center-2.20.0.1/./configure  --build=x86_64-linux-gnu --prefix=/usr --includedir=${prefix}/include --mandir=${prefix}/share/man --infodir=${prefix}/share/info --sysconfdir=/etc --localstatedir=/var/lib --libexecdir=${prefix}/lib/gnome-control-center --disable-maintainer-mode --disable-dependency-tracking --srcdir=. --disable-mime-cache --disable-scrollkeeper --enable-aboutme --en
<lamont> able-gstreamer=0.10 --disable-update-mimedb build_alias=x86_64-linux-gnu CC=cc CFLAGS=-g -Wall -O2 LDFLAGS=-Wl,-z,defs -Wl,-O1 -Wl,--as-needed CPPFLAGS= CXX=g++ CXXFLAGS=-g -Wall -O2  --no-create --no-recursion
<lamont> /bin/bash: /tmp/gnome-control-center-2.20.0.1/./configure: No such file or directory
<lamont> make[1] : *** [config.status]  Error 127
<cjwatson> seb128: launchpad isn't creating build records for hppa properly
<seb128> cjwatson: ah, ok
<lamont> cjwatson: s/isn't/didn't/
<cjwatson> seb128: long story, but no-change uploads are one workaround that's possibly less scary than changing launchpad at this point
<pitti> "in-field rebuild test" :)
<cjwatson> lamont: still isn't
<seb128> cjwatson: ok, I was just wondering
<cjwatson> the bug fix, AIUI, has not yet been rolled out
<seb128> mjg59: ^ your g-c-c update doesn't build
<lamont> cjwatson: well, isn't generating build records for things that it didn't generate build records for when we lit it, true.
<lamont> any new upload works just fine
<cjwatson> right, but new P-a-s changes will have the same problem
<Kopfgeldjaeger> pitti: should i open a new bug for that? or did i something wrong?
<lamont> seb128: and I'm being good... you're taking care of re-uploading gnome for me (thanks) :-), with that and kde, there were only about 180 packages in main that are missing.
<lamont> so I'm only uploading enough to tickle launchpad into getting ubuntu-server current
<pitti> Kopfgeldjaeger: that might not a bug, just a way the (admittedly confusing) way partman works
<lamont> db, db4.3, and db4.4 are currently doing the "test-build before upload" step
<lamont> and then I _THINK_ I'm done.
<lamont> cjwatson: new PaS changes that add an architecture _may_ experience the problem, depending on the nature and state of the package
<lamont> likewise, if we lit m68k, we'd see the same issues there...
* lamont bets there are still some packages that lack lpia build records
<Riddell> tkamppeter: I'm looking at bug 99372
<ubotu> Launchpad bug 99372 in kdebase "MASTER: [Feisty]  KDE Printing Manager does not list the PPDs of Gutenprint" [High,Confirmed]  https://launchpad.net/bugs/99372
<Riddell> tkamppeter: where should KDE be looking to find information on the "Epson Stylus DX3850" (for example)
<cjwatson> pitti: partman> what's the problem?
<pitti> cjwatson: I don't know; Kopfgeldjaeger had a problem with manually configuring encrypted partitions, but I didn't investigate it yet
<Kopfgeldjaeger> pitti / cjwatson: alternate cd->partitioning->create boot partition, create "physical volume for encryption" -> "next" -> "no root file system specified"
<pitti> Kopfgeldjaeger: yes, you need to select "configure encrypted devices" first (or so)
<Kopfgeldjaeger> where is this? in the partitioning menu?
<pitti> Kopfgeldjaeger: it should appear there, yes (at the top)
<Kopfgeldjaeger> ok, i will try this. thanks
<pitti> soren: in your lvm/crypt install yesterday, did a mere update-initramfs help to get it boot?
<pitti> soren: it did here
* ogra twiddles thumbs ... watching his pbuilder updating ....
<pitti> Kopfgeldjaeger: just tried it, and it works ("Configure encrypted devices..." is at the top)
<Kopfgeldjaeger> ok, thanks
<Kopfgeldjaeger> :)
<pitti> soren: hah! I managed again to find the magic combination of steps to get autopartitioning without erasing the disk; I set up the encrypted volume manually, set erase to false, and then chose "guided partitioning" again, which seems to do the trick
<tkamppeter> riddell, KDE should ask CUPS for available drivers, doing "lpinfo -l -m" or the equivalent IPP call. Then it will find all PPDs including the mentioned one.
<tkamppeter> Riddell, mistyped your name, see my previous message which is perhaps not in red for you.
<Riddell> tkamppeter: as usual KDE printing seems to be behind the times, it just searches for PPD files to read
<Riddell> tkamppeter: installing foomatic-db-gutenprint solves the missing files problem, should we just promote that to main and put it on the kubuntu CDs for a quick fix?
<Kopfgeldjaeger> pitti: i chose this entry, was asked for the passphrase etc., but now i am back at the partitioning menu
<pitti> tkamppeter: curious, why isn't that package in main anyway? don't we need it?
<MacSlow> seb128, I've this issue here still with the current gnome-panel (ubuntu5) and the visible viewports-frame under metacity when I open the wnck-applet's properties-dialog
<Kopfgeldjaeger> pitti: i chose the entry again, and atm it is creating the ext3 fs.
<lamont> mvo_: I assume you saw  libcompizconfig-backend-gconf is ftbfs everywhere?
<seb128> MacSlow: did you start the session using metacity?
<seb128> MacSlow: or did you start the panel under compiz and hotswitched?
<MacSlow> no
<MacSlow> yes
<seb128> ok, so that's probably it
<seb128> it's probably not clever about windows manager changes
<MacSlow> but the check (also reloading of the glade-file) should happen as the dialog is opened, should it not?
<seb128> I didn't look at the code, mvo did sponsor this upload
<seb128> I'll have a look
<Riddell> pitti: I think cupsys-driver-gutenprint has all the data, foomatic-db-gutenprint has the same data as ppd files but cups no longer needs them
<MacSlow> well I leave that for later... first I want to get the other three issue regarding gnome-control-center done
<Riddell> (I'm guessing mostly)
<pitti> Riddell: ah, right
<pitti> Riddell: yep, cups 1.3 generates them on the fly
<Riddell> pitti: yeah, and KDE's make_driver_db_cups doesn't
* Hobbsee waves to sabdfl
<seb128> MacSlow: right, dynamic switching is a corner case anyway
<MacSlow> ok
<sabdfl> hey Hobbsee
* pitti waves to sabdfl 
<zul> hi sabdfl
<jono> what is the current state of work solving this insane trackerd processor use?
<seb128> jono: do you have the current version?
<seb128> hey sabdf1
<pitti> jono: what's the insanity about it? does it slow down your apps?
<seb128> jono: it should create some load while indexing for the first time but behave correctly then
<pitti> jono: it's supposed to stop on battery, and to be nice
<jono> pitti: it thrashes the processor constantly
<pitti> jono: and it should finally use some ionice, too
<jono> I upgraded to gutsy a week ago, and it is still thrashing my processor
<jono> let me check if there are updates
<seb128> 0.6.3 is supposed to be nicer
<seb128> what version do you have?
<pitti> jono: the latest version (0.6.3) needed a complete reindex, that might be it
<jono> 0.6.3
<pitti> jono: the new version uses a different (more efficient) db
<pitti> hm
<jono> pitti: right
<bddebian> Heya
<lamont> morning sabdf1
<jono> I do have 32GB of music to index :)
<pitti> jono: the most important question is: does it steal cpu from apps, or does it just use the otherwise idle cycles?
<kylem> jnothat's it?
<pitti> jono: hm, I'd expect that to be very fast
<jono> pitti: the system feels pretty sluggish at times
<jono> is it possible to see what it is indexing?
<pitti> jono: that would be a problem indeed; although I figure that's more due to I/O trashing
<pitti> jamiemcc: ^ any idea how to debug that?
<jamiemcc> pitti: start trackerd -v 2 will log all output of whats it is indexing
<jamiemcc> jono: when did you start indexing?
<jono> jamiemcc: not sure - I guess when I installed the last update - few days back?
<jamiemcc> did you stop old trackerd ?
<jono> jamiemcc: I killed it a few times when it thrashed my system
<jamiemcc> jono: music filers should not cause any thrashing - maybe its emails?
<Kopfgeldjaeger> pitti: no matter what i do, i get the "no root fs" error or get back to the partitioner
<jono> jamiemcc: might be - I have a rather large inbox
<pitti> Kopfgeldjaeger: but you did define a root partition?
<jamiemcc> jono: can you get me file list in ~/.cache/tracker
<Kopfgeldjaeger> pitti: you.. say.. aaaah! i understand!
<jono> do we have a pastebin I can use?
<pitti> Kopfgeldjaeger: well, there was no root fs? :-)
<asac> jono: paste.ubuntu.com ?
<Kopfgeldjaeger> yeah... now i understand what this crypt device entry above my hd is for :D
<mvo_> lamont: yes
<jono> jamiemcc: http://paste.ubuntu.com/622/
<jono> asac: :)
<asac> jamiemcc: i really think that a tray icon for trackerd showing its status and allowing you to suspend the indexing temporarily would help a lot.
<jamiemcc> asac: thats coming this weekend
<asac> jamiemcc: really? do you use dbus to communicate?
<jono> asac: I agree, the lack of indexing status is odd
<jamiemcc> asac: yes applet is in svn
<jamiemcc> jono: the email db is pretty big so that means its indeixng emails and has finished indexing files
<pitti> Kopfgeldjaeger: as I said, setting this stuff up manually is still some low-level wizardry
<jono> jamiemcc: so its indexing mail right?
<jamiemcc> jono: yes - you have mbox or imap?
<jono> jamiemcc: imap
<jamiemcc> jono: ok looks like you have millions of emails!
<jono> jamiemcc: I do have quite a few :)
<mvo_> lamont: I fix the libcompizconfig thing in a minute. funny thing, I send the patch to upstream but forgot to include it in my upload
<jamiemcc> jono: how sluggish is system?
<mvo_> (for some definition of funny anyway)
<jono> jamiemcc: not hugely, just a little at times
<lamont> mvo_: lol
<asac> jamiemcc: how do you measure sluggishness?
<jamiemcc> asac: does it slow other apps
<Kopfgeldjaeger> pitti: atm it's "checking ext3 filesystem on encrypted volume", since some minutes at 0%.. is this normal?
<jamiemcc> jono: only time it gets sluggish is when it does index merges which can hammer the disk
<asac> jamiemcc: i sometimes had a system load of 6 or even 8 ... i blame trackerd IO for that
<jono> jamiemcc: right
<jono> thanks for your help folks :)
<jono> much appreciated :)
<jamiemcc> np
<jamiemcc> asac: I blame ext3!
<jamiemcc> asac: im switching to reiser much faster at disk writes
<asac> jamiemcc: well without trackerd i don't have these massive issues ;)
<asac> jamiemcc: but i see your point
<pitti> Kopfgeldjaeger: sure that it isn't erasing it? that takes a while
<pitti> Kopfgeldjaeger: you can switch this off, btw
<pitti> Kopfgeldjaeger: it's only for paranoia
<Kopfgeldjaeger> pitti: now, i know what you mean, that isnt it. but its now at 50%
<Kopfgeldjaeger> s/now/no
<soren> pitti: Yes, at one point an update-initramfs -u did the trick.
<soren> pitti: I've got a hunch about what makes it fail. I've only just got back from the doctor now, so I need to get it swapped back into my working memory.
<pitti> soren: I updated the bug; I hope to find some time to find out why
<pitti> oh
<pitti> soren: the initial initramfs is very different from the one produced by another update
<soren> pitti: Yes, I noticed.
<pitti> so maybe this is done too early, or without /proc mounted in /target, or whatnot
<pitti> soren: I'm still working on libgnome, but that beast is next on my list
<soren> pitti: I looked at the syslog from the installer, and it runs the finish-install.d/05cryptroot things after the last update-initramfs call.
<cjwatson> yes, it will
<cjwatson> if that's supposed to fiddle the initramfs, it's done far too late
<soren> pitti: so I'm thinking the magic config stuff from cryptroot doesn't get written until then.
<soren> cjwatson: Yes, exactly. I don't know if that's the case, though.
<cjwatson> use /usr/lib/post-base-installer.d if you want it to affect the initramfs
<cjwatson> assuming that everything else you need is done by that point (the kernel won't be installed yet, but the rest of the base system will be installed)
<cjwatson> anything selected by apt-install won't be present yet
<asac> ogra: i have issues with virtual box ... somehow setup fails with /usr/lib/virtualbox/src/build_in_tmp: No such file or directory
<asac> any idea?
<ogra> not really, which packages do you use ?
<pitti> cjwatson: just wondering, won't installing the kernel and l-u-m trigger an initramfs update anyway?
<asac> ogra: apt-get install virtualbox :)
<ogra> i use the ones from their website
<pitti> ah, wait, kernel is installed before cryptsetup
<StevenK> virtualbox-ose is in Gutsy
<ogra> (didnt notice we had them until last week)
<StevenK> I need to sit down and figure out how to package up the modules properly for virtualbox so users will stop bitching
<asac> ogra: so you use the non-free package?
<asac> ogra: is there a gutsy build available?
<cjwatson> pitti: sure, but ideally you want to get the necessary bits in place before that
<cjwatson> pitti: and finish-install.d is WAY after the kernel is installed
<pitti> soren: hm, where is that script? it's not in the udeb, and neither in cryptsetup itself
<tepsipakki> any release-manager: a lot of fixes for x-x-o-ati from upstream, tormod has kept a version on his PPA, and I've merged it here: http://users.tkk.fi/~tjaalton/dpkg/ati/ati.debdiff
<pitti> soren: cryptsetup itself only ships the initramfs hook, but I don't see where it controls when the initramfs is updated?
<ogra> asac, i could tell you if my FF wouldnt hang :P, i think it was the feisty version
* pitti excuses for his blatant ignorance about how the installer works
<mjg59> seb128: Sigh. Built fine here.
* mjg59 looks again
<StevenK> pitti: It's like booting - magic
<pitti> StevenK: except that I at least now understand the booting part :)
<soren> pitti: initramfs seems to use triggers these days?
<pitti> soren: right
<pitti> soren: and both cryptsetup and the actual kernel bits trigger an update-initramfs
<pitti> soren: so whenever that stuff gets installed in the /target chroot, it should run
<soren> pitti: Yeah.. Hm...
<pitti> that's why I wonder how this could fail
<pitti> soren: this shuold have nothing to do at all with the udeb or the installer environment, unless there is some initramfs specific magic in d-i
<cjwatson> the finish-install script doesn't trigger an initramfs update though
<cjwatson> cryptsetup is installed way earlier
<pitti> cjwatson: so it has to? i. e. does d-i somehow inhibit update-initramfs when it installs stuff into /target?
<cjwatson> you're all confused
<pitti> I certainly am, sorry
<cjwatson> if there is a finish-install.d script that's expecting to affect the initramfs, it shouldn't
<cjwatson> it should be moved earlier
<ogra> asac, i used this one http://www.virtualbox.org/download/1.5.0/virtualbox_1.5.0-24069-1_Ubuntu_feisty_i386.deb
<soren> cjwatson: Right, of course. As I said: I'm not sure it does.
<asac> ogra: thanks ... lets see
<pitti> hm, I guess that's a script in partman-crypto then; it's not in the cryptsetup udeb
<cjwatson> exactly what script are we talking about here?
<cjwatson> finish-install.d/05crypto? soren said 05cryptroot
<soren> cjwatson: I just guessed that was the case as that would explain why the config is not in the initial initramfs.
<doko> pitti: please accept python-xml (NEW) 300k less on the CD
<soren> cjwatson: That was from memory.
<soren> cjwatson: finish-install.d/05crypto sounds right.
<cjwatson> 05crypto does nothing for us
<cjwatson> it's only relevant for loop-AES installs
<cjwatson> (and it's too late there too, but that's not important for us)
<cjwatson> pitti: d-i used to divert update-initramfs away and run it once at the end, but now that we have triggers it doesn't do that any more
<pitti> ok
<doko> dholbach, seb128: 337356 2 168678 usr/share/doc/gnome-games/changelog.gz usr/share/doc/gnome-cards-data/changelog.gz usr/share/doc/gnome-games-data/changelog.gz
<pitti> so I'm back at the beginning, wondering why it apparently doesn't happen
* pitti examines the diff between the initramfses
<cjwatson> so the problem is that update-initramfs -u after installation fixes something?
<pitti> right
<doko> asac: 209246 2 104623 usr/share/doc/network-manager/changelog.gz usr/share/doc/libnm-glib0/changelog.gz usr/share/doc/libnm-util0/changelog.gz (if you make an upload)
<pitti> it creates a very different initramfs which then has the necessary bits
<cjwatson> pitti: ok, so what's missing?
<pitti> most importantly, the /conf/conf.d/cryptroot file
<pitti> let me create a complete diff
<cjwatson> what generates that?
<pitti> cjwatson: /usr/share/initramfs-tools/hooks/cryptroot
<pitti> and that works now when calling it in the installed system
<pitti> it grabs the necessary bits from fstab and crypttab and writes that file
<mjg59> seb128: I really don't understand this build failure. Where does configure go?
<mjg59> seb128: Especially since it builds fine here
<cjwatson> pitti: could you put the installer syslog somewhere?
<pitti> also, right after installation I have an initrd.img-2.6.22-12-generic and a different initrd.img-2.6.22-12-generic.bak
<pitti> so u-i -u is called at least twice
<cjwatson> it will be, but that's not important
<seb128> mjg59: I'm getting the source to have a look
<pitti> http://people.ubuntu.com/~pitti/tmp/syslog
<soren> pitti: Does the .bak work for you?
<cjwatson> soren: I wouldn't bother
<cjwatson> it's very unlikely that the .bak will be better
<cjwatson> pitti: 403
<pitti> cjwatson: sorry, fixed
<soren> cjwatson: I know. But it does for me.
<soren> cjwatson: I just noticed that.
<pitti> ah, so the missing conf/conf.d/cryptroot is in fact the only difference
<pitti> weird, yesterday it was much more, but I did a slightly different installation mode now
<soren> pitti: Do you happen to have the .bak file that was there right after install?
<pitti> soren: yes
<pitti> I saved them all
<soren> pitti: Try booting with that.
<cjwatson> ok, so cryptsetup is installed between the base system and the kernel, as expected
<pitti> soren: indeed, that thing does have a cryptroot file
<pitti> to the *earlier* call gets it right, and the latest call doesn't; humm
<cjwatson> is it possible that the initramfs hook is expecting a kernel to be installed?
<soren> Could it be a bug in initramfs-update that doesn't move the .bak and non-.bak files around properly?
<cjwatson> or perhaps that it's being broken by some other initramfs hook, from what pitti said
<pitti> soren: it could very well be
<soren> pitti: I'll check the timestamps..
<pitti> soren: since the .bak did *not* get updated on update-initramfs -u
<cjwatson> soren: I'd rather bet on a hook invocation bug
<seb128> mjg59: http://pastebin.ubuntu.com/624/
<pitti> soren: I made backups of both the file and the .bak, and the .bak didn't change
<seb128> mjg59: that's your update
<cjwatson> you guys need a set -x trace
<cjwatson> of mkinitramfs probably
<cjwatson> but maybe update-initramfs as well
<pitti> cjwatson: will the output of that appear somewhere in the installer logs?
<seb128> mjg59: I think that shipping the config.log config.status and Makefiles make it do a clean and remove the configure
<soren> The syslog, I think.
<cjwatson> pitti: yes (as soren says), but I meant just on the regular system to see why .bak isn't being update
<cjwatson> d
<cjwatson> when is crypttab created?
<mjg59> seb128: Hm. make clean (or even make distclean) shouldn't do that, should they?
<pitti> ah, that
<seb128> mjg59: yes, should
<cjwatson> pitti: also check the state of /target/dev/mapper while cryptsetup is being installed
<seb128> mjg59: might be buddy, I didn't try to investigate
<cjwatson> pitti: there's specific code in base-installer to deal with that and it could be broken
<cjwatson> http://paste.ubuntu.com/625/
<mjg59> seb128: I've just unpacked what I uploaded and done debuild, and can't get it to fail like that
<pitti> when crypttab created> intersting question, I'll check it
<seb128> mjg59: like because you have the autotools installed and configure get regenerated?
<mjg59> Hm.
* mjg59 looks at the logs more closely
<seb128> mjg59: I can fix that if you want by doing with an update without the changes that you did out of the debian directory
<mjg59> seb128: Yeah, that would be good
<seb128> mjg59: ok, doing that
<pitti> soren: main difference between the .bak and the uptodate initramfs are ntfs-3g, fuse, and apparmor (and the removed cryptroot, of course)
<soren> pitti: Yes, that's what I see, too.
<mjg59> seb128: Thanks!
<pitti> soren: right, booting with the original .bak works
<cjwatson> how do I go about reproducing this in vmware?
<soren> cjwatson: Alternate installer, choose autocryptolvm partitioning.
<pitti> cjwatson: installing CLI speeds it up
<soren> cjwatson: (go for commandline installation)
<cjwatson> that's it?
<soren> Yes.
<cjwatson> mkay
<mdz> tepsipakki: anything with "a lot" in it is unlikely to be attractive to a release manager at this late hour, especially when it needs to be tested on a variety of hardware.  better to go for SRU
<pitti> cjwatson: right; that'll fail to boot, the initramfs .bak works, and so does update-initramfs
<pitti> cjwatson: to make it boot, do "cryptsetup luksOpen /dev/sda5 sda5_crypt" in the initramfs shell and then ^D
<tepsipakki> mdz: well, that's what tormod has been doing, asking people to test his versions :)
<cjwatson> I won't bother going that far
<mathiaz> soren: can you take a look at my dovecot merge ?
<soren> mathiaz: Sure thing. Where?
<mathiaz> soren: it's on p.u.c/~mathiaz/pacakges
<mathiaz> soren: http://people.ubuntu.com/~mathiaz/packages/
<mathiaz> soren: there is the merge from debian, with a FFe.
<mathiaz> soren: there is also a change for bug https://bugs.launchpad.net/ubuntu/+source/dovecot/+bug/146648
<ubotu> Launchpad bug 146648 in dovecot "Suboptimal defaults in dovecot.conf" [Medium,Triaged] 
<mathiaz> soren: I'm not 100% sure about my proposal. I've attached a patch to bug 146648
<ubotu> Launchpad bug 146648 in dovecot "Suboptimal defaults in dovecot.conf" [Medium,Triaged]  https://launchpad.net/bugs/146648
<mathiaz> soren: that I used in my merge.
<pitti> soren: ah, update-initramfs indeed runs twice
<pitti> soren: first after setting up linux-image, then after linux-ubuntu; I wonder why that doesn't use triggers
<soren> pitti: Only twice?
<pitti> soren: no, four times actually
<cjwatson> pitti: only -u uses triggers; the kernel package uses -k VERSION
<pitti> ah
<soren> pitti: It's probably because of multiple dpkg runs.
<cjwatson> not really worth fixing, IMO
<soren> I agree.
<pitti> no, just trying to understand where it could get wedged
<soren> if the result is correct, no problem.
<soren> It should be fixed at some point, though, but it's not important enough to try to pull it off at this point.
<dholbach> can somebody put a comment on http://lwn.net/Articles/253340/ or http://www.my10sen.com/2007/10/05/ubuntu-a-speedup-guide/ and tell people why the things mentioned on the page are bad for them?
<tepsipakki> mdz: what about just enabling those patches with confirmed success?
<lool> Do you people sign all your bzr revisions by default for Ubuntu repos?
<mvo> lool: I don't but I guess I should
<dholbach> lool: nope
<mdz> tepsipakki: I won't speak for the release team, but "works for someone" is not very compelling.  wouldn't you prefer to upload something better tested after release, rather than pushing in something less tested before release?
<tkamppeter> Riddell, KDE searches for physical PPD files and also for Foomatic XML data by itself, it is not prepared for the PPD generator concept of CUPS 1.2 and newer. foomatic-db-gutenprint would add Foomatic data, but take a lot of additional disk/CD space. The best would be patching KDE Printing Manager to run "lpinfo -l -m" (or do equivalent IPP call) and remove any direct PPD file and Foomatic scans.
<tkamppeter> Riddell, sorry for the long delays, but here is a holiday and so I am not at the IRC continuously.
<cjwatson> lool: I do
<cjwatson> I don't have create_signatures = always though, but I use gnupg-agent and it always seems to sign anyway
<tepsipakki> mdz: of course, but.. it's still just one driver with active upstream and people testing it :P
<tepsipakki> and the issues to be fixed are like bug 132716, bug 144297, bug 144011
<ubotu> Launchpad bug 132716 in xserver-xorg-video-ati "ATI Driver Gets Black Screen on Radeon 7500 Mobile (Regression)" [High,Fix committed]  https://launchpad.net/bugs/132716
<ubotu> Launchpad bug 144297 in xserver-xorg-video-ati "[RC410]  Xpress 200m with pci id 1002:5a62 and Linux 2.6.22 - X will not start" [Undecided,Fix committed]  https://launchpad.net/bugs/144297
<ubotu> Launchpad bug 144011 in xserver-xorg-video-ati "GUTSY. No video output firing up X." [Undecided,Fix committed]  https://launchpad.net/bugs/144011
<pitti> soren: ah, the .bak handling is a bit special in update-initramfs; it only keeps the original as .bak if it was used for booting; that explains why it is sometimes not updated
<Riddell> tkamppeter: the format KDE needs is like this http://paste.ubuntu-nl.org/39641/
<Riddell> tkamppeter: but I don't know how to get that information (e.g. the manufacturer) out of "lpinfo -l -m"
<soren> pitti: That sounds... special?
<lool> cjwatson: Weird, I have an agent too, but querying the signature_text as in James' blog post results in an exception
<pitti> soren: it is; but I don't think it's important for that bug, it just makes it unclear when the .bak was actually generated
<cjwatson> lool: which blog post?
<cjwatson> lool: I don't have any special configuration here
<lool> http://blogs.gnome.org/jamesh/2007/10/04/signed-revisions-with-bazaar/
<lool> It works with his repo, but not with the bzr repo where I last pushed
<soren> What does it mean if /var/lib/dpkg/status lists a conffile with "obsolete" at the end of the line?
<tepsipakki> mdz: upstream just confirmed that there should be a release this weekend, and that we "definately want master" :)
<cjwatson> I suppose it's possible I thought I was signing but am not ;-)
<lool> cjwatson: How did you check you were?
<lool> cjwatson: jamesh writes that there's no command to do this by default and gives a Python snippet to test it
<cjwatson> lool: if I commit and my agent doesn't have my passphrase cached, it asks me for it ...
<cjwatson> (well actually it fails because I'm using pinentry-curses but never mind that
<cjwatson> )
<cjwatson> so it's clearly signing *something*
<jamesh> John's plugin can check the signatures on a branch, but there isn't a builtin command
<lool> cjwatson: I didn't ask me until I had create_signatures = always
<lool> cjwatson: pinentry-gtk2 works here though :)
<mdz> tepsipakki: I'm talking about the Ubuntu 7.10 release
<cjwatson> lool: I'm sure it works, doesn't mean I like it ;)
<tepsipakki> mdz: sure, I meant ati :) Anyway, I'll do a FFe request once the new driver release is out (called either 6.7.195 or 6.8.0..)
<pitti> doko: python-xml and bzip2 binary-NEWed, thanks (right in time for publisher)
<ivoks> cjwatson: what happens with udev when /dev/ and /var/log/ are on different partitions?
<ivoks> cjwatson: and if /var/log/ is lvm, and doesn't get mounted before mv /dev/.udev.log to /var/log/udev
<cjwatson> ivoks: -> Keybuk
<ivoks> ok :)
<ivoks> ah, sorry...
<Keybuk> err ?
<Keybuk> how can /var not get mounted before that happens?
<Keybuk> oh, because I'm an idiot
<ivoks> i'm not sure, but there is a bug about empty 70-persistent-net
<ivoks> and when udev is restared, it's full
<Keybuk> ?
<Keybuk> bug#?
<Keybuk> (and what's that got to do with udev.log)
<ivoks> 149319
<ivoks> i don't know, but that's one more thing this user notices
<Keybuk> ok, well the first bit is colin's busybox bug
<tkamppeter> Riddell, the proceeding of CUPS is as folows:
<tkamppeter> 1. lpinfo -l -m
<ivoks> it's possible, ruben installed trough beta version
<soren> ivoks: Yes, this was fixed post-beta.
<Keybuk> so he wiped the file, and then rebooted
<Keybuk> and the file remained empty?
<tkamppeter> 2. Extract manufacturer from "make-and-model" field replacing Hewlett-Packard by HP and "Lexmark International" by Lexmark and then taking the first word as the manufacturer name
<soren> Keybuk: Yeah.
<Keybuk> eek
<Keybuk> who told him to udev stop && start? :p
<soren> Keybuk: Well, actually, it wasn't touched at all. If he trunc'ed it, it stayed emtpy. If he removed it, it didn't reappear.
<tkamppeter> 3. List manufacturers alphabetically, case-insensitively
<ivoks> Keybuk: I did :p
<Keybuk> ivoks: yeah, that's err, bad
<Keybuk> don't tell people to do that :p
<tkamppeter> 4. After user selects manufacturer, list all
<ivoks> ok
<Keybuk> udev stop = "I'm uninstalling udev"
<Keybuk> hmm
<Keybuk> I can see the problem
<Keybuk> cjwatson: are we frozen yet?
<soren> What does it mean if /var/lib/dpkg/status lists a conffile with "obsolete" at the end of the line?
<Keybuk> soren: lost from the package, but still on the disk
<soren> Keybuk: Thanks.
<soren> what's the proper way to see if a file is a conffile? I usually grep through /var/lib/dpkg/status, but that doesn't feel right :)
<Keybuk> that works for me :p
<tkamppeter> Riddell, 4. After user selects manufacturer, list all PPD entries which match this manufacturer case-insensitively.
<tkamppeter> 5. User chooses an entry, take its name field and use this for the "-m" option in the "lpadmin" command.
<tkamppeter> Note that "lpinfo" and "lpadmin" can also be replaced by IPP calls, see system-config-printer or KDE's code itself.
<soren> Keybuk: Hehe.. I just think I remember someone doing some clever dpkg-query trickery which I of course forgot.
<cjwatson> Keybuk: no
<Hobbsee> soren: somethign with grep-dctrl?
<soren> Hobbsee: That would make sense, yes.
<Hobbsee> as for what....i dont remember :
<Keybuk> update-initramfs: deferring update (trigger activated)
* Keybuk swoons with joy
<Keybuk> every time I see that, a kitten comes back to life
<ivoks> :)
<Keybuk> amitk: you can follow up to your bug here if you like :)
<doko> pitti: sane-backends and xsane in NEW (the last ones for today)
<pitti> doko: did you see cjwatson's list with broken /usr/share/doc/ symlinks?
<pitti> doko: processing, thanks
<doko> pitti: yes, working on these
<seb128> Riddell: is anybody working on gtk-qt-engine?
<seb128> Riddell: I start being tired of all the GNOME apps crashers we get about it, I'm considering adding an apport hook to refuse bugs when it's installed
<Kopfgeldjaeger> pitti: i now have 2 partitions on the "real" disk (/boot [ext3]  and the "physical volume for encryption). i created a / partition in the encrypted partition, but i cannot add another. (auto partitioning tells me that i probably have too much primary partitions...)
<pitti> Kopfgeldjaeger: no, you can only put one thing into an encyrpted partition
<pitti> Kopfgeldjaeger: i. e. one PV for an LVM, or one partition (/)
<seb128> pitti: would it be easy to make apport refuse to open bugs on GTK applications when gtk-qt-engine is installed and the backtrace has a defined symbol?
<Kopfgeldjaeger> aaah. i have to create the lvm myself, ok. thanks
<pitti> Kopfgeldjaeger: if you want to enclose several partitions in an encyrpted container, use LVM
<pitti> seb128: easy when the package is installed (just add to blacklist), doable with a custom hook
<seb128> pitti: ok, maybe something to consider next cycle then, thanks
<pitti> seb128: we're switching off apport anyway, so right
<seb128> pitti: yes
<Riddell> seb128: not that I know of, can't say I've noticed any problems, but feel free to point me at relevant bugs
<seb128> Riddell: there is 50 open bugs on the package
<seb128> so for sure there is some problems
<seb128> the most frequent one is that it makes gtk applications crash to gdk_events functions, not sure of why though
<seb128> 46 opens bugs now, I closed some duplicates
<seb128> Riddell: maybe that's a strategy to convince KDE users that GNOME is not stable, make it crash ;)
<Hobbsee> hah.
<bddebian> heh
<seb128> Hobbsee: maybe that's one of the reason why GNOME was not stable when you tried it BTW
<Hobbsee> seb128: the gtk-qt engine?
<seb128> yes
<Hobbsee> seb128: i tried to use all gtk apps, when on gtk.
<seb128> well, most of crashes we get happens under GNOME
<seb128> but KDE writes some gtkrc config to use gtk-qt-engine
<seb128> and that creates issues under GNOME
<Hobbsee> true - which is why i tested a clean install, iirc.
<Hobbsee> (no config)
<seb128> usually those crashes are fixed when they apt-get remove gtk-qt-engine
<seb128> Hobbsee: ok
<Hobbsee> but noted, for if i try them together :)
<LaserJock> seb128: would that cause pidgin to crash, by chance?
<soren> cjwatson: Will d-i need a rebuild to catch the fixed busybox?
<seb128> LaserJock: could, but that's not the most common crasher cause, usually those are due to applications bugs, do you have a backtrace?
<LaserJock> seb128: no, pidgin just seems to disappear a few minutes after I start it
<seb128> apport should be triggered and offer to send a bug
<LaserJock> nope
<pitti> soren: we need a rebuild anyway for the new kernel, btw
<seb128> weird, dunno why
<soren> pitti: point
<pitti> LaserJock: anything in /var/log/apport.log?
<pitti> LaserJock: maybe you ignored crashes for that version, etc.?
<LaserJock> seb128: btw, that problem I had in Feisty with the logout dialog freezing up went away when I dist-upgraded to gutsy
<cjwatson> soren: yes
<soren> cjwatson: Okay. do you plan on doing one soon?
<cjwatson> soren: yes!
<cjwatson> :-)
<cjwatson> I was just waiting for kickseed to land
<cjwatson> which it has now
<soren> cjwatson: Ok. Um.. I have a change for module-init-tools that I need to do..
<LaserJock> pitti: hmm, I do see a few pidgins in the apport log
<soren> cjwatson: I can't really tell if that will need to be done before.
<cjwatson> soren: oh?
<cjwatson> soren: yes, it will
<soren> Ok, I'll do it right away.
<LaserJock> I wonder why it never asked me about them
<cjwatson> build/pkg-lists/base:28:module-init-tools-udeb
<pitti> asac: https://bugzilla.mozilla.org/show_bug.cgi?id=398728 -> or "3. ship them under BSD/MIT"
<ubotu> Mozilla bug 398728 in General "mozilla/firefox source tarballs ship binary only files - conflicts with GPL/LGPL license terms" [Normal,New] 
<soren> cjwatson: Where's that from?
<Kopfgeldjaeger> pitti: installation works now fine! i hope the system will boot :-] 
<cjwatson> soren: debian-installer
<lool> Hmm on resume from suspend and hibernate, I get a popup that there was "Sleep Problem" but ... everything was fine
<pitti> Kopfgeldjaeger: chances are it won't; if not, please /query me, and we'll debug it
<lool> I tried searching for bug reports along these lines, but it's flooded by real problems
<lool> Does that ring a bell to someone?
<soren> cjwatson: *headdesk* of course.
<soren> Woo! My first upload to main. :)
* Hobbsee blames soren for all the bugs in main then :)
<soren> Yeah, it'll probably break all sorts of stuff. I'm that clever^Wlucky.
<soren> mathiaz: Sorry for the delay. Your patch looks sensible. I just want to run a few tests and I'll upload if it's good.
<soren> mathiaz: Great stuff!
* soren goes for coffee
<ScottK> pitti: Are you archive admin'ing today?  If so, I'd appreciate you doing Bug #149496.
<ubotu> Launchpad bug 149496 in dapper-backports "Please backport Postfix 2.4.5-3build1 from Gutsy to Dapper" [Wishlist,In progress]  https://launchpad.net/bugs/149496
<pitti> ScottK: ok, I didn't see that this morning
<ScottK> pitti: It wasn't there this morning.  I just finished with testing it.
<pitti> ScottK: done
<ScottK> pitti: Thanks.
<mathiaz> ScottK: you're part of the -backport team right ?
<ScottK> Yes.
<ScottK> Mostly the one that whines about backports not being for fixing serious bugs.  That's what SRUs are for.
<mathiaz> ScottK: I was thinking about the request we receive regarding samba upgrade.
<mathiaz> ScottK: yeah - I remember that :)
<ScottK> mathiaz: How about --> #ubuntu-server
<Keybuk> I have a desktop full of ~ files
<tkamppeter> Riddell, still there?
<tkamppeter> Riddell, see my Kubuntu Gutsy solution in bug 99372
<ubotu> Launchpad bug 99372 in kdebase "MASTER: [Feisty]  KDE Printing Manager does not list the PPDs of Gutenprint" [High,Confirmed]  https://launchpad.net/bugs/99372
<Kopfgeldjaeger> pitti: error while installing LILO
<lamont> anybody know a package off the top of their head that has the same version in feisty and gutsy, but different version in edgy?
<minghua> lamont: xfonts-wqy seems so. :-)
<pitti> Kopfgeldjaeger: oh, lilo?
<lamont> minghua: thanks
<pochu> lamont: xqf too.
<lamont> just needed an existance case.  thanks.
<Kopfgeldjaeger> pitti: thought the same. if i go into the menu with all options (i think you know what i mean), i cannot see grub anywhere
<pitti> seb128: ugh, that libgnome thing is much harder than I thought :/
<seb128> pitti: oh :(
<pitti> seb128: I fixed the logic for the aplay fallback, but I noticed that libgnome itself does not do the filename -> sound name mapping; apparently that's pre-filled by gnome-session
<pitti> seb128: for aplay I need the file names
<Kopfgeldjaeger> pitti: any idea?
<pitti> Kopfgeldjaeger: no, sorry
<seb128> pitti: /etc/sound/events has the mapping (or .gnome2/sound/events/ for user changes)
<pitti> seb128: oh, wait; nevermind, I think I found it
<seb128> ok
<pitti> seb128: yeah, problem is that this gets called by gnome-session, which pokes it into esd; apps call a different instance of the library, so I need to write it out somewhere
<ion_> keybuk: I got around to creating ion-meta, thanks again for the idea. :-) http://codebrowse.launchpad.net/~ion/+junk/ion-meta/files
<Keybuk> thank mdz :)
<pitti> meh, I *so much* don't want to reintroduce esound into the default install
<ion_> pitti: pulseaudio-compat-esound? :-)
<pitti> ion_: not ten days before the release, and our pulseaudio still sucks; we need a new version
<pitti> seb128: I can fix the login and logout sounds, but fixing the general plops and plings is going to be hard without esound
<seb128> pitti: login and logout would already be nice, we don't active other sounds by default anyway
<seb128> and people who need those can still install esd
<pitti> I can write out the cache to a file somewhere, but that's so icky
<pitti> or that
<pitti> and break their videos and get lockups on their desktop
* pitti puts pulse on the list of things for hardy
<LaserJock> have we frozen for RC yet?
* sladen grabs grabs the  latest and does a reboot to see what's still broken
<cjwatson> LaserJock: if https://launchpad.net/ubuntu/gutsy says "Active Development", then we haven't frozen
<tepsipakki> uh, lame adobereader package.. "no $HOME/Desktop.. ok, let's create one as root"
<lamont> db (4.6) is universe? ok
<minghua> tepsipakki: Why does adobereader has root privilege in the first place?  Is it suid?
<tepsipakki> minghua: sudo dpkg -i?-)
<amitk> Keybuk: err, what bug?
<minghua> tepsipakki: Huh?  Is the $HOME/Desktop/ dir created at installation time?  Or when you run Adobe reader?
<tepsipakki> minghua: installation time, since it tries to install a launcher there
<Keybuk> amitk: udev bug?
<Keybuk> maybe wrong nick :p
<minghua> I see.  Although that doesn't make sense to me at all.  Many people install packages as root (or sudo -H).
<ion_> A package writing *anything* to $HOME is evil.
<ion_> Especially for such a stupid reason as polluting the desktop with its icons.
<minghua> True, but that's what you get for using third-party packages.
<minghua> I personally never trust third-party binary packages.
<mdke> what's the syntax for closing bugs automatically with uploads? I see the ubuntu-docs upload today didn't do it
<evand> mdke: (LP: #00000)
<mdke> hmm, that's what I used
<evand> mdke: did the Launchpad-Bugs-Fixed header show up in the changes file?
<mdke> lemme see
<mdke> evand: no, I don't see it (http://launchpadlibrarian.net/9802239/ubuntu-docs_7.10.1_i386.changes)
<evand> mdke: you're missing the hash sign.  I think it has to be (LP: #00000)
<mdke> gah
<mdke> thanks evand
<evand> you're welcome
<Kopfgeldjaeger> does anyone have a working menu.lst for gutsy, luks/cryptsetup and lvm?
<Kopfgeldjaeger> i think i got grub installed manually, but i have no idea what to write to the menu.lst
<cjwatson> the hash is indeed mandatory
<cjwatson> see /usr/lib/dpkg/parsechangelog/debian for the implementation
<mdke> thanks
<soren> mathiaz:  Two things for the dovecot patch: If you could reload dovecot in dovecot-{pop3d,imapd}'s post{inst,rm}'s, that would be good.
<soren> mathiaz: and I still think we should do something to make dovecot work properly even when neither pop3d or imapd is installed.
<mathiaz> soren: yes. I noticed that too... I think there is even a bug about it.
<soren> There is.
<soren> It suggests to change the default from "" to "none".
<soren> I agree with that approach.
<soren> I doesn't agree with your rewriting magic in postinst, thought.
<mathiaz> soren: well - none won't work. It seems that it's still looking for imapd.
<soren> mathiaz: Oh, really? I'll look into that when I get back. I'm on my wait out the door to get some food.
<mathiaz> soren: ok.
<soren> mathiaz: How long are you around for?
<mathiaz> soren: hum.. another 2 hours.
<soren> mathiaz: That should suffice.
<soren> ttyl
<mathiaz> soren: ttyl
<Kopfgeldjaeger> i have no vmlinuz-* file in my /boot directory. how can create it?
<geser> Kopfgeldjaeger: then you have no kernel installed, vmlinuz-* is the kernel
<Kopfgeldjaeger> geser: i found it out just now, too. but the kernel is installed, but i created the whole /boot stuff etc. myself, so theres no vmlinuz file. currently im reinstalling linux-image-2.6.22-12-generic
<elmo> GAH, someone broke a2ps in gutsy
<nicolai> _Y_A_Y_! i got it working! cryptsetup/luks, LVM and gutsy!
<cjwatson> mdz: do you think it would be worth disabling fglrx and nvidia on the live CD for gutsy? the facilities to do that are already in lrm-manager, so it should be straightforward
<cjwatson> as you observe, they aren't used anywayon the live CD anyway
<sladen> elmo: file a bug!  ;-)
<evand> Can someone in core dev sponsor this: http://people.ubuntu.com/~evand/upload/gobuntu-meta_1.3.dsc .  Thanks in advance.
<kylem> evand, ok.
<soren> mathiaz: Do you have a bug reference for the thing about dovecot starting the imap server even though protocols was set to none?
<mathiaz> soren: nope.
<soren> mathiaz: Ok, here's what I'd like to happen: Default (if only dovecot-common is installed) should be "protocols = none". In pop3d's postinst, "none" should be replaced with "pop3 pop3s". Similar for imapd, of course. In their postinst, they should get removed and detect if protocols = would become empty and if so, add "none".
<mathiaz> soren: I discovered it while doing some tests.
<soren> mathiaz: I can't reproduce it.
<mathiaz> soren: try to install dovecot-common and dovecot-pop3, but not dovecot-imap
<soren> With your patches?
<soren> Or does that matter?
<soren> Ok, done.
<soren> Now what?
<mathiaz> soren: hum.. I'm checking.
<mathiaz> soren: ok. Set none to the protocols line and try to restart
<soren> Done.
<soren> Oh.
<mathiaz> soren: yop...
<heno> *** I've posted a custom entry on for tacking a custom ISO with unionfs 1.4. Please help test! ***
<soren> mathiaz: Ok, I'll be looking into that this weekend.
<soren> mathiaz: Will you look into the protocols rewriting thing?
<mathiaz> soren: well - I can. But I though it was pointless as the none option doesn't work.
<soren> mathiaz: I'll fix it.
* soren calls it a day
<slangasek> cjwatson: how often is germinate output regenerated?
<cjwatson> slangasek: four-hourly
<cjwatson> 2 */4 * * *             update-germinate
<slangasek> ok
<cjwatson> (ubuntu-archive@rookery; you should have access to that account I think, in case you want to kick a more urgent update)
<slangasek> hmm, I think that's the wrong question anyway; I can see that the germinate output is more recent than the CDs
<cjwatson> but the rookery mirror only updates once every six hours anyway, IIRC
<slangasek> the right question would've been, is it possible to get another rebuild of alternate CDs to confirm libdb4.3 is gone?
<cjwatson> actually, the germinate output on rookery runs off archive.ubuntu.com ...
<cjwatson> slangasek: sure, I think you can do it yourself, but best wait until the new debian-installer lands or the images will be useless
<slangasek> ok
<cjwatson> slangasek: as cdimage@antimony, 'for-project ubuntu cron.daily'
* ..[topic/#ubuntu-devel:slangasek] : Development of Ubuntu (not support, even with gutsy; not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/edgy/feisty, #ubuntu+1 for gutsy support | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Gutsy release freeze in effect
<bluefoxicy> ok
<bluefoxicy> what in the hell logic is this?
<bluefoxicy> [ "$1" != "" ]  && runlevel=$1
<bluefoxicy> if [ "$runlevel" = "" ] 
<mjg59> bluefoxicy: One of those is assignment, not equality
<slangasek> it's [ "$1" = "" ]  || runlevel=$1, written backwards
<bluefoxicy> and the runlevel=$RUNLEVEL line before that too, and then the usage note that's a result of that if statement.. I'm not sure exactly what that script is checking for
<mjg59> Or is sh more confusing than I remember?
<cjwatson> [ foo = bar ]  is equality. foo=bar is assignment.
<knix> ....
<bluefoxicy> mjg59:  no, the thing is I'm confused on what the rc script is doing.  It looks like it's (get current runlevel) => (if user gave a runlevel as an argument, then use that instead) => (if neither is assigned, tell the user he's supposed to give us one!)
<slangasek> bluefoxicy: that's correct
<bluefoxicy> there's always a current runlevel though, isn't there....
<slangasek> not always
<slangasek> not if pid 1 isn't init, e.g.
<bluefoxicy> ah, right.
<bluefoxicy> ok, makes sense now.
<bluefoxicy> (that's from /etc/init.d/rc)
<tkamppeter> Someone knows the IRC nick of Steve Langasek?
<Mithrandir> tkamppeter: slangasek
<kylem> slangasek could possibly be it
<bryce> slangasek
<tkamppeter> Sorry, I have seen a posting fromn him now.
<tkamppeter> <slangasek
<tkamppeter> slangasek, you have mail.
<slangasek> aigh my screen
<slangasek> :)
<tkamppeter> slangasek, it is about system-config-printer. I have packaged it to fix bug 149264 and bug 149529
<slangasek> tkamppeter: while I do have mail, I don't seem to have any from you yet.  I had a good idea that's what it would be about though :)
<tkamppeter> slangasek, I will resend it, as I accidentally sent it to the list, and there it gets auto-discarded
<slangasek> though these bugs are different than what I thought you were going to say, hmm
<Kopfgeldjaeger> maybe #144390 should be milestone=rc?
<Kopfgeldjaeger> argh, sorry ;)
<Kopfgeldjaeger> it already is
<bryce> slangasek: we have several high priority updates for the -ati drivers to fix "X won't start" issues reported recently and validated in testing.  timo had been going through finding more bugs the update fixes, and just missed the freeze cutoff
<tkamppeter> slangasek, resent the mail.
<slangasek> bryce: "freeze" only means "release team reviews and judges"; if they're high priority updates, upload them :)
<mjg59> bryce: Oh, btw, thanks for the X fix
<bryce> ok cool
<tkamppeter> slangasek, current s-c-p does not set up any Canon inkjet properly and messes up the menus.
<bryce> mjg59: no prob; I also have a list of synaptic bugs that I think that, plus your new gui tool, renders closable...  I'll go through them probably next week
<mjg59> bryce: I'm planning on doing quite a lot of synaptics work once I've got the thesis done
<mjg59> Should be doable in the hardy timeframe
<bryce> mjg59: awesome :-)
<bryce> mjg59: I also hope to spend more time on the input side of things in hardy, with xserver 1.4 in place
<donspaulding> I'm making a virtual package which only consists of a control file with dependencies and a changelog, is there anything I absolutely have to put in the rules file?
<slangasek> tkamppeter: ah, so as far as uploads are concerned, please subscribe ubuntu-main-sponsors to the bugs; they don't trust me to upload yet, just to block things that others upload ;)
#ubuntu-devel 2007-10-06
<tkamppeter> slangasek, so it is OK with the freeze? Then pitti or doko can simply upload it?
<slangasek> tkamppeter: yes, clear, targetted bugfixes are ok
<tkamppeter> slangasek, Thanks, I have subscribed bug 149264 and bug 149529 to the main uplod sponsors now and added an appropriate comment.
<ubotu> Launchpad bug 149264 in system-config-printer "Wrong driver selected for my Canon iP3000" [Medium,Fix committed]  https://launchpad.net/bugs/149264
<ubotu> Launchpad bug 149529 in system-config-printer "should not add an item to Applications -> System tools" [High,Fix committed]  https://launchpad.net/bugs/149529
<doko> slangasek, tkamppeter: uploading ...
<tkamppeter> doko, thanks.
<pochu> slangasek: is it ok to upload this liferea new upstream release? it's just a bug fix release, and works pretty well. It has been there for some days, but slomo, who sponsors me, hasn't had time to upload it...
<pochu> http://emilio.pozuelo.org/~deb/
<slangasek> pochu: upstream changelog please?
<pochu> slangasek: first lines of http://emilio.pozuelo.org/~deb/liferea-debian.diff
<slangasek> ah, that's the entire upstream changelog?
<pochu> yes, minor bug fix release.
<pochu> 1.4.3b -> 1.4.4
<pochu> slangasek: I've checked every commit for the release, and can ensure you it doesn't add new features.
<slangasek> pochu: the changes described in the changelog could have introduced regressions; I'd like to review the full upstream diff before accepting it
<slangasek> pochu: if it's not inconvenient for you, uploading it and having me review it there would be fine
<pochu> slangasek: I would do, but liferea is in main and I'm not even a motu... :-)
<pochu> And slomo hasn't been around for all the day... any volunteer?
<pochu> http://emilio.pozuelo.org/~deb/liferea_1.4.4-0ubuntu1.dsc <-- a big hug to the nice person who sponsors that!
<slangasek> pochu: right, if you don't have a sponsor already lined up, let me take the time to download what you have
<pochu> dget -x http://emilio.pozuelo.org/~deb/liferea_1.4.4-0ubuntu1.dsc is fast ;)
<lamego> liferea had some serious bugs on latest upgrades
<pochu> such as?
<lamego> http://sourceforge.net/project/shownotes.php?release_id=542165&group_id=87005
<lamego> 1.4.2b had a grave bug, then, 1.4.3 data loss
<lamego> all of them, bug fixing upgrades
<pochu> lamego: that isn't true. Those upgrades were fixing those bugs, but those bugs were already there in past releases. So there was no regression.
<lamego> pochu, please read the notes, " This
<lamego> problem was introduced with 1.4.2b."
<lamego> anyway I am just warning :)
<pochu> Hmm, true for the update interval. But not for the data loss.
<pochu> btw I've been using it for 5 days and I haven't found any regression.
<tepsipakki> slangasek: bryce already mentioned about ati, here's a debdiff that has fixes from git master and one of our own which will be pushed soon: http://users.tkk.fi/~tjaalton/dpkg/ati/ati.debdiff
<slangasek> tepsipakki: if it's nothing more than bugfixes, please upload and let the release team review it there
<tepsipakki> slangasek: right, forgot about that.. will upload :)
<slangasek> (also, if any of the bugs being fixed aren't yet milestoned, please milestone them or ask the release team to look at milestoning them)
<tepsipakki> yep, milestoned
<slangasek> pochu: liferea looks ok
<pochu> cool. any volunteer to sponsor me? http://emilio.pozuelo.org/~deb/liferea_1.4.4-0ubuntu1.dsc
<mjg59> pochu: I don't suppose that fixes the loss of posts on unclean shutdown?
<pochu> mjg59: I'm afraid it doesn't, nope :(
<pochu> http://sourceforge.net/tracker/index.php?func=detail&aid=1784045&group_id=87005&atid=581684
<ubotu> Sourceforge bug 1784045 "changes are not saved" [Pri: 8,Open wont] 
<xjkx> booting ubuntu 7.04 livecd i had an error like no such user/module layer or something wtf
<xjkx> oh sry
<ScottK> xjkx: Try #ubuntu for support
<xjkx> that channel sucks, too many messages then nobody sees it :P but i know...here you don't give support thats why i said sorry and went there
<ScottK> OK.
<xjkx> [caps lock]  :) [/caps lock] 
<slangasek> gutsy-alternate-amd64.iso         06-Oct-2007 05:46  656M
<slangasek> I feel as though something's missing...
<StevenK> The kernel? :-P
<slangasek> nope, it's there!
<StevenK> openoffice.org-base?
<slangasek> oh, heh, actually it looks like we are missing some kernel bits (l-r-m) due to an ABI change
<slangasek> and we also still haven't gotten rid of libdb4.3, hnngh
<kylem> sigh.
<slangasek> kylem: ?
* kylem mutters unprintable things about people breaking his X.
* kylem mutters unprintable things about how stupid he is to upgrade his kernel in the middle of watching a dvd.
<slangasek> they're printable on my screen, must be chipset-specific breakage
<kylem> yes, indeed.
* kylem goes back to watching house and being bitter.
<slangasek> oh, there we go, cdimage still had the old version of postfix, sigh
<rhkfin> Anyone else failing to start X w. 2.6.22-13-generic & nvidia ?
<rhkfin> 2,6,22-12 works good
<persia> rhkfin: It's waiting on a l-r-m update
<Hobbsee> slangasek: dont you have archive admin access yet?
<rhkfin> l-r-m?
<Hobbsee> or has l-r-m not even built yet?
<rhkfin> ah, restricted modules..
<slangasek> Hobbsee: sure; how does that help in this case?
<Hobbsee> slangasek: you have access to the new queue.  the new binaries are in the binary new queue.  i thought you were a RM and archive person in debian....
<Hobbsee> slangasek: https://edge.launchpad.net/ubuntu/gutsy/+queue?queue_state=0&queue_text=linux-restricted-modules-2.6.22
<Hobbsee> bottom 6.
<slangasek> oh
<slangasek> duh
<slangasek> didn't even occur to me that they were waiting in new :)
<sladen> slangasek: the word you're looking for is "touch" :)
<bryce> slangasek: still abouts?
<slangasek> bryce: yah
<bryce> I made some silly typos in my last bulletproof-x upload
<bryce> slangasek: mind okaying this debdiff?  http://people.ubuntu.com/~bryce/Uploads/xorg_7.2-5ubuntu12.debdiff
<Hobbsee> bryce: looks fine.
<StevenK> bryce: How much Perl have you coded? :-P
<StevenK> next is a Perl-ism, not a shell-ism. :-)
<bryce> StevenK: waaay too much ;-)
<slangasek> bryce: yes, please to upload
<bryce> thanks
<tepsipakki> slangasek: ati FTBFS (due to a typo in patch 10), but there is a new upstream already (with a proper version of that patch) and the delta is very small, so I'll just upload that, ok?
<tepsipakki> hm, it'll take a while ->
<slangasek> tepsipakki: what's in the very small delta, rm -rf * ? :)
<Fujitsu> Haha, it's in the >100MiB l-r-m, isn't it?
<bryce> slangasek: fixes for bugs that are not in our Launchpad yet iirc
<slangasek> bryce: if they're all straight bugfixes, then go for it
<bryce> slangasek: thanks, will do
<Keybuk> UserFriendly is weird last couple of days
<slangasek> s/days/years/, I'm pretty sure
<Keybuk> maybe
<Fujitsu> It has deteriorated of late :(
<Keybuk> it's referring to a "new" UK legislation about encryption keys
<Keybuk> except that it seems to be referring to the RIP Act, which is over seven years old now
<lifeless> internet time
<lifeless> in reverse
<Keybuk> :)
<lamego> hello, is anyone aware of a crash bug on gdebi ?
<lamego> i mean, gdebi-gtk
<lamego> hum, it is only triggered when installing an app after downloaded by firefox, which is odd
<mvo> lamego: what is the backtrace?
<lamego> anyone willing to reproduce the problem to make sure it is reproducable ?
<mvo> lamego: if it produced a crash file with a backtrace, that should be good enough for a bugreport
<lamego> ok, but I wanted to be sure is not specific to my config :P
<slangasek> if the backtrace is good enough, we might not need anything else
<lamego> I found a particular detail, it only happens on reinstall, not during install
<lamego> slangasek, but if I have a live sample it may allow you a better debug/fix testing
<lamego> I am filling the bug, but in case someone one to try: http://build.getdeb.net/abs/post_build/gutsy/webilder_0.6.2-1~getdeb1_all.deb
<lamego> hum, is is already reported
<sladen> lamego: make sure you add your report to it aswell
<lamego> https://bugs.launchpad.net/ubuntu/+source/gdebi/+bug/123674
<ubotu> Launchpad bug 123674 in gdebi "gdebi-gtk crashed with AttributeError in on_button_install_clicked()" [Undecided,Confirmed] 
<lamego> it's a show stopper
<lamego> the error is self-explanatory
<lamego> AttributeError: 'GDebi' object has no attribute 'unauthenticated'
<lamego> hum, how does gdebi checks for a package authentication ?
<lamego> mvo, is this future code ?
<slangasek> there we are now, 670MB and the packages are all there. :)
<Amaranth> 670MB? how did you get it so small?
<Amaranth> did we finally drop OOo? :)
<sladen> quick, lets fill it up.  back issues of ubuntu-calendar ftw!
<Keybuk> Amaranth: if only someone would write a GNOME presentation app, then we could!
* Amaranth runs
<slangasek> Amaranth: doko's crazy fdupes attack on evolution-common
<Amaranth> nice
<Amaranth> I never could figure out the output of that thing (the fdupe checker)
<ogra> Keybuk, what happened to criawips ?
* ogra always thought there was a gnome presentation app ... just not loved enough
<Keybuk> ogra: unmaintained, afaict
<ogra> ah, bad
<tepsipakki> slangasek: I lied, the debdiff was actually quite large, since the version I just uploaded doesn't have the changes as patches anymore, but it's safe nevertheless :)
<pochu> bryce: displayconfig-gtk isn't saving my changes, when I try to change the driver from i810 to intel. I'm running it from a terminal, and I just see this warning.
<pochu> *** Error: no screens were specified in the ServerLayout section
<pochu> bryce: it won't save the screen selection. Actually, it doesn't seem to be saving anything.
<pochu> bryce: or maybe it's saving it, but everytime I start displayconfig-gtk it doesn't show my actual settings, but the defaults one?
<pochu> brb, let's see if this is working
<pitti> Good morning
<mvo> hey pitti
<stgraber> hi pitti
<pitti> hey guys
<pitti> seb128: \o/ my libgnome works now (login/logout sound)
<pochu> heya pitti
<pitti> seb128: I just didn't manage to upload it yesterday any more; I'll clean up the patch and upload now
<stgraber> pitti: I'm about to reinstall my home server (new hardware) and would like to know if today gutsy server images should have a working cryptsetup ?
* seb128 hugs pitti, you rock
<pochu> bryce: this is working, so it was saving the changes. The issue is that when I open displayconfig-gtk those changes aren't displayed, as if I hadn't done them. I'll file a bug report in a bit.
<pitti> stgraber: problem is still that you need to do an "update-initramfs -u" after installation, then it works
<pitti> stgraber: we haven't figured out the reason for that yet
<pitti> stgraber: so if you don't mind a first broken boot, it works
<stgraber> does a "in-target update-initramfs -u" work too ?
<pitti> no idea
* seb128 kicks network-manager
<seb128> which does it start on upgrade and tell applications I'm not connected when I am on the internet just not using it
<Amaranth> seb128: So maybe when NetworkManager first starts it should advertise that it's connected until it determines otherwise?
<seb128> Amaranth: that's not a temporary state, it lists no wired or wireless connections
<Amaranth> Oh, so it's broken then
<seb128> yes ;)
<mdke> pitti: got a sec?
<pitti> mdke: sure
<pitti> doko: wow, you rock! downsizing evo by 27 MB??
<pitti> the alternates have loads of space now
<pitti> so I'll add back the amputated bits I chopped for beta
<pitti> mdke: please go ahead and upload the uncrippled ubuntu-docs then (maybe dropping the bar to 50%?)
<doko> pitti: +9 in gnome-user-docs, place for icedtea =)
<mdke> pitti: so that's what I wanted to talk to you about
<pitti> doko: +9? ugh
<mdke> doko: oh, did you do a gnome-user-docs upload?
<doko> mdke: yes
<mdke> doko: did you push the changes somewhere?
<doko> no
<mdke> can you? that package is maintained in bzr
<pitti> doko, mdke: erm, do we talk about gnome-user-docs, or ubuntu-docs?
<mdke> sorry, I wanted to talk to you about ubuntu-docs, but got distracted by gnome-user-docs (which the docteam also maintains)
<lastlemming> hello
<mdke> pitti: so about ubuntu-docs now. I need to check if daniel's upload yesterday was the crippled version; it looks from the changelog that he didn't get my changes for that
<lastlemming> 7.10 RC will out this thurday right?
<pitti> lastlemming: yes
<mdke> pitti: with the next upload, could I also have your permission to update the translations in the package, they are a bit out of date and it would be nice to update them.
<pitti> mdke: sure
<lastlemming> thx pitti
<mdke> pitti: thanks, I'll do that this weekend then
<mdke> doko: so, gnome-user-docs, would you mind pushing your changes to LP so we can update the main branch?
<doko> mdke: http://people.ubuntu.com/~doko/tmp/gnome-user-docs.debdiff , afk now
<mdke> doko: thanks, and thanks for improving the package too :)
<mdke> doko: it didn't apply cleanly, I guess you didn't get the source from bzr? I thought that it did it automatically with those packages that are maintained there
<Kopfgeldjaeger> hi
<seb128> doko: is that normal that /usr/share/doc/evolution is empty now?
<er4z0r> hi
<er4z0r> I just updated to gibbon and now I cannot get my wireless-card to wrok
<pitti> seb128: it shouldn't be; evolution-common does not ship any docs AFAICS
<seb128> pitti: there is nothing, no changelog, no copyright, etc
<seb128> same for evolution-common
<pitti> seb128, doko: oh, it does, but I guess the preinst removes it
<pitti> seb128: /u/s/d/evolution is a symlink to evo-common
<seb128> which is empty
<seb128> $ ls -l /usr/share/doc/evolution-common
<seb128> total 0
<pitti> if [ "$1" = upgrade ]  && [ ! -L /usr/share/doc/evolution ] ; then
<pitti>     rm -rf /usr/share/doc/evolution
<pitti> fi
<seb128> ii  evolution-common         2.12.0-0ubuntu4          architecture independent files for Evolution
<pitti> somehow this wreaked havoc
<seb128> bah
<seb128> anyway lunch time for now
<seb128> see you later
<pitti> seb128: libgnome uploaded, btw
<pitti> seb128: it waits RM approval now, but feel free to snatch it from the queue and try :)
<pitti> kylem, BenC: can someone please upload l-b-m for abi -13?
* LongPointyStick waves
<LongPointyStick> hiya pitti
<pitti> hi Hobbs^WLongPointyStick
<LongPointyStick> :)
<LongPointyStick> dammit, i wish i'd booted into the right kernel...
<pitti> have a good weekend everyone!
<LongPointyStick> bye pitti!
<LongPointyStick> weekends are overrated.
<Karnaugh> bryce: updated #149726
<Karnaugh> bryce: the driver off ATI site seems to work
<Hobbsee> kylem: ping
* Hobbsee waves to cjwatson_
<kylem> Hobbsee, hi.
<Hobbsee> kylem: you mention in http://www.gossamer-threads.com/lists/linux/kernel/828214 that the change is wrong.  you're right - sbalneav's X has been broken by it, by this new kernel upload
<kylem> i know.
<Hobbsee> kylem: ah, OK.
<kylem> unfortunately it apparently fixes another bug.
<Hobbsee> kylem: you cant just make hte corresponding change to xf86-video-intel?
<Kopfgeldjaeger> does anyone have some configs using lvm+cryptsetup for me? (menu.lst, fstab etc.)
<kylem> Hobbsee, the point isn't that it's wrong, it's that it was wrong for 2.6.23
<Hobbsee> kylem: indeed.
<sbalneav> kylem: Morning!
<kylem> hi.
<sbalneav> kylem: Was going to mention my G33 got bitten by the kernel update, however, Hobbsee's already beaten me to the punch :)
<kylem> Hobbsee, if i i upload a fixed xf86-..-intel will you approve it?
<Hobbsee> kylem: just to fix that?  i can via irc, but i have no archive admin access
<Hobbsee> kylem: so i'm of limited help
<Hobbsee> cjwatson: may be around to actually shove it thru
<kylem> you're an RM, i can do the archive admin evil.
<Hobbsee> kylem: ok, fine by me
<Hobbsee> kylem: one day i'll ask for archive admin, i think :)
<sbalneav> kylem: If you'd like to point me at a place where you've got the package sitting on an HTTP server, I can grab it and try it here quickly, if that's helpful.
<Hobbsee> sbalneav: that'd be good
* kylem reboots to test
<kylem> sbalneav, amd64?
<sbalneav> No, Intel Core Duo
<kylem> s/amd64/64-bit/?
<sbalneav> No.
<kylem> darn. ok.
<sbalneav> I'm running 32
<sbalneav> Good? Bad? Indifferent? :)
<kylem> people.ubuntu.com/~kyle/ has the dsc,diff,changes if you want to build it on i386
<kylem> i'm testing on amd64 atm
<sbalneav> ok, I can do that.
<kylem> well, will be in a second when i reboot
<kylem> it works. ship it. :)
* Hobbsee has an i386 version
<Hobbsee> http://wedontsleep.org/~sarah/
<kylem> heh, ain't that the truth, i went to sleep at 6am
<sbalneav> Ok, got it, gimme a second to reboot
<sbalneav> brb
<minghua> StevenK has interesting domain names...
* Hobbsee wonders if it's worth testing on a random intel machine
<Hobbsee> minghua: yes, seems so.
<LongPointyStick> uhh...
<StevenK> Uh?
<sbalneav> Yup
<LongPointyStick> my X appears to have died.
<sbalneav> Works like a charm
<sbalneav> hehehe
* LongPointyStick wonders if that's from removing -i810
<sbalneav> LongPointyStick: O-RLY?
<sbalneav> LongPointyStick: kylem just fixed it.
<LongPointyStick> yep, that does it.
<sbalneav> kylem: Thanks, dude.
<LongPointyStick> note to self: dont remove -i810 driver
<sbalneav> Where'd Hobbsee go?
<LongPointyStick> here
<sbalneav> Oh, lol
<sbalneav> Didn't recognize the alternate nick.
<sbalneav> Now I feel like a dope :)
<LongPointyStick> :)it's secret for a reason
<LongPointyStick> okay, so my X entirely breaks with just the -intel driver.  that's interesting.
<sbalneav> Linux phobos 2.6.22-13-generic
<sbalneav> ii  xserver-xorg-video-intel                   2:2.1.1-0ubuntu6
<sbalneav> Looks like I'm running on all the latest goodies.
<kylem> the problem is if people upgrade and don't reboot just restart X, they'll be boned too
<Hobbsee> kylem: oh, was that my problem?
<kylem> you need -13 running for that -intel to work (on G33 hw)
<kylem> it shouldn't change anything for anyone else.
<sbalneav> I've always considered not rebooting when the reboot icon to pop up to be asking for trouble, so I always reboot when there's a kernel upgrade.
<sbalneav> kylem: Will you be in Boston?
<kylem> unfortunately not.
<sbalneav> Ah, well, then I'll have to send you and e-beer, as opposed to buying you a real one :)
<kylem> heh, don't worry about it. i had tofix it anyway so i could keep watching house. :)
<sbalneav> I hope when they do a show finale, it ends up being lupus.
* StevenK idly wonders if kylem plays the House drinking game.
<StevenK> "Every time they say Lupus, take a drink" "Every time House insults Cutty, take a drink." ...
<kylem> StevenK, nope, but that sounds like a brilliant idea.
<kylem> is there a full rule list?
<StevenK> http://forums.televisionwithoutpity.com/index.php?showtopic=3127762
<StevenK> I found that, but it isn't the list I remember.
<sbalneav> kylem: Off to make breakfast for the fambly, thanks for the help!!
<kylem> np
<StevenK> pitti: Weekend, you say?
<pitti> sort of; I need to wrestle with some fiscal authority stuff
<pitti> meh, why did this desktop only boot half up?
<Kopfgeldjaeger> pitti: i got it working (manual partitioning+cryptsetup+lvm)
<pitti> yay
<Kopfgeldjaeger> i had to boot a live-cd, chroot into the system, install-grub /dev/sda and edit fstab/crypttab/menu.lst
<Kopfgeldjaeger> and, cryptsetup shows (after entering the password): "could not set up lvm". but it works
* stgraber is installing cryptsetup on 3 different HDDs + LVM, let's hope it'll work fine
<kylem> Hobbsee, did you approve it?
<Hobbsee> kylem: yes, sorry for not being explicit
<kylem> Hobbsee, np,i don't see it on drescher so i was confused
<Hobbsee> kylem: i have no access, and they keep switching machine names around.  so i dont know where it's supposed to be.  it certainly hit unapproved, i can see that much
<kylem> ok.
<Hobbsee> kylem: like i say, one day i'll probably ask for shell access.
<kylem>   288657 | S- | xserver-xorg-video-i | 2:2.1.1-0ubuntu6     | 1 hour 30 minutes
<Hobbsee> and see what happens
<kylem>          | * xserver-xorg-video-intel/2:2.1.1-0ubuntu6 Component: main Section: x11
<Hobbsee> yep
<kylem> there it is (in unapproveD)
<Hobbsee> yep
<kylem> cool, thanks
<hunger> grub forgot about my windows installation. Is that a bug in gutsy or did I do something wrong?
<Hobbsee> hunger: where did you have your windows installation, in menu.lst?
<Hobbsee> hunger: in particular, did you have it below line 52?
<hunger> Hobbsee: I had windows installed and then installed gutsy from the alternate beta CD.
<Hobbsee> oh, and windows never got put there at all?
<hunger> Hobbsee: Just pressed ESC to see the grub menu for the first time and no windows.
<Hobbsee> might be a bug, but likely hard to reproduce
<hunger> Dunno whether it ever was there... you no longer show the menu:-(
<Hobbsee> hunger: people seem to like putting it between the ## BEGIN AUTOMATED section, and ## END AUTOMATED sections.  and then wonder why it goes missing.
<Hobbsee> so, assuming you didnt edit your menu.list to do that, it's quite possibly a bug.  if you can reproduce it
<StevenK> menu.lst, too
<Hobbsee> yeah, that.
<Kopfgeldjaeger> stgraber: um... with gutsy and the alternate installer?
<stgraber> Kopfgeldjaeger: gutsy and server install yes
<Kopfgeldjaeger> stgraber: i guess it wont work. but tell me anyway :-) if it doesnt work, im maybe able to help you
<gustavonarea> Hello. I have a Toshiba Satellite L35 laptop and sounds is not working with the latest 2 kernels. I
<gustavonarea> I have an up-to-date Gutsy
<luca> hi everyone
<Kopfgeldjaeger> gustavonarea: better go to #ubuntu
<luca> the daily updates on gutsy have broken my nvidia and dual-core support :( any suggestion?
<gustavonarea> Kopfgeldjaeger: ok, thank you!
<crimsun> luca: with linux-restricted-modules-2.6.22-13-generic 2.6.22.4-13.6 installed?  BTW, this is better addressed in #ubuntu+1.
<luca> crimsun: yeah. :) I tried in ubuntu+1 but received no good help
<xbehave> is there anycahnce that ndiswrapper will ever be added to ubuntu live CDs?
<stdin> xbehave: ndiswrapper-common and ndiswrapper-utils will be/are on  the gutsy live CD
<xbehave> ill check next time i boot i didnt think they were on mine!
<highvoltage> is automated-ubiquity actually working yet?
<encompass> hey guys... can I have a volunteer for a quick test for a bug in gutsy?  It is a simple gtk test... any takers?
<ScottK2> encompass: You might have more luck on #ubuntu-bugs or #ubuntu+1
<encompass> oh they have something like that?  cool, let me go there... thanks...
<Kopfgeldjaeger> encompass: if you still need somebody, i can do it
<lamego> encompass, shoot
<encompass> I will give the bug report in a sec
<encompass> lamego: https://bugs.launchpad.net/ubuntu/+bug/149980 have fun!
<ubotu> Launchpad bug 149980 in ubuntu "some svg files don't display correctly in a GTK widget..." [Undecided,New] 
<Chipzz> encompass: that's most likely not a gtk+ bug, but a librsvg bug
<Chipzz> (you should file it against that, at least)
<Chipzz> the svg pixbuf loader is *not* part of gtk+
<Chipzz> but gets built from the librsvg source
<Chipzz> (iirc)
<encompass> Chipzz: thanks for the pointer I will update the bug
<Chipzz> encompass: the exact package is librsvg2-common
<cjwatson> highvoltage: should be, folks are starting to use it
<encompass> Chipzz: thanks... and just found it is fixed in gutsy thanks guys
<luca> hi everyone
<Kopfgeldjaeger> hi luca
<luca> does someone know how much time will be needed before the restricted modules/drivers are compiled for latest kernel? :)
<Kopfgeldjaeger> choose the main server
<luca> ?
<luca> oh wiat
<luca> wait
<Kopfgeldjaeger> are you using a local mirror? like ch.archive.ubuntu.com etc.
<luca> I am using gutsy beta ;-/
<Kopfgeldjaeger> yeah.
<lamego> restricted is already fine for me
<Kopfgeldjaeger> its already on the main server
<luca> which one? can you copy the line please?
<luca> some of the restricted (realtek, iwp345) are ok
<luca> others (nvidia, dual-core) not
<lamego> nvidia is ok, I am using it
<Kopfgeldjaeger> just archive.ubuntu.com in your /etc/apt/sources.list
<lamego> and I am using a local mirror
<Kopfgeldjaeger> atm it may be de.archive.ubuntu.com or whatever
<luca> let me see
<luca> deb http://archive.ubuntu.com/ubuntu/ gutsy main restricted
<luca> it should be ok I guess; still, my nvidia does not function - API kernel mismatch
<Kopfgeldjaeger> hmm
<luca> and at least according to kde-power-guidance-manager, the system sees only one cpu, not two, as it should as I have a dual-core
<stgraber> luca: cat /proc/cpuinfo is the best way to check how many CPU are really used
<luca> stepping?
<stgraber> luca: in your case you should have processor:0 and processor:1
<luca> nope just processor: 0
<stgraber> maybe : dmesg | grep -i cpu
<stgraber> will give you an idea of where the problem is
<luca> !pastebin
<ubotu> pastebin is a service to post large texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu-nl.org (make sure you give us the URL for your paste - see also the #ubuntu channel topic)
<luca> http://paste.ubuntu-nl.org/39800/
<highvoltage> cjwatson: do you perhaps know someone who uses it who I could ask a bit? I couldn't find any documentation on it, and would like to fix that
<stgraber> the warning is the problem, it looks like there is a CPU limitation of 1
<stgraber> so the second one (second core in fact) is ignored
<luca> uhm how would I correct the issue? Is it a problem in how the kernel was compiled and got into a binary?
<mjg59> luca: You're booting the -i386 kernel, not -generic
<mjg59> -386 has no SMP support
<luca> yeah the generic though gives me the same problem
<luca> I guess
<mjg59> No, it doesn't
<luca> uhm I will have to purge the 386 then and retry
<luca> the NVIDIA problem remains though...well let's try for the dual core :)
<luca> ok removing the 386
<stgraber> while speaking about kernel, it's time for me to reboot on -13-generic, see you in a minute
<luca> hope things will be smoother than for me ;)
<luca> ok rebooting
<superm1> other than it being !weekend, would any archive admins happen to be hanging around?
<luca> actually it did function
<luca> removing the 386 kernel I mean
<luca> now only Nvidia problem :-/
<pochu> any -core-dev awake to upload liferea?
<geser> pochu: !weekend
<pochu> geser: yeah I know but if you are here why can't be a -core-dev? ;-)
<luca> night
<pochu> geser: when will you apply for -core? :)
<geser> pochu: contrary to core-devs MOTUs work also at the weekend :)
<pochu> hehe
#ubuntu-devel 2007-10-07
<cjwatson> highvoltage: best talk to evand, who wrote it
<Kopfgeldjaeger> n8
<m1ke> Will a xbox 360 wireless controller be supported in future updates?   Just curios since it is so popular and a preferred controller of choice.
* lamont looks around for someone who can explain http://launchpadlibrarian.net/9420116/buildlog_ubuntu-gutsy-hppa.gmetadom_0.2.5-1ubuntu1_FAILEDTOBUILD.txt.gz to him
<mekius> bryce: ping
<bryce> mekius: rather than ping me, just ask a question, so I can answer it when I get back, even if you're not
* Hobbsee pings bryce with no question
<mekius> bryce: I apologize :)
<mekius> bryce: Is the use of xdebconfigurator sane, or should i really be using something else?
<mekius> i noticed it is looked for in the dexconf script
<mekius> and is used if there
<bryce> hmm, I don't notice 'xdebconfigurator' in my dexconf
<mekius> oh wait
<mekius> it is in the 20xconfig script in the casper-bottom scripts in initrd
<mekius> sry about that, been looking at a lot of files trying to put this auto loading of drivers together
<bryce> no prob
<bryce> yeah it's a confusing nest of scripts in there
<mekius> it seems though that xdebconfigurator uses a card db of sorts to setup the debconf database with the right X values
<mekius> so that when dexconf reads it, it actually gets an autogenerated one
<mekius> but there might be something else in place already
<bryce> hmm, unfortunately I'm not too familiar with casper internals yet
<mekius> ok :)
<mekius> yeah, it is hard to find any docs on this type of stuff :)
<bryce> yeah
<bryce> can you explain what you're thinking you need it for?
<mekius> well i don't know if you remember me, but we need to make sure a custom VIA driver loads for X, but don't want to break compatibility with other systems
<mekius> but i'd like to do it as right as possible
<bryce> ah, right
<mekius> in case we work anything out with others
<mekius> but dexconf reads from debconf db, just trying to find the piece that auto configures the db
<mekius> and xdebconfigurator seems to do that :)
<bryce> I think now you know more about this area of the code than me.  :-)
<mekius> hehe
<mekius> xorg 7.3 will be nice
<mekius> it is suppose to do all this by itself
<mekius> will be very cool if it works well
<bryce> which package is the 20xconfig script in?
<mekius> well it is part of the casper scripts, i'm not entirely sure :)
<mekius> the scripts inside the initrd image
<bryce> yup; of course that's not magic either - you'll want to make sure your driver is accounted for inside the x codebase so it gets detected and loaded correctly
<mekius> yep
<mekius> but i hope they make it easy to update this or something
<mekius> if it is hardcoded that doesn't seem too good heh
<bryce> it's hardcoded, but the code itself is pretty straightforward... just setting some defines and stuff
<mekius> hmm
<bryce> ok, found it in 'casper'
<mekius> why not make this editable via a card database or something so if someone does have a newer card or a weird card, support can be added in a custom distribution for that PC
<bryce> I suppose they don't see that as a huge need, but I'm not sure.  I imagine they'd say, "Send us a patch."  ;-)
<mekius> yeah hehe
<mekius> thx for all the help btw
<bryce> sure, I'm digging into xdebconfigurator right now
<bryce> looks like it's a wrapper around a variety of detection tools
<mekius> yeah
<mekius> tries to get strings and compare them against data in a Cards file
<mekius> i installed the hwdata package but it didn't have a Cards file :P
<mekius> i found a random one at /usr/share/apps/guidance/Cards+
<mekius> seems to follow the format but not sure heh
<bryce> oh that's different, that's for kde-guidance.  unrelated
<mekius> yeah i know
<mekius> but the format of the file is pretty much identical :)
<mekius> and has quite a few of the cards in it
<mekius> not sure why the hwdata package doesn't contain the Cards file unless there is no central file
<mekius> and you are meant to just define you overrides
<bryce> ok I get what's going on here
<bryce> xdebconfiguration is a wrapper script that calls a variety of different underlying hardware identification systems
<bryce> one of the systems it calls is discover, which I mentioned the other day
<mekius> yeah
<mekius> i figured this is the one i will want :)
<bryce> I *think* that all you need to do is get your card+driver recorded in one of the underlying programs (i.e., insert it into discover-data, as I described before), and this should pick it up from there
<bryce> xdebconfigurator will read the info from discover, and populate debconf with it
<mekius> ok nifty, let me check this out :)
<mekius> /lib/discover eh
<mekius> ?
<mekius> has a bunch of xml files :)
<mekius> sweet, yes, this looks like the one :)
<mekius> awesome, thx again, sometimes it helps to have that little push in the right direction :)
<bryce> I have to say thanks myself - this xdebconfigurator finally explains the one piece of the whole process that was still sort of a black box to me.
<mekius> :)
<mekius> yeah, for some reason it wasn't on our live cd
<mekius> i'm not sure if i accidentally removed it at some point :/
<mekius> bryce: VIA has an open source driver that they develop, I don't know all the details of how open source it is or how much community involement they have, but what are the chances of this driver being able to be on the livecd and such to better support VIA hardware?
<bryce> heh
<bryce> there's quite a story here
<mekius> hehe
<bryce> there are actually three drivers for via.  -via, -openchrome, and -unichrome
<bryce> all are adequately open source
<bryce> -unichrome was a fork of it, that the community began developing
<mekius> yeah, via -> openchrome
<bryce> however due to a strong personality leading that effort, the community forked again, to make -openchrome
<mekius> unichrome is supposedly better coded, but doesn't support as much :)
<mekius> yeah i read most of it heh
<bryce> I think partly due to this forking, it's hampered things
<mekius> yeah, i can imagine
<bryce> -via is the most official, but if I understand correctly, isn't very actively developed
<mekius> the unichrome dev doesn't want to just put in new cards and features though unless they are coded perfectly :)
<mekius> via i think is dead
<bryce> I do not know if VIA is involved in its maintenance
<mekius> i think openchrome has picked it up
<mekius> i don't think so, they have their own driver
<mekius> which i believe they release source for
<mekius> and we are actually in talks to hopefully get this stuff even more out there and open
<bryce> hmm, then that would be a fourth.  :-P
<mekius> indeed, but this one should support most new hardware, but might be a bit less stable, not sure :)
<bryce> url?
<mekius> viaarena.com is their open source "portal"
<mekius> well community portal i gues
<mekius> guess*
<bryce> anyway, I've heard good things about -openchrome and have considered promoting it to main and making it the default for via hardware; I hadn't thought about the livecd, though
<mekius> i haven't looked at the licensing for them, but if there are any conflicts with packaging it, let me know and we can discuss this with them :)
<mekius> yeah, openchrome is pretty good as far as i can tell
<mekius> but still lacking support for the newest cards :)
<mekius> openchrome has 3D for most of the older cards (can't imagine very fast, but doesn't hurt)
<mekius> they are talking of trying to do compiz type effects on these cards, i'm a bit skeptical :)
<mekius> bryce: i think this is it, has all the cards in there and I think the ones we have aren't returning anything, so i'm updating it and hopefully the via driver will load :)
<mekius> will be so awesome if it does :)
<bryce> great!
<mekius> honestly it sucks that they all name their driver via :P
<mekius> otherwise you could do hints for the different drivers heh
<mekius> cause certain cards work best with the different drivers :)
<bryce> yeah
<bryce> hmm, poking through a few of their drivers, yeah they look like they're all licensed BSD
<bryce> doesn't seem like they've structured things open source-ish though... no mention of how to contribute stuff, no sign of public rcs, etc.
<bryce> so guess it qualifies as open source by license, not open source by community
<mekius> yeah
<mekius> which is what i've seen as well
<mekius> so i think I and my team will try to push them to open up to the community
<mekius> they have a lot of packaged versions
<mekius> so i'm not sure if they do those themselves or have people do them for them
<bryce> that'd be good.  I wonder if there's an overlap with what the openchrome folks are doing
<mekius> the build system they have for their drivers is kinda ugly though :P
<mekius> i don't think so
<mekius> afaik the openchrome is just an extension of the original via driver and continues by just using docs that are available
<bryce> ah
<mekius> would be nice if via would fuel openchrome though
<mekius> as openchrome is closer to the community and seems like a better overall drivers
<bryce> yeah
<bryce> unfortunately that hardly ever works out for a company to collaborate with an existing open source community
<mekius> yeah :/
<bryce> mekius: do you know if some of their drivers are already in ubuntu?
<mekius> i really think they could help each other a lot
<bryce> agreed
<mekius> openchrome and via are in there
<mekius> i don't think the unichrome drivers are in ubuntu
<mekius> the via driver has feisty packages i believe, but not in the repo
<bryce> what about their savage driver?  is that the same as xserver-xorg-video-savage?
<mekius> not sure on that one
<mekius> those cards are so old lol
<bryce> yeah
<mekius> it probably is not though
<mekius> i love intel right now, working right with the community and contributing to the intel driver shipped with xorg
<mekius> just lovely :)
<bryce> yup
<mekius> i bought an intel laptop largely because of that
<bryce> yup, I got a laptop and a desktop because of that
<mekius> :)
<bryce> they've got a fair number of bugs though
<mekius> gonna build a desktop soon, might go amd though, still deciding on the video card for that heh
<bryce> but I like that the process is open and we can just chat directly with the devs about the problems
<mekius> might go with an nvidia integrated until AMD releases enough specs to have a great driver for their stuff :)
<mekius> bryce: yes, that is so nice
<bryce> we've really been enjoying working with alex deucher on -radeon issues
<mekius> how long before they release some more specs?
<mekius> btw, do you work on X or what is your specialty?
<bryce> yes X
<bryce> I don't know when they're going to release more specs, but I suppose it should be any time now
<bryce> I talked with one of the development managers for fglrx at XDS.
<mekius> neat
<bryce> smart fellow, but I wasn't as impressed at his attitude towards open source
<mekius> yeah
<mekius> i think some people just can't understand it
<bryce> but it's amazing they're releasing the specs
<mekius> I'm sure some of the long time ATI devs might be sore about that :)
<mekius> maybe they feel threatened hehe
<mekius> the only holdout is nvidia
<mekius> hopefully they will crack too :)
<bryce> it sounded like AMD's strategic goals required having their graphics chips with an available open source driver
<bryce> I'm not so sure about that
<mekius> that is cool
<bryce> the reason ATI released specs is to support AMD's main processor sales
<mekius> well you open source the driver, you open yourself up to embedded linux stuff much more
<bryce> nVidia doesn't have that pressure
<mekius> yes, true
<mekius> i think the gpu should be just as open as the cpu at this point though
<mekius> they are both processors, different instruction set
* bryce nods
<mekius> anything ever happen with that open graphics project?
<bryce> you might be right, as embedded devices gain more sophisticated graphics capabilities
<mekius> indeed
<bryce> which one?
<mekius> not sure
<mekius> i recall one where they were building it ground up
<mekius> designing the processor, making the drivers
<bryce> the one to design an open design for a graphics chip?  don't know, but I think they took on a pretty ambitious objective
<mekius> yeah heh
<mekius> i don't think the hardware was as capable as today's hardware
<mekius> not sure if it could hold against intel or what not heh
<mekius> http://wiki.opengraphics.org/tiki-index.php
<tepsipakki> mekius: unchrome is in universe since edgy
<tepsipakki> unichrome..
<tepsipakki> anyone here who could push the new ati package, currently waiting for approval?
<Treenaks> hm, bugs.freedesktop.org's cert expired les Wednesday
<Treenaks> les=last
<Amaranth> mjg59: any idea how resume from suspend could fail on the ptyb9 device?
<nicolai> siretart: any progress with the cryptsetup@installer thing? can i help somehow? i got it working in QEMU (manual partitioning, cryptsetup, lvm)
<Lhademmo1> , can anyone tell me where in the docteam svn trunk is the GNOME Desktop Users Guide? I can't find it!
<gameldar> heya all
<minghua> Lhademmo1: Are you sure docteam has a svn repo for GNOME desktop user's guide?
<gameldar> just looking at https://wiki.ubuntu.com/SponsorshipProcess - I have a fix for a bug I need to upload for sponsorship. Does the requestsponsor script work for others in gutsy?
<geser> gameldar: iirc it was broken but I don't know if it still is
<gameldar> geser: is there an alternative way of submitting them then?
<persia> gameldar: You can also request sponsorship manually: just make sure everything is attached, and subscribe the appropriate team to the bug (see further down the page).
<Lhademmo1> minghua. no, but wherer  is it thrn?
<minghua> Lhademmo1: The upstream svn of GNOME desktop user's guide should be http://svn.gnome.org/viewcvs/gnome-user-docs/
<minghua> Lhademmo1: I have no idea if docteam have another svn repo, I suggest you ask in #ubuntu-docs
<minghua> Lhademmo1: Hmm, #ubuntu-doc, apparently.
<Lhademmo1> minghuam its because of bug 126988
<ubotu> Launchpad bug 126988 in ubuntu-doc "Incorrect text to add logout (exit) button" [Low,Confirmed]  https://launchpad.net/bugs/126988
<minghua> Lhademmo1: As I've said, go to #ubuntu-doc and ask.
<Lhademmo1> k
<minghua> Lhademmo1: Be aware that it's weekend though, so developers may be not around.
<Lhademmo1> nah, I've noticed that :)
<cjwatson_> bryce: we don't use xdebconfigurator (it got into casper by way of a merge from Debian, where it's an optional feature I believe), so if you're looking to it to explain part of our process I think you've found a red herring :-)
<gameldar> heya all again
<gameldar> persia: sorry got disconnected (I updated to the latest packages and it killed my wireless kernel driver).... I have a question about the sponsorship still.
<persia> gameldar: OK.  Which bug?
<gameldar> bug 126314 - I have the debdiff now - do I modify that bug to add it to the list shown on: https://launchpad.net/~ubuntu-universe-sponsors/+subscribedbugs
<ubotu> Launchpad bug 126314 in anjuta "Anjuta crashes on opening or creating a glade file" [Undecided,Confirmed]  https://launchpad.net/bugs/126314
<persia> gameldar: First, this package is a universe package (MOTU Developers), so #ubuntu-motu is a better channel, but it's a weekend, so here is fine for now (next time, ask there).
<persia> Second, you'll need to wrap the patch into a debdiff.  There are some instructions in the "Preparing New Revisions" section of https://wiki.ubuntu.com/MOTU/Contributing
<gameldar> persia: ok thats done (followed that part)
<persia> Do you mean with http://launchpadlibrarian.net/9678551/anjuta-2.2.0.patch?  If so, you're missing a changelog entry.
<gameldar> no i haven't uploaded it yet - after I do that I assign the bug to ubuntu-universe-sponsors?
<persia> Third, once you've attached the debdiff to the bug, use the "Subscribe Someone Else" action (upper left) to subscribe ubuntu-universe-sponsors
<persia> gameldar: Don't assign.  Just subscribe.
<gameldar> persia: ahh ok
<gameldar> persia: thanks for that - I have it up there now!
<persia> gameldar: Great.  Thanks for taking the time to make a debdiff from the patch.
<gameldar> persia: Not a problem.
<gameldar> thanks again for those steps. time for me to sleep - bye all
<mekius> tepsipakki: ah ok, wasn't aware of that :)
<cypherbios> ogra: Hi. Could you tell me who is the responsible for the Edubuntu addon CD? I mean, the building process. Is that the release team or someone else?
<cjwatson> cypherbios: ubuntu-cdimage team; I deal with most of the code though much of the code for the Edubuntu addon CD was contributed by Edubuntu people
<cypherbios> I am interested in the script used to separate the .desktop and icons files (if any is used) for use with the gnome-app-install
<cjwatson> check out http://people.ubuntu.com/~cjwatson/bzr/cdimage/mainline/, check out the bits in configs/devel within that
<cjwatson> then debian-cd/tools/gutsy/app-install.sh
<mjg59> Amaranth: It doesn't. That's a false call from pm_trace
<cypherbios> cjwatson: thank you. It seems to be exactly what I was looking for
<Amaranth> mjg59: ok then, i'm lost :/
<cromo> I just noticed that vino-server ignores hosts.allow and hosts.deny. this seems to be a serious security issue.
<Amaranth> hrm, update-manager doesn't make sure ubuntu-desktop is installed?
<pochu> slangasek: liferea uploaded, fyi (in case you have time to let it go in)
<soren> Amaranth: No, but if it's installed, it makes sure that it stays that way.
<superm1> bryce, i was looking a little more regarding bulletproofx stuff.  during the live cd, debconf is updated with the results of the casper-reconfigure xserver-xorg.  is this data supposed to also be copied over to the resultant system though?  By what mechanism is it supposed to occur?
<bryce> I believe it should; yes.  I am not certain of the process used, though
<superm1> hm well for us its for sure not happening, and that is where the issue lies.  i didn't see any references to reconfiguring xserver-xorg in ubiquity source, so i wonder if there is an external hook by which it is supposed to happen
<superm1> bryce, do you know who i should ask to determine that this week?
<bryce> superm1: cjwatson
<superm1> bryce, okay i'll talk to him during business hours this week. thanks, have a good weekend :)
<cjwatson_> superm1: casper/ubiquity-hooks/20xconfig copies xorg.conf over
<cjwatson> superm1: the relevant bits of the debconf database aren't copied over, but per general debconf design principles they aren't supposed to need to be
<cjwatson> superm1: apologies in advance for the confusing accept/reject mails about mythtv; I only noticed that there were two in the queue with the same version after hitting accept, and therefore switched to rejecting the first and accepting the second
<cjwatson> (please try not to do that in future though; bump the version for the second upload instead)
<YokoZar1> weird weird weird: put "xdg-open $HOME" (with the quotes) in a terminal
<YokoZar1> It returns an error saying there's no such file or directory for your home folder
<YokoZar1> without quotes it works fine
<mjg59> YokoZar1: If you put quotes around the entire thing, bash is interpreting it as a command called xdg-open\ /home/whatever
<mjg59> Which obviously doesn't exist
<YokoZar1> mjg59: ok
<Viper550> Just wondering, does Ubuntu use hwd to detect X settings?
<YokoZar1> mjg59: it comes from this question though: if you make an applications menu entry for xdg-open $HOME, it will fail (with or without quotes)
<mjg59> It's probably not doing environment expansion
<mjg59> Try ~ rather than $HOME
<xjkx> why not bring "broadcom dell wireless 1390" support natively?
<mjg59> xjkx: It is.
<YokoZar1> mjg59: ahh, that worked.  Hmmm
<xjkx> mjg59, here http://ubuntuforums.org/showthread.php?t=297092 it says i have to apt-get lol...
<mjg59> xjkx: There's a driver included with the distribution, but we're not allowed to distribute the firmware that's required for it to work
<Viper550> hello, can I just discuss something?
<xjkx> mjg59, then what should I do? apt-get won't work with no nic
<mjg59> xjkx: Use a wired connection to obtain it? There's basically nothing we can do here, I'm afraid. We're not legally permitted to provide you with the firmware.
<xjkx> mjg59, why you cant
<xjkx> provite it
<mjg59> xjkx: Because the copyright holder hasn't granted us permission to do so
<xjkx> at least these sudo apt-get install build-essential ; sudo apt-get install linux-headers-`uname -r` could be avoided, they are free softwares
<Viper550> Just wondering, is anyone familar with the tool hwd?
<xjkx> mjg59, what do you think? Download the driver on other system that i have connection and install isn't the problem, the problem is building essential and getting kernel headers that i cant just simply download and install, there is the dependencies thing
<mjg59> xjkx: You don't need to build anything. The driver is included already.
<xjkx> the tutorial is crazy then? :p
<xjkx> its on ubuntuforms
<xjkx> mjg59, i am not an advanced user, what is really needed, this firmware is what package, ndiswrapper?
<mjg59> xjkx: #ubuntu is a better place to ask this sort of thing
<Chipzz> xjkx: for the record, apt-get *will* work without a nic (if you know what you're doing)
<Viper550> Just wondering, I found this awesome tool for autoconfiguring X
<xjkx> Chipzz, i mean with no connection at all
<xjkx> its out of the network world
<Chipzz> xjkx: you have to put the right files in the right place
<Chipzz> by means of an usb stick
<Chipzz> (for example)
<Viper550> http://user-contributions.org/projects/hwd/hwd.html
<Chipzz> /var/lib/apt/lists/ is where the package indexes go, /var/cache/apt/archives is where the .debs go
<Chipzz> !weekend | Viper550
<ubotu> Viper550: It's a weekend.  Often on weekends, the paid developers, and a lot of the community, may not be around to answer your question.  Please be patient, wait longer than you normally would, or try again during the working week.
<xjkx> Chipzz, i know how to dpkg, the problem is that if i download the packages on other system i wouldn't have a way to know what needs what
<Chipzz> sure you can?
<Chipzz> apt-get --print-uris update
<mjg59> Viper550: No, we don't use hwd
<Chipzz> download the files it prints
<Chipzz> (you have to rename them though)
<Chipzz> put those in /var/lib/apt/lists
<Viper550> why don't we? You know, if we used it, if someone had to regenerate their X config, they could just go "hwd -xa"
<Chipzz> apt-get --print-uris install foo
<Chipzz> download the files it prints and put these in /var/cache/apt/archives
<mjg59> Viper550: As opposed to dpkg-reconfigure xserver-xorg?
<Chipzz> apt-get install foo
<mjg59> Chipzz: Please move this to #ubuntu
<Viper550> yeah. it would be theoretically quicker to do that, since it wouldn't go through a long reconfigure process that is not needed
<Chipzz> mjg59: or rather, I'll shut up now ;)
<mjg59> Or just run dexconf
<Viper550> is it as quick?
<Amaranth> mjg59: if having it fail on ptyb9 is not correct do you have any idea what else i can test?
<Amaranth> mjg59: on resume the cd drive spins up, don't think the HD does, and that's it
<Amaranth> no keyboard, no screen, nothing
<mjg59> Amaranth: What type of hardware?
<Amaranth> mjg59: http://rafb.net/p/8MzWKH81.html
<Amaranth> mjg59: hp laptop
<mjg59> Using nvidia?
<MrMazda> Does gutsy have a startup option that allows to use legacy drivers instead of libata for IDE HDs?
#ubuntu-devel 2008-09-29
<retro89> hellow
<dholbach> good morning
<StevenK> dholbach: It's what, 5am?
<dholbach> StevenK: I didn't sleep very well, so I thought "why not get up and do some work?" - YAWN
<Hobbsee> morning dholbach!
<dholbach> hi Hobbsee
<Hobbsee> wow.  since when does hppa only have 8 pending builds for intrepid?
<StevenK> Hobbsee: Since the other 5,000 failed
<Hobbsee> StevenK: ahh.  that'd do it.
<TheMuso> oheh. If one sees an FTBFS mail, one can almost be 100% sure that it is hppa that has failed.
<ajmitch> do you have spam filters to throw them away?
<dholbach> james_w: congratulations!
 * Darklock is still up, celebrating the fall of the CSU in bavaria :->
 * Hobbsee beats dholbach with a herring
<Hobbsee> dholbach: yes, 6 mails later, I understand that james_w is a MOTU!  :P
<Darklock> Master Of The Universe?
<Darklock> it is......
<pitti> Good morning
<wgrant> Hi pitti.
<Hobbsee> pitti!
 * Hobbsee waves the "we love pitti" flag around, and drapes it over pitti's shoulders
<Hobbsee> (thanks to the we love pitti fanclub for the flag, which got borrowed)
 * pitti blushes
<pitti> BenC: I sub'ed you to bug 271956, I'd like to get your "still works" ack before uploading this; thanks in advance!
<ubottu> Launchpad bug 271956 in makedumpfile "Upgrade to new upstream version 1.2.9" [Undecided,New] https://launchpad.net/bugs/271956
<nxvl> heh
<nxvl> i will bring a "we love pitti" flag to UDS
<nxvl> :D
<StevenK> pitti: So, wgrant and I found two things that aren't in NBS, and should be. lib{32,64}ffi4
<wgrant> StevenK: Ah, thanks - I'd forgot about those!
<pitti> StevenK: oh? libffi4 was NBS, and removed a while ago
<StevenK> pitti: lib32ffi4 is still listed on amd64
<StevenK> Filename: pool/universe/g/gcc-4.2/lib32ffi4_4.2.3-2ubuntu7_amd64.deb
<pitti> $ asrc gcc-4.2|grep Binary.*ffi
<pitti> $
<wgrant> lib{32,64}ffi4 are very arch-specific, definitely NBS, but not in NBS.
<pitti> sorry, asrc = apt-cache show-src
<wgrant> Right.
<wgrant> They're not built any more.
<wgrant> Their source is long gone.
<wgrant> They're still published.
<wgrant> But they're not in the generated NBS lists.
<StevenK> Built from gcc-4.2, which is currently 4.2.4-3ubuntu2
<wgrant> http://launchpad.net/ubuntu/intrepid/amd64/lib32ffi4
<wgrant> It could be because they're arch-specific, or because their source is published in another distroseries, or blah blah blah...
<persia> I've seen this previously, which arch-specific stuff.  Is there maybe a way to tweak the NBS finder to find things like this?  The last I found was some leftover linux-meta stuff.
<persia> s/which/with/
<pitti> I'm not entirely sure how the NBS finder works
<wgrant> Do we have the source?
<pitti> wgrant: for the reverse depends checker yes, but the list of stale packages is created by a soyuz script, which isn't too useful without the corresponding database, etc.
<wgrant> pitti: Ahh, so it is a Soyuz bug after all.
<seb128> to whoever build retried gnome-python-extras that didn't work because pygtk is out of sync between arch all and any pacakges due to xvfb being broken
<pitti> seb128: oh, indeed, I was going to ask you about pygtk
<pitti> seb128: I sponsored that trivial fix for the example hashbang, and it FTBFSed all over the place
<pitti> seb128: oh, first: bonjour!
<pitti> seb128: some failed due to xvfb, amd64 failed due to "extension "RANDR" missing on display ":99.0""
<RAOF> That's an awesome FTBFS error in so many ways :)
<seb128> pitti: guten tag ;-)
<pitti> seb128: so I could maybe try the workaround with the mesa build dep, too?
<seb128> pitti: we could, would be nice if the xorg guys were fixing xvfb though
 * directhex hands pitti cake
<persia> I don't see a bug on that.  Does it need one?
<pitti> persia: well, not really; we need to get the damn thing building; if that's tricky to do, we could use a bug as discussion place, of course
<pitti> I'll set up an intrepid chroot somewhere; it locally built fine
<persia> pitti: Makes sense.  I was thinking one against xvfb, as I was also looking at pygtk today.
<pitti> oh, xvfb, indeed
<seb128> pitti: just do the workaround for pygtk I would say
<pitti> seb128: will that also help for the xrandr thing?
<pitti> seb128: I can do a test build on i386, but I currently don't have an amd64 pbuilder at hand
<seb128> pitti: that seems to be a random xvfb error, dunno about it but it might
<slangasek> lool: ping
<lool> slangasek: pong
<seb128> pitti: other option is to comment the xvfb-run call in debian/rules, it's just to call the testsuite
<lool> What did I break /again/
<lool> :-P
<seb128> pitti: or try the xvfb workaround on your ppa quickly?
<pitti> seb128: hm, test suite iz good
<pitti> seb128: oh, ppa, right!
<seb128> pitti: ppa are great ;-)
<lool> pitti: I'm not the RANDR stuff is a failure
<slangasek> lool: :-)  I see that elisa-plugins-good recommends: gtreamer0.10-ffmpeg and gstreamer0.10-plugins-ugly, both of which are in universe; I think those need to be demoted to Suggests?
<lool> slangasek: Good point; I'll demote them for Ubuntu
<slangasek> lool: (I'm trying to track down why ffmpeg stuff is being wrongly pulled onto the livefs; elisa itself isn't to blame for this, but I might as well mention it :)
<pitti> seb128: uploaded to my ppa, crossing fingers
<lool> slangasek: Hmm which verison of elisa-plugins-good are you looking at?
<slangasek> lool: 0.3.5-2; is that not current?
<seb128> no, currents didn't build
<lool> No, the current one doesn't build because a package needs promotion to main and the MIR is pending since 10 days
<slangasek> ah
<slangasek> oh, well then
<slangasek> :)
<lool> I have in my TODO "* Find out who's processing MIR and ping them"
<StevenK> lool: ubuntu-mir ; pitti and doko
<lool> But also "* write a MIR for python-cssutil"
<lool> Of course the latter before the former  :-P
<seb128> pitti: bah, the pygtk builds failed in your ppa too
<pitti> ah, same problem
<slangasek> pitti: dunno if you saw, I followed up to the console-kit-daemon crasher bug; the log certainly doesn't tell me anything, and the crashes are still happening
<pitti> slangasek: ah, I hoped it would have a truncated log, or at least tell me at which precise point it crashes (when writing a session open or close log, or so)
<lool> I reproduce the pygtk FTBFS in pbuilder
<slangasek> pitti: did there end up being any problems with langpack generation (bug #273489)? You suggested during the meeting to follow up on #-devel, not sure whether that's happened yet
<ubottu> Launchpad bug 273489 in rosetta "Remaining Intrepid template approvals" [Critical,Fix committed] https://launchpad.net/bugs/273489
<slytherin> seb128: sorry to bug you again, but do you plan to update gst-plugins-base to latest prerelease? This is regarding DVD playback blocked with resindvd plugin.
<pitti> slangasek: I did followup with jtv; apparently the rosetta export crashes for ominous reasons, he is investigating
<slangasek> ok
<seb128> slytherin: not likely before beta now, no
<lool> pitti: Re: python-dateutil MIR; there's an embedded storm copy in elisa which is the code which relies on python-dateutil
<seb128> ups
<lool> I don't know how easy it would be for storm to move to python-tz; I'll try to ask them, but it's unlikely that it happens in time for intrepid
<seb128> somewhat I manage to close xchat-gnome tabs while switching workspaces sometimes
<slytherin> seb128: Ok. So should I try backporting the fix form upstream cvs? I will do that sometime tonight.
<seb128> slytherin: if you want to, I'll try to update the version after beta
<lool> Ok, I think xvfb-run exits because it tries to kill Xvfb which already exited
<lool> (the program is set -e and the kill clearly fails)
 * slytherin looks through intrepid schedule
<pitti> lool: so eliza actually uses the time zone db in python-dateutil?
<pitti> lool: I guess it's much easier in the end to make p-dateutil use the system tzdata than trying to convert storm
<lool> pitti: elisa uses storm which uses dateutil for db dates I guess
<lool> pitti: Got the same comment on #storm that it'd be simpler to fix python-dateutil
<shingara> there are no way to get list of all package with name of /package/version upstream/ubuntu version/ ?
<shingara> apt-cache send me the full version, no separate upstream version and ubuntu version
 * lool tries a pygtk build with -s -noreset
<lool> Cool, pygtk actually liked that
<lool> slangasek, pitti: could you please look at pygtk 2.13.0-0ubuntu5 waiting for approval?  It fixes a FTBFS similar as the one on the buildds for me (in pbuilder here though)
<lool> (Well it wasn't processed yet I guess)
<lool> seb128: I think I pushed a fixed pygtk
<lool> seb128: Are other packages likely affected?
<seb128> lool: the change you mentionned was one of the workaround listed on #ubuntu-x the other day
<lool> Too bad I had to search for it then
<lool> seb128: How come it wasn't applied?
<seb128> lool: well, gnome-python-extras, I opted for the libgl1-mesa-dri build-depends which was supposed to workaround that too, let's see if it builds after pygtk
<lool> It's not the same failure
<seb128> ok so ignore my comment ;-)
<mvo> shingara: there is a debian project for getting the upstream version based on debian/watch files
<shingara> what project ?
<broonie> ddpo
<seb128> lool: thanks for fixing it, there is still a xvfb bug though?
<wgrant> shingara: Everything before the last - in a version should be the upstream version, or close to it.
<shingara> xserver-xorg-driver-all_1:7.3+10ubuntu10
<shingara> and this package is the exception?
<wgrant> There's no upstream version for that.
<wgrant> It's a native metapackage.
<lool> seb128: Well it's a Xvfb design issue
<shingara> ah
<lool> Rather xvfb-run
<lool> seb128: xvfb-run <cmd> seems to assume only one client will connect, it seems
<seb128> lool: which is not the case there?
<seb128> lool: the issue you tracker was a different one indeed, the other one was a loop due to swrast_dri.so not being available
<lool> seb128: I think I had to add bdeps to pygtk already to fix this IIRC
<lool>   * Build-dep on xauth and xfonts-base as xvfb-run needs these and also bdep
<lool>     on libgl1-mesa-dri for now until Xvfb can start without AIGLX support or
<lool>     this dep is added to the package.
<lool> pygtk 2.13.0-0ubuntu1
<seb128> ah right
<lool> seb128: I think what happens is that "make check" starts multiple individual commands (one per test) and each test connects and disconnects from the DISPLAY
<seb128> that one is a xvfb bug then ;-)
<lool> Well, it's made to run a "client" not a command starting multiple clients
<lool> And the flag to not close after the first client is the one I added
<lool> It might be that we were trying to run multiple tests but in fact were only running one!
<seb128> lool: ok, so that was not what we discussed the other day, thanks for fixing this one ;-)
<lool> I'm not too happy with xvfb-run in general, but here I think it's ok that we have to pass this special fla
<lool> flag
<seb128> right, it's just weird that things were working without that before
<lool> Well TBH I'm not sure how they did
<lool> Perhaps make check was completing really quickly because of the closed Xorg connection and kill had still something to kill
<lool> No idea  :-/
<seb128> lool: did you upload the fixed version to intrepid?
<lool> Yes
<seb128> thanks
<lool> I pinged slangasek and pitti to unblock it
<lool> I should have pushed to my ppa to make sure
<seb128> the bug fix explanation makes sense and if you verified in pbuilder that should be good enough ;-)
<pitti> lool: rock, thank you
<lool> pitti: I think we should act on the python-dateutil situation one way or the other; it seems the only doable solution is to fix python-dateutil to use tzdata; I don't want to keep elisa non-buildable and non-installable further, so could you either demote elisa to universe or promote python-dateutil to main until we sort it out?
<lool> I have no idea of the time budget to fix python-dateutil, but I have an idea of my time availability and I fear that nobody will step up before the intrepid release to fix it, so I prefer that we get at least some elisa testing, even if it's universe, or live with the tzdata copy in main
<Adri2000> can I upload a main package directly to -proposed or should I wait for the ubuntu-sru ack?
<cjwatson> it's held in -proposed until the bug is approved anyway ...
<Adri2000> ok, I guess I can upload then
<lool> james_w: Congrats
<james_w> thanks lool
<lool> seb128, pitti: pygtk failed ot build in ppa and ubuntu; it's a new error again
<seb128> gra
<pitti> bah, and all that just to fix an example script :/
<lool> Now it's "Xvfb failed to start"; it does start with the same command-line in my pbuilder though
<lool> xvfb-run -s -noreset /usr/bin/make -C build-2.5 check
<lool> make[1]: Entering directory `/tmp/buildd/pygtk-2.13.0/build-2.5'
<lool> ...
<lool> xvfb-run -s -no-reset /usr/bin/make -C build-2.5 check
<lool> Xvfb failed to start
<lool> make: *** [build-2.5/build-stamp] Error 1
<lool> dpkg-buildpackage: failure: debian/rules build gave error exit status 2
<lool> (first is my pbuilder, second it buildd)
<lool> Now it might need some love from someone using sbuild
<slangasek> lool: so the pygtk in the queue shouldn't be accepted?
<lool> slangasek: No use to, it will ftbfs
<slangasek> :/
<lool> Hmm I suspect XVFBARGS might get overwritten with -s
<lool> Not sure how this affects Xvfb
<lool> Anyone could do a test build in sbuild?  Or should I throw at my ppa?
<lool> I'd like to change '-s -no-reset' to '-s "-no-reset -screen 0 640x480x8"'
<seb128> lool: ppa will be faster to try
<jcristau> lool: i'd be surprised if that was the problem
<lool> jcristau: Any idea what it could be?
<lool> GRAH
<lool> I typoed the one I uploaded
<lool> to my ppa
<jcristau> lool: i'm tempted to change the default ERRORFILE in xvfb-run...
<seb128> oh, yeah, there is an extra "-"
<lool> yeah
<pitti> lool: accepted pygtk, let's cross fingers
<lool> jcristau: Wow this would certainly help debugging indeed!
<pitti> lool: looking into -dateutil now
<lool> Status: Successfully built
<lool> woohoo
<lool> So the typo in my ppa upload was the only issue, sorry for the confusion
<lool> jcristau: And sorry for bothering :)
<lool> The second ppa upload with the proper flag name built fine
<pitti> lool: I think I fixed -dateutil
<lool> pitti: woah
<lool> pitti: Well thanks
<lool> pitti: So I do owe you some beverage
<pitti> lool: at least I broke the test suite after removing the tarball, and it runs fine again with my fix
<xyz> could someone have a look at bug 231407
<ubottu> Launchpad bug 231407 in pulseaudio "pulseaudio causes restart- volume-restore.table file not found" [Undecided,Confirmed] https://launchpad.net/bugs/231407
<xyz> it's still present in intrepid beta
<xyz> no sound for VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller
<lool> jcristau: I kind of wonder whether this kill isn't racy in all cases: here we have multiple commands, so it's obvious why it might fail, but even for a single client, it's not impossible that Xvfb shuts down before the kill is reached
<jcristau> lool: why would Xvfb exit?
<lool> jcristau: When X client disconnects
<jcristau> only if you pass -terminate
<lool> jcristau: I thought this was the default; I'm puzzled as to why -noreset helps if -terminate isn't the default
<lool> jcristau: Aha, the default is -reset
<jcristau> the default is to regen (shut down clients and screens, and re-init everything)
<lool> jcristau: I suspect the server restarts between commands
<lool> Hmm is this a good default
<lool> jcristau: Heh the xprint backend has dispatchExceptionAtReset = 0
<lool> Since 2006; don't know how to check earlier history
<lool> jcristau: https://bugs.freedesktop.org/show_bug.cgi?id=764 seems to be related to Xprt
<ubottu> Freedesktop bug 764 in Server: Config: startup scripts "Xprt permanently resets itself after each client disconnect" [Critical,Resolved: fixed]
<lool> dd831c7a5c1b0c540a78350aadaeb34a8aa67395 in changelog
<lool> The rationale for xprint is slowness, and the fact that resources need to be configured again
 * jcristau pretends Xprt doesn't exist
<lool> Xpfrt!
<lool> jcristau: I can't come up with an use case of xvfb-run where one wants to reset the server for multiple clients though: the script inherently suggests you're running a single command to do some stuff
<lool> So even if the Xvfb default has some rationale behind it, xvfb-run could pass -noreset by default I think
<pitti> mvo: oh, you dropped the "remove landscape-client stub" update-manager code? IMHO this should still be present, we only install landscape-common by default
<pitti> mvo: maybe you can drop that change from 1:0.93.18 and reupload (same version number is ok)? I'll accept it afterwards, so that we'll get hte xorg driver transition in time for beta
<mvo> pitti: thanks, I can fix this after lunch
<mvo> sorry, there seems to have been some confusion about the right handling of this
<pitti> mvo: right, there was; this is the current approach now (isntall -common by default, but not -client)
<pitti> mvo: I rejected the current upload; please ping me after you uploaded the new version, for immediate processing; thanks! *hug*
<StevenK> pitti: Can you have a look at linux-lpia?
<StevenK> pitti: It is mainly so we can switch back to aufs
<pitti> StevenK: accepted, doesn't really affect ubuntu desktops
<StevenK> pitti: Thanks
 * persia tries harder to make the lpia alternate CD work for installing ubuntu desktops
<persia> ls
<ogra>  /
<whyking> hi
<whyking> a package wants to install a dependency which has been renamed (libgsl0 became libgsl0ldbl), how could I fix that in the best way?
<whyking> create an alias for that package?
<Mithrandir> rebuild the package with the old dependenc.
<Mithrandir> +y
<whyking> Mithrandir, how can I rebuild that package?
<whyking> and where should I get the old dependency?
<whyking> or maybe, is there a way to ignore that dependency? because it is already installed
<persia> whyking: You don't need the old dependency: rebuilding should pull the new dependency.
<Mithrandir> hmm?  You have package foo that depends on libgsl0.  So you download the source, rebuild it using dpkg-buildpackage and install using dpkg.
<whyking> can't I just tell apt-get to ignore the broken dep?
<whyking> sth like --ignore-missing
<Mithrandir> because you don't have it installed?
<whyking> Mithrandir, I have
<whyking> everything is in place.. but he wants to install the old dependency.. the new one is installed
<Mithrandir> no, you don't.  libgsl0ldbl and libgsl0 are two distinct libraries.
<whyking> Mithrandir, are they? so why was libgsl0 deleted?
<Mithrandir> because it was superseded by libgsl0ldbl
<Mithrandir> but they are not completely compatible.
<Mithrandir> so you need to rebuild any applications depending on libgsl0
<whyking> ok, but it should work nonetheless then
<whyking> mhh
<whyking> I'd rather not :-/ its a huge source
<whyking> no other way?
<persia> whyking: Rebuild anything depending on libgsl0ldbl with libgsl0, but that's the reverse of what everyone else will be doing.
<whyking> persia, alright.. I guess I'll have to wait for upstream to fix it then
<whyking> thanks
<slangasek> apachelogger: why is libksquirrel marked i386-only?
<geser> slangasek: should packages in main have a -dbg or -dbgsym package or is it only nice to have?
<slangasek> geser: -dbgsym packages are autogenerated; -dbg packages get in the way of this more than anything, so I wouldn't call them nice to have at all
<siretart> slangasek: they 'get in the way'?
<geser> slangasek: libselinux has neither, and I wonder if it's important or only a wishlist bug
<slangasek> siretart: some packages are known to do things in the creation of their -dbg packages which breaks the -dbgsym extraction
<persia> slangasek: What about cases where -dbgsym autogeneration fails?
<soren> slangasek: From http://revu.ubuntuwire.com/details.py?package=libksquirrel: - Only build on i386 for now, have to talk to upstream about fixing amd64 build.
<cjwatson> -dbg is only useful if the package needs a second pass to build useful debugging
<cjwatson> if it doesn't, then a request for -dbg is neither important not wishlist, it's invalid
<cjwatson> (or wontfix I suppose)
<cjwatson> s/not/nor/
<cjwatson> if -dbgsym autogeneration fails, it should probably be fixed :-) ask pitti
 * siretart wonders if he should make ffmpeg and xine stop building -dbg package in ubuntu
<cjwatson> there's no need to introduce diffs to stop building -dbg packages
<slangasek> make them stop building -dbg packages in Debian :P
<cjwatson> contrariwise, there's no need to put any effort into building them either
<geser> the problem is libselinux doesn't use debhelper so dh_strip isn't used and the trigger to build the -dbgsym doesn't get called
<slangasek> geser: ah, yes, heh
<cjwatson> exceptions are things like python modules which need a second pass
<cjwatson> it would be straightforward to call the dbgsym extractor, wouldn't it?
<siretart> slangasek: I could, but I've found them rather useful. espc. for non-maintstream architectures.
<siretart> 'mainstream', even.
<geser> it should be possible, if such change is deemed worth it
<cjwatson> it should be no harder than creating a separate -dbg package, and produces better results
<siretart> slangasek: are there guidelines in debian when and when not to provide -dbg packages?
<slangasek> siretart: no, unfortunately
<siretart> :(
<slangasek> so we have awesomeness like -dbg packages for firewall tools
<slangasek> soren: hmm, and the revu page doesn't show the reason for the build failure... but ok, thanks
<pitti> re
<pitti> what's up wrt. -dbgsym breakage?
<pitti> seb128: looking into the camera bug now
<seb128> pitti: thanks
<seb128> pitti: what dbgsym breakage?
<pitti> discussed half an hour ago here, between slangasek, siretart, and cjwatson
<geser> pitti: not a breakage, but only a question how important it is if a package in main has no -dbgsym (or -dbg) package
<geser> pitti: see bug 275082
<ubottu> Launchpad bug 275082 in libselinux "no debug symbols package in intrepid" [Undecided,Confirmed] https://launchpad.net/bugs/275082
<pitti> geser: oh; well, if it's a package which gets a lot of crash reports, we should fix it; otherwise I wouldn't waste too much time on it
<cjwatson> pitti: turns out it's a package that doesn't use debhelper. I guess it's fairly easy to call the helper by hand too
<slangasek> seb128: hi, do you have any idea about the gstreamer0.10 build failure?
<siretart> pitti: does ffmpeg/xine-lib break the apport retracer by providing -dbg packages? both are using debhelper
<seb128> slangasek: oh, no, I wanted to ask lool or slomo about those
<pitti> yes, it is: pkg_create_dbgsym debian/foo
<pitti> siretart: ATM the retracer doesn't consider -dbg packages
<pitti> lool, seb128: yay, pygtk built everywhere
<siretart> pitti: that didn't answer my question ;)
<pitti> siretart: ok, then; to literally answer your question: "no" :)
<siretart> excellent :)
<siretart> seb128: did you hear any news from the TB regarding my inquiry about ffmpeg?
<pitti> siretart: "break" in the sense of "non-symbolic result if no -dbgsym is available": yes, "-dbg are merely available/present" -> no
<seb128> siretart: no
<siretart> seb128: FYI, an updated ffmpeg package is currently in debian NEW
<siretart> pitti: okay, that means users have to retrace themselves. okay
<slangasek> lool, slomo: ping?  Do you know what's up with the gstreamer.10 ftbfs?: http://launchpadlibrarian.net/17880819/buildlog_ubuntu-intrepid-i386.gstreamer0.10_0.10.20.2-1_FAILEDTOBUILD.txt.gz
<geser> pitti: have you some time to help me on the fdi file for some smart card readers?
<pitti> geser: oh, sure; what's the issue?
<slangasek> pitti: do you think that the fdi file in 267682 is a right solution, and ready fo upload?
<pitti> slangasek: I think it's a reasonable workaround for intrepid, yes; it's not a long-term correct solution (we should clean up that entire mess in jaunty)
<pitti> slangasek: it was tested by a couple of thinkpad users now AFAICS
<slangasek> pitti: ok.  Can you prepare the upload to add the fdi file to wherever is the appropriate place, or should I ask someone else about this?
<pitti> slangasek: I think the most correct place would be the -evdev driver, wrt. correct behaviour of backported packages (i. e. we should not ship it in hal)
<geser> inspired by kirkland's work I started to write a similar file to grant access to smart card readers. I got it nearly working. I'm currently stuck at the point that it only works if I hardcode the device file name into the fdi file.
<pitti> slangasek: yes, I can prepare the upload
<slangasek> pitti: ok, thanks
<geser> see http://paste.ubuntu.com/50012/ for my current fdi and policy file and the lshal output for the smart card reader
<pitti> geser: you mean access to the raw device?
<pitti> geser: do you know that a while ago StevenK already prepared this for all removable block devices?
<geser> pitti: to e.g. /dev/bus/usb/001/002
<geser> pitti: it's to finally close bug 57755 which got stuck as it used a new group (scard) for it in the udev rules
<ubottu> Launchpad bug 57755 in gnupg "Udev Rules for SmartCard Support" [Wishlist,Confirmed] https://launchpad.net/bugs/57755
<pitti> geser: oh, right, I misunderstood what you meant with smartcards, nevermind
<geser> pitti: does it matter that the smart card reader appears as a character device and not as a block device?
<pitti> geser: yes, it does; I mixed it up with "SD card"
<geser> I mean those to read a OpenGPG card
<pitti> geser: right, I know now
<pitti> geser: so, the tricky bit is to find out that a particular device is in fact an sd card reader
<geser> would it be possible to use the product id and vendor id? like in the proposed udev rules from that bug
<mdz> asac: one-liner patch for you in ~mdz/network-manager/ubuntu.0.7/
<pitti> geser: yes, that's always a possibility, if there's a reasonably small list
<pitti> geser: some devices have a particular device or interface class, but if that's not the case, there's no other way than to use vendor/product ID lists
<mvo> pitti: update-manager uploaded
<pitti> geser: btw, hal supports int_outof="0x001;0x002;0x003", that makes the rules shorter to write
<geser> pitti: currently it's only a small list, 2 or 3 devices from SCM which gpg supports natively
<geser> so the user needs access to the device file
<pitti> mvo: and accepted, thanks
<pitti> geser: if the list gets longer, the fdi should probably be autogenerated during build, but for now, a static one seems ok to me
<pitti> geser: allow_inactive should be false, though, otherwise several user sessions race for grabbing the device
<seb128> Hobbsee: bouh
<pitti> geser: otherwise your paste looks quite good to me
<Hobbsee> seb128: i'm sorry?
<Hobbsee> seb128: (oh, and re: the last ping, i figured it out, thanks)
<seb128> Hobbsee: nice to mail about not testing uploads to upload an anjuta which can't built
<Hobbsee> seb128: yeah, well.
<geser> pitti: do you have an idea why it only works if I hardcode the device file into the fdi?
<seb128> Hobbsee: we need the new anjuta version, huat is working on it
<geser> if I use the copy-property line I get no acl for it
<Hobbsee> seb128: at least i found about it pretty quickly.  And i'm not sure why no one in debian's reported the same problem yet.
<Hobbsee> seb128: yes, so he said.
<seb128> Hobbsee: anjuta 2.24 has been uploaded to debian
<Hobbsee> seb128: yes, it has, and there's a grave bug about it.
<Hobbsee> seb128: however, it's not passed to unstable yet, and i'm surprised that the unstable version hasn't been rebuilt at all - given that it should be uninstallable by now?
<Riddell> mvo: could the upgrader be set to purge kdm-kde4 ?
<pitti> geser: why do you copy it from the device's parent, and not from the device itself?
<seb128> Hobbsee: I can't parse that
<pitti> geser: the device you pasted already has linux.device_file, which seems to be the correct one?
<geser> pitti: good question, I tried looking at how the other files do it
<pitti> geser: drop the @info.parent:
<seb128> Hobbsee: I'll fix anjuta, I'm talking regularly to huat about it for some days now
<geser> pitti: still no acls (I've restarted hal and also issued a ck-launch-session)
<Hobbsee> seb128: cool.  I've seen some action on the bug.
<Hobbsee> oh, interesting.  according to debian packages, libgdl-gnome-1-0 still exists - but an old version.
<slangasek> it's uninstallable and NBS
 * slangasek sharpens the axe while he waits for python-gnome2-extras to build
<seb128> Hobbsee: right, nbs is not cleaned if there is still some packages depending on the binaries
<geser> pitti: is /usr/share/hal/fdi/policy/10osvendor/ the correct location for my fdi file?
<Hobbsee> seb128: in debian, it appears.  It's gone in ubuntu, apparently.
<seb128> slangasek: I kicked the builds after pygtk built, now you might want to ask pitti to score higher those
<pitti> prio bumped to 5000
<seb128> pitti: danke
 * Hobbsee want's pitti's version of buildd.py.
<pitti> geser: yes, looks good
<asac> mdz: committed (rev2902) thx
<pitti> Hobbsee: hm, you are right; it doesn't actually *work*
<Hobbsee> pitti: good.  so i'm not going mad!
 * Hobbsee sighs at seb.  I get build failure mails for a reason.
<Hobbsee> Install failures, however....
<Hobbsee> ah well.
<mdz> pitti: I was looking at network-manager crashes, and noticed there were several which have been retraced but are still marked private.  is it a manual process to make them public after retracing?
<pitti> mdz: yes, it is; until someone inspected them, we cannot guarantee that there are no sensitive information in the stack trace; also, we just generally keep them private, in order to not clutter the bug mail recipients so much
<pitti> slangasek: I applied it in hal in the end; rationale in bug updated, and uploaded
<slangasek> pitti: great, thanks
<pitti> slangasek: want to review, or shall I ack myself?
<mvo> Riddell: sure, purge, not remove? I put that into bzr
<slangasek> pitti: having already tested the fdi file and trusting that you know better than I where it needs to go in the package, I'm ok with you acking yourself if you don't think you need another pair of eyes
<pitti> slangasek: I'm reasonably sure, but best would be to test it again with the actual .deb from the repos
<pitti> (I don't have a thinkpad here)
 * slangasek nods
<james_w> hey ema
<ema> hey james_w
<ema> james_w: congrats for becoming a MOTU :)
<james_w> thanks ema. How are you?
<ema> I'm fine, but very busy with work any uni unfortunately
<geser> pitti: found the problem: it's "copy_property" and not "copy-property" and I had to use @info.parent:linux.device_file
<geser> pitti: it works now :)
<pitti> geser: still curious, since the hal device you pasted had both the vendor/product IDs and the device file; but if it's conceptually correct to use the parent's, sure
<geser> pitti: the next question would be, which is the best package to include the fdi (and policy) file as both gnupg and gnupg2 can use it (perhaps also libccid)
<pitti> geser: is there a smartcard library which both use/
<pitti> ?
<geser> pitti: no, both gnupg and gnupg2 support it natively, they don't need any special lib for it
<pitti> geser: I guess then we should put it in hal; it has become the dumping ground for all sorts of stuff already, but *shrug*
<pitti> geser: it should be integrated into the existing device access fdi/policy then, maybe upstream will even tak eit
<pitti> take it
<geser> pitti: I'll prepare then a debdiff and let you know for review
<pitti> geser: cool, thanks (NB that I just uploaded a hal, thus bzr is newer than apt-get source)
<seb128> re
<seb128> lool: so gnome-python-extras fails the same way than pygtk now
<pitti> wb seb128
<soneca> helo folks, i am working on Pidgin. There is an issue on Blocked users. Even when the contact is blocked, he also can send messages to user, and vice-versa. So, i want to help the team, making a patch to this issue, in libpurple and pidgin. Anyone else is working with this?
<stefanlsd> soneca: is it an ubuntu specific problem, or rather a problem with pidgin?
<TheMuso> cjwatson: I had a look at the Ubuntustudio seeds today, following the steps for tasksel that you outlined last Friday, and got no errors at all. This was on intrepid, with intrepid's version of bzr.
<soneca> it's a pidgin problem. Sorry post in this channel
<soneca> I've posted on pidgin channel now
<stefanlsd> soneca: your best bet will be to work with upstream.  Try #pidgin  :)
<soneca> thanks, it's an control-V issue. Copied from other channel and pasted in the wrong place ;)
<lool> seb128: Hmm ok, we don't have the xvfb-run call in pkg-gnome so I didn't find it
<seb128> lool: right, we didn't sync this one for a while
<lool> seb128: Would have been nice to send that part to Debian
<lool> It's there since sep 2007
<Riddell> mvo: actually I'm not sure about that purge, it shares file with kdm in intrepid which we don't want removed
<lool> dpatch...
<seb128> lool: yes, we didn't sync this cycle because the package has been splitted in debian and has dbg variants in ubuntu and the sync is not trivial and I've been too busy to do it and nobody else picked on the job
<lool> I pushed a similar fix (adding -noreset Xvfb flag) for gnome-python-extra to my ppa and intrepid
<seb128> lool: thanks!
<pitti> tedg1: good morning
<ogra> seb128, do you know if there is a way to preseed timed-login from d-i for gdm ? (i know there is for autologin, but that doesnt help if a user logs out)
<seb128> no clue
<pitti> seb128: so, do you agree about the "do nothing" approach for bug 274146? I don't see any correct approach to that
<ubottu> Launchpad bug 274146 in gnome-session "Has not yet replaced the existing log out applet" [High,New] https://launchpad.net/bugs/274146
<seb128> pitti: I'm not happy about that but I prefer to not do anything than to do something broken
<pitti> seb128: me too
<tedg1> Morning pitti
<pitti> seb128: ok, then AFAICS desktop team is down to bug 274140 (tedg1), bug 258083 (me), and bug 274085 (unassigned); do you see anything else critical for beta?
<ubottu> Launchpad bug 274140 in fast-user-switch-applet "Visability of Suspend and Hibernate doesn't match gnome-session's dialogs" [High,In progress] https://launchpad.net/bugs/274140
<ubottu> Launchpad bug 258083 in f-spot "F-Spot - Error connecting to camera.  "Could not lock the device"" [Medium,Confirmed] https://launchpad.net/bugs/258083
<ubottu> Launchpad bug 274085 in ekiga "Please update Ekiga to 3.00" [Wishlist,Triaged] https://launchpad.net/bugs/274085
<seb128> pitti: Scott opened the bug, let's stay on the "do nothing" for now and wait for him to comment if he disagrees
<pitti> tedg1: how is that going, btw? (fusa suspend/resume), need any help?
<pitti> tedg1: we need to get the fixes in today in order to get the release out in time
<seb128> Hobbsee: replying here to you gdl question, that's an upstream change
<seb128> Hobbsee: and why I synced the new version, because that's a GNOME 2.24 tarball
<seb128> Hobbsee: what is still using it in intrepid?
<mterry> superm1, persia: I attached a debdiff to bug 269540 to fix the issue with the BT wizard in bluez-gnome 0.28
<ubottu> Launchpad bug 269540 in bluez-gnome "Add bluetooth wizard" [Undecided,New] https://launchpad.net/bugs/269540
<tedg1> pitti: In testing.  Is there a particular time you need them?
<persia> mterry: Does it work with keyboards on intrepid?
<pitti> tedg1: ah, good to hear; no, just "today" would be good
<mvo> Riddell: hm, ok. let me know when you have decided what to do with it
<mterry> persia: I don't have a keyboard to test.  But what I remember you saying is that they were broken in 0.25 anyway?  This wouldn't fix that
<Hobbsee> seb128: it *was* anjuta, but that became uninstallable, as the binary was pulled.
<persia> mterry: Oh well.  Thanks for that.  If we don't move to 4.x, it's probably worth applying.
<seb128> Hobbsee: yes, anjuta has to be uploaded to 2.24 too, but to update anjuta we had to upload gdl first because anjuta 2.24 depends on the new gdl
<Hobbsee> seb128: i can understand that the new version got synced, but i would have expected the old version of the obsolete binary to stay, and not automatically vanish, but show up on the NBS lists?
<tedg1> pitti: Okay, I'll finish catching up on e-mail from the weekend then :)
<seb128> Hobbsee: the lib didn't vanish, it's just not installable because it doesn't match the libgdl-1-common current version
<Hobbsee> seb128: ah.  I must have misread it, in the general churn of trying to make things installable again.  My error.
<seb128> no problem, sorry about the installability issue late in the cycle
<Hobbsee> seb128: hopefully it'll be fixed soon :)
<seb128> today for sure
<cjwatson> TheMuso: did you use the current revision, or the one before I worked around the problem?
<lool> seb128: gpe successfully built, can you accept?
<lool> (in my ppa)
<lool> https://edge.launchpad.net/~lool/+archive/+build/726045
<seb128> pitti: can you?
<seb128> pitti: gnome-python-extras in intrepid fixes the build correctly thanks to lool
<pitti> seb128: can what?
<seb128> lool: is you accent circonflexe broken too in intrepid?
<seb128> pitti: accept -g-p-e
<pitti> I already accepted g-p-e from unapproved
<seb128> ah ok
<seb128> thanks
<lool> seb128: Rebooting to make sure, but it worked in xterm
<lool> pitti: ty
<Riddell> mvo: if it's going to remove files even though they now belong to kdm then it shouldn't br purged
<amikrop> Can I tell distutils not to place my data_files in /usr/foo but in /etc/foo? The docs do not refer anything about it.
<pitti> amikrop: just set the destination dir to an absolute path
<amikrop> pitti: Alright, thank you. :-)
<pitti> amikrop: 'share/foo' will land in prefix, '/etc/foo' will be absolute
<amikrop> thanks ;)
<Hobbsee> amikrop: any *particular* reason you stuck that in 2 channels, simultaneously?
<lool> seb128: Yeah, Ãª is broken in gtk+
<lool> not in xterm though
 * ogra ands lool a Ã¶ ... just cut out the right side, make a connection between the dots and it *nearly* looks the same 
 * Hobbsee hands ogra an h
<ogra> heh
<Hobbsee> :)
<ogra> Hobbsee, i'm speaking to french people ... the h is builtin :P
 * ogra hides
<Hobbsee> ogra: riiiiight...
<apachelogger> slangasek: FTBFS on anything but i386 IIRC
<persia> apachelogger: even lpia?
<apachelogger> persia: can't remember TBH, it isn't of much use without ksquirrel anyway
<lool> ogra: Hans hat ein hohes Haus im Hamburger Haffen
<lool> The h is for Germans
<ogra> Ha Ha :)
<lool> We have oi ou oÃ¯
<mvo> lool: alter! du kennst hans :) ?
<apachelogger> Oo
<apachelogger> ...germans...
<Koon> mvo: aptitude recommends libparse-debianchangelog-perl (which results now in a set of extra packages being included in standard seed). As far as I can tell it doesn't use it at all... am I missing something obvious ?
<mvo> Koon: let me check
<persia> apachelogger: OK.  I think I nearly have the alternate CDs working for lpia, and suspect that as more of the shiny little toys come out, it may be an interesting target for your stuff, although this is probably not a sane target for intrepid at this point.
<mvo> Koon: it will use it for its internal changelog display widget to make version numbers more pretty, but it should work just fine without it
<Koon> mvo: hm. then I missed where in the code it calls it :)
<mvo> Koon: let me re-check, maybe it got removed again
<Koon>  mvo: got it
<Koon> mvo: calls "parsechangelog" without calling any perl. Sorry for thenoise
<mvo> Koon: no problem
<Koon> was fooled into thinking libparse-debianchangelog-perl would only contain perl modules :)
<mvo> Koon: it should work without it afaics
<mvo> Koon: :)
<lool> mvo: Nah klar kenn ich him, und auch Fischer Fritz and seine frische Fische  :-P
<mvo> lol
<lool> seb128: So what's that Ãª regression ?  gtk+ with latin1 layouts again?
<jcristau> lool: s/him/ihn/?
<lool> geez
<seb128> lool: no idea, it's not a multiple layout thing I've only an french one configured
<lool> I just spoke to my german grandmother and I kept mixing english and german
<lool> is hardz
<lool> seb128: Me too
<lool> seb128: But that's the closest thing which came to my mind
<mrooney> is there a guide for making patches in the Ubuntu kosher way? I tried diff -crB but it isn't giving me something comparable to the original patch I was working with
<apachelogger> persia: yes, since KDE is doing a lot of work towards MIDs, this might be a good target for jaunty(+1)
<persia> apachelogger: I suspect you'll be able to get Kubuntu/lpia working for jaunty.  Whether you can get a kubuntu-mobile or kubuntu-mid flavour by then probably depends a lot more on upstream.
<ogra> cjwatson, can i assume that if i simply add "buildlive ubuntu-mobile ;for-project ubuntu-mobile build-image-set" to the crontab on antimony it will just DTRT ? (assuming there is a recent livecd-rootfs that knows abotu ubuntu-mobile)
<persia> Given device availability, I'd recommend chasing kubuntu-mobile before kubuntu-mid.
<apachelogger> persia: I think all the core KDE packages already build on lpia, NCommander did quite some work in this direction.
<persia> apachelogger: In that case, you might try to see if a kubuntu-lpia image works.  I'd recommend waiting for ubiquity 0.10.1, but I think that's the last piece you need.
<ogra> cjwatson, oh, i see build-image-set nedds to be taught about it
<apachelogger> persia: ok, thanks :)
<cjwatson> ogra: check with StevenK, as he's been working on fixing that stuff up
<geser> pitti: can you review and sponsor the hal debdiff in bug 57755?
<ubottu> Launchpad bug 57755 in hal "Udev Rules for SmartCard Support" [Wishlist,Confirmed] https://launchpad.net/bugs/57755
<pitti> geser: not before the beta release (unless you get slangasek's permission); can you please assign it to me?
<ogra> cjwatson, well, i try to wrap my head around it first
<ogra> (beyond the fact thats 1am for him)
<StevenK> ogra: Nope, it won't
<StevenK> cjwatson: There's a bug to remove multiseat -- it contains a udeb, is there anything I need worry about wrt d-i that uses it?
<geser> pitti: assigned, it's not that important that it can't wait after beta release
<ogra> StevenK, yeah, i see buildlive is the first thing needing to learn about ubuntu-mobile ... then build-image-set, then build-mobile and in the end build-mobile-img, did i miss something ?
<geser> pitti: and thanks for your help with it
<pitti> geser: thanks
<StevenK> ogra: publish-mobile
<ogra> yeah and purge ...
<ogra> i wanted to get something building forst before publishng or purging :)
<ogra> *first even
<cjwatson> StevenK: multiseat> no
<bdmurray> \sh: It looks like some stuff is still missing for bug 271550.
<ubottu> Launchpad bug 271550 in ia32-libs "ia32-libs missing libQtDBus, others?" [Critical,Fix released] https://launchpad.net/bugs/271550
<bdmurray> \sh: I think they are libqtgui4, libqtcore4 and libqt4-xml
<sistpoty|work> pitti: Hobbsee already rejected gnome-iconedit ;) (and yes, it was deleted on the very same day where I later fixed it... .not some months ago ;)
<Keybuk> ?! Sorry, the program "bzr" closed unexpectedly
<Keybuk> damned right it was unexpected, I wasn't _running_ bzr!
<YokoZar> I uploaded wine-gecko a while ago, and I forgot to mention that it needs to go into multiverse and not universe
<pitti> Keybuk: but you should!
<pitti> sistpoty|work: ah, ok
<Keybuk> pitti: I don't normally run it while reading e-mail ;)
<Nafallo> Keybuk: you don't have your mails in bzr? :-O
<Keybuk> no
<ScottK> Keybuk: Last week while I was offline you said something to me about changing a 3 year old bug from fix released to incomplete.  I've looked back over my bugmail and can't find anything that looks relevant.  If you still recall the issue and can point me at the bug, I'll be glad to have a look and clarify the situation.
<Keybuk> I commented on it, maybe you hadn't subscribed?
<Keybuk> I don't have the bug# to hand
<ScottK> Perhaps.  I don't recall doing that, but I was totally offline for a week, so my brain pretty well purged that kind of stuff.  If you figure it out, let me know.
<Keybuk> np
<ion_> !away
<ubottu> You should avoid noisy away messages in a busy channel like #ubuntu, or other Ubuntu channels; it causes excessive scrolling which is unfair to new users. Use the command "/away <reason>" to set your client away silently.  See also Â«/msg ubottu GuidelinesÂ»
<cjwatson> cody-somerville: FYI I'm working on fixing up the Xubuntu powerpc CD building problem
<cjwatson> better get it sorted before beta
<cody-somerville> cjwatson, thank you
<kees> doko, Keybuk: when doing an install of glibc from apt, I an error (this didn't happen when I installed it locally with dpkg)
<kees> init:io.c:724: Assertion failed in nih_io_message_send: message != NULL
<Keybuk> kees: it doesn't fail though, right?
<kees> Keybuk: doesn't seem to, no.  and init is running afterwards... is this some "hey, reload" msg being sent to upstart?
<Keybuk> yeah
<Keybuk> which obviously has no reply, since upstart drops the connection to telinit ;)
<kees> heh
<kees> I can reproduce it every time with   sudo apt-get --reinstall install libc6
<Keybuk> you can reproduce it with just "telinit u"
<kees> yes
<kees> ah, this is a recent change to upstart.  whew.  I couldn't even begin to imagine how my glibc patch would have caused it
<Keybuk> well
<Keybuk> it's a bug in glibc's postinst that after a security upgrade, it never restarted upstart
 * kees nods
<Keybuk> so upstart would still have the old libc open on the root filesystem
<Keybuk> so you couldn't remount that ro
<kees> "u" is reload?  (not in the manpage)
<Keybuk> so I monkey-patched "init u" support in the quickest way I could to paper over that
<kees> Keybuk: so upstart had been ignoring "u" before now?
<Keybuk> kees: err, well, it wasn't implemented
<Keybuk> it would have replied "unknown runlevel" or something
<kees> ah-ha found it
<kees> libc.postinst:(init u ; sleep 1)
<kees> sleep 1.  very exacting.  ;)
<Keybuk> heh
<Keybuk> I like the way it's done in a sub-shell
<kees> so, why didn't the "unknown runlevel" stderr show up prior to now?
<Keybuk> no idea
<Keybuk> actually, I may have been silently ignoring u
<kees> yeah, looking at your patch, it seems so
<Keybuk> i silently ignore anything I vaguely saw in a manpage but couldn't be bothered to implement at the time ;)
<kees> heh
<kees> so the fix is to exit(0) instead of break ?
<Keybuk> yeah
<Keybuk> "But that's a critical feature, you can't remove that!"
<Keybuk> "How long have you been using Ubuntu?"
<Keybuk> "Every release since warty!"
<Keybuk> "So you haven't had that critical feature for the last two years, and you haven't noticed until I tell you? :p"
<kees> heheh
<sabdfl> apachelogger: yowser, good stuff on the 5-a-day front
<kees> Keybuk: oooh, I'll bet this not-ro-/ bug is what kept corrupting my XFS root partitions so many moons ago
<kees> (well, really that's an XFS bug, but this was triggering it)
<Keybuk> no, that was just XFS
<kees> heh
<Keybuk> XFS likes to trash filesystems every now and then
<sebner> sabdfl: but afaik he got rejected as core-dev O_o
<Keybuk> it's like a dog weeing on the carpet
<Keybuk> it's just letting you know it's still there
<kees> Keybuk: btw, the "u" crash was filed as 275958
<sebner> Keybuk: no we know how jaunty will boot faster ^^
<Keybuk> sebner: I'm going to comment out the entire boot sequence
<Keybuk> and only uncomment bits people complain about it
<kees> Keybuk: okay, so you're uploading a fixed upstart for beta?
<sebner> Keybuk: hrhr. bad boy :D
<Keybuk> kees: it's not really beta freeze critical?
<sabdfl> sebner: i'm sure just deferred, not denied :-)
<Keybuk> it's a scary warning
<sabdfl> crimsun: also, amazing work there
<kees> Keybuk: I guess not, but it sure is alarming
<Keybuk> kees: I could replace it with a less scary warning
<Keybuk> "GLIBC DETECTED!"
<sebner> sabdfl: hopefully. he just ROCKS :D
<kees> Keybuk: "YOUR MACHINE HAS BEEN ERASED!  just kidding"
<Keybuk> kees: I still want to write something that detects glibc, and outputs "*** glibc detected ***" to let you know
<kees> hahaha
<kees> make sure it writes it to /dev/tty instead of stderr so you have to dig through the source to figure out how to redirect it.
<Keybuk> :)
<ion_> Hehe
<bddebian> lamont: ping? (about palo)
<lamont> which freedom-hating aspect thereof?
<pitti> tedg1: need to leave for Taekwondo; can you please ask one of the US folks for sponsoring the fusa fix?
<pitti> tedg1: (seems seb128 is already out as well)
<bddebian> lamont: Heh, just curious if you were going to fix it in Debian?  It appears you fixed in in Ubuntu? (BTS #464262)
<tedg1> pitti: Yes.
<apachelogger> sabdfl: hehe, doing my best ;-)
<lamont> bddebian: I think someone fixed it in ubuntu
<lamont> I've been ignoring it
<lamont> the assertion was that it was broken glibc headers somewhere
<bddebian> Oh, slangasek uploaded the fix in Ubuntu
<sebner> apachelogger: hehe \o/
<lamont> last time I mentioned it in the parisc channel, there were other ideas about fixing it, so I left it in their hands.
<lamont> OTOH, dunno
<apachelogger> sebner: btw, when do you apply for MOTU?
<sebner> apachelogger: not in this month and not in the next one. why?
<apachelogger> sebner: just wanted to know, I am currently at 698 unread mails, and KDE 4.1.2 packaging is still gonna take a while, so I will probably have one month of lag in reading mails ;-)
<sebner> apachelogger: oh. didn't know that you really consider to comment. otherwise I'd let you know when I send the mail
<apachelogger> sebner: commenting might be time consuming, but for you I consider taking the effort :P
 * sebner feeds apachelogger with cookies :P
<apachelogger> (:
<sebner> apachelogger: so it only make sense if it's a postive comment :P
<apachelogger> sebner: will be a short commen then :P
<apachelogger> +t
<geser> apachelogger: you're cheap :)
<sebner> apachelogger: perfect. you save time and I have a postive comment :P
<apachelogger> geser: :P
<sebner> geser: I still have a secret weapon :D
 * sebner gives apachelogger a captain :D
<apachelogger> hm
<apachelogger> sebner: KDE release packaging > captain
<sebner> apachelogger: gnome > kde :P
<sebner> apachelogger: and think of your poor padawans. R.I.P :P
<apachelogger> sebner: mac > gnome :P
<sebner> apachelogger: gnu > mac :P
 * apachelogger mentions darwin and hides
 * sebner slaps apachelogger with hurd :P
<jdong> apachelogger: lol I've seen someone running more or less Darwin with GNU CLI stuff onboard
<jdong> apachelogger: I guess just taking "think different" a step or 10 too far.
<apachelogger> hehe
<jdong> oh the things people go through to look cool.
<ahasenack> does anybody know what causes this? http://pastebin.ubuntu.com/52169/
<ahasenack> some post calling debconf again?
<ahasenack> that's on intrepid, btw
<ahasenack> (if it matters)
<mvo> ahasenack: is that on your system?
<mvo> ahasenack: or in a VM?
<ahasenack> mvo: no, it was reported by somone in launchpad
<ahasenack> mvo: https://bugs.launchpad.net/ubuntu/+source/landscape-client/+bug/275615
<ubottu> Launchpad bug 275615 in landscape-client "package landscape-common 1.0.21.1-0ubuntu1 failed to install/upgrade: subprocess post-installation script returned error exit status 1" [Undecided,New]
<mvo> ahasenack: aha, ok. I have seen reports with that as well, but I haven't had anything conclusive yet, it might be cause by someone running dpkg-reconfigure something (ee.g. console-setup) in another window
<ahasenack> mvo: ok, I see
<ahasenack> mvo: thanks!
<infinity> mvo: Doesn't dpkg-reconfigure check the dpkg lockfile?
<infinity> mvo: You'd think it would...
<infinity> mvo: s/check/check, touch, and remove/
<mvo> infinity: indeed, but it seems like it does not, dpkg-reconfigure console-setup (and leaving it) and then dpkg -i /tmp/foo.deb does work, just debconf does not
<mvo> infinity: I guess that would be the bug then :)
<infinity> mvo: Yeah, given that dpkg-reconfigure is executing maintainer scripts, it's effectively a dpkg-like process, so should definitely lock.
<infinity> mvo: Of course, as soon as you change it to lock, you'll discover some (utterly broken, IMO) package that uses dpkg-reconfigure in it's own maintainer scripts. :P
<infinity> mvo: (Hypothetical, but I'll give good odds that SOMEONE's done it)
<mvo> infinity: heh :) let them burn!
<cjwatson> infinity: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=469354
<ubottu> Debian bug 469354 in debconf "debconf: dpkg-reconfigure should acquire dpkg lock" [Normal,Open]
<stgraber> Am I the only one with passwd behaving strangely ?
<stgraber> When changing my password and not entering the same password twice, it tells me:
<stgraber> Sorry, passwords do not match
<stgraber> passwd: password updated successfully
<stgraber> and returns 0
<slangasek> stgraber: there's a bug on pam about that
<slangasek> I need to look at it for intrepid, but not before beta
<stgraber> ok
<james_w> bug 272232
<ubottu> Launchpad bug 272232 in pam "passwd - passwords do not match but updated successfully" [Undecided,Confirmed] https://launchpad.net/bugs/272232
<slytherin> any archive admin around?
<infinity> slytherin: Several.
<slytherin> can anyone please fix the bug #272866? I am waiting for it to work on rdepends and reverse-build-depends
<ubottu> Launchpad bug 272866 in javassist "Please move package to universe" [Undecided,Confirmed] https://launchpad.net/bugs/272866
<tedg1> Can someone sponsor a couple of packages to main for me please?  In my PPA, gnome-power-manager_2.24.0-0ubuntu3 and fast-user-switch-applet_2.24.0-0ubuntu2.  http://launchpad.net/~ted-gould/+archive
<bryce> tedg1: have you gotten a beta-freeze exception?
<tedg1> bryce: Well one is a beta-freeze milestone thingy.  Is that an exception?
<slytherin> tedg1: Why not add debdiff to the bugs that are fixed by these packages?
<tedg1> slytherin: Because the person that would have to turn them into a package is me :)
<slytherin> tedg1: I don't understand. You are asking for sponsorship. Do you expect people to take package form your PPA and sponsor it?
<tedg1> slytherin: I thought they could copy it?
<tedg1> Isn't that one of the new LP features?
<slytherin> tedg1: Could or could not, that is not how it works.
<slytherin> tedg1: You have to add debdiff to the bug. Then subscribe ubuntu-main-sponsors to the bug. Someone will take that debdiff, verify and then sponsor.
<ogra> bryce, tjaalton, is there any way for me to not have to install the evtouch .fdi files into /etc/hal/fdi/policy ? if i put them into /usr/share/hal/fdi/policy/10osvendor they seem to be overwritten by mouse settings ... but it somehow feels wrong to put them into /etc
<slangasek> tedg1: as far as ppa copying is concerned, I didn't think that was going to (initially?) be available to anyone but archive admins
<bryce> tedg1: yeah if I were to sponsor a package from a ppa, I'd normally convert it into a debdiff
<bryce> even with ppa copying, i'd still want to see the debdiff for review purposes
<bryce> ogra, could it go into hal itself?  we've put a few fdi files into there so far
<cody-somerville> Launchpad generates the diff automatically
<ogra> bryce, upstream nearly flamed me when i asked ...
<ogra> danny kukawa doesnt want driver specific fdi'd in hal
<bryce> ogra, we've generally worked with pitti on these sorts of issues
<ogra> *fdi's
<ogra> well, you need the driver package installed anyway, so i dont think the attempt is to wrong
<ogra> the only prob i have atm is the forced install location
<slangasek> apachelogger: so I had to fix a cross-arch libksquirrel FTBFS, and along the way I've fixed the amd64 build failure too since that's what I have to hand as a dev env; I haven't changed the architecture: field, though
<superm1> TheMuso, something I didn't see mentioned in that pulseaudio bug, check and see whether users were setting up automatic login and how that affects the pulseaudio daemon that gets spawned (since automatic login is easy to setup now in oem-config or ubiquity)
<ogra> i'm not sure why they get ignored in /usr/share either
<slangasek> lool, slomo_: gar, this gstreamer0.10 build failure is evil, it never fails if I run the command by hand :(
<bryce> slangasek: friday seb128 mentioned an xvfb fbs issue, that I offered to look into today, yet I can't find a mention of it in launchpad.  Do you know more about what the issue is and where I could find an error log or bug report?
<bryce> (I've been hoping seb128 would pop online but I guess he's done for the day)
<bryce> I'm assuming it's something that gets triggered during a 'make test' kind of a thing in some package(s)
<slangasek> bryce: last-but-one builds of pygtk or gnome-python-extras show the error; it has to do with xvfb -noreset or something, it was discussed extensively in scrollback here this morning (around 4am or so, IIRC)
<slangasek> I don't know if it's still regarded as an Xvfb bug; the package builds are fixed
<slangasek> tedg1: oh, bug #274681 fixed, awesome
<ubottu> Launchpad bug 274681 in gnome-power-manager "g-p-m is reporting 2 separate voltage/power levels" [High,Fix committed] https://launchpad.net/bugs/274681
<tedg1> slangasek: Yes, except that the reason it was broken was entirely my fault :)
<slangasek> sure, it's still awesome that it's fixed before I had a chance to report it :-)
<bryce> slangasek: hrm, wonder if I should spend time investigating or not
<slangasek> bryce: I vote "no" for now :)
<bryce> wish someone had filed a bug on it so it'd be easier to tell
<slangasek> bryce: the immediate issue was the build failure, which I understand has been fixed without having to drop the test suite out
<bryce> slangasek: ok, looks like look did this to fix the build failure:
<bryce> pygtk (2.13.0-0ubuntu5) intrepid; urgency=low
<bryce>   * Pass no -s -no-reset to xvfb-run to prevent Xfvb from exiting when the
<bryce>     last client disconnects and hence allow xvfb-run to kill it.
<bryce>  -- Loic Minier <lool@dooz.org>  Mon, 29 Sep 2008 10:53:49 +0200
<Edulix> hi
<Edulix> I've noticed that NEtworkManager leaks memory in 8.04, is that fixed in 8.10 ?
<bryce> slangasek: ok you're right.  It looks like the issue was that xvfb by design assumes a single client, and exits after that client exits.  According to lool's analysis, the pygtk testsuite was attempting to use a single xvfb instance with multiple clients (individual tests), which was causing the breakage.  Having to include the -no-reset flag appears to be a correct fix and not just a workaround
<slangasek> calc: gstreamer0.10-plugins-good (+base, which it depends on) gives you all the codecs and formats that are supported by everything in main
<slangasek> calc: if OOo users need something outside that set, well, there are Larger Reasons why we don't install them by default :/
<slangasek> (and no, it's not just theora/vorbis - at least flac, qtdemux, speex are there)
<slangasek> tedg1: fwiw, fusa can't do a source build after a binary build, it leaves generated .png files around
<slangasek> (clean target should be fixed)
<tedg1> slangasek: The uudecoded ones?
<slangasek> yes
<slangasek> they should be removed in clean
 * tedg1 is a little curious what make is going to do with that.  Since they're a data tag, I'm curious if they'll be built to be deleted....
<slangasek> if you mean automake 'DATA', it shouldn't
<tedg1> Yeah, it doesn't cool.
<kees> slangasek: should I upload a fix for 273761 before beta?
<slangasek> kees: sorry, I'm on my way out the door so can't look that up right now; but it doesn't hurt to upload and have it sit in the queue, regardless
<slangasek> (unless it hurts you to do the work, I guess :)
<kees> slangasek: no, the fix is trivial. when discussing it with Keybuk earlier, it seemed like it wasn't important to fix (amd64 handles it more gracefully).  but it seems that i386 segv's triggering apport.  (38 dups in 6 days)
<sbeattie> kees: you verified it addresses the issue for i386?
<kees> sbeattie: waiting for the compile to finish, but it fixes it for amd64.  a few more moments...
<kees> sbeattie: confirmed to fix it on i386.
<kees> I have no idea where Keybuk keeps the actual _code_ for upstart's ubuntu branch, his bzr tree is packaging only and I can't commit to it.
<sbeattie> kees: okay. So long as we're sure it won't get lost in a future upstart update.
<kees> sbeattie: I don't think so.
<kees> doko: I don't know why, but PPC glibc isn't building (it's failing in tests, and I'm pretty sure my change isn't the cause).  any idea?
<doko> kees: which test?
<kees> doko: I just retry'd the build.  none of the other archs fail.
<kees> doko: http://launchpadlibrarian.net/18052012/buildlog_ubuntu-intrepid-powerpc.glibc_2.8~20080505-0ubuntu7_FAILEDTOBUILD.txt.gz
<kees> GCONV_PATH=/build/buildd/glibc-2.8~20080505/build-tree/powerpc-libc/iconvdata LC_ALL=C   /build/buildd/glibc-2.8~20080505/build-tree/powerpc-libc/elf/ld.so.1 --library-path /build/buildd/glibc-2.8~20080505/build-tree/powerpc-libc:/build/buildd/glibc-2.8~20080505/build-tree/powerpc-libc/math:/build/buildd/glibc-2.8~20080505/build-tree/powerpc-libc/elf:/build/buildd/glibc-2.8~20080505/build-tree/powerpc-libc/dlfcn:/build/buildd/glibc-2.8~20080505/bu
<kees> /bin/sh: Syntax error: Bad fd number
<doko> I'll retry on the other buildd
<kees> make[3]: *** [/build/buildd/glibc-2.8~20080505/build-tree/powerpc-libc/nptl/tst-cleanup0.out] Error 2
<kees> ieee
<kees> sorry, that was a much longer paste
<kees> than I was expecting.  :)
<kees> doko: how do you push it to another buildd?
<doko> setting the other to manual
<kees> heh
<infinity> They both use the same chroot...
<infinity> I see no way that something like FD breakage would change from one host to another.
<doko> but today is Monday
<kees> I'd seen this error the very first time I built glibc locally the ("Bad fd number") stuff, and suspected maybe I was running out of disk space.  I cleaned up, and it went away.
<doko> hmm
<infinity> Which host was the failure on?
<kees> Builder:   ross (powerpc)
<calc> slangasek: oh i don't disagree that it shouldn't be pulled in by default (i had forgotten about the recommends bit) just that only installing the good set won't be of too much use for cross platform office document viewing
<ogra> cjwatson, i still end up with epiphany in the mobile build :/
<ogra> so adding the task didnt really solve it it seems, unless my preseeding is wrong
<sbeattie> kees: whoops, sorry for the bug editing collisions.
<cjwatson> ogra: point me to the build logs?
<ogra> not sure they are mirrored already
<ogra> log/ubuntu-mobile/intrepid/daily-20080929.7.log
 * ogra looks at people.u.c
<cjwatson> I meant the livefs log
<ogra> oh
<ogra> indeed
<cjwatson> http://people.ubuntu.com/~ubuntu-archive/livefs-build-logs/intrepid/ubuntu-mobile/latest/livecd-20080929.1-i386.out?
<ogra> argh, my FF is broken
<ogra> likely -2
<ogra> if there is one
<kees> sbeattie: no problemo :)
<cjwatson> ogra: wouldn't you need http://paste.ubuntu.com/52238/ in order to actually use the task?
<ogra> asac, http://people.ubuntu.com/~ogra/FF_no_button_text.png
<ogra> cjwatson, oh, sigh, indeed, i forgot about that one
<ogra> not for mid though, they dont want a task i was told
<ogra> lool, ^^^
<cjwatson> ogra: actually, make that http://paste.ubuntu.com/52239/
<ogra> yeah
<ogra> the preseed already has mobile-mobile
<ogra> cjwatson, sorry for wasting your time :(
<norsetto> asac: just uploaded new versions for gnome-mplayer/gecko-mediaplayer to mentors if you want to sponsor ...
<cjwatson> ogra: it's ok
<cjwatson> it took almost no time since I suspected that was the problem from the start :)
<cjwatson> ogra: do you want that ubuntu-mobile crontab entry added to the live crontab?
<slavik> any chance of evolution 2.26 in ibex?
<ogra> cjwatson, i already added it, i suppose someone needs to activate it ?
<cjwatson> hence "live crontab"
<cjwatson> done
<ogra> cjwatson, oh, well, the cdimage entry calls "buildlive ubuntu-mobile; for-project ubuntu-mobile build-image-set"
<ogra> so i should drop the "buildlive ubuntu-mobile;" i suppose ?
<cjwatson> ogra: what? not that sort of live
<ogra> oh, k
<cjwatson> ogra: editing the crontab requires running the crontab command to update it
<ogra> ah
<cjwatson> ogra: I've done it now
<ogra> live as in actual :)
<ogra> heh
<asac> ogra: not properly restarted after upgrade?
<ogra> i totally misunderstood ... we actually meant the same ... live confused me
<ogra> asac, rebooted
<asac> ogra: LANG? en-us?
<ogra> de_DE
<ogra> de_DE.UTF-8 actually
<ogra> humm, cjwatson can you let the livecd-rootfs package through ? (and probably as well xf86-input-evtouch)
<asac> ogra: maybe language changes something?
<ogra> asac, let me try
<ogra> asac, hmm, gone now
<ogra> cant reproduce it
<asac> ogra: yeah .. you didint properly restart :-P
<ogra> well, i'd expect a reboot to be a proper restart :)
<ogra> but well
<ogra> all fine now
<cjwatson> ogra: both done
<ogra> gracias
<ogra> i wonder if it makes it until 2:45UTC ...
<asac> ogra: i agree ... if you see it again, let me know.
<ogra> will do
<seb128> slangasek: I've sponsored a gnome-build upload which fixes the previous screwed update we synced on debian, could you consider accepting before beta? only anjuta uses it and it's not installable right now due to the gdl changes, once this gnome-build is built we can sync anjuta 2.24 which fixes the installability issue
 * ogra calls it a day
<asac> ogra: enjoy
<slavik> is openchange going to be in ibex?
<asac> cjwatson: slangasek: i have uploaded latest NM with the wizard. its network-manager, -applet, -pptp, -vpnc and -openvpn. thanks.
<slavik> cjwatson: does it honor the /etc/network/interfaces settings?
<asac> slavik: you probably ask me?
<slavik> bah ...
<slavik> yes
<lool> ogra: Sorry, don't quite get why you say mid doesn't want the task?  You mean the mobile one?  Or is this about the task headers?
<asac> slavik: it honours them if you append the ,ifupdown plugin to the nm-system-settings.conf
<slavik> ty
<slavik> asac: will that be default?
<asac> slavik: the fix for the /etc/network/interfaces bug will be fixed individually
<slavik> there's a bug associated with that?
 * slavik is not aware of anything
<slavik> also, any idea of the best place to track the e1000e regression in the kernel?
<asac> slavik: well, there is bug 256054
<ubottu> Launchpad bug 256054 in network-manager "[intrepid] new 0.7 branch ignores /etc/network/interfaces" [Unknown,Confirmed] https://launchpad.net/bugs/256054
<asac> slavik: look in the mailing list archives. i think there was mail that referred to a bug id
<slavik> k
<slavik> asac: any idea about the openchange mapi plugin for evolution?
<asac> slavik: why do you have so many questions ;)
<slavik> I know gnome 2.26 will have it ... but any chance 2.24 to have it?
<slavik> asac: asking questions is what I do
<asac> slavik: i am not the gnome maintainer ;)
<asac> slavik: bug 263555
<slavik> it's the best way to learn things (and to annoy people, too)
<ubottu> Launchpad bug 263555 in linux "[intrepid] 2.6.27 e1000e driver places Intel ICH8 and ICH9 gigE chipsets at risk" [Critical,In progress] https://launchpad.net/bugs/263555
 * norsetto calls it
<TheMuso> cjwatson: Oh right, I'll have another look today then.
<mathiaz> slangasek: openchange is already available in the intrepid archive.
<mathiaz> slangasek: hm - sorry - not for you
<superm1> TheMuso, the bzr tree for alsa-lib is missing your last few uploads.  don't forget to merge them back in
<TheMuso> superm1: I am well aware of that.
<superm1> TheMuso, okay wasn't sure, just a friendly reminder.  I was pushing a bzr branch out for merging and noticed i had more changelog entries than i should in my commit
<MaximLevitsky> I suggest you add glipper to base install, bacause it is very awkward to deal with the disapperance of clipboard when you close an app
<MaximLevitsky> Or at least something that does that
<seb128> TheMuso: hi, could you look at http://bugzilla.gnome.org/show_bug.cgi?id=535827, basically at-spi has a schemas which is not installed in ubuntu
<ubottu> Gnome bug 535827 in gtk "Automatically load gail:atk-bridge if AT_SPI_IOR is set on root window" [Normal,Unconfirmed]
<TheMuso> seb128: I've been made aware of it by the orca lead developer, will take a look once I've processed email for the morning.
<seb128> TheMuso: ok, they subscribed me to the bug so I was just forwarding the information
#ubuntu-devel 2008-09-30
<slangasek> kees: #273761> yeah, that ought to get in
<kees> slangasek: okay, it's uploaded and waiting for you.  :)
<slangasek> yep, seen :)
<slangasek> seb128: I don't see gnome-build in the queue; did someone already accept it?
<seb128> slangasek: apparently yes, there was a batch of updates accepted a few minutes after I asked apparently
<slangasek> asac: ok, will look at the NM uploads, thanks; btw, I'm seeing that the system-level secret store for NM doesn't seem to be working, every time I reboot I get prompted for the wep key before I can connect :/ do you know if there's a bug about this?
<cjwatson> slangasek: I did an accept-everything-for-universe pass which included gnome-build
<slangasek> ah, sure
<slangasek> thanks :)
<asac> slangasek: i think that secret issue should be fixed now
<slangasek> asac: in your current upload, you mean?
<asac> slangasek: yes.
<slangasek> cool
<asac> slangasek: there was definitly an issue in the applet with regards to writing secrets which is in the diff
<slangasek> ah; as far as I could tell it was an issue reading, not writing, the secret
<slangasek> (at least, I saw the secret was written to a file)
<TheMuso> asac: Have you tried flash with recent pulseaudio updates I've made by any chance? I have some users saying that since a recent update to pulse I made, flash and pulse via alsa plugin are not working as they should...
<asac> slangasek: +               - (nm_gconf_write_connection, write_one_secret_to_keyring): split out
<asac> +                       writing of secrets into it's own function for clarity.  Fixes a
<asac> +                       regression introduced in r875 where secrets wouldn't get saved.
<asac> slangasek: oops ;)
<slangasek> ok
<asac> TheMuso: i tried it a bit ... my sound worked nicely
<asac> TheMuso: (after removing my asoundrc ... which should be enough?)
<TheMuso> asac: Right, I'll have to keep digging then.
<doko> pitti: I'd like to fix an ice-on-invalid bug in gcc-4.2 in hardy (seen when working with eclipse). do you want to move the packages to -updates first?
<slangasek> calc: so OOo is ftbfs on all !x86 right now?
<doko> slangasek: please accept ant and libxerces2-java
<slangasek> doko: is there an associated, beta-blocking bug?
<doko> slangasek, calc: I did talk with calc about powerpc; didn't look at sparc yet
<doko> slangasek: yes, mentioned in the changelog
<slangasek> doko: but, notably, not tracked on https://bugs.launchpad.net/ubuntu/intrepid/+bugs?field.milestone=1325 ? :)
<doko> https://bugs.edge.launchpad.net/ubuntu/+source/ant/+bug/264808
<ubottu> Launchpad bug 264808 in libxerces2-java "ant does not work with JDK 5" [Undecided,New]
<doko> milestone is ubuntu-8.10-beta
<doko> what did I miss?
<slangasek> 'target to release'
<doko> nominate?
<wgrant> Due to an LP bug, yes.
<cjwatson> it's "nominate for release" if you aren't in ubuntu-drivers or ubuntu-release or whatever team it is
<doko> wgrant: is this LP bug filed?
<cjwatson> wgrant: what LP bug?
<cjwatson> just that the text is different?
<slangasek> TheMuso: hrm, after my latest reboot, audio seems to have regressed somewhere for me; is this a known issue?
<wgrant> doko: I don't think so.
<wgrant> cjwatson: Right - it only checks if you're a driver, but there are special privileges for distros.
<doko> no, I was surprised that just setting the milestone is not enough
<wgrant> Only the text is wrong, however.
<cjwatson> doko: http://wiki.ubuntu.com/RCBugTargetting
<cjwatson> that part at least is not an LP bug, it's intentional
<cjwatson> "Only those milestoned bugs which are also marked as release-critical, by way of targeting to the release, will be managed by the release team"
<cjwatson> and this was because developers not on the release team asked for this
<doko> ok, wasn't aware about the history
<cjwatson> the idea is that targeted + milestoned == release-critical for milestone, not targeted + milestoned == developer planning own work but might slip
<TheMuso> slangasek: What were you trying to play audio with, and how were things set up?
<slangasek> TheMuso: quodlibet, which uses gstreamer and has worked previously; through pulseaudio, which is running; consolekit has the correct perms on the devices; that's as far as I've looked so far
<TheMuso> slangasek: Yeah its known, I haven't been able to pin it down yet, and I can't seem to reproduce locally. Just updating an intrepid install to the latest updates now, and I will see what I can find.
<slangasek> ok
<slangasek> is there a bug number for this?
<TheMuso> slangasek: in gnome-sound-properties, you are using pulseaudio or auto detect are you not?
<TheMuso> slangasek: one sec, I'll fetch.
<slangasek> autodetect
<slangasek> shall I try to hard-code to pa?
<slangasek> ah, the 'test' button gives me: 'audiotestsrc wave=sine freq=512 ! audioconvert ! audioresample ! gconfaudiosink: Failed to connect stream: Invalid argument
<slangasek> '
<doko> slangasek: did nominate the bug
<slangasek> doko: thanks
<TheMuso> slangasek: I think bug 274124 is the most relevant.
<ubottu> Launchpad bug 274124 in pulseaudio "Sound no longer working after kernel upgrade to 2.6.27-4" [High,Confirmed] https://launchpad.net/bugs/274124
<TheMuso> slangasek: there is a libasound2-plugins package I linked to in that bug, install that and see if that helps you.
<slangasek> TheMuso: hmmm, I can neither confirm nor deny that this was my first reboot to 2.6.27-4
<TheMuso> It sounds like autodetect for most people is defaulting to alsa which then attempts to use the alsa pulse plugin.
<TheMuso> slangasek: I am almost 100% sure it is not kernel related, but the bug reporter thought it was.
<slangasek> well, I get the same error with the 'test' button if I manually select pulseaudio instead of autodetect
<TheMuso> I think I even said as much in the bug./
<crimsun> it's not related to the kernel; it's an alsa-plugins issue.
<TheMuso> crimsun: but alsa-plugins doesn't make sense for straight pulse not working...
<crimsun> TheMuso: but pulseaudio seems to have problems when swfdec is attempting to play audio, so I'm going to take a look there.
<slangasek> ok, here's what I have in the log:
<slangasek> Sep 29 15:53:36 dario pulseaudio[7368]: alsa-util.c: Error opening PCM device hw:0: Device or resource busy
<slangasek> Sep 29 15:53:36 dario pulseaudio[7368]: module.c: Failed to load  module "module-alsa-sink" (argument: "device_id=0 sink_name=alsa_output.pci_8086_27d8_alsa_playback_0"): initialization failed.
<TheMuso> slangasek: SOunds like you have something else that is holding the hardware open, and pulse hasn;'t been able to grab itr.
<slangasek> nothing else has the hardware open at this point
<slangasek> $ sudo fuser -v /dev/dsp  /dev/snd/pcmC0D*
<slangasek> $
<TheMuso> hrm.
<crimsun> if so, then you should be able to restart pulseaudio from the cli successfully
<slangasek> if I kill and restart pulseaudio, it works,y es
<slangasek> so: device contention at login time, wih the startup sounds?
<TheMuso> slangasek: Do you happen to have any .asoundrc files in your home directory?
<slangasek> yes
<slangasek> (for trying to configure bluetooth audio)
<TheMuso> Ah ok.
<TheMuso> Try moving them away for now...
<TheMuso> they probably may have somethign to do with it, depending on whether they alter the default device used.
<slangasek> they don't
<TheMuso> ok they shouldn't be a problem then.
<slangasek> do you still want me to try moving it aside, and re-logging in?
<TheMuso> No if they don't alter the default device used I don't think they are a problem.
<slangasek> asac: how thoroughly has this NM build been tested?  it's a rather large change to drop this close to beta
<calc> slangasek: it did build on amd64/lpia last time i built it from what i recall
 * calc looks at the build logs
<calc> slangasek: yea it builds on the supported archs :\
<calc> slangasek: i think i can get it working on powerpc again, if nothing else by disabling java (which makes is of questionable use)
<calc> slangasek: hppa doesn't work at all, its unsupported platform
<calc> er unsupported all around i mean, not by sun/go-oo/us etc
<calc> not sure about the ia64/sparc issue will have to see if it is due to the same basic problem affecting powerpc
<calc> but sparc generally doesn't build OOo either, it has failed nearly every time generally in ICEs
<TheMuso> calc: I'm happy to do a test build of OpenOffice on PowerPC again if that is of any help...
<calc> TheMuso: the problem was it couldn't find libjawt and i think i know how to fix it properly now
<calc> TheMuso: i missed a patch that was needed when adding support for openjdk
<TheMuso> calc: Ah ok.
<calc> slangasek: ia64 fails due to what seems like is probably an openjdk issue
<calc> "error (RuntimeException): [jni_uno bridge error] UNO calling Java method initialize: java.lang.StackOverflowError"
<asac> slangasek: well. beta is supposed to bring the testing.
<calc> yea sparc looks like it is probably the same issue as powerpc, even after fixing i would be surprised if they build correctly though
<asac> slangasek: the core features (wired and wifi) are unlikely to have regressed much
<asac> slangasek: there is one known regression ... it sets the hostname to localehost.localdomain in /etc/hosts
<asac> that is because we are lacking a system integration part that reads /etc/hostname
<asac> slangasek: except from that most changes in ChangeLog are either from me or about non-core features like VPN, etc. and a bit polishing
<asac> (from me -> upstreamed)
<ScottK> slangasek: I took a brief look at Intrepid uninstallables and the solution for ubuntu-virt-management is to demote it to Universe.  The MIR (Bug #274053) says that binary should not be promoted.
<ubottu> Launchpad bug 274053 in ubuntu-virt "main inclusion request: ubuntu-virt-server" [Undecided,Fix released] https://launchpad.net/bugs/274053
<slangasek> calc: yes, amd64 and lpia are also "x86" :)
<calc> slangasek: ok so yea more or less :)
<slangasek> asac: "beta is supposed to bring in the testing" -- yes, but testing of things that we have some assurance are solid; not things that have been dropped in hours before the CD builds need to start
<calc> slangasek: powerpc has had java issues forever, sparc has had compiler broken issues forever, hppa is completely unsupported, and ia64 appears to have broken openjdk
<calc> so yep x86 is about all OOo will work on
<slangasek> asac: uhhh. why is NM touching /etc/hosts *at all*?  That alone sounds like a major regression to me that's going to have lots of knock-on effects :/
<slangasek> ScottK: thanks, demoted
<calc> ok i think i have the patch that should help for powerpc and sparc
<calc> slangasek: so i take i should NOT upload the OOo fix until after beta release, correct?
 * calc takes no answer as a no unless he hears otherwise later
<calc> i'm doing a build to verify i didn't break anything on amd64 with the patch but i think it will at least fix the current cause of failure on powerpc/sparc
<slangasek> calc: hum, yeah, let's hold off on the OOo powerpc/sparc fix
<dholbach> good morning
<slytherin> ï»¿should I file a bug for this? type-handling any linux-gnu generates a list which contains i686 and lintian throws error invalid-arch-string-in-source-relation i686
<pitti> Good morning
<pitti> doko: yes, I'd prefer that, if they got verified by someone?
<superm1> pitti, good morning.  i've been reluctant to milestone a bug that i've subscribe ubuntu-release to (bug 274950), but given the amount of churn it will cause if it's done, i'm thinking feedback sooner (before beta would be better), would you agree that i should milestone it in this case so that it shows up on more people's radars?
<ubottu> Launchpad bug 274950 in obex-data-server "Look into switching to bluez 4.x" [Undecided,In progress] https://launchpad.net/bugs/274950
<superm1> (i'm not trying to queue jump and get you to exert ubuntu-release decisions right now, just whether i should put it into the milestone queue in the first place)
<pitti> superm1: I think just pinging slangasek and me will do; right now there seems to be much discussion and testing, and thus too early to make a decision (that was my impression anyway)
<slangasek> superm1: I don't see this as critical for beta, so we shouldn't risk disrupting the CD prep
<superm1> pitti, yeah i just haven't seen any constructive criticisms at this point, so i wanted to make sure it doesn't just show up as a big "surprise"
<superm1> slangasek, okay, but you think it will still be feasible to possibly squeeze between beta and release still though?
<slangasek> superm1: didn't I see a comment in the bug log that the only regression presented as justification for the update could also be addressed by twiddling a conffile and starting hidd?
<slangasek> I think it's not entirely out of the question
<slangasek> the testing seems pretty thorough, judging by how often I'm getting bug mail about it :;;-)
 * slangasek thwaps his semicolon key
<superm1> slangasek, not that i'm aware.  regarding hidd.
<superm1> it at least crashes hcid when you pair with a keyboard too, so that would be masking the problem
<superm1> or "try" to pair with the keyboard
<slangasek> ah
<superm1> slangasek, something else that i don't see brought up on this bug is that it will bring an soname bump (libbluetooth2->libbluetooth3).  should I add tasks for the rebuilding of those applications to ensure that there are no possible compile failures on them with API changes?
<slangasek> superm1: ah, that would be good, yes
<dholbach> hi mvo
<superm1> slangasek, okay that list of bugmail will grow a bit then :)  that'll be a task for tomorrow morning
 * StevenK checks for a list of rdepends
<superm1> okay one last question; the old bluez-utils package was providing an initscript called "bluetooth" which is now provided by the "bluez" package.  if "bluez-utils" isn't purged and they share the same init script name - that causes complications where you can't purge bluez-utils later.  i worked around it by making a new bluetoothd init script instead for the bluez package.  upstream prefers to use the same init script name instead though.
<superm1> is the proper way to clean up between the two by using a transitional bluez-utils dummy package then?
<slangasek> superm1: the problem on purge is that the postrm update-rc.d fails?
<superm1> slangasek, yup
<slangasek> transitional bluez-utils package would be ok.  Why are we reorganizing binary packages at all, though?
<superm1> because that package provides more than just utlities
<superm1> it's the whole stack that doesn't need more dependencies sans libbluetooth
<superm1> again, that's how upstream wants to see it instead
<superm1> that's how it's being implemented in F10 too
<slangasek> well, F10 package splits are usually crack
<slangasek> s/F10/Fedora/
<slangasek> so I don't think that's a compelling argument for changing the split in Ubuntu
<superm1> well it really doesn't make sense to have a separate binary package for a single .so though that has no other dependencies
<superm1> eg what bluez-input and bluez-serial etc were
<superm1> also how it's being implemented in suse from what I understand too.
<slangasek> is this change also being made in Debian?  I care a lot more about how it's going to affect interdependencies with packages from a distro we actually sync from :)
<superm1> debian isn't packaging 4.x for some time
<superm1> and godog hasn't been responding to pings about it at all
<slangasek> so the packaging change isn't coordinated, then :/
<superm1> so perhaps this does make most sense to keep the same binary packages as close to prior as possible
<superm1> at least until debian has a decision about how they want to do it
<superm1> i'll reorganize it again then tomorrow
<mvo> hey dholbach
<StevenK> There are 39 sources that rdepend on libbluetooth2
<slangasek> peanuts
<kagou> i
<kagou> Hi
<StevenK> I can pick out 2 from the list that don't build from my dealing with NBS
<superm1> StevenK, is that on hardy or intrepid?
<StevenK> superm1: The latter
<superm1> yeesh
<StevenK> superm1: I have a bunch of scripts that automates most of it
<StevenK> Can you tell I've been doing NBS stuff for a while? :-P
<kagou> i'v tested daily-livre intrepid desktop on (for the forst time for me) raid 1 (nvidia). I had to manually install dmraid on livecd (partition ...), and manually install dmraid on installed system (to boot). SO my question : why dmraid is not automatically installed ?
<StevenK> superm1: Has the library package in your PPA been bumped to 3?
<superm1> StevenK, so can you do a test against libbluetooth-dev from the bluetooth PPA and see which failed?
<superm1> StevenK, yeah it has
<StevenK> superm1: ~bluetooth/+archive ?
<superm1> StevenK, yup
<StevenK> superm1: I'll set it up and kick it off.
<superm1> StevenK, thanks, that will be a big help
<StevenK> superm1: Let me pastebin the list I got, some of them you will update, so I don't need to touch
<superm1> StevenK, yeah at this point i can tell you that gnome-user-share, gvfs, obex-data-server and bluez-gnome don't need to be on it
<superm1> (i've already touched all of them)
<StevenK> superm1: http://paste.ubuntu.com/52382/
<doko> pitti: hmm, not yet applied upstream, lets wait a bit
<superm1> StevenK, okay then this list should be reflective of what still needs testing: http://paste.ubuntu.com/52383/
<StevenK> superm1: I guess bluez-* can pretty much be ignored. Do you want to dump out the things I don't care about and re-pastebin it?
<TheMuso> kagou: dmraid is on the alternate CD. You can use the alternate CD now to install onto dmraid arrays. Unfortunately the live CD won't get dmraid till Jaunty.
<kagou> ok TheMuso. Why not providing dmraid on desktop. It's a very small package :)
<TheMuso> kagou: It has to do with implementing support into the installer. It was relatively easy to do for the alternate CD, but from what I've been told, work has to be done on ubiquity to properly support device-mapper devices, such as dmraid arrays.
<kagou> TheMuso, oh I understand. Thanks !
<StevenK> Ew.
<StevenK> Evolution needs a rebuild
 * StevenK quietly sobs
<slangasek> seb128: was there a sync request for anjuta? (getting ready to NBS out libgdl-gnome-1.0)
<seb128> slangasek: no, I didn't bother filing a bug and just synced directly
<slangasek> seb128: ok - so it's synced now?
<seb128> slangasek: yes, I did it one hour ago
<slangasek> cool
<slangasek> hmm, ftbfs though
<slangasek> seb128: well, I guess you've seen the ftbfs, and it's somewhere in your todo, so I'll kick the gdl NBS out now
<seb128> which failed to build grrr, fixing that
<seb128> slangasek: yes, stupid scrollkeeper, it built fine locally because I'm using rarian-compat
<slangasek> oh, so we could fix this by making the scrollkeeper package go away? :)
<pitti> I thought we did ages ago?
<seb128> pitti: it's still in universe
<pitti> oh, I have it installed
<pitti> ubuntu-desktop pulls it in
<pitti> rarian-compat | 0.8.1-1ubuntu1 |      intrepid | amd64, i386
<pitti> ^ maihn
<pitti> main, too
<slangasek> pitti: ubuntu-desktop pulling it in won't make much difference on a buildd though
<pitti> right, just noting that I still think it's our current default
<slangasek> yes, no question of that
<norsetto> asac: thx for your kind sponsoring ;-)
<james_w> slangasek: would you please take a look at bug 274238?
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/274238/+text)
<norsetto> ubottu: you have all my sympathy
<ubottu> Error: I am only a bot, please don't think I'm intelligent :)
<slangasek> james_w: midori is in universe so it doesn't really require my approval - but if this is xubuntu-affecting, the xubuntu team should have their say
<james_w> slangasek: it is, and Michael is a Xubuntu developer, but I can check with the rest of the team. It's on the CDs though I believe, so I thought it was your juristiction.
<slangasek> ah, I wasn't aware he was xubuntu-dev
<james_w> slangasek: so you see no problem?
<slangasek> james_w: well, I don't think it's a wise decision to push back the xubuntu beta build for this change; but it's not my decision
<james_w> is there a way to provide a migration path for changing the priority of an alternative?
<james_w> slangasek: ok, I'll talk to them, thank you
<asac> slangasek: ok. so no NM in beta. perfect.
<ogra> cjwatson, i have a slight prob with user-setup in ubiquity ... "d-i passwd/auto-login boolean true" doesnt appear to do what i expect
<ogra> though i see user-setup-apply DTRT in the code
<ogra> but the checkbox in ubiquity isnt set (just doing an install to see if that matters)
<persia> ogra: ubiquity is only checking for passwd/auto-login to set that.
<ogra> well, thats what i set
<persia> ogra: It's controlled by ubiquity/components/usersetup.py in ubiquity, if you want to look at the details.
<ogra> oh, ok
<ogra> so the standard user-setup is ignored ?
<persia> No.  ubiquity mitigates user interaction with the standard user-setup.
<persia> ogra: Mind you, it doesn't seem to work for me either, oddly.
<cjwatson> right, I bet ubiquity doesn't check for the preseeded value of that question to initialise the UI
<cjwatson> that sort of thing needs to be done explicitly
<ogra> explicitly eaning not through preseeding here ?
<ogra> *meaning
<persia> Looking at the code it seems ubiquity needs to more carefully read the incoming preseed values, and explicity activate them.
<cjwatson> err
<cjwatson> don't try to work out what I meant, I'm partly talking to myself
<cjwatson> persia: umm. sort of.
<norsetto> how dumb can one possibly be ...
<cjwatson> actually the reason it's tricky is that auto-login isn't explicitly asked by user-setup, but is for preseeding only
<ogra> tjaalton, i see a lot of race conditions with hal on the mobile image ... sometimes i dont even get a keyboard (seems to depend on bootspeed)
<pitti> ogra: does the mobile image still move the gdm init priority further up?
<ogra> cjwatson, so is there a way for me to set it somehow without hacking ubiquity ?
<ogra> pitti, i dont touch gdm
<cjwatson> ogra: no, we need to fix ubiquity
<ogra> cjwatson, bug 276247
<ubottu> Launchpad bug 276247 in ubiquity "preseeding autologin should set the checkbox in the UI" [Undecided,New] https://launchpad.net/bugs/276247
<cjwatson> thanks
<cjwatson> is this beta-critical?
<cjwatson> since if it is I have to drop everything to do it
<ogra> well, it would be a nice to have but after beta should suffice
<cjwatson> yeah, I can't justify nice-to-have uploads right now
<ogra> final should have it though
<ogra> UMPCs not necessarily have a keyboard and i havent hacked gdm to support cellwriter for password input in this release
<ogra> so its critical for final
<cjwatson> easy to fix for final
<cjwatson> I'll show you the patch in a few minutes
 * ogra nominates for intrepid
 * ogra wonders why the wlan gets dropped several times during install
<ogra> pitti, it seems to largely depend on CPU speed, while i see it failing only from time to time, persia seems to see that issue constantly
<ogra> (my Q1 only has a 800MHz cpu, his is a fast atom)
<ogra> persia, what about the installed system ?
<persia> ogra: I haven't tried an installed system: I can't navigate the installer with no keyboard and no mouse.
<ogra> hmm
<ogra> the builtin kbd doesnt work on the Q1
<ogra> which is kind of fatal without autologin :P
<ogra> ugh
<ogra> not even a usb kbd does
<ogra> oh, fun, i can switch consoles but i cant type anything
<ogra> well, only in X apparently
<ogra> i can log in at the console
<ogra> no kbd ... even after gdm restart
<asac> hmm ... we dont have a milestone for rc
<persia> ogra: That sounds like my experience.
<ogra> no mouse either
<cjwatson> milestone it for final - not many things should be RC as distinct from final (i.e. bugs milestoned for final should typically land by RC)
<asac> ok. just thought we had rc milestones in the past
<asac> but makes sense
<asac> RC should be RC bug free ;)
<ogra> pitti, hmm, seems hal is completely broken here, it used to work some days ago
<ogra> (or X)
<ogra> shriek
<ogra> who added evtouch to xserver-xorg-input-all ??
<ogra> sigh
<ogra> thats not right
<persia> Why not?
<cjwatson> it's in universe last I checked ...
<persia> Ah.  That would be a good reason.
<roachmmflhyr> i am trying to install gimp 2.5.4 but i told i need to install gtk along with a million other libraries does ubuntu store libraries somewhere else and do i need to point make to that PATH??
<wgrant> roachmmflhyr: This isn't a support channel; you likely want #ubuntu.
<cjwatson> roachmmflhyr: 'sudo apt-get build-dep gimp' will help you alone
<cjwatson> along
<roachmmflhyr> sorry i thought this was support for dev
<cjwatson> no, it isn't
<ogra> cjwatson, right, but i just tried to remove it to make sure i didnt break anything with my .fdi files ... it wants to remove all xserver-xorg-input* and -video* pacages
<cjwatson> it's for people developing Ubuntu, not for people developing *on* Ubuntu
<cjwatson> if you catch the distinction
<persia> With recommends-by-default, shouldn't xserver-xorg-*-all be recommending stuff now?
<ogra> xserver-xorg depends: xserver-xorg-input-all|xserver-xorg-input-2.1 ....
<ogra> evtouch provides -input-2.1
<pitti> persia: no, I don't think so; otherwise the -all would be pretty pointless
<ogra> hmm
<ogra> and -all isnt installed
<pitti> persia: however, you should be able to uninstall {video,input}-all
<persia> pitti: Hrm.  OK.
 * ogra guesses he should drop the provides then 
<ogra> hmm
<ogra> Provides: ${xinpdriver:Provides}
<roachmmflhyr> cjwatson, wow so your saying ive wasted 4 hours of my life installing libraries, gtk, cairo, freetype, fontconfig, expat, tiff libs, jpeg libs, png libs, atk, pango, gegl, babl, dbus-glib, glib......?
<ogra> well, i actually want it pulled in by -all if somenone installs that ...
<pitti> roachmmflhyr: you installed them all from upstream tarballs??
<roachmmflhyr> pitti, yes
<pitti> roachmmflhyr: we have libfoo-dev packages for that
<ogra> ah, well, -all doesnt even depend on it
 * ogra giggles evlish
<ogra> persia, found the prob :P
<Treenaks> elvish?
<roachmmflhyr> pitti, they werent working...when i ran ./configure in the package i was trying to install it said it couldnt find the libraries
<ogra> Treenaks, isnt that the same (according to terry pratchett at least :P)
<StevenK> superm1: I think libbluetooth-dev should provide libbluetooth2-dev too
<ogra> persia, seems the task change for ubuntu-mobile is at fault
<roachmmflhyr> pitti, there isnt a libfoo for gegl
<ogra> pitti, sorry, not hals fault at all
<persia> ogra: That explains why I wasn't seeing it with other flavours.
<pitti> roachmmflhyr: libgegl-0.0-dev
<ogra> persia, the only xserver-xorg-input-* package thats installed *is* evtouch
<ogra> no keyboard or touchpad drivers
<persia> ogra: Yeah.  That's not ideal :)
<pitti> roachmmflhyr: "apt-cache search gegl dev" is your friend, or use synaptic (the graphical package manager)
<ogra> yay for provides
<ogra> but i thought we install the xorg metapackage
 * ogra changes seeds
<cjwatson> roachmmflhyr: I expect it would have been a lot easier to figure out why it wasn't finding the system libraries (e.g. config.log) than to spend hours installing libraries by hand
<roachmmflhyr> cjwatson, i did check the config.log it told me certain libraries werent found
<roachmmflhyr> cjwatson, so i googled for them
<cjwatson> remember that we build gimp by installing libraries from .debs, so we know it can be made to work
<roachmmflhyr> pitti, apt-cache search gegl dev gives me nothing... :(
<cjwatson> anyway, not this channel
<wgrant> We only have gegl in Intrepid.
<roachmmflhyr> cjwatson, well thats what im trying to learn how to do...i would like to become a dev for ubuntu...but i need to figure everything out
<cjwatson> roachmmflhyr: ok, that's fine - one of the skills you need is to learn how to troubleshoot problems without going off and installing gtk from source, though :)
<roachmmflhyr> cjwatson, lol i see that now
<ogra> roachmmflhyr, #ubuntu-motu might be a better choice for such discussions (its at least less off topic there)
<cjwatson> usually you need to find the code that's failing, drill down, and run it by hand with added verbosity or debugging or whatever
<roachmmflhyr> cjwatson, at least ive gotten real good at compiling source...
<roachmmflhyr> lol
<slytherin> roachmmflhyr: 2.4.5 is available in hardy. Are you not using hardy (Ubuntu 8.04)?
<roachmmflhyr> slytherin, yes i was using that...but i was feeling a bit frisky and wanted to test out some stuff
<roachmmflhyr> slytherin, kinda sucks that gimp doesnt support CMYK coloring
<roachmmflhyr> slytherin, thats one of the reasons i was trying 2.5
<slytherin> ok
<alex-weej> how are we supposed to use usbfs with Intrepid now?
<alex-weej> VBox still requires it...
<pitti> alex-weej: /dev/bus/usb?
<alex-weej> old-style /proc i guess
<pitti> alex-weej: or does it need the counterpart of /proc/bus/usb/devices?
<alex-weej> devices file in proc
<alex-weej> yes
<alex-weej> i have tried following some "guides" people have posted but none of them are working and i'm wondering if something changed in 8.10
<alex-weej> ah i may have figured it... let's see
<ogra> meh, i get weird germinate errors
<ogra> cjwatson, any idea ? http://paste.ubuntu.com/52421/
<ogra> i get that running the update script in mobile-meta
<ogra> oh, wait ... probably Packages are just regenerated
 * ogra waits a moment to try again
<cjwatson> ogra: http://paste.ubuntu.com/52423/ is the auto-login fix, FYI
<cjwatson> yeah, that suggests unlucky timing
<ogra> ah, neat ... seems small enough
<Ng> pitti: the hal/f-spot stuff seems to work, thanks very much for fixing that :)
<ogra> hmm, how do i revert ownership in a metapackage the right way if someone ran sudo ./update
<cjwatson> just chown it
<ogra> ok
<ogra> just wanted to make sure people dont need to be ogra in the future if they update :)
<ogra> and that also made ./update work again :)
<cjwatson> you realise that that sort of ownership change doesn't get preserved in souece packages?
<cjwatson> source
<ogra> well, root did though
<cjwatson> only if you unpack as root
<ogra> i didnt
<cjwatson> a user cannot create files owned by root so it would be physically impossible for that change to be preserved
<ogra> but my predecessor i guess
<ogra> apt-get source mobile-meta && cd mobile-meta-1.118 && ./update
<ogra> thats all i did
<cjwatson> any Unix system that supports quotas either forbids non-root chowning to other users, or else has a very obvious security hole :)
<ogra> the package already had all files owned by root
<StevenK> ogra: 1.118?
<ogra> yes
<StevenK> ogra: Then it wasn't me
<StevenK> My tarball of 1.118 has steven/users
<cjwatson> <cjwatson@sarantium ~>$ apt-get source mobile-meta
<cjwatson> dpkg-source: info: unpacking mobile-meta_1.118.tar.gz
<cjwatson> <cjwatson@sarantium ~>$ cd mobile-meta-1.118/
<cjwatson> <cjwatson@sarantium ~/mobile-meta-1.118>$ ls -l mobile-i386
<cjwatson> -rw-r--r-- 1 cjwatson cjwatson 1699 2008-09-27 07:40 mobile-i386
<StevenK> ogra: You looz.
<ogra> mobile-meta (1.118) intrepid; urgency=low
<ogra>   * Have ubuntu-mid Conflicts against xfce4-panel. (LP: #274825)
<ogra>  -- Steve Kowalik <stevenk@ubuntu.com>  Sat, 27 Sep 2008 18:34:23 +1000
<cjwatson> ogra: it's a local problem on your system. or else you're unpacking as root.
<ogra> i dont
<ogra> definately
<cjwatson> pastebin a transcript that demonstrates the problem
<StevenK> ogra: Well, I didn't do it
<jcristau> alias ls='fakeroot ls'
<ogra> cjwatson, i did the above triplet and ran into the update-metapackage.py error i pasted ... after some looking i recognized all files are owned by root ... i am not root and didnt sudo
<cjwatson> ogra: in any case, it doesn't really matter since nobody else's system is broken this way, as far as I know
<cjwatson> ogra: do you understand why I'm saying this can't happen on a properly functioning system?
<ogra> well, essintially i found it because rm -rf mobile-meta-1.118 complained
<ogra> cjwatson, i do, but why did it happen then :)
<slytherin> seb128: Can you please take a look at the debdiff attached to bug #260765 when you have time.
<ubottu> Launchpad bug 260765 in gst-plugins-base0.10 "DVD playback does not work anymore" [Undecided,Confirmed] https://launchpad.net/bugs/260765
<cjwatson> ogra: that's why I'm trying to get you to *investigate your local system*
<cjwatson> only you can debug this
<cjwatson> for example, 'touch new-file; ls -l new-file'
 * ogra doesnt want to stop the working ./update atm
<ogra> i'll investigate afterwards
<cjwatson> or 'touch new-file; chown root new-file' which should return an error
 * StevenK blinks at two symlinks in his home dir
<StevenK> lrwxrwxrwx 1 steven users 1 2008-05-13 00:41 a -> b
<StevenK> lrwxrwxrwx 1 steven users 1 2008-05-13 00:41 b -> a
<ogra> ogra@osiris:~/Devel/packages$ touch new-file; LANG=C chown root new-file
<ogra> chown: changing ownership of `new-file': Operation not permitted
<ogra> seems its all fne
<ogra> *fine
<seb128> slytherin: after beta, such uploads will not be accepted now for beta so there is no hurry
<ogra> hrm
<ogra> and newly unpacking the source doesnt expose that either
<slytherin> seb128: Ok. I thought that since we were not updating to pre-release the backported fix would be acceptable.
<ogra> ok, i ran: sudo apt-get update ... and out of lazyness i replaced s/update/source mobile-meta/
<ogra> StevenK, sorry
<ogra> my own fault
<StevenK> Heh
<seb128> slytherin: it's a bit late for changes now, doing updates require to rebuild CD images, restart testing for the new images etc
<seb128> slytherin: the bug is not really an import one for beta
<slytherin> seb128: right, I forgot about the CD images. No issues. Meanwhile I will backport the resindvd changes also in my PPA so both are ready with some testing and can be uploaded post beta.
<ogra> cjwatson, can you let mobile-meta through once you find time (no hurry, need to get susie to a doctors appointment now anyway)
<cjwatson> ogra: done
<stgraber> stgraber@castiana:~$ xterm
<stgraber> No protocol specified
<stgraber> xterm Xt error: Can't open display: :0.0
<stgraber> asac: ^ could that be your fault ? :)
<asac> stgraber: yeah. ppa has the fix
<stgraber> I just updated from the PPA
<asac> stgraber: version?
<stgraber> 0.7~~svn20080928t225540+eni0-0ubuntu2~nm1
<asac> stgraber: did you properly restart everything?
<stgraber> I also restarted NM (kill all process and restart it in init.d) and killed my X session
<cjwatson> that NM bug isn't in intrepid is it?
<asac> cjwatson: no
<cjwatson> good :)
<asac> not in
<asac> stgraber: is your hostname correct?
<stgraber> /etc/hostname is castiana, so that's correct. I just scped a /etc/hosts from a hardy computer and replaced my computer name in it so this one should be good now too.
<stgraber> I'll just restart NM again and hope it doesn't destroy it :)
<asac> stgraber: no /etc/hosts
<stgraber> asac: didn't work ... as soon as NM connected to the wireless network I lost the ability to start new X applications
<asac> stgraber: so what does "hostname" commadn give you?
<stgraber> castiana.local (instead of castiana)
<asac> stgraber: so the nm1 version worked better?
<stgraber> when was nm1 released ?
<stgraber> hmm, nm1 is what I have :)
<asac> stgraber: ok ... anyway. you get "from address lookup" ?
<asac> in the syslog?
<stgraber> Sep 30 07:55:18 castiana NetworkManager: <info>  Setting system hostname to 'castiana.local' (from address lookup)
<asac> stgraber: castiana.local ... what IP is that?
<asac> i guess 127.0.0.1?
<Ng> it should be his LAN IP
<Ng> .local is zeroconf/bonjour jazz
<asac> right
<Ng> so his mdns name would now either not work, or be castiana.local.local or something like that ;)
<asac> so changing hostname _after_ login will always break X or only if you change the hostname in a way that it resolves to a different IP?
<stgraber> asac: yes
<stgraber> stgraber@castiana:~$ ping castiana.local
<stgraber> PING castiana.local (127.0.0.1) 56(84) bytes of data.
<asac> stgraber: and when you log in its castiana which also is 127.0.0.1 right?
<stgraber> yes
<Ng> ehh, a 127 .local address makes no sense
<stgraber> and xauth shows castiana/unix:0
<stgraber> adding castiana.local/unix:0 with the same magic cookie makes X to work fine again
<asac> Ng: strager got that through a reverse lookup for his wifi ip
<Nafallo> Ng: I got my reverse set as hostname you know... ;-)
<Ng> Nafallo: indeed
 * Nafallo should get the PTR fixed anyway :-)
<stgraber> I usually have:
<stgraber> stgraber@castiana:~$ cat /root/hosts
<stgraber> 127.0.0.1	localhost
<stgraber> and now I get:
<stgraber> stgraber@castiana:~$ cat /etc/hosts
<stgraber> 127.0.0.1	castiana.local	localhost.localdomain	localhost
<stgraber> (I don't understand why NM would change /etc/hosts at all ...)
<Ng> stgraber: for dynamic hostnames, apparently
<Spads> Nafallo: are you sure it updated /etc/hosts, or did it just affect the running hostname?
<Nafallo> Spads: both running hostname and /etc/hosts
<asac> stgraber: the idea is to all dhcp to provide your hostname
<Spads> ow
<Ng> that clearly shouldn't be a default, imho
<stgraber> +1
<asac> Ng: yeah. i am trying to get that out of tambeti ;)
<stgraber> I don't want DHCP assigned hostname
<stgraber> only half of the network I connect to give me the right hostname and I'd prefer not to have stgraber@dhcp123 :)
<Nafallo> stgraber: I had nafallo@reserved fwiw... :-P
 * Nafallo likes his wizard
<stgraber> or if I connect directly to my ISP I'd have some like stgraber@dsl-35-95-230 :)
<asac> stgraber: the only problem is the authority i think
<asac> stgraber: otherwise its just an optical issue ;)
<stgraber> yeah, well just make that an option and disable it by default and I'll be happy :)
<stgraber> anyway, got to go to work. I'll check how bad things work and see if I need to reinstall NM from Intrepid in order to work (I'm doing some thin client testing and changes network all the time)
<asac> stgraber: you can add to nm-system-settings.conf:
<asac> [keyfile]
<asac> hostname=yourpreferredhostname
<asac> until nm3 is there
<Riddell> pitti: apport seems to think this crash doesn't belong to an Ubuntu package http://muse.19inch.net/~jr/tmp/_usr_bin_python2.5.1000.crash
<Riddell> pitti: also jockey doesn't seem to say anything about having a broadcom wireless on my girlfriend's laptop (only a driver called wl)
<pitti> Riddell: the latter is bug 263097
<ubottu> Launchpad bug 263097 in jockey "wl vs. b43 are not properly configured" [Undecided,In progress] https://launchpad.net/bugs/263097
<pitti> Riddell: (currently working on it for hardy)
<pitti> Riddell: do you have a locally built .deb for /usr/bin/guidance-power-manager
<pitti> ?
<Riddell> pitti: no, this is a newly installed intrepid system
<pitti> Riddell: ok, I'll need to reproduce this then; can you please drop me an email with that link?
<Riddell> ok
<asac> stgraber: nm3 uploaded. let me know if that fixes all corner cases
<asac> Nafallo: Ng: ^^
<Ng> k :)
<Nafallo> asac: will do once I've had lunch :-)
<Nafallo> oh. uploaded isn't built :-)
<Nafallo> goy ya
<Nafallo> s/y/t/
<asac> bryce: tjaalton: fedora and opensuse have no problem when you update "hostname" in a running session. any idea what they have done to auto-add the new hostsnames to .Xauthority (which appears to be what happens for them)
<soren> I'm trying to help a guy mount a USB memory stick. It works for him locally at the machine, but not when connected to a vnc session (vncserver style, not vino). He gets org.freedesktop.DBus.Error.AccessDenied. I presume this is policykit and/or consolekit doing its thing. What's the magic words to shout at the thing to get it to work?
<pitti> soren: hm, I thought VNC was merely a remote "view" onto a local session?
<pitti> soren: (in that case it shuold "just work")
<soren> pitti: As i said: It's not vino.
<soren> pitti: It's a proper vnc-only desktop.
<pitti> so there's someone at the other end plugging in the USB stick for him?
<soren> He's at the machine.
<pitti> so ck-list-sessions probably doesn't show a local session for him then
<soren> Probably not.
<pitti> one possibility is to use "sudo gnome-mount", the more proper one to use polkit-gnome-authorization to grant the privilege for mounting devices to the remote user
<pitti> (you need admin privileges in both cases)
<soren> polkit-gnome-authorization is probably the magic incantation I was looking for.
<soren> so "sudo polkit-gnome-authorization", I presume.
<soren> ?
<pitti> a non-admin user cannot magically get that privilege from a remote session
<pitti> soren: sudo isn't required, that thing itself uses policykit, too, to ask you for your admin password
<soren> pitti: Ah, I see.
<pitti> soren: (System -> Administration -> Authorizations)
 * soren still hasn't realised the problem polkit+consolekit are trying to solve
<liw> I need an icon for system-cleaner -- rather than make one with /dev/urandom, I'd like some help with it: any suggestions?
<pitti> liw: you can ask kwwii
<persia> liw: You can ask in #ubuntu-artwork
<liw> thanks, I'll do both :)
<tjaalton> asac: nothing comes to mind..
<pitti> asac, tjaalton: is it possible to use IP-based xauth?
<pitti> OTOH, "xauth list" also shows "tick/unix:0"
<StevenK> soren: Only allow access to devices for the currently locally logged-in user on, not a unix group any user can join
<soren> StevenK: That's not a "problem".
<cjwatson> soren: the problem is that there's no reliable way to revoke group membership
<soren> StevenK: Not from where I'm sitting, anyway.
<cjwatson> once you're a member of a group, you can create a setgid executable and retain membership indefinitely
<cjwatson> or simply leave a process running
<cjwatson> all the solutions that have been tried beforehand have security flaws to one extent or another
<persia> That means that if you and I both have access to the same machine, I won't be able to read your keystrokes easily when you're at the console.
<soren> I just don't really get the idea that any local user should have access to all these things, and noone else. I used to rather like that fact that I wasn't tied to my chair to be able to do stuff.
<cjwatson> policykit makes it configurable
<cjwatson> so actually it's not as restrictive as all that, it's just a sane default
<soren> cjwatson: Do you happen to know how?
<cjwatson> System -> Administration -> Authorisations
<soren> cjwatson: All I've seen so far is ways to grant a user access to do one tiny thing.
<cjwatson> (insane GUI alert)
<soren> I'm specifically looking for the button that gives me the same privileges that I had a year ago.
<pitti> soren: PK is quite a lot more flexible than unix system groups, and avoids overloading unix groups with "access permissions", where their original idea is "groups of people"
<asac> tjaalton: ok thanks. Ill see if redhat/opensuse devs have more info (though the suse NM developer didnt know how this happens)
<soren> pitti: I've just never seen a scenario where that's actually a problem.
<pitti> soren: the old groups still work, we just stop putting the default use into it
<pitti> soren: it is a problem for things which you can't control through group memberships
<cjwatson> soren: there was a major problem that came up in lots of 8.04 reviews that was essentially due to this
<soren> pitti: Most often, I don't actually want to grant a privilege at the rather extreme granularity that polkit offers, and not just to a single individual.
<pitti> soren: like "this should only work for a local user", or "only for an active console", or "only these guys should be able to configure the system clock"
<soren> I want to allow a group of folks privileges to perform a set of related actions.
<cjwatson> soren: the default user isn't in the sambashare group by default, and adding them to it requires logging out and logging back into the session, so the widget in the desktop GUI to configure sharing didn't work unless all the sambashare stuff was installed right from the start, which it wasn't
<cjwatson> there is simply no way to fix that with Unix groups without installing everything you could possibly need by default
<pitti> soren: with groups you'd also need to add them one by one
<pitti> soren: let alone the fact that unix groups don't stack, you can't e. g. put the "students" group into "plugdev"
<cjwatson> pitti: I think it's a fair criticism that it's too hard to configure groups of authorisations with pk
<soren> pitti: Yes. Once. Not once for each tiny, little action they might want to do.
<pitti> cjwatson: it is, yes; hard with PK, impossible with unix groups
<cjwatson> pitti: I don't think that's actually true in practice
<soren> cjwatson: I think there are better approaches to fix the sambashare issue. I believe we've discussed this before? Or was that someone else?
<cjwatson> soren: the "better approach" I've seen is to create the sambashare group at installation time and add the default user to it
<cjwatson> which is not really all that great
<soren> My major problem with polkit is that it introduces a granularity, I've *never* seen a demand for.
<pitti> cjwatson: (which we do ATM)
<cjwatson> pitti: with PK, when an application adds a new action you have to go and configure it all over agin
<cjwatson> again
<cjwatson> which is a new problem
<cjwatson> anyway, I have to run
<soren> o/
<pitti> right (although our goal should be to not require that)
<pitti> after all, it's similar to adding new system groups
<pitti> which you have to put existing people into
<StevenK> pitti: And running 'id' and having the output be four lines isn't great either
<soren> Except there seemed to be a natural limit to the amount of groups people felt like adding.
<superm1> StevenK, why should it Provides: libbluetooth2-dev?  It doesn't contain the SONAME that matches to that.
<soren> People don't seem to restrict themselves from adding lots and lots of polkit "actions" (or whatever the lingo is).
<pitti> soren: yes, the idea was to get away from the almighty root and (1) only allow them to do what they need, and more importantly, (2) get rid of the recurrent gksu dialogs for stuff they need every day
<StevenK> superm1: Well, I've had to change 9 packages from libbluetooth2-dev to libbluetooth-dev.
<superm1> StevenK, ah so you are saying just more of an interim solution to prevent diffs when rebuilding
<pitti> and (3) provide control of privileges you can't express through groups, as I already said
<StevenK> superm1: I see your point, though.
<superm1> but long term they really should correct themselves
<soren> I mean... Honestly, when have you *ever* wanted to grant a person access to "Directly access digital cameras" and not "directly access audio players"?
<StevenK> superm1: It's a tiny diff, so *shrug*
<pitti> soren: that's rare in practice, yes; that's why we have default privs you don't normally need to touch
<StevenK> superm1: obex_socket.c:(.text+0x97a): undefined reference to `hci_remote_name'
<StevenK> superm1: A bunch of failures with that error or similar
<superm1> StevenK, yeah there may be a few apps that fail related to OBEX.  It's generally pretty easy to patch around, but i'll have to look at the cases.  OBEX has changed significantly
<glatzor> hello mvo, are there any concerns using the force-confdef and force-confold option of dpkg in a non-interactive apt session?
<superm1> StevenK, any other standouts other than the libbluetooth2-dev -> libbluetooth-dev & the OBEX stuff?
<mvo> glatzor: its not ideal, but its the only way with PL
<mvo> PK
<soren> pitti: but that's my point: It offers a granularity that noone has ever demanded, and it does so at the expense of people who actually need to deviate from the defaults.
<glatzor> mvo, luckily dpkg still sends the conffile-prompt status in this case. So we get notified. I replaced the "send n\n" by setting the mentioned dpkg options in packagekit
<glatzor> mvo, just wanted to be sure doing the right thing.
<mvo> glatzor: ok, that is good to hear that it does that
<StevenK> superm1: If you'd rather not do libbluetooth2-dev -> libbluetooth-dev, that's cool. For each of those 9, the diff is tiny.
<pitti> soren: so then your problem is not PK itself, but the current set of too granular privileges
<pitti> soren: and I tend to agree to that, yes
<superm1> StevenK, yeah I think it sends a mixed message to do so
<soren> pitti: Actually, it's not just the privileges that are too granular.
<pitti> soren: (that problem would correspond to splitting plugdev into camera, usbstick, scanner, etc.)
<soren> pitti: The only case where I've ever wanted to only give a single person access to something (rather than a group of people) is the case where I've wanted to do so temporarily so that he could do that one thing and then revoke the privilege again.
<pitti> soren: ah; so you actually can do that with PK, but not with unix groups
<soren> pitti: And the only part of that problem polkit solves is that it removes the need to log out and back in again.
<seb128> could somebody having a clue about python-support look at bug #276324
<ubottu> Launchpad bug 276324 in gnome-python-extras "update of python-gtkhtml2 in hardy-updates breaks" [Critical,New] https://launchpad.net/bugs/276324
<seb128> doko, mvo: read that?
<pitti> soren: you don't need that with unix groups, btw, there's newgrp
<pitti> soren: but as I said, groups only work for things like /dev access, not for things like package installation or system time setting
<soren> pitti: I need sudo to do that.
<mvo> seb128: is that reproducable?
<pitti> soren: right, but you don't want to give sudo to everyone who just wants to be able to access a camera or set the system clock, or do you?
<seb128> mvo: no clue, I've no hardy machine here to update to try, but the packages moved to updates some days ago and that's the first bug so I would say "no"
<soren> pitti: No, precisely.
<pitti> (and you can't ever revoke sudo privileges or groups)
<soren> pitti: hence, newgrp won't do.
<pitti> soren: hm?
<pitti> soren: newgrp doesn't need sudo
<pitti> (I thought you referred to somethign else with "I need sudo to do that"
<soren> pitti: Oh, right, newgrp is suid root.
<soren> pitti: I forgot about that.
<soren> Er... Yeah, that wouldn't make sense at all.
 * soren clearly wasn't thinking straight
<soren> pitti: Why can't I revoke sudo privileges?
<pitti> soren: once you are root, you can make sure to stay root, same as with groups
<soren> pitti: Erm.. sudo is not limited to allowing people to switch to root.
<pitti> create suid/sgid binaries, create another user with uid 0 and your password, leave processes running, etc.
<soren> pitti: ...and you don't have to grant people access to run stuff like su or whatever.
<pitti> soren: well, sure, you can configure it to run certain apps with certain arguments, but don't tell me that's easier :)
<soren> pitti: If I want to give that privilege to 50 users?
<soren> pitti: I'll argue that it's waaay easier.
<pitti> (and it's still not flexible enough to tell apart remote from local sessions, or active from inactive ones)
<soren> That's another thing I've never really needed :)
<soren> I *liked* that there was no difference between local and remote sessions.
<pitti> soren: on a desktop you do :)
<pitti> but anyway, if you have 50 users, you'd probably stick them in a group ("teachers" or whatever) and then grant privileges to that group
<soren> I can do that with polkit?
<pitti> of course you can add 50 indiviual lines to /etc/sudoers, too
<pitti> or call pk-auth 50 times
<pitti> same complexity, but nobody would actually do that
<soren> Can I grant privileges to groups with polkit?
<pitti> yes, you can, although not (yet) with the GNOME tool
<soren> Ok. That helps quite a bit. I didn't think so.
<pitti> but only in /etc/PolicyKit/PolicyKit.conf
<pitti> (which is the sudoers counterpart)
<pitti> I'd really like the GUI tool to be able to do that too
<soren> How do I do this?
<soren> <match group="something"> ?
<soren> The man page only mentions groups in the context of define_admin_auth.
<pitti> soren: yes, match can match on users, groups, and actions
<soren> It would be wicked cool if the man page had mentioned that :)
<pitti> erm, hm, at least it should
<pitti> soren: sorry, might be it doesn't do that so far
<pitti> there is no reason it shouldn't, though
<soren> I'm almost sure I've had this part of the discussion before with Keybuk.
<soren> and I seem to remember that he disagreed.
 * soren consults logs
<norsetto> glatzor: if bug 276264 is meant for motu-release perhaps its a good idea to subscribe them
<ubottu> Launchpad bug 276264 in packagekit "Freeze Exception for 0.3.5 and corresponding packagekit-gnome" [Undecided,New] https://launchpad.net/bugs/276264
<glatzor> norsetto, thanks. I just want to add more information before subscribing the moto-release team
<norsetto> glatzor: ok, I'll set it to in-progress then
<glatzor> norsetto, thanks
<norsetto> glatzor: my pleasure
<pitti> soren: there's no upstream bug asking for that so far
<ScottK-laptop> slangasek: To fix the kleopatra uninstallable needs Bug #267555 approved by ubuntu-mir.
<ubottu> Launchpad bug 267555 in dirmngr "Main Inclusion Report for dirmngr" [Undecided,New] https://launchpad.net/bugs/267555
<norsetto> ScottK-laptop: how was the holiday?
<ScottK-laptop> norsetto: It was very nice.  Nothing like a complete lack of electricity to enforce actually being on vacation.
<norsetto> ScottK-laptop: hehe, seems you had fun
<ScottK-laptop> Yes.
<pitti> soren: also, just FAOD: we didn't kill any udev rules to assign groups to devices, and neither sudoers nor those groups will go away; we just don't want to put users into all of those groups by default, because (1) it gives a wrong semantics, and (2) it is clutter, but nobody stops you from manually adding those to groups (or sudoers)
<pitti> soren: just for the desktop case we try to unify on one auth system instead of all three
<ScottK-laptop> pitti: Could you have a look at Bug #267555 and see if it could be approved so we could resolve an uninstallable problem?
<ubottu> Launchpad bug 267555 in dirmngr "Main Inclusion Report for dirmngr" [Undecided,New] https://launchpad.net/bugs/267555
<sladen> what a horrible name for a package
<ScottK-laptop> Fortunately it's not one a user would invoke directly and it is the upstream name....
<pitti> erm, a daemon running as root, downloading stuff from the internet?
<pitti> that's not something we can approve with the snap of a finger
<norsetto> seb128: are nice-to-have fixable now?
<seb128> norsetto: well, they can be fixed and uploaded but CD packages will probably not be accepted before beta
<asac> tjaalton: pitti: http://mail.gnome.org/archives/networkmanager-list/2008-September/msg00291.html
<norsetto> seb128: ok, this is not a real problem, its for nautilus-sendto, which still refers to and Suggests sylpheed-claws (which is since long obsolete)
<persia> unless they are targeted fixes to fix some issue that broke the CDs.
<seb128> norsetto: ah ok, feel free to do a patch and subscribe the sponsor team, I'll upload that later
<asac> ^^ the reason why fedora and suse dont have a problem with changing hostnames during X session ;)
<norsetto> seb128: willco
<asac> "Xauth is completely unecessary with local
<asac> users.  The fact that Xauth depends on hostname is bogus and has always
<asac> been bogus.
<asac> "
<asac> ;)
<pitti> asac, tjaalton: ah, so it *does* have to do with xauth list showing an entry for unix:0, too
<ScottK-laptop> pitti: Understand it'll take some looking at.  It's a mature project and pretty widely used, so I suspect it's in good shape, but who knows.
<asac> pitti: yeah. thats what strikes us here
<pitti> apparently it doesn't work for us
<asac> pitti: http://cvs.fedoraproject.org/viewvc/rpms/xorg-x11-xinit/devel/localuser.sh?revision=1.1&view=markup ... thats what they do for local users
<asac> are we doing the same?
<pitti> asac: I don't think so; looks like an Xsession.d script?
<asac> pitti: install -m 755 %{SOURCE17} $RPM_BUILD_ROOT%{_sysconfdir}/X11/xinit/xinitrc.d/localuser.sh
<tjaalton> asac: thanks for digging it up.. and yes, looks like a candidate to put in Xsession.d (we don't have xinitrc.d)
<pitti> asac: we don't have that, but it's strikingly similar to Xsession.d
<asac> yeah
<Riddell> evand: am I right in thinking we can install to an existing partition now, and it'll wipe /usr et al but keep /home ?
<pitti> tjaalton: any idea why xauth list already has it, but it doesn't work?
<pitti> Riddell: if you don't tick "format", it should
<cjwatson> yes, that's correct
<asac> pitti: (disclaimer: i have no real clue, but) from what i understood the xhost -si:localhost... stuff will make X ignore Xauthority completely for local users
<tjaalton> pitti: xhost != xauth
<cjwatson> it removes bin dev etc lib lib32 lib64 proc sbin usr var sys
<tjaalton> pitti: so xhost allows the user to connect to the server, regardless of what xauth has (AIUI)
<evand> indeed, what everyone else said :)
<pitti> aaah
<asac> tjaalton: which package is the one to file a bug against?
<tjaalton> asac: xorg
 * pitti -> off for a long phone call
<Keybuk> soren: not that I remember
<Keybuk> there's certainly been a longer meta-conversation about it
<Keybuk> ie. should we do device access by group
<Keybuk> davidkit may certainly have been involved
<norsetto> seb128: its strange, ScottK already did that change in bug 138010 but it went lost apparently
<ubottu> Launchpad bug 138010 in nautilus-sendto "Nautilus-sendto suggests obsolete slypheed-claws package" [Low,Fix released] https://launchpad.net/bugs/138010
<seb128> norsetto: we probably synced on debian since and judged that a suggests was not worth have ubuntu specific changes
<seb128> norsetto: should really be fixed in debian
<norsetto> seb128: well, so, its not worth doing it again, I'll see if it is reported to the debian bts
<seb128> ok
<asac> tjaalton: 276357
<tjaalton> asac: thanks
 * ogra notices that ubiquity talks about "LiveCD" on the greeting screen despite it is run off a USB key :P
<evand> hrm
<ogra> evand, on ubuntu-mobile though
<jdong> s/LiveCD/LiveMedium/g okdone.
<jdong> lol
<evand> right, I'm just thinking about usb-creator.
<ogra> yep
<ogra> well, you could check the mountpoints
<geser> zul: Hi, can I ask you about http://launchpadlibrarian.net/17272861/xen-3.3_3.3.0-1ubuntu4_3.3.0-1ubuntu5.diff.gz? as this seem to be the reason for bug 264554
<ubottu> Launchpad bug 264554 in xen-3.3 "libxen3 and libxen3-dev both include /usr/lib/libblktap.so" [High,Confirmed] https://launchpad.net/bugs/264554
<ogra> or follow jdong's suggestion
<geser> zul: do you remember why you added that line?
<evand> AIUI, we've been trying to move away from "Live CD" to "Desktop CD" for some time.  Perhaps we should follow jdong's suggestion.
<evand> cjwatson: mpt: thoughts?
<norsetto> RAOF: ping
<zul> geser:  Im kind of busy right now but no I dont remember why, if you want can you submit a diff thanks
<ogra> hrm
<ogra> why does my device drop its wlan during partitioning
<ogra> thats reproducable
<ogra> does ubiquity restart udev or something like that ?
<evand> it does udevtrigger; udevsettle
<ogra> ah
<ogra> should be udevadm trigger/settel btw
<ogra> it changed some time ago
<mpt> evand, I suggest calling it "Test Drive" rather than "Live CD"
<jdong> mpt: I like the pun too!
<evand> ogra: noted; perhaps we should make that udevadm trigger --subsystem-nomatch=net (or whatever it may be)
<ogra> yeah, seems to make sense
<evand> ok
<cjwatson> evand: I don't like wiki case here, and I think we should avoid "live" jargon altogether
<cjwatson> test drive WFM
<cjwatson> evand: I thought it did use udevadm
<mpt> evand, previously: <http://osdir.com/ml/linux.ubuntu.devel.desktop/2006-08/msg00017.html>, <https://bugs.edge.launchpad.net/ubuntu-cdimage/+bug/109064/comments/35>, <https://lists.ubuntu.com/archives/ubuntu-devel/2008-March/025159.html>
<ubottu> Launchpad bug 109064 in ubuntu-cdimage "Boot-up option 'Start or install Ubuntu' scares new users" [Undecided,Fix released]
<norsetto> ScottK-laptop: I wonder if bug 276364 should teach us to ask for an upgrade log too
<ubottu> Launchpad bug 276364 in gnome-do-plugins "package gnome-do-plugins 0.4.0-0ubuntu2 failed to install/upgrade: trying to overwrite `/usr/share/gnome-do/plugins/Rhythmbox.dll', which is also in package gnome-do-plugin-rhythmbox" [Undecided,Confirmed] https://launchpad.net/bugs/276364
<cjwatson> mpt: although perhaps we should be consistent with what was implemented in the end, i.e. "Try Ubuntu"
<evand> cjwatson: so it does
<cjwatson> actually, "Try Ubuntu without any change to your computer"
<cjwatson> personally, I prefer that to the more metaphorical "test drive"
<evand> ogra: FWIW, I've filed your issue as bug 276383
<ubottu> Launchpad bug 276383 in debian-installer-utils "wlan connection drops during partitioning" [Undecided,New] https://launchpad.net/bugs/276383
<ogra> evand, merci :)
<cjwatson> partly because a lot of other languages are going to end up rendering it as something more like "try" anyway, but in general I prefer avoidance of idiom
 * ogra subscribes
<evand> test drive works for me
<evand> I'll create a bug report to track it.
<mpt> If there was a simple non-metaphorical way to express it I'd be all in favor, but I haven't come across one in the past three years :-)
<mpt> Possibly it will require a little more creativity on the part of translators, but I don't think that's a bad thing (and they can still go long-and-literal as a last resort)
<cjwatson> mpt: I think "test drive" is unfortunate here because it implies that you can't do anything persistent
<evand> Filed as bug 276387
<ubottu> Launchpad bug 276387 in ubiquity "Ubuntu should use "test drive" instead of "live CD" and "desktop CD"" [Undecided,New] https://launchpad.net/bugs/276387
<cjwatson> mpt: in the case of usb-creator, that isn't true
<mpt> hmm, good point
<evand> Yeah, that had crossed my mind, though we might have to do some text substitution there anyway, as we either need to add a persistence option...
<evand> or leave it as is, where it modifies the existing options to add persistence (bug perhaps we should change the wording here?)
<mpt> There should be some very obvious distinction between an Ubuntu session where stuff you create or change will be remembered, and one where it won't be
<mpt> using the live CD is the latter
<cjwatson> ... sometimes
<mpt> using a USB key is sometimes the former and sometimes the latter
<cjwatson> (it's possible to set up a customised live CD with persistence)
<mpt> It is?
<mpt> With a CD-RW?
<cjwatson> you can store the information on an accompanying USB stick
<cjwatson> I think somebody did try doing it with multi-session CDs as well but I don't think that got finished
<mpt> well sure, but you can do that with a non-customized live CD too, right?
<cjwatson> err, right, indeed
<cjwatson> and indeed some people explicitly cite that as something they like to do with the Ubuntu live CD
<mpt> or do you mean it's customized to assume that $HOME is on the USB stick?
<cjwatson> sorry, I shouldn't have said "customised". I'm on the phone so distracted
<cjwatson> I meant that you need to do some setup and boot with non-default options
<mpt> ok
<evand> (creating a casper-rw ext2/3 file on a disk, or making a partition with the casper-rw label, then adding "persistent" to the kernel command line options)
<cjwatson> right, it's essentially the same as doing it on a USB stick, we just wrap it up more nicely for the latter now
<mpt> So just using "live CD" everywhere is ~98% accurate (inaccurate in the USB and customized-boot cases), but meaningful to ~0.5% of people
<mpt> Using "test drive" everywhere would be meaningful to many many more people, but would be less accurate
<Spads> clearly "test drive" is the verb and "Live CD" is the noun
<_MMA_> slangasek: Can Studio's disks be respun? We had a important update just hit the archive that we need on the beta disks.
<mpt> evand, was this something you were intending to change at all for 8.10? If not, perhaps we can sort it out at UDS
<evand> No, I imagine it is quite late for 8.10, so yes, I think we can discuss this at UDS at length.
<mpt> ok, I'll register it for discussion
<evand> much appreciated
<mpt> evand, <https://blueprints.edge.launchpad.net/ubuntu/+spec/ubiquity-sans-live-session> is already implemented, right?
<cjwatson> Spads: "Desktop CD" is the noun :-)
<cjwatson> mpt: yes, it is - I don't think evand will have privileges to close it though, I'll do it
<kees> cjwatson: question about overrides, why are some binary packages listed in multiple repos?  e.g. mpg123 is in both multiverse and universe.
<kees> override.gutsy.multiverse:mpg123	optional	multiverse/sound
<kees> override.gutsy.universe:mpg123	optional	universe/sound
<cjwatson> kees: I'm betting on different architectures
<kees> blarg.
<cjwatson>     mpg123 |   0.59r-21 | gutsy/multiverse | hppa
<cjwatson>     mpg123 |     0.66-1 | gutsy/universe | source, amd64, i386, ia64, powerpc, sparc
<cjwatson> happens sometimes, sorry
<kees> whee
<cjwatson> you could grab the Packages files and use madison-lite on them
<cjwatson> it will give you output like the above
 * kees nods
<cjwatson> (or just grep-dctrl or whatever)
<kees> cjwatson: is the above mpg123 disparity due to hppa being out of date?  i.e. if it built mpg123 0.66-1, it'd end up in universe, or does each arch have its own set of overrides?
<\sh> asac, doko: somehow I'm missing {ia32-}sun-java{5,6}-plugin ... any clue if it's reaching intrepid before release?
<cjwatson> kees: ultimately, it's because we have no mechanism at the archive level to ensure that overrides are in sync across architectures
<cjwatson> kees: combined with (probably) some subtle Soyuz bugs
<kees> cjwatson: okay, so it sounds like the only way for me to predict where a given binary will go is to pull all arch Packages files and look at the prior release.
<kees> cjwatson: I'm basically trying to create the list of files to check for on the archive to confirm that mirroring has finished before sending a USN.
<kees> cjwatson: it's designed to fight both human and soyuz glitches.
<asac> \sh: ia32- like in "a amd64 package"?
<siretart> kees: even then you cannot be sure because some archive admin might change the override just before you upload the package ;)
<\sh> asac: yes
<cjwatson> kees: yeah, we discussed it so I guessed
<\sh> asac: and like in "it was in hardy"
<cjwatson> siretart: in theory; but pretty unlikely for stable releases, in practice
<siretart> indeed
<kees> siretart: right, but those are one-offs that we can fix manually in the USN
<\sh> siretart: hey...sorry to not phoned you back the last days..but we were more bound to IPX then planned :( you can ask nobse he actually saw us three times a day (when he entered the office, when he left, and when he entered it the next morning again ;))
<siretart> \sh: no problem. The next time then!
<\sh> siretart: sure...the next racks are already planned I just need to wait for the hardware ;))
<siretart> :)
<doko> \sh: we never had an ia32-plugin afaik
<asac> ack ... i think only icedtea
<\sh> doko: right, we only had ia32-sun-java*-bin *grmpf*
<\sh> doko: but then we have to remove somehow the suggest from sun-java6-jre
<\sh> doko: because it mentiones ia32-sun-java{5,6}-plugin
 * ogra just had to fiddle with his heating and really doesnt think its the time of year for icedtea
<asac> arch dependent suggests? ;)
<\sh> hmm...lemme check the source ;()
<\sh> doko: any clue how to make the ilo2 java applet fly on openjdk?
<\sh> or better to say, any applet which doesn't work on openjedk?
<\sh> jdk even
<asac> \sh: applets that use avascript to interact with browser wont work
 * \sh doesn't want to install i386 ubuntu now :(
<\sh> asac: but btw...even if  suggest is arch dependent, it should mention a package which doesn't exists, or?
<\sh> and no it's not arch dependent...Suggests: sun-java6-plugin | ia32-sun-java6-plugin, sun-java6-fonts, ttf-baekmuk | ttf-unfonts | ttf-unfonts-core, ttf-kochi-gothic | ttf-sazanami-gothic, ttf-kochi-mincho | ttf-sazanami-mincho, ttf-arphic-uming,
<asac> not sure ... its not uncommon to mention packages that only exists outside the archive as a suggests
<pitti> BenC: hello Ben; if you have a minute, I'd appreciate an ack/nack from you in bug 271956
<ubottu> Launchpad bug 271956 in makedumpfile "Upgrade to new upstream version 1.2.9" [Undecided,New] https://launchpad.net/bugs/271956
<BenC> pitti: ok
<cody-somerville> slangasek, cjwatson: Why is the date on the manifest file from yesterday in current?
<cody-somerville> ie. http://cdimages.ubuntu.com/xubuntu/daily-live/current/
<cjwatson> cody-somerville: that indicates a livefs build failure
<cjwatson> well, not always
<cjwatson> actually today I did a mass build just to update the ISO wrappers, not the livefs, because there was a bug in those
<cjwatson> (p.s. cdimages is for compatibility only, official name is cdimage)
<slangasek> ah, so no one did livefs rebuilds for xubuntu/kubuntu yet
<cody-somerville> : (
<slangasek> those should be done, particularly kubuntu which has ~100 packages out-of-date on the CD...
<slangasek> I'll schedule those now
<lool> bryce: I've committed the fix for #274833; I see other bits are pending, is it because they would be disruprive right now?
<lool> *disruptive
<slangasek> asac: no, not "perfect", but you can't hand me a massive diff for a component as critical as NM within hours of the CD builds (i.e., well in the beta freeze), and expect me to be able to be able to drop it in :/
<slangasek> ScottK-laptop: meh, I don't remember kleopatra being uninstallable yesterday, is that a new dep due to the new KDE drop?
<bryce> lool, was just waiting for some more significant changes to include with it
<lool> Cool
<lool> bryce: Mind if I upload it?  I'm seeking release ack ATM
<bryce> lool: certainly, go ahead
<lool> Thanks
<bryce> those changes are just some usability frosting for the failsafe mode; pretty low risk
<ScottK> slangasek: Kleopatra wasn't on the list yesterday, but the dirmngr MIR's been outstanding for some time.  I'm not sure why it's not on the list.  We wrote the MIR after I saw it on the list for one of the alphas.
<BenC> wow...virtualbox seamless mode is pretty impressive
<pitti> Riddell, ScottK: do you know a good kubuntu person to poke about a qt4-x11 packaging bug? (bug 261380)
<ubottu> Launchpad bug 261380 in qt4-x11 "Packages have invalid .gnu_debuglink" [Undecided,Triaged] https://launchpad.net/bugs/261380
<slangasek> jdstrand, kees: have you seen pitti's request for security review on bug #267555 (MIR), and when do you think you'd have time for that?  (it's not on the CDs, so that can be fixed for beta any time before beta, effectively)
<ubottu> Launchpad bug 267555 in dirmngr "Main Inclusion Report for dirmngr" [Undecided,Incomplete] https://launchpad.net/bugs/267555
<bryce> lool: out of curiosity, what is the kernel bug that is preventing -psb from working?
<pitti> slangasek: is it actually critical for beta? I mean, such a dependency doesn't come up two days before beta, or did it?
<lool> bryce: It needs portin
<lool> *porting
<pitti> slangasek: if it breaks stuff, we could temporarily promote it, but TBH I really don't like it
<lool> bryce: You might recall the drms are incompatible, and we use linux-lpia for non-psb chips
<pitti> slangasek: ("it" being the package, not the "temporary in main" cowboying)
<bryce> lool, ahh
<ScottK> pitti: I'll see if I can dig someone up.
<lool> We didn't want to carry the lpia hack forward in intrepid, so we don't have the psb drm and associated libdrm in intrepid main
<lool> bryce: Intel will start development of an intrepid driver this week and will deliver in december
<asac> slangasek: all fine. ;)
<lool> Which is probably pointless
<asac> slangasek: and of course you were right :)
<bryce> lool, just in time for jaunty, eh?
<lool> bryce: :-/
<slangasek> pitti: two days before beta - KDE had a pre-agreed code drop at the beginning of this week, and apparently kleopatra grew a dependency in the process; it's not critical for beta /because/ it's not on the CDs, but it would be nice to fix up that uninstallables list
<kees> slangasek: I haven't reviewed MIRs in a bit.
<kees> slangasek: I can look into that probably next week
<slangasek> ok
<slangasek> that'll be fine, thanks
<pitti> slangasek: ah, ok; it just looks a bit curious to me, since it looks like it wouldn't work out of the box for normal users anyway, and thus a strict depends: might be too much?
<Riddell> slangasek: kleopatra can just be moved to universe
<pitti> slangasek: (unless there is some other suid-root-ness which I missed)
<ion_> Hm. Updated to intrepid and now X doesn't seem to find any input devices.
<jdstrand> slangasek: I have the same timeframe as kees
<ScottK> Riddell: kleopatra is seeded on the Kubuntu DVD.
<Riddell> ion_: I got that
<jdstrand> kees: we can discuss who does it when we are closer to being able to do it (unless of course, you really *want* to do it :P)
<Riddell> ion_: I filed it as bug 275825, bryce know anything about it?
<ubottu> Launchpad bug 275825 in xorg "X does not detect a keyboard after upgrade" [Undecided,New] https://launchpad.net/bugs/275825
<kees> jdstrand: cool, yeah
<kees> jdstrand: I'm not itching for an audit :)
<jdstrand> :)
<bryce> Riddell: what kind of keyboard is it?  the bug's a bit sketchy on details
<bryce> also I'd like to see the xorg.conf there
<ion_> riddell: The output of lshal and startx -- -verbose 999 2>&1 might be useful. I'll be able to add that later, but if you can do it immediately, go ahead.
<Riddell> ion_: I can't, computer has been reinstalled since
<Riddell> bryce:
<Riddell> bryce: keyboard is just a laptop one, I also plugged in a hal one and restarted X
<slangasek> Riddell: "can just be moved to universe" - ok, do you want to unseed it then? :)
<bryce> Riddell: well, in general upgrades to intrepid don't lose the keyboard like this normally, so there is something unusual about your system
<bryce> Riddell: it looks like the touchpad got detected okay; I assume that works?
<Riddell> bryce: yes the touchpad worked, nothing unusal it's an HP laptop and it works fine from a fresh install.  I also deleted the xorg.conf and restarted X but no difference
<bryce> ah that's interesting
<bryce> Riddell: the next step would be to review your lshal output and see what it shows for your keyboard
<slangasek> james_w: I see midori in the queue; so there was a consensus among the xubunters?
<Riddell> bryce: can't do that immediately I'm afraid, computer has gone back to girlfriend, I'll be doing more upgrade testing tomorrow and will add more details then
<bryce> Riddell: my guess is that some bad hal data got stuck in there somewhere.  Might be interesting to compare what's in your /etc/hal with an upgrade vs. fresh install
<ion_> bryce: Please see http://heh.fi/tmp/x-problem/ â the config/hal lines at the end of x.log are interesting.
<Riddell> pitti: I have no idea where to start with that qt debug bug
<bryce> Riddell: ah ok
<ion_> bryce: Btw, is there hope of getting MPX support for intrepid?
<bryce> ion_: so it looks like you need to have 'evdev' set as the input.x11_driver for your keyboard
<bryce> ion_: no
<james_w> slangasek: there wasn't
<slangasek> james_w: oh.  what was there in its place? :)
<slangasek> (i.e., should I go ahead and accept this now?)
<james_w> slangasek: oh, you *do* see it in the queue, sorry :-)
<james_w> slangasek: I didn't upload
<james_w> slangasek: cody-somerville did I guess
<ion_> bryce: I wonder why x11_driver isn't set?
<bryce> ion_: it wasn't required to be set in hardy
<slangasek> james_w: ah, let me check the sig and we'll see :)
<bryce> ion_: can you check if you have -evdev installed?  dpkg -l xserver-xorg-input-evdev
<ion_> It is.
<kees> is there some kind of sound regression?  I can't get anything using gstreamer to play...
<slangasek> james_w: yep, cody-somerville uploaded, so I'll take that as an indicator of consensus and push it in
<james_w> slangasek: I agree
<ion_> bryce: Hm. In lshal output, xkb.model is 'evdev' instead of 'pc105'.
<bryce> ion_: more interestingly is the lack of an input.x11_driver entry
<bryce> which *should* be 'evdev'
<bryce> I think the model being 'evdev' is probably ok
<bryce> ion_: you might want to come to #ubuntu-x
<pitti> Riddell: I wonder how it installs the files, does upstream do that? dh_strip --dbg-package doesn't do it that way
<Riddell> pitti: yes upstream does that I believe, I just spoke to an upstream person who suggested using -no-separate-debuginfo and stripping it ourselves
<ion_> pitti: I was told to bug you about this. After an upgrade from a fresh hardy installation to intrepid, HAL had old information in /var/cache/hald/fdi-cache. It only stat()d most of the FDI files without opening them, and never took /usr/share/hal/fdi/policy/10osvendor/10-x11-input.fdi into account, which caused X not to find any input devices. I renamed the cache file away and everything works now.
<ion_> pitti: Perhaps hald's postinst should just remove the cache file.
<Sonne> hi
<Sonne> i've found a bug in a package in intrepid after backporting it to hardy
<Sonne> how should i report it?
<Sonne> my best idea since now is to use reportbug and write in the notes that it has been backported from intrepid
<Sonne> maybe there's some better solution :)
<infinity> Sonne: Does the bug exist if built for intrepid, or is it a result of running it on hardy?
<infinity> Sonne: If the bug exists when running in Intrepid, just report it in launchpad like any other bug.
<Sonne> ah, they can be reported via web?
<Sonne> cool
<infinity> Sonne: If it only shows up on hardy, you could still report a bug, I suppose (especially if you have a simple fix to provide to make it happy), but make it very clear that it only breaks in a hardy environment.
<Sonne> well, the bug is a typo in a script in cmake, so i guess the problem would show up on intrepid too :)
<infinity> Sonne: Which package?
<Sonne> cmake
<infinity> http://launchpad.net/ubuntu/+source/cmake/+bugs
<Sonne> /usr/share/cmake-2.6/Modules/FindLua51.cmake
<Sonne> it reports lua51 as lua50
<Sonne> yep, let me submit it :)
<Sonne> done
<Adri2000> bug #254905 < needs review from an -sru person
<ubottu> Launchpad bug 254905 in vsftpd "FTPS doesn't work with clients such as FileZilla" [Medium,In progress] https://launchpad.net/bugs/254905
<Adri2000> btw, why is registry a member of ubuntu-sru in LP?
<AlinuxOS> hello all, asac is there some news from Bug #256054 ?
<ubottu> Launchpad bug 256054 in network-manager "[intrepid] new 0.7 branch ignores /etc/network/interfaces" [Unknown,Confirmed] https://launchpad.net/bugs/256054
<asac> AlinuxOS: i will follow up on the bug
<slangasek> asac: should we drop that one in the beta errata, I guess, since it's slipping until post-beta?
<AlinuxOS> asac, ok :) I discovered some minutes ago that I cant use static IP.
<asac> slangasek: yes push ahead. doing that now
<asac> slangasek: do you need any info for the errata?
<asac> AlinuxOS: have you tried the workaround posted?
<slangasek> asac: someone needs to distill the bug into a user-friendly description; that can be you or me
<AlinuxOS> asac, on the same page ?
<AlinuxOS> asac, which one?
<asac> AlinuxOS: ,ifupdown to make NM honour your interfaces
<AlinuxOS> asac, ah ok..
<AlinuxOS> I see now..
<asac> not sure if that helps in your bridge setup ... what you need is the ability to unmanage interfaces most likely
<AlinuxOS> is intrepid beta ?
<asac> AlinuxOS: not yet, but soon
<AlinuxOS> or are we in alpha 6 ?
<AlinuxOS> ah ok
<AlinuxOS> asac, thank you for your time.
<calc> is there a way to get the old logout screen back in intrepid?
<james_w> no, not without some coding as far as I know
<calc> ok :\
<liw> if I want to have foo-gtk depend on foo, should I use source:Version or binary:Version? the latter sounds more binNMU-friendly (which may matter only to Debian, perhaps)
<slangasek> liw: that depends on which of the packages are arch: all and which are arch: any
<slangasek> (the difference does only matter in Debian, though)
<liw> slangasek, both are arch:all
<slangasek> liw: then it doesn't matter at all, since arch: all packages are never binNMUed
<liw> oh, right
<liw> thanks
<asac> slangasek: http://paste.ubuntu.com/52586/
<asac> slangasek: if its ok, i will update the bug description like that
<slangasek> asac: for the bug description, that looks fine to me.  For the errata, I'll want to condense it further.
<NCommander> ScottK, ping
<asac> slangasek: sure go ahead.
<asac> updated bug
<NCommander> Anyone know how I get a machine added to acpi-support?
 * NCommander isn't quite sure what information he has to provide
<kees> slangasek, smb: I can't reproduce this: 276299
<NCommander> lool, can you help me get a machine added to acpi-support so sleep.sh force isn't needed
<persia> NCommander: Does the source not help you find the info?
<NCommander> persia, Sorta, I'm kinda afraid to try and provide a patch for the ACPI scripts due to the possibility of breaking things :-)
<persia> NCommander: I'd recommend preparing a patch for discussion and review.  It might be horribly wrong, but at least it's a starting point.
<NCommander> persia, my "patch" at the moment is just hard coding force to true so I can suspend from within Xfce ;-). Once I figure out the specifics, I'll cook up a patch
<slangasek> kees: that's been marked as a dupe of the one that was fixed already?
<slangasek> kees: is the implication that it's not really fixed?
<kees> slangasek: that would be how I'm reading it, but I can't reproduce the crash with -8.  :(
<Ng> NCommander: isn't pm-utils the new hotness? I don't think acpi-support is used very much anymore
<NCommander> Ng, pm-utils doesn't work on any machine I ever tried it on. (a few apples, and three sony laptops).
<slangasek> kees: ok, well, pochu's not around to ask; I wonder if apport is wrongly reporting the current version when the crash really happened with the old version?
<NCommander> pm-is-supported --suspend returns 1 which means my hardware is unsupported
<slangasek> NCommander: have you filed bug reports about these failures?  pm-utils is the supported Thing
<Ng> NCommander: aiui acpi-support is targetted to disappear in jaunty, so getting whatever quirks are required in place would seem like a good solution
<NCommander> slangasek, there are already a bunch for the Macs, and one for my sony laptop
<slangasek> ah
 * NCommander no longer has the other laptop to file a report
<NCommander> Ng, it doesn't require any quarks, it checks for the existence of /dev/pmu, which doesn't exist for me
<NCommander> Thus no suspend support
<NCommander> ACPI works properly however
<Ng> I dont have pmu and -is-supported returns 0
<slangasek> acpi-support doesn't implement suspend/resume anyway in the current incarnation, afaik
<NCommander> Ng, looking at the code, it checks for the existance of /dev/pmu it seems
<NCommander> Ng, are you on intrepid?
<Ng> NCommander: yep
<NCommander> slangasek, /etc/acpi/sleep.sh is owned by acpi-support
<NCommander> Ng, lucky then
<Ng> hardy used pm-utils to sleep, afaik
<NCommander> It worked on Hardy only after I did some nutty hacking
<Ng> but ultimately both of them just do some magic and echo something into proc or sys
<NCommander> It broke on intrepid after alpha 2 or 3 completely, but I only just got around to fixing it
<Ng> (where "magic" means "run scripts")
<NCommander> If I can figure out how to make pm-is-supported return 0, I could suspend
<NCommander> + ARG=suspend
<NCommander> + check_suspend
<NCommander> + command_exists s2ram
<NCommander> + type s2ram
<NCommander> It seems pm-is-supported checks force the existence of s2ram which was removed ...
<slangasek> do you have uswsusp installed?
<sbeattie> kees|slangasek: that's my belief as well, that the apport crash detection stuff gets run after upstart gets updated, and is reporting the fixed version rather than the buggy one. I've seen that with other apport crash reports.
<Ng> s2ram is old and busted too
<slangasek> sbeattie: yeah, annoying :/
<NCommander> Ng, s2ram worked.
 * NCommander doesnt' give a damn if its old if the new solution works
<NCommander> -_-;
<kees> sbeattie, slangasek: I hope that's the case.  :)
<NCommander> I thought pm-utils was a complete replacement though
<NCommander> I can't even understand why its checking for s2ram
<slangasek> do you have uswsusp installed?
<NCommander> slangasek, yes
<NCommander> slangasek, but the s2ram command was removed from that package in Ubuntu
<slangasek> try uninstalling it
<Ng> NCommander: I think that's a debian patch, going by 20080926112602.GA4015@srcf.ucam.org
<NCommander> (its still there in Debian)
<sbeattie> slangasek: I tried to have apport filter out those dupes, but I explicitly checked for -7 because the stacktrace is so useless. If you've got better ideas for a regex to match that, I'd be happy to improve it.
<NCommander> slangasek, removing ...
 * NCommander waits on initrd ...
<slangasek> NCommander: there's an open bug about pm-utils' support for backend selection; uswsusp deliberately doesn't support suspend, and pm-utils doesn't fall through to another backend in this case
<Ng> I'm not sure how pm selects which "module" it uses for suspend, but the options I have are uswsusp (old and busted), tuxonice (crack) and kernel (correct hotness). the latter checks for suspendability by grepping in proc
<slangasek> (was discussed on ubuntu-devel last week)
<NCommander> Now I'm getting 0 from pm-is-supported
<NCommander> which means ACPI should start working
<NCommander> er
<NCommander> suspend
<NCommander> slangasek, I've still dealing with my inbox, I've been somewhat MIA all week ;-)
<NCommander> Hold on, testing suspend
 * NCommander hugs slangasek 
<NCommander> WOOO
<NCommander> That fixed it
 * NCommander checks the seed on Xubuntu
<slangasek> ah, right, xubuntu; where the main/universe barrier doesn't stop the pm-utils Recommends: uswsusp from being honored
<slangasek> that'll be fixed post-beta
<slangasek> (by demoting the Recommends, since it's not Recommended at all)
<Ng> NCommander: :)
<NCommander> slangasek, I'm going to ask Cody put it on our blacklist just so it doesn't get pulled in period. We got a rash of bug reports about sleep, but most of them were written off as 2.6.27, not Xubuntu related ;-)
<NCommander> hey BenC
<cody-somerville> blacklist doesn't quite work like that
<NCommander> cody-somerville, ?
<cody-somerville> A package on the blacklist does not prevent a package from being included in a build IIUC.
<NCommander> cody-somerville, then what's the point of blacklists?
<NCommander> slangasek, the uswsusp problem will be resolved before Intrepid ships, right?
<Ng> can we just remove it alltogether?
<ogra-maemo> ++
<NCommander> Ng, if you want to help remove the rdepends ;-)?
<ogra-maemo> drop it from the archive
<slangasek> NCommander: yes
<NCommander> slangasek, \o/
 * NCommander hugs sladen 
<NCommander> er
 * NCommander hugs slangasek 
<slangasek> what are the reverse-depends?  Looks like 'hibernate', and that should probably go away too :-P
<sladen> NCommander: perhaps whilst you're politely hugging vorlon you could whisper something about changing his nick
<slangasek> sladen: someone else already has the nick 'vorlon' on this network ;P
<NCommander> slangasek, aw, but my 1993 Thinkpad wants to sleep too ;-)
<Ng> NCommander: I suspect much of the rdepends are suggests
<sladen> slangasek: 22:38 [Freenode] -!- There is no such nick vorlon
<NCommander> I thought apt-cache rdepends showed only actual depends
<sladen> slangasek: grab it quick
<NCommander> sladen, its registered to a freenode staffer I thought
<Ng> in fact they're all recommends or susggests if a quick for loop is to be trusted
<slangasek> sladen: oops, it's back
<sladen> vorian [i=steve@freenode/staff/vorian]  is
<sladen> slangasek: "/nick vorlin" /msg Nickserv register
<sladen> meh
<ogra-maemo> heh
 * NCommander prefers outside of an encounter suite ;-)
<NCommander> ^slangasek
<soren> NCommander: It's worse than that.
<soren> NCommander: It also lists conflicts, breaks, etc.
<NCommander> ewwwwwwww
<soren> Basically anything that states a relationship with the package, AFAIR.
<Ng> getting recommends and suggests is nice, but it might be better if it listed the relationship
<soren> Oh, wait.
<NCommander> Do you think we could remove uwsusp for this release?
<NCommander> Or should it wait for 9.04?
<soren> Perhaps I'm confused. I might be thinking of the dotty output.
<slangasek> NCommander: well, see the feedback on bug #264311; some people are quite attached to uswsusp
<ubottu> Launchpad bug 264311 in pm-utils "pm-utils stopped working in Intrepid (dup-of: 267141)" [Undecided,New] https://launchpad.net/bugs/264311
<ubottu> Launchpad bug 267141 in pm-utils "suspend button disappears after pm-utils upgraded to 1.1.2.4-1ubuntu2 " [Medium,Confirmed] https://launchpad.net/bugs/267141
<slangasek> I also don't think it's worth removing && blacklisting the package, instead of just fixing it so nothing else pulls it in
<cjwatson> NCommander: I invented the blacklist syntax for a single special case
<NCommander> slangasek, well, if its feasible,
<cjwatson> NCommander: most of the other uses people have tried to put it to don't work
 * NCommander notes thats why warning labels were invented
<cjwatson> NCommander: a blacklist entry is a big hammer which causes things to break if a package that isn't supposed to be installed gets into germinate's output, so that you can go and fix the packages to stop that happening
<soren> NCommander: Sorry, I was indeed mistaken. I was thinking of the dotty output.
<cjwatson> NCommander: trying to use it instead to work around package relationships doesn't work, because apt doesn't (and can't) know about blacklist entries in seeds
<slangasek> cjwatson: by 'blacklist' I meant 'sync blacklist', fwiw
<cjwatson> NCommander: so in particular you would find that the package keeps on being pulled into livefses
<cjwatson> 22:32 <NCommander> slangasek, I'm going to ask Cody put it on our blacklist just so it doesn't get pulled in period. We got a rash of bug reports about sleep, but most of them were written off as 2.6.27, not
<slangasek> ah
<cjwatson>                    Xubuntu related ;-)
<cjwatson> slangasek: ^- that was what I was replying to
 * cjwatson adds some documentation based on the above description of the purpose of blacklist entries to germinate(1)
<infinity> cjwatson: Dude, why haven't we fixed that gaping OpenSSH hole yet, WTF?!
<cjwatson> haha
<infinity> (For the confused, the above is sarcastic spillover from another channel)
<slangasek> infinity: #ubuntu-security-theater?
<asac> tjaalton: so debian appears to not have an issue with changing hostname in-session :/
<asac> tjaalton: and the debian guy that said that didnt find anything about xhost in Xsession.d/
<kirkland> slangasek: hiya, could you perhaps help sponsor two minor uploads, one to landscape-client, and one to update-motd ?
<kirkland> slangasek: landscape-client change in https://code.launchpad.net/~kirkland/landscape-client/270862
<kirkland> slangasek: update-motd change in https://code.launchpad.net/~kirkland/update-motd/main
<slangasek> kirkland: hmm, they won't go anywhere until after beta (due to the archive freeze); I have a long list of other things to try to get done between now and beta
<slangasek> so if you can find someone else to sponsor, that's probably preferable
<kirkland> slangasek: okey doke, no problem.  i think mathiaz can help with that
<kirkland> slangasek: what do i need in terms of "approval"?
 * persia points at ~ubuntu-main-sponsors, and encourages everyone to use that to keep the queue small.
<kirkland> slangasek: note that not making the beta is not an issue
<slangasek> kirkland: bugfixes don't need any approval, just sponsorship; they just don't clear the queue until after beta
<slangasek> s/any approval/any central approval/
<kirkland> slangasek: gotcha, thanks
<kirkland> persia: i've had relatively little success in several months of subscribing ~ubuntu-main-sponsors or ~ubuntu-universe-sponsors to bugs
<kirkland> persia: i find i have to talk to people in real time, synchronously on irc to get patches sponsored
<ogra-maemo> thats what persia hopes to change
<persia> kirkland: Understood, but the way to make them work is for everyone to use them.  The more people that don't use them, the more they get ignored.
<wgrant> Then this problem should be fixed, rather than likely diverting potential spponsor attention away even further.
<jcristau> asac: 'sudo hostname foo; xlogo' sure fails here, on sid.
<ogra-maemo> why would you do that?
 * ogra-maemo wonders about the usecase
<asac> ogra-maemo: hostname?
<wgrant> ogra-maemo: Because NM does it.
<asac> correct ;)
<ogra-maemo> ah
<asac> ogra-maemo: it works on fedora and suse
<ogra-maemo> why does it call  hostname explicitly ?
<ogra-maemo> to change ti ?
<ogra-maemo> *it
 * slangasek gets a silver bullet for NM
<jcristau> asac: 'it works' doesn't mean it's a good idea..
 * ogra-maemo holds his lighter at the edge of the archive to distract slangasek
<asac> jcristau: its understood that its not what most users want
<asac> jcristau: but there are several users that constantly ask for that feature
<asac> otherwise that wouldnt have been added
<ogra-maemo> well, you need to  update Xauthority i guess
<asac> ogra-maemo: fedora doesnt use xauthority for local users
<liw> er, why is NM changing the hostname?
<asac> ogra-maemo: they use xhost in xinitrc
<ogra-maemo> asac, bbut we do
<persia> liw: DHCP provided hostnames, perhaps?
<slangasek> liw: Chronic Batshit Syndrome
<ogra-maemo> just addd a proper xauth entry
<asac> ogra-maemo: yea wich is the bug
<liw> persia, does DHCP provide hostnames or just domain names? (system hostname and network interface domain names have zilch to do with each other...)
<asac> ogra-maemo: http://mail.gnome.org/archives/networkmanager-list/2008-September/msg00291.html
<persia> liw: It provides network node names.  There's no reason that one can't use that to populate the system host name (and many environments choose to do this).
<ogra-maemo> we do that in ldm, subscribe me to the bug, i'll take a look tomorrow
<infinity>   option host-name "S01060005023e7454";
<persia> liw: Note that the DHCP node name may have absolutely nothing to do with the value of the PTR record for the provided IP address.
<ogra-maemo> thats a silly statement in that mail
<infinity> liw: host-name is provided by many providers and on many corporate networks, so forward/reverse all match your IP.
<asac> ogra-maemo: which?
<infinity> liw: Whether or not this should be USED on a sane UNIX-like system is an entirely different story.
<liw> infinity, yeah, and that has nothing to do with what the computer is called
<asac> ogra-maemo: i think he means "hostname" vs. "ip"
<infinity> asac: Does NM not use the provided hostname if a static one is set in /etc/hostname?  Please tell me it doesn't...
<ogra-maemo> asac, the one about the issue indeed :)
<slangasek> yes, the network I'm connecting my laptop to should *not* get a vote on my hostname
<persia> liw: Well, it may.  Many large corporate environments enforce identity between host name, node name, and PTR reference.
<asac> infinity: thats my ttask ;)
<slangasek> persia: that's fine, but it's not a sane default
<liw> persia, then they can go and enable things and let the sane parts of the world have a sensible default
<asac> infinity: e.g. to do that in the debian backend
<persia> slangasek: No disagreement.  I'm just defending the existence of the use case, not the sanity thereof.
<liw> persia, I note that many large corporations do lots of other insane things that most others should not do...
<infinity> slangasek: I like it for cluster/node computing, where the system knows nothing about itself, except what the boot server told it.  But, yeah, for a worksation/laptop, it's ludicrous.
<jcristau> surely they can also run xhost in their session scripts, then
<infinity> slangasek: I just about choked when I powered up my YDL machine here, and saw that it was called "masq-012" (the forward/reverse for the IP it got on my internal network)
<persia> Well, it's rather unlikely one is running an X server on a cluster node anyway.
<jcristau> persia: or NM
<infinity> ... which just makes the NM usecase that much more ludicrous, but whatever. :)
<ogra-maemo> asac, i meant the statement that xauth isnt needed with local users above too be silly btw
<wgrant> NM isn't just for the X-dwelling universe any more, is it?
<asac> ogra-maemo: whats the problem with that? do fedora and opensuse have a security issue?
<ogra-maemo> is unix multiuser or what ?
<ogra-maemo> i would call it one, yes
<wgrant> Permissions on UNIX sockets work well.
<ogra-maemo> well ...
<asac> ogra-maemo: http://cvs.fedoraproject.org/viewvc/rpms/xorg-x11-xinit/devel/localuser.sh?revision=1.2&view=markup
<asac> thats the proposed implementation
<asac> ogra-maemo: its bug 276357
<ubottu> Launchpad bug 276357 in xorg "disable xauth for local users" [High,Triaged] https://launchpad.net/bugs/276357
<wgrant> Won't this break sudo in some circumstances?
<ogra-maemo> asac, i'd go with xauth add with a fresh cookie... but xhost migth serve the same purpose
<asac> ogra-maemo: sounds more difficult to set a fresh cookie
<asac> ogra-maemo: to fix the general issue we would need to have a hook that gets triggered when hostname is updated
<ogra-maemo> mcookie is your friend, you  just add it to the existing set
<ogra-maemo> yeah
<asac> ogra-maemo: how to trigger the update. NM is probably not the right place
<ogra-maemo> might be, i have to look at it with less wine in my blood :)
<ogra-maemo> i'll take a look tomorrow
 * ogra-maemo notices that on screen keyboards help  his typoing :)
<asac> ogra-maemo: if you have ideas post them in the bug ;)
<ogra-maemo> i will
<wgrant> ogra-maemo: Do they help your typoing, or did you typo typing?
<ogra-maemo> the former :)
<ogra-maemo> the thing is  that if you have to look at the keys, yor fingers  can't misbehave silently :)
<ogra-maemo> heh, i typoed :)
<Ng> persia: maybe not a cluster node, but you might on a machine in a large pool of thin clients, for example
<ogra-maemo> though it's stil impressive how fast and precise you get with some training
<persia> Ng: Indeed.  Classroom environments would be a good model.
<Ng> persia: yeah
<ogra-maemo> yeah.. and you might  have apps that only pulled the hostname on startup and cache it
#ubuntu-devel 2008-10-01
<kirkland> hrm, it seems that my eth0 device has disappeared on my intrepid thinkpad
<wgrant> kirkland: e1000e?
<kirkland> wgrant: i'm not sure
<kirkland> wgrant: 82566MM Gigabit Network Connection
<wgrant> That sounds like e1000e to me.
<kirkland> poop
<TheMuso> ThinkPads are known for their intel ethernet cards.
 * kirkland goes boot a live cd to see if his hardward is toasted :-/
<wgrant> kirkland: Don't!
<wgrant> kirkland: The driver has been disabled for a few days.
<wgrant> But booting an Intrepid alpha might kill it, as it's not blacklisted tehre.
<ogra-maemo> try a gutsy livecd
<wgrant> Or Hardy.
<ogra-maemo> or hardy,, right
<kirkland> wgrant: i booted a Damn Small Linux, 2.4 kernel
<kirkland> wgrant: device wouldn't load
<kirkland> gone
<wgrant> kirkland: I doubt 2.4 has drivers...
<wgrant> Does it appear in lspci?
<kirkland> wgrant: yeah
<wgrant> Try a Hardy live CD, as ogra-maemo suggested.
<kirkland> wgrant: lspci says http://pastebin.ubuntu.com/52659/
<kirkland> wgrant: lshw says http://pastebin.ubuntu.com/52660/
 * kirkland goes try a hardy cd
<infinity> kirkland: Looks like it's getting setup, which is a good sign.
<wgrant> kirkland: Your hardware is probably safe; in the other cases I've heard of it has disappeared off the PCI bus.
<infinity> kirkland: AFAIR, if you fried the firmware, it won't even get BIOS setup (so, no IRQ, etc)
<hikenboot>  /join #linuxhelp
<kirkland> infinity: wgrant: eth worked okay with hardy cd... whew
<wgrant> kirkland: Good news indeed.
<kirkland> wgrant: thanks ;-)
<wgrant> np
<kirkland> wgrant: funny thing is, i saw that announcement from slangasek and thought, "whoa, sucks for them"
<kirkland> :-D
<wgrant> kirkland: Hahah.
<kirkland> i hadn't used my wired ethernet on my laptop in so long
<wgrant> All of my hardware is far too old, fortunately.
<stgraber> hehe, I'm currently connected to internet using a linksys ethernet USB card :)
<kirkland> stgraber: good idea... i've got some old pcmia "fast" ethernet card somewhere :-)
<stgraber> but that sucks as my test network is using gigabit and that card is only 100Mb/s, but still better than a toasted gigabit card
<stgraber> kirkland: yeah, I also have a couple of 3COM PCMCIA cards but they were 10Mb/s only :) I thought I had a 100Mb/s one somewhere but couldn't find it
<kirkland> stgraber: yeah, i hooked it up to gig ethernet to transfer some huge kvm images, as wireless just wasn't cutting it
<mathiaz> kirkland: I've merged your landscape-client branch.
<kirkland> mathiaz: thanks
<kirkland> mathiaz: which do you prefer?  bzr or debdiff?
<mathiaz> kirkland: I'll upload the package once BetaFreeze is over.
<kirkland> mathiaz: cool
<mathiaz> kirkland: in that case, the bzr branch.
<mathiaz> kirkland: as everything is in bzr already.
<mathiaz> kirkland: next time you could try to use the 'propose for merging' feature in lp.
<kirkland> mathiaz: sure
<kirkland> mathiaz: want me to do that for the update-motd one?
<mathiaz> kirkland: well not really - since Vcs-Bzr points to a branch only you can commit to
<kirkland> mathiaz: right but i want my branch to be merged into the ~ubuntu-core-dev branch though, right?
<mathiaz> kirkland: sure - except that ~ubuntu-core-dev doesn't exist.
<kirkland> mathiaz: ;-)
<kirkland> mathiaz: gotcha
<mathiaz> kirkland: sure - except that the ~ubuntu-core-dev *branch* doesn't exist.
<wgrant> Who turned my background green?
<wgrant> Which package do I blame for the live CD ejecting and immediately reeating itself on shutdown?
<TheMuso> wgrant: casper possibly.
<TheMuso> As afaik casper does the ejecting.
<wgrant> (only on some machines, strangely enough...)
<wgrant> Thanks TheMuso
<TheMuso> np
 * Hobbsee ewwwww
<portablejim> Is this the place for talking about putting changes to an app into Ubuntu repos?
 * wgrant agrees with Hobbsee.
<wgrant> portablejim: Depends - you likely want to file a bug on Launchpad.
<portablejim> I wnt help about getting the changes i have made to an app into the repos (since the app was broken due to lack of maintanance).
<wgrant> portablejim: Which app, what sort of changes.
<wgrant> s/./?/
<portablejim> App: cdcontrol. Changes: Make the app so it does not fail 90% of the time.
<wgrant> It's in universe, so #ubuntu-motu is likely more appropriate.
<wgrant> But you probably want to file a bug (if there isn't one already), attach a debdiff, and get it sponsored.
<wgrant> https://wiki.ubuntu.com/SponsorshipProcess
<portablejim> Thanks.
<NCommander> I think I inherited evil
<NCommander> I have an RS/6000 running Windows NT for PowerPC
<IntuitiveNipple> asac: ping (NM 0.7 dhcp debugging)
<StevenK> NCommander: You don't Ctrl-Alt-Del to login, but you draw a Sigil using the mouse?
<NCommander> StevenK, probably
<NCommander> Its running Windows NT server 4
<NCommander> and
<NCommander> Oh god, IIS ....
<NCommander> ;.;
<NCommander> I could run a website off this relic
 * StevenK arms a cobalt bomb
<NCommander> YES, SAVE ME WITH MIPS
<StevenK> I meant Cobalt, the element, not the product, you dolt :-P
<pitti> Good morning
<StevenK> pitti: The 25-1 ports kernel has landed in NBS
<StevenK> pitti: There's a new linux-ports-meta waiting in unapproved, so it can't get killed yet
<pitti> StevenK: acknowledged
<slangasek> the linux-ports-meta in unapproved was nacked by cjwatson
<StevenK> Ah
<StevenK> slangasek: It's crack?
<slangasek> the package names are altogether inconsistent
 * StevenK pokes at it
<StevenK> Ew
<StevenK> Actually, it's NEW, not unapprovied
<StevenK> Er, unapproved
<StevenK> pitti: Can you poke me after you've caffinated?
<pitti> StevenK: poke (I'm online, just processing IRC scrollback in all channels)
<StevenK> pitti: So, the scariest thing still in NBS is libltdl3 :-(
<pitti> StevenK: yeah, that'll require a big bunch of rebuilds still
<StevenK> pitti: I think they all FTBFS
<pitti> right, s/rebuilds/build dep fixes/, I mean
 * StevenK is checking
<pitti> Riddell: ah, so upstream most likely develops qt on Fedora then :)
<pitti> Riddell: I just wonder why it has wrong debuglinks then; does it still call dh_strip with some --dbg information?
<wgrant> Did anybody end up working out what should happen to get lib{32,64}ffi4 and the like caught by the NBS scripts?
<pitti> ion_: oh, thanks for pointing that out; it's actually supposed to ignore the cache if any of the .fdis is obsolete; otherwise you would always have to restart hal if you install any package with an .fdi
<StevenK> wgrant: I didn't, at least
<pitti> ion_: can you please file an RC bug for this and assign it to me? I'll look into that ASAP
<StevenK> pitti: wgrant just reminded me. Should we NBS those two binaries out?
<pitti> sure, they aren't built any more
<wgrant> There are probably dozens of others.
<StevenK> pitti: liblame0 only has rdepends of mencoder and mplayer on powerpc, do you think we can kill it?
 * TheMuso digs into the PowerPC mplayer FTBFS.
<pitti> StevenK: it's pretty popular, but sure, we can rebuild it a bit later
<pitti> oh, it's FTBFS? darn
<TheMuso> oh.
<TheMuso> and FTBF sbecause of a compiler segfault it seems.
<StevenK> Whee
<StevenK> An ICE?
<TheMuso> let me check
<StevenK> ad_imaadpcm.c:376: internal compiler error: Segmentation fault
<StevenK> So, yeah, an ICE
<StevenK> It was given back about 9 hours ago, too
 * TheMuso goes to try and build locally.
<dholbach> good morning
<Hobbsee> morning dholbach
<dholbach> hi Hobbsee
<StevenK> wgrant: Bug 276629, if you want to subscribe
<ubottu> Launchpad bug 276629 in soyuz "archive-cruft-checker doesn't pick up all cruft" [Undecided,New] https://launchpad.net/bugs/276629
<wgrant> StevenK: Thanks.
<StevenK> Oh, this isn't cool.
<StevenK> guile-gnome-platform runs xvfb during the build process which spins with 100% CPU usage
<wgrant> Nice.
<StevenK> 3 failed: cacao guile-gnome-platform ksimus
<StevenK> 3 unaccounted for: gnash mit-scheme myodbc
<wgrant> Hm?
<StevenK> (unaccounted for is either "Build Depends failed to install" or similar erorr, or it's still building)
<wgrant> Ah. Some Soyuz CLI tool output?
<StevenK> Nope, it's a script I wrote for test builds
<StevenK> One of the 6 or so scripts I wrote to help with NBS
<wgrant> Aha.
<wgrant> Didn't think I'd seen it before.
<StevenK> Ah ha. mit-scheme is only i386.
<StevenK> steven@liquified:~/ubuntu/libltdl3-cruft% grep -c 'warning:' cacao/current
<StevenK> 481
<StevenK> Bah
<TheMuso> Yep, mplayer on PowerPC fails for me locally in the same way as on the buildds.
<wgrant> Gar, not again.
<wgrant> TheMuso: With what kind of error?
<StevenK> wgrant: An ICE
<wgrant> Ah. SEP
<NCommander> ARGH
 * NCommander shivers
<NCommander> Launchpad's new UI burns
<NCommander> wgrant, its a compiler segfault. I did a little work debugging it, but its really ugly
<wgrant> NCommander: Bug #276618?
<ubottu> Launchpad bug 276618 in launchpad-foundations "New black (sub)subtabs look bad" [Undecided,New] https://launchpad.net/bugs/276618
<StevenK> mplayer is in multiverse, perhaps we could build it with gcc-4.2?
<StevenK> TheMuso: Do you want to try that? It's a hack, but it could get a working mplayer on PPC
<StevenK> pitti: What do you think? ^
<TheMuso> StevenK: Wortha try, as soon as I work out what needs changing to do that. :)
<StevenK> TheMuso: export CC=gcc-4.2 and Build-Depend on gcc-4.2
<StevenK> Er, export CC=gcc-4.2 in debian/rules
<StevenK> wgrant: Argh
<StevenK> wgrant: It really does reach out and slap you
<TheMuso> StevenK: Right, will have a play.
<NCommander> TheMuso, I can roll those changes
<wgrant> StevenK: What does? The black hole?
<StevenK> wgrant: The black subtabs
<wgrant> StevenK: Right.
<TheMuso> NCommander: I'll try here as well.
<StevenK> Open that page, flip to another tab, and then go back and it hits you
<wgrant> NCommander: Comparing LP to SF... that's low.
<StevenK> 6 failed: cacao guile-gnome-platform ksimus mit-scheme myodbc pacemaker
<StevenK> 1 unaccounted for: gnash
<StevenK> Sob
<wgrant> StevenK: Indeed.
<NCommander> wgrant, I could do worse
<StevenK> Hm. Where did libkonq4-dev go?
<wgrant> StevenK: Away with KDE3, maybe? It is KDE, so it can do that.
<StevenK> libkonq4 is KDE3?
<StevenK> Blink
<wgrant> It might be.
<wgrant> Probably not, though.
<wgrant> libkonq5-dev exists now...
<StevenK> Yeah, just trying that
<NCommander> wgrant, can I just switch it to use gcc-4.2 across the board, or would you perfer if I just made that change on PPC :-)
<wgrant> Ideally just on PPC, but I can't see it killing much on other archs...
<NCommander> Is there a handy trick to determine an architecture in the rules?
<StevenK> Yes
<StevenK> Let me dig it up
<wgrant> mplayer already uses it lots.
<NCommander> Yes, yes there is
<StevenK> ifeq (lpia,$(shell dpkg-architecture -qDEB_BUILD_ARCH))
<StevenK> EXTRA_CONFIGURE_ARGS +=  --enable-hildon
<StevenK> endif
<TheMuso> Yes, I am just popping the export under the configure arch setting for altivec.
 * NCommander did the same :-)
<NCommander> TheMuso, its a race to see who finishes first
<TheMuso> heh.
 * NCommander test builds ;_0
<TheMuso> its not really.
<TheMuso> NCommander: Don't forget changing debian/control.
<NCommander> TheMuso, already done
<NCommander> StevenK, BTW, do you know anyone who cares about Ubuntu SPARC?
 * NCommander notes that all ports are uninstallable from scratch in intrepid
<StevenK> NCommander: Due to what error?
<NCommander> StevenK, due to lack of kernel
<TheMuso> StevenK: linux-ports-meta
<NCommander> no linux-ports-meta package
<NCommander> The upshot is that no ports can release with intrepid
<StevenK> It's in NEW, it got nacked
 * NCommander rolls eyes
<NCommander> (PowerPC has made some progress, but we won't be releasable until jaunty likely)
<NCommander> The problem is there is no one that I can find who can do the work on getting the kernel into shape for HPPA, IA-64, or SPARC
<NCommander> (LPIA sidestepped the issue with linux-lpia and linux-lpia-meta)
 * StevenK is well versed on linux-lpia{,-meta}
<TheMuso> NCommander: The difference is that there is actually a team supporting that port.
<NCommander> Well, maybe we should do linux-powerpc{,-meta}
<NCommander> That way each port can work without stepping on each others toes so to speak
<wgrant> No. Three copies of linux in the archive is quite enough.
<wgrant> Although -rt might still be separate. I forget.
<TheMuso> wgrant: Well there is actually more, but you have a point re the metas at least.
<StevenK> wgrant: -lpia and -generic are now both 27
<NCommander> StevenK, you won't happen to know a closet SPARC developer, would you?
<TheMuso> lol
<NCommander> I ask more that I'm worried that REVU will have to switch to Debian
<NCommander> The irony would be overwhelming :-/
<NCommander> StevenK, BTW, I got a new toy, an RS/6000 ;-)
<StevenK> NCommander: Running NT4 server
<StevenK> You know, I made a joke about it
<NCommander> oh right
<NCommander> I fail
<NCommander> Sorry
<NCommander> Windows NT for PowerPC hurts my brain
<ajmitch> then don't use it
<NCommander> I'm not
<NCommander> Its just the mere proximity ;-)
<StevenK> Yay, progress:
<StevenK> 7 failed: cacao gnash guile-gnome-platform ksimus mit-scheme myodbc pacemaker
<StevenK> NCommander: Didn't you look at cacao?
<slangasek> why is myodbc failing?
<StevenK> ../driver/.libs/libmyodbc3_r.so: undefined reference to `mysql_odbc_escape_string'
<NCommander> StevenK, yeah, thats a FUN FTBFS
<NCommander> StevenK, the general issue is GCC changes its JNI mappings, the cacao SVN has a fix
<NCommander> But
<NCommander> (there is always a but)
<NCommander> They completely redid the JNI code
<NCommander> So backporting would be an absolute nightmare
<slangasek> StevenK: ummm, that appears to be a function provided by libmysqlclient, so where did it go?
<StevenK> slangasek: Would you like to see the complete build log?
<slangasek> no, just the linker command line immediately befor eit :)
<StevenK> gcc -O3 -DDBUG_OFF -I/usr/include/mysql -DBIG_JOINS=1 -fPIC -g -Wall -O2 -Wl,-Bsymbolic-functions -o .libs/my_basics my_basics.o  ../driver/.libs/libmyodbc3_r.so -L/usr/lib -L/usr/lib/mysql /usr/lib/libmysqlclient_r.so -lcrypt -lnsl -lm -lz /usr/lib/libodbcinst.so /usr/lib/libltdl.so -ldl -lpthread -Wl,--rpath -Wl,/usr/lib
<NCommander> o_o;
<slangasek> ah.  Stupid test suite
<StevenK> slangasek: Hm?
<slangasek> my_basics is part of the test suite; I'm blaming the test suite to avoid acknowledging that there's probably a bug elsewhere ;)
<StevenK> Hehe
<StevenK> And gnash now installs it's Build-Depends, but promptly fails in ./configure
<StevenK> Sigh
<NCommander> sladen, probably the MySQL API changed, and someone didn't bother to update the test suite
 * StevenK points NCommander at slangasek 
<slangasek> s/test suite/package/
<NCommander> *sighs*
<NCommander> Two autocomplete failures
<NCommander> Damn it
 * NCommander hacks it so that if sladen is in the room, he is ignored and slangasek is selected instead
<slangasek> poor sladen
<NCommander> StevenK, anyway, if you want to "fix" cacao, its not a picture
<StevenK> NCommander: The new version of cacao in Debian builds?
<NCommander> They packaged the SVN snapshot
<StevenK> Typical
<slangasek> StevenK: the fact that myodbc is FTBFS in this way means that the libmysqlclient ABI has silently changed since June, dropping library entry points
<StevenK> And only uploaded it to experimental
<StevenK> slangasek: \o/
<NCommander> StevenK, yeup
<NCommander> It's a rather nasty problem
<NCommander> Since we're dealing with GCC JNI ABI
<NCommander> It seems you can build it if you use Sun's javac, but I didn't get too far in figuring out how to do that
<StevenK> slangasek: Could you be convinced to hand wave a cacao in? :-D
<slangasek> do what then?
<StevenK> slangasek: Be convinced to sync "cacao | 0.99~rc5-1 |  experimental | source, amd64, i386, mips, mipsel, powerpc"
<NCommander> ewwww
<slangasek> StevenK: er... why wouldn't you do that yourself?
<StevenK> Haha
<StevenK> That's cheating
<StevenK> slangasek: I can, but I need a FFe and all that jazz for you to approve, don't I?
<StevenK> And Debian have a newer version of gnash than we do
<slangasek> StevenK: motu-release; it's in universe
<StevenK> Aren't you also on that team? :-P
<slangasek> not by choice ;)
 * StevenK chuckles
<pitti> tjaalton: JFYI, running with the older -intel 3a2.4.1-1ubuntu4 for three days now, and didn't have the "suddently turns black" issue; that's with current kernel, current X, and (few) pipe A/B underruns in Xorg.0.log
<NCommander> slangasek, it could be worse. You could be a member of ubuntu-hppa ;-)
<NCommander> pitti, how soon do you need libpam-blue by?
<NCommander> oh wait
<NCommander> That was persia who asked me to look at that
<pitti> right; I was pretty confused :)
<pitti> (although I'm watching the progress in the bluez 4 bug)
<NCommander> Argh
<NCommander> Bah
<NCommander> I hate packages that don't have a patch system
<NCommander> pitti, if there is no patch system, which one do you recommend I add, or should I just inline?
<NCommander> (I need to inline a bunch of M4 marcos to fix libtool :-/)
<NCommander> ls
<NCommander> er
<lool> NCommander: I didn't touch acpi-support for a while, but I could check whether it's ok if I commit some fixes to it
<lool> NCommander: The Debian maintainer is nice but he has been doing all the work, so I'd prefer checking with him before using my commit rights
<lool> or permissions rather
<NCommander> lool, I resolved the issue without needing to touch it, and since ACPI sleep is seemingly going away for jaunty
<lool> ACPI sleep is going away?
<NCommander> Thats what someone said
<lool> As in, the kernel will do the sleeping without speaking to ACPI, or no sleep?
<NCommander> Just pm-utils will be supported
 * wgrant can't see either as being possible.
<lool> NCommander: Oh, you mean acpi-support is going away
<NCommander> yeah
<NCommander> Sorry if I wasn't clear
<pitti> NCommander: my personal recommendation is "simple-patchsys.mk for cdbs" and "dpatch for normal debhelper", they are the least intrusive ones
<pitti> NCommander: however, I wouldn't add one at all if diff.gz already has patches
 * NCommander nods
<NCommander> Yeah, it does
 * NCommander HATES autotools
<NCommander> even though they're good
<NCommander> When they break, they're miserably
<slangasek> ugh simple-patchsys
<StevenK> Ugh CDBS
<NCommander> Ugh quilt
<pitti> ugh a gazillion different possibilities for source packages
<StevenK> I quite like dpatch, though. It doesn't require that I smash my head through my desk to patch something
<slangasek> pitti: you're right; let's eliminate the one that's most inadequate, simple-patchsys :)
<NCommander> StevenK, WOOOOOO
<StevenK> Haha
<wgrant> Ugh dpkg
<NCommander> Ugh rpm
<StevenK> So says Steve "Vendetta" Langasek
<pitti> slangasek: /usr/share/cdbs/1/rules/patchsys-quilt.mk WFM, too
<pitti> however, I found that many people have more troubles with quilt than with cdbs-edit-patch
<StevenK> quilt is the patch system that forces me to smash my head through my desk to patch something
<wgrant> quilt is insanely stupidly complicated.
<pitti> slangasek: simple-patchsys' popularity is actually quite astonishing, given that it was just meant as an "example"...
<wgrant> With dpatch and simple-patchsys I just tell it to edit the patch.
<NCommander> wgrant, its the emacs of patch systems
<pitti> wgrant: wait until you see bzr-loom then :)
<NCommander> bzr-loom?
<StevenK> quilt refresh \n Launching tactical nukes
<wgrant> bzr-loom isn't bad.
 * NCommander is reminded of the Lucasarts Game
<pitti> wgrant: the stupidity of quilt is mainly "quilt add" IMHO; the general design is quite good
<wgrant> pitti: But that is infinite stupidity.
 * NCommander hates it when a package maintainer changes something for no clear reason without noting it in the changelog
<pitti> wgrant: has bitten me more than once, too
<seb128> I don't like the inline change, there is no way to "exit 1" if you screwed something
<StevenK> seb128: Me either
<seb128> and it often let noise in the source after doing the refresh and pop too
<siretart> quilt is the only one I finally understood how it is supposed to work :)
<pitti> seb128: however, you can actually change/build/test in that mode, which isn't possible wit simple/dpatch
<StevenK> I usually end up binning the source tree and starting again
<wgrant> It always leaves something in .pc for me... or am I missing something?
<seb128> siretart: you don't understand how cdbs simplepatchsys is working?
<NCommander> OMG WHY
<NCommander> WHY
<NCommander> WHY
<StevenK> Woo, caco 0.99~rc5 builds
 * pitti reduces NCommander verbosity by 1
<NCommander> WHY IS THIS MAINTAINER REGENERATING AUTOTOOLS IF THERE ARE NO CHANGES TO CONFIGURE.IN
<NCommander> Ack verbise -1
<siretart> seb128: it seems to insist to create a copy of my tree every time I want to create or modify a patch
<NCommander> **** - new verbose explination
<siretart> which is insane for larger trees
<NCommander> BTW, siretart do you care about Ubuntu SPARC?
<siretart> NCommander: spooky is one. so to some degree, yes
<NCommander> siretart, good, you just became the sparc kernel guy for linux-ports :-)
<seb128> siretart: right it does a copy, I don't work on packages large enough for that to be annoying though, gtk or evolution take a couple of seconds to do that
<siretart> seb128: I mainly work on my laptop with crypted everything. copying is painful for me
<siretart> NCommander: I see.
<siretart> NCommander: as first step, I resign :)
<NCommander> Well, intrepid SPARC is not installable
<NCommander> If you want to fix that for jaunty, you shouldn't resign
<NCommander> Less we make spooky run Debian ...
<NCommander> But that would be wrong :-)
<TheMuso> Ok mplayer successfully built using gcc 4.2.
<StevenK> \o/
<StevenK> pitti: Do you think that's a good call -- uploading a mplayer that uses gcc-4.2 on ppc?
<pitti> StevenK: if it ICEs with 4.3, that's an acceptable workaround, yes
<pitti> especially since it's not in main
<StevenK> TheMuso: Upload it!
<NCommander> argh
 * NCommander wanted credit for that upload
 * NCommander runs
<TheMuso> heh
<StevenK> NCommander: U looz
<TheMuso> Ok mplayer is in bzr so I'll do things that way.
<NCommander> Well, I don't have any uploads in multiverse or restricted
<StevenK> NCommander: http://www.pvponline.com/2008/06/30/interlude-the-adventures-of-lolbat
<NCommander> StevenK, lolbot
<NCommander> er
<NCommander> bat
<NCommander> # well, rm -f config.log :)
<NCommander> libpam-blue source: configure-generated-file-in-source config.log
<NCommander> o_o;
<NCommander> Why do people think its a good idea to disable lintian warnigns
<NCommander> *warnings
 * TheMuso ponders how mplayer got uploaded with that maintainer field. I try and dpkg-buildpackage it, and I get the maintainer field warning.
 * NCommander thinks we need to resurrect the ubuntu-powerpc group, and get someone who is active to be an admin
<pitti> TheMuso: the previous upload might not have had an ubuntuish DEBEMAIL
<TheMuso> pitti: You're totally correct.
<TheMuso> I'm using themuso@ubuntu.com.
<pitti> so then he just got a warning and ignored it
<pitti> TheMuso: "update-maintainer" FTW :)
<TheMuso> right
<StevenK> libtool: compile:  x86_64-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I../../libbase -I.. -Wall -g -Werror-implicit-function-declaration -O2 -W -Wall -Wcast-align -Wcast-qual -Wpointer-arith -Wreturn-type -Wmissing-declarations -Wmissing-prototypes -Wstrict-prototypes -MT libltdlc_la-ltdl.lo -MD -MP -MF .deps/libltdlc_la-ltdl.Tpo -c ../../libltdl/ltdl.c  -fPIC -DPIC -o .libs/libltdlc_la-ltdl.o
<StevenK> ../../libltdl/ltdl.c:32:25: error: lt__private.h: No such file or directory
 * StevenK kicks libtool
<TheMuso> pitti: I know, but the maintainer is an Ubuntu team, i.e the MOTU media team, which has an email address pointing to tauware.de.
<pitti> TheMuso: oh, ok; workaround: "DEBEMAIL= debuild -S"
<TheMuso> pitti: Right.
<pitti> TheMuso: I don't think how we can make the check recognize this case without becoming totally useless
<pitti> s/think/see/
<NCommander> StevenK, libpam-blue fixed
<StevenK> \o/
<NCommander> THe fix was removing the maintainers insane rules file
<NCommander> He rebuilt autotools incorrectly, disabled autoconf's Makefile generator and ...
<NCommander> Ew
<NCommander> The debdiff is massive
<NCommander> Since all the crap he added was removed
<wgrant> TheMuso: The solution is probably to move than to a *ubuntu* domain, like motu-reviewers was.
<TheMuso> wgrant: Long term, I agree.
 * TheMuso double-checks it on x86 to make sure he didn't inadvertantly break anything else.
<NCommander> superm1, ping
<TheMuso> NCommander: likely asleep.
<NCommander> :-(
<NCommander> StevenK, care to upload libpam-blue to the bluetooth PPA
<NCommander> https://bugs.edge.launchpad.net/ubuntu/+source/libpam-blue/+bug/276343
<ubottu> Launchpad bug 276343 in ussp-push "Rebuild for libbluetooth2 -> libbluetooth3 transition" [Undecided,Fix committed]
<StevenK> NCommander: I can add you to the bluetooth team
<NCommander> \o/!
<NCommander> YALPT
<StevenK> NCommander: Apply, I'll approve you
<NCommander> It's offical
<NCommander> at 800x500, I now have enough teams to cause a horizonal scrollbar on my profile ;-)
<TheMuso> NCommander: heh
<NCommander> TheMuso, I'm in a race with cody-somerville to see who can cause a scrollbar to show up at 1024x768 first
<NCommander> StevenK, applied
<StevenK> NCommander: I just approved you
 * NCommander adds ppa-bluetooth to his dput config
<TheMuso> NCommander: *sigh* you're not really in a race are you?
<NCommander> \o/
<NCommander> TheMuso, 29 to 30
<NCommander> er
<NCommander> wait
<NCommander> 30 to 30
<NCommander> WOOO
<NCommander> tied
<Hobbsee> !enter | NCommander
<ubottu> NCommander: Please try to keep your questions/responses on one line - don't use the "Enter" key as punctuation!
<NCommander> OK, fine. Enter
<NCommander> :-)
<StevenK> Haha
<NCommander> libpam-blue uploaded :-)
<NCommander> StevenK, so the bluez transition is complete
<NCommander> Now we just need to release intrepid, and pound the Debian BT guys to adopt our packages
<NCommander> StevenK, ew, there were a few ugly bluetooth build failures
<StevenK> There are?
<StevenK> Which?
<NCommander> StevenK, libbtctl4-dev(inst 0.10.0-1ubuntu1~ppa1 ! >= wanted 0.10.0-1ubuntu1)
<NCommander> That's an anonying one :-)
<NCommander> same with sylpheed
<StevenK> That's due to the funness of ~
<StevenK> 0.10.0-1ubuntu1~ppa1 isn't greater than 0.10.0-1ubuntu1
<NCommander> That's why you use source:Version
<NCommander> StevenK, the transition for bluetooth was done damn fast O_O;
<NCommander> less than 19 hours
<StevenK> NCommander: slypheed wants pilot-link
<StevenK> And wants greater than ubuntu3
<StevenK> Argh
<StevenK> Death to PPA versioning
<NCommander> StevenK, you could just upload sane versions ;-)
 * NCommander runs
<tjaalton> pitti: so, the no_render_suspend patch broke it for you..
<pitti> tjaalton: likely, but the changelog made it look hardware specific?
<pitti> tjaalton: shall I file a bug about this now?
<tjaalton> pitti: yep, but the patch also affects 965GM systems
<tjaalton> pitti: which one did you have?
<pitti> tjaalton: (00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03)
<tjaalton> pitti: huh, should not make a difference then..
 * StevenK kicks gnash
<pitti> tjaalton: it might be a more complicated chain of change, such as building ubuntu6 against a newer X server, or newer toolchain, or so, but that becomes really obscure then
<StevenK> pitti: Right, all seven of the source packages required by libltdl3 are broken in odd ways.
<StevenK> pitti: cacao can be fixed by sync'ing from Debian experimental, but that requires a jump from 0.98-2 to 0.99~rc5-1
<pitti> StevenK: that should get doko's blessing then
<StevenK> gnash is still busted, even the newer upstream version in Debian doesn't build
<pitti> just because of libtool, or for other reasons?
<slangasek> StevenK: myodbc isn't broken; that's a mysql-dfsg-5.0 bug
<slangasek> (well, perhaps myodbc is also broken, if we choose the horrible option of bumping soname :P)
<NCommander> StevenK, what's wrong with gnash?
<Tonio_> hi !
<asac> StevenK: 0.8.4 will be it
<asac> (gnash)
<asac> upstream has fixed gstreamer support a few days ago
<Tonio_> hum I accidentally uploaded a package to ubuntu that should have gone to my ppa...
<Tonio_> this is NEW package so might not reach the archives, can somehow drop it when falling in NEW plz ?
<Tonio_> the package is libpackagekit-qt
<asac> Tonio_: to be safe ping the archive admins directly
<Tonio_> asac: true that, and most of them are here :)
<Tonio_> asac: but yeah, an email or Riddell directly would be better :)
 * Hobbsee looks
<Hobbsee> Tonio_: hm, it's not there yet.
 * Hobbsee accepts a bit more universe stuff in the mean time
 * Hobbsee %^&*&^%$#%^&*(*&^%$%^&*(*
 * pitti reports a memory corruption bug against Hobbsee
<slangasek> you mean that's not a clever regexp?
<pitti> rather a sendmail config file
<Hobbsee> pitti: i hope the title is "launchpad is being a pain in the neck" again.
<pitti> tseliot: FYI, just committed a jockey change to test main window without any handlers
<Hobbsee> right.  I can accept at least 4 at a time.  OK.
<tseliot> pitti: great, I'll have a look at it
<Riddell> Tonio_: rejected libpackagekit-qt
<doko> StevenK: 0.99~rc5 seems to be way too old
<slangasek> Riddell, ScottK: is there web content for kubuntu that I should link to for the beta?
<Tonio_> Riddell: thanks :)
<Riddell> slangasek: will be at https://wiki.kubuntu.org/IntrepidIbex/Beta/Kubuntu
<StevenK> doko: Debian experimental has 0.99~rc5, should I be looking at a newer version?
<asac> Riddell: qxembed.h ... where would that be?
<StevenK> asac: And you'll deal with gnash when 0.8.4 is released, right?
<asac> StevenK: yes
<StevenK> asac: Cool
 * ogra wonders what it is that makes NM keep asking for the network passphrase on his mobile image
<asac> StevenK: i will bring up a snapshot right after beta and release should happen quite close to our release
<asac> ogra: because its a bug
<asac> ogra: take the NM from PPA
<StevenK> slangasek: So, bug you about mysql-dfsg-5.0 after you've had 2 days sleep after the beta is released?
<asac> ogra: ~network-manager
<slangasek> StevenK: bug me?  Bug the server team instead? :)
<ogra> asac, phew, i was suspecting its a missing package or something in the gnome-keyring stack
<ogra> if its a bug all is fine
<asac> ogra: no. its a regression and we had bad luck with that snapshot ;)
<StevenK> Hm. Who on the server team deals with mysql?
<slangasek> StevenK: changelog says zul uploaded it
<ogra> asac, then i'm fine, i cant build from PPAs now that its built in the datacenter
<ogra> but its a bit painful if you are bound to an onscreen kbd to have to put it in every boot
<asac> ogra: sounds complicated :-D
<asac> ogra: not sure. you could put it into keyring manually ;)
<doko> StevenK: http://www.complang.tuwien.ac.at/cacaojvm/download/
<ogra> asac, well, i assume its targeted to be fixed for final
<asac> ack
<StevenK> doko: Okay, I can look at updating to 0.99.3 ?
<ogra> so i dont care for now, its not mobile specific
<ogra> asac, btw feel free to test mobile on your Q1 :) http://cdimage.ubuntu.com/ubuntu-mobile/intrepid/current/
<asac> ogra: is that an install or live image?
<doko> StevenK: there should be another release soonish. please could you add a cacao-source binary package just including the source rarball? then I don't need to copy that into cacao-oj6
<ogra> asac, installable live image :)
<doko> btw, why are you interested in cacao itself?
<ogra> asac, its my side of ograsac on a livecd
<asac> ogra: yay ... byebye imagecreator?
<ogra> err s/cd/usb image/
<ogra> yup
<ogra> all mobile images (ubuntu-mid and ubuntu-mobile) are built in the datacenter with livecd-rootfs
<StevenK> doko: I'm interested in cacao because it's in the NBS list for libltdl3
<StevenK> asac: We haven't touched MIC all Intrepid
<StevenK> \o/
<ogra> :D
<StevenK> doko: Hm. cacao-oj6 is just source and has a 6b... version number. I'm confused.
<doko> NBS?
<StevenK> Not Built from Source
<StevenK> libltdl7 is now provided by libtool, not libltdl3
<doko> the versioning is done using the opnjdk source drop
<StevenK> doko: If cacao is on your list to deal with, then please go ahead :_)
<doko> StevenK: no, I don't care about cacao myself. why is cacao needed for libltdl7?
<StevenK> doko: Because the cacao binary package Depends on libltdl3. We can't remove the libltdl3 binary package from the archive until nothing depends on it, or we break them
<doko> ahh, ok. well, go ahead. would save me some typing adding this package myself. else I'll include the copy myself
<StevenK> doko: Well, hence this conversation. 0.98-2 in Intrepid FTBFS. 0.99~rc5 in Debian works, but I can update that to 0.99.3 if you wish
<doko> StevenK: yes, and please add the cacao-source binary package
<StevenK> doko: Okay, cool. I think a debdiff is worthless, but I'll point you at it when I'm done
<StevenK> Oh, ew. Cacao uses cdbs
<Riddell> asac: kdelibs4c2a (from memory)
<Riddell> or kdelibs4-dev
<asac> Riddell: hmm
 * anilg is portinf kdelib4-dev and he hates waiting 15 minutes to see if the last change fixed the issue
<asac> Riddell: what should gnash use for kde? qt4 and kde4 ?
<Riddell> asac: if it has a kde 4 port then it should use that.  as far as I know if only has a kde 3 port in which case it should use kdelib4-dev
<Riddell> anilg: porting to what?
<anilg> Nexenta hardy
<anilg> some thigns dont work the same way in solaris.. and things debian/rules expects arent always there
<asac> Riddell: would the kde3 plugin still be useful in kde4 knoqueror?
<Riddell> asac: no
<asac> Riddell: kde4 will be default right?
<Riddell> asac: yes, there is no kde 3 konqueror, so the kde 3 kpart can be dropped
<asac> Riddell: ok. so unless gnash devs fix kde4/qt4 support its just the standalone player we can ship
<asac> assuming that kde4 users can install kde3 apps ;)
<Riddell> yes that's fine
<ion_> pitti: Will do
<pitti> wow, shift+K now actually works when editing .py files in vim; hadn't noticed that yet
<ogra> what does it do ?
<ion_> Shows the help for the keyword under the cursor.
<ogra> sweet
<pitti> normally it shows the manpage for the word under the cursor
<pitti> but now it's clever enough to actually consult Python docstrings
<pitti> just tried it with "shutil" and "tempfile", and it shows the python modules
<ogra> pitti, btw, i use fdi files for touchscreens, but that apparently only works if i install them to /etc/hal/fdi/policy ... if i put them into /usr/share/hal/fdi/policy/10osvendor the evdev driver overrides evtouch, any hint how to solve that ?
<pitti> ogra: you might need a higher number prefix then, for correct ordering?
<ogra> oh, that might help indeed, i use 10 for all of them ... which the evdev one surely does as well
<ogra> and sadly touchscreens often enough match input.mouse
 * ogra hugs pitti ... that seems to work
 * pitti hugs ogra back, good
<ogra> seb128, can you let ubuntu-mobile-default-settings through ? (universe)
<ogra> or do i need a release team member to do that during the freeze ?
<pitti> no, any archive admin can shove through universe
<seb128> ogra: technically I can not sure if I'm supposed to though, better to ask pitti though
<ogra> right, thats what i thought
<seb128> ok, good to know
 * pitti pokes
<ogra> thanks :)
<pitti> flushed all pending universe stuff
<ogra> gconf is silly ...
<ogra> as soon as i put quotes around a default setting it makes it a string, tsk
<seb128> I would say that's a good thing
 * ogra applies the same fix to ubuntu-mid-default-settings
<ogra> seb128, well, depends ... many apps just cope with that, but some dont, i used to quote all my settings unlit i found that some booleans dont apply
<seb128> where do you set those values?
<seb128> and how?
<ogra> in a file in /usr/chare/gconf/defaults
<ogra> seb128, /apps/gksu/disable-grab "true" doesnt work, /apps/gksu/disable-grab true does :)
<seb128> why would you quote numbers or boolean there
<seb128> you are asking for trouble
<seb128> right, "" is usually a string
<seb128> that's the same in let's say python
<ogra> well, /apps/gnome-power-manager/lock/hibernate "false" works
<seb128> 1 and "1" are different things
<ogra> it really depends how the app pulls it out of the db in the end it seems
<seb128> that's probably because the code is smart enough to ignore incorrect types
<ogra> g-p-m doesnt seem to care
<seb128> or that it works by luck
<seb128> no, the gconf api let you specify the object type you expect
<ogra> well, gksu was the first app where i ran into trouble in 3 years ...
<seb128> some software will ignore incorrect values
<ogra> since it apparently does strict checks
<seb128> almost nothing uses .gconf-default
<ogra> which indeed is a good thing
<seb128> that's a debian specific things to make easy to set system defaults
<ogra> right
<ogra> which i use in edubuntu, ubuntu-mobile and the mobile team uses in ubuntu-mid
<seb128> ok so you have been lucky until now ;-)
<ogra> and i guess xubuntu does that as well
<ogra> yeah
<ogra> :)
<munckfish> Keybuk: Hi thx for your comment on LP #274860. Any idea why this  problem doesn't show up on other systems?
<ubottu> Launchpad bug 274860 in ubuntu-ps3-port "usplash doesn't run on boot on PS3 in intrepid" [High,In progress] https://launchpad.net/bugs/274860
<ogra> phew, gdm is a bad beast ... seems teher is no easy way to get cellwriter only shown in the login screen
<cjwatson> munckfish: different framebuffer drivers maybe?
<munckfish> cjwatson: hi
<munckfish> cjwatson: do you think would could just revert that debian change?
<munckfish> so that it works again?
<cjwatson> munckfish: seems like we should just revert that initramfs-tools change, yes
<cjwatson> I don't see any benefit to it
<munckfish> ok
<cjwatson> it's an optimisation, and correctness trumps that
<munckfish> ok
<munckfish> Our initramfs-tools source isn't in bzr I think
<munckfish> cjwatson: I wonder if we should revert this commit too ...
<munckfish> http://git.debian.org/?p=kernel/initramfs-tools.git;a=commitdiff;h=d377e38823d06d8e79341fba44ce8ea9c42daff6;hp=0aec8b0c22b7622841c4ab7a3b492b4d2657456f
<munckfish> as it removes the /dev/tty* setup which was done there too
<munckfish> cjwatson: comment indicates udev is expected to do that too
<cjwatson> mm, possibly
<davmor2> TheMuso: ping
 * StevenK tries to figure out how to bend find(1) to his will
<munckfish> cjwatson: ok i'll revert the fb one first if it all works without the tty one then ... so be it
<munckfish> willl attach patches to the bug once I'm done
<munckfish> cjwatson: any thoughts on the spufs one? Seems initramfs needs to bundle the spufs.ko module and explicitly load it.
<munckfish> jeremy has told me that spufs should be autoloaded by the kernel
<munckfish> but it's not in our case. I'm going to do a build with some printk in to see if I can see what's wrong
<cjwatson> I hadn't seen that bug
<cjwatson> oh, I had, just forgotten about it
<cjwatson> wouldn't be the first time we had to explicitly load a module *shrug*
<munckfish> LP #274854
<ubottu> Launchpad bug 274854 in ubuntu-ps3-port "spufs filesystem not mounted on boot" [Medium,In progress] https://launchpad.net/bugs/274854
<munckfish> There were too other bugs sort of related to the installer failing
<munckfish> because of spufs
<munckfish> I created this new one for the "on boot" version of the problem
<munckfish> cjwatson: my question would be where best to do the loading ...
<munckfish> 1) in an initramfs script, if so which package should home it? mountkernfs.sh is in the initscripts package
<cjwatson> why does it need to be loaded in the initramfs, though?
<munckfish> we could add a script to that
<munckfish> cjwatson: well this is the other thing
<cjwatson> I mean, it's being used outside the initramfs
<cjwatson> doesn't make sense for the initramfs to load it
<munckfish> it's getting mounted in mountkernfs along with /sys and /proc
<munckfish> it doesn't need to be
<munckfish> in which case the question is where and how should it be loaded?
<cjwatson> how about right before it gets used?
<cjwatson> i.e. mountkernfs
<munckfish> where does it get used?
<cjwatson> when mountkernfs tries to mount it?
<munckfish> ok I see
<TheMuso> davmor2: pong
<davmor2> TheMuso: has the login music in ubutnu been changed?
<TheMuso> davmor2: No, its just that there are two themes, the freedesktop theme and the ubuntu one, and there seems to be a weird bug where sometimes the ubuntu one is not used.
<cjwatson> munckfish: if it isn't clear, mountkernfs is run after the end of the initramfs
<munckfish> cjwatson: sorry I was just checking exactly that by extracting my ramfs
<munckfish> for some reason I thought it was bundled
<munckfish> cjwatson: anyway, so it would be easiest to modify mountkernfs.sh to do a modprobe if required
<cjwatson> providing that works
<munckfish> yep should be easy enough I'll knock that up this week
<munckfish> cjwatson: thx for your advice
<davmor2> TheMuso: yes I thing it might be to do with metacity/compiz.  I got 2 test machines and on my all intel one I get the normal ubuntu tune but on the nvidia one I get the other version (or it could be the other way around)
<TheMuso> davmor2: I think its more random than that. Most of the time when I log in I get the Ubuntu one, but occasionally I get the freedesktop theme.
<TheMuso> But thats only eover for the login sound. It has something to do with the gconf key for the theme not being loaded by the time it has to play.
<TheMuso>  /c
<cjwatson> asac: see bug 268005 for an interesting test case for n-m/ifupdown interaction
<ubottu> Launchpad bug 268005 in network-manager "live cd from nfsroot breaks the nfs mount during bootup" [Undecided,New] https://launchpad.net/bugs/268005
<cjwatson> asac: if you have an alternative proposal for how casper could stop network-manager from getting in the way, I'd be interested
<asac> cjwatson: only way i see is to make the device used for nfs in initramfs unmanaged. so the bug 256054 will fix it
<ubottu> Launchpad bug 256054 in network-manager "[intrepid] new 0.7 branch ignores /etc/network/interfaces" [Unknown,Confirmed] https://launchpad.net/bugs/256054
<asac> like you said
<cjwatson> asac: right, so just what casper's doing at the moment then
<cjwatson> it does "inet manual" for it
<asac> cjwatson: is that a special image?
<cjwatson> asac: hmm?
<asac> cjwatson: thought that we dont create anything in /etc/network/interfaces
<cjwatson> asac: not by default, but if you're using the wacky boot-live-CD-over-NFS mode then we do
<asac> or are we doing that on livecd, but remove those lines when installing?
<cjwatson> and since it's done in casper it isn't copied when installing
<asac> cjwatson: right. i think booting over nfs will not work with NM at least until NM 0.8 - if ever
<cjwatson> ok, that's quite an important regression so I'd like to do something about it. What do you think is the most practical option for the live CD?
<asac> cjwatson: oh. so the install will not boot over nfs?
<cjwatson> just disable n-m altogether if you're booting over NFS/
<cjwatson> ?
<asac> cjwatson: the entries in /etc/network/interfaces should be enough. if you need something before bug 256054 is fixed you have to disable NM
<ubottu> Launchpad bug 256054 in network-manager "[intrepid] new 0.7 branch ignores /etc/network/interfaces" [Unknown,Confirmed] https://launchpad.net/bugs/256054
<asac> but that fix has to land anyway
<asac> the touch NetworkManager in "cow" workaround looks like a proper hack ;)
<cjwatson> asac: hmm, ok
<cjwatson> yeah, I was quite impressed by that hack :)
<StevenK> cjwatson: Impressed or sickened? :-)
<cjwatson> *shrug* I've seen worse
<StevenK> Heh
 * norsetto wonders if TheMuso already went to bed
<asac> siretart: yt?
<norsetto> Anybody any idea about being dropped to a busy box during boot with an error message saying a raid partion wasn't found? After doing a dmraid -ay I can proceed but the fs is mounted read-only
<siretart> asac: about to leave. what's up?
<asac> siretart: not sure if i already asked that, but what would it take to make ifupdown wpasupplicant integration use the dbus service?
<asac> or is that mission impossible ;)
<kirkland> tkamppeter: ping, regarding https://bugs.launchpad.net/ubuntu/+source/cups/+bug/276573
<ubottu> Launchpad bug 276573 in cups "P2POutputStream: write error" [High,New]
<siretart> asac: I'd think some appropriate tweaks to /etc/wpa_supplicant/functions.sh. why?
<siretart> it is written in shell, but you could call some python helper, if that would help you
<asac> siretart: does wpa_cli have a dbus variant?
<siretart> asac: wpa_cli does not deal with dbus. wpasupplican does, AFAIUI
<asac> siretart: hmm. isnt wpa_cli the command line tool to send instructions to wpasupplicant (which could listen on socket or dbus)
<siretart> asac: wpasupplicant does already listen on a socket. that's what wpa_cli is using
<siretart> jouni isn't that in favor of dbus, but favors a custom protocol
<asac> yeah. right. thats why i would think that teaching wpa_cli to speak dbus instead of socket would make it easy :)
<siretart> dan is pushing the dbus interface AFAIUI
<asac> ok
<siretart> asac: I don't see what that would buy you
<siretart> perhaps you should talk to Dan about this
<siretart> you seem to be in good contact with him anyways
<siretart> anyway, need to run now. cu!
<asac> siretart: thanks cu
<asac> siretart: it would buy us that ifupdown would just work (TM) with dbus activated supplicant :)
<MacSlow> what causes an error like this: "** (gdm-binary:6390): Warning **: Failed to acquire org.gnome.DisplayManager: Connection ":1.950" is not allowed to own the service "org.gnome.DisplayManager" due to security policies in the configuraion file"
<MacSlow> Missing some dbus- or pk-config-file there?
<tedg> MacSlow: Yeah, I'd also guess that perhaps there are two GDMs running?  Someone already has the name.
<tedg> MacSlow: I realize that's not what the error says, but that would cause being unable to own the name also.
<MacSlow> tedg, on my intrepid-box it was missing /etc/dbus-1/system.d/gdm.conf
<munckfish> cjwatson: re LP: #274860. Reverting just that one initramfs commit did the trick. usplash is working again on PS3. Is it too late to get that one included for the beta?
<munckfish> https://bugs.launchpad.net/ubuntu-ps3-port/+bug/274860
<cjwatson> munckfish: too late for beta, but it can be queued up for right afterwards
<ubottu> Launchpad bug 274860 in ubuntu-ps3-port "usplash doesn't run on boot on PS3 in intrepid" [High,Fix committed]
<munckfish> cjwatson: ok understood. Anything I need to do make sure it doesn't get missed (other than bug you on here)?
<cjwatson> munckfish: ps3 can't release with beta anyway since linux-ports-meta isn't in yet
<munckfish> cjwatson: doh!
<cjwatson> munckfish: I'll do it right now
<munckfish> cjwatson: still not in?
<munckfish> So there won't be a PS3 beta
<cjwatson> no, it was uploaded, but all the package names were wrong
<munckfish> doh (weeps ....)
<jg> superm1: rotate X crash is bug #276782
<ubottu> Launchpad bug 276782 in xserver-xorg-driver-ati "X server crashes on rotation with ATI driver." [Undecided,New] https://launchpad.net/bugs/276782
<munckfish> cjwatson: so our """beta""" will have to be the next daily build afterwards
<cjwatson> munckfish: uploaded, it'll sit in the queue
<cjwatson> munckfish: yeah, sorry
<munckfish> cjwatson: which one is uploaded?
<jg> superm1: powertop is complaining: a USB device is active 100.0% of the time: /sys/bus/usb/devices/2-2
<munckfish> ports meta?
<cjwatson> munckfish: initramfs-tools
<munckfish> oh great thx
<cjwatson> Stefan Bader is doing linux-ports-metqa
<cjwatson> -q
<munckfish> yep ok
<munckfish> cjwatson: thx
<norsetto> seb128: hi seb
<norsetto> seb128: this is the packages list I'm currently using in generating the desktop packages list: http://bazaar.launchpad.net/~norsetto/+junk/main/annotate/20?file_id=packages.list-20080929175829-yjv3cr6q0lssue9a-1
<seb128> hey norsetto
<seb128> norsetto: what is the file format?
<norsetto> seb128: csv
<seb128> norsetto: right, but the columns? the 0 and 1 value for example
<seb128> seems to be source name, upstream name, something, usual uploader, watch?
<norsetto> seb128: ubuntu package name, upstream package name (if different), blacklist (0 will download from ftp.gnome.org, 1 will not), maintainer, watch line
<norsetto> seb128: yes, that something is if you don't want to consider the package in ftp.gnome.org (for instance gimp, or ubuntulook)
<seb128> norsetto: I'm wondering if we should not simply have watches for everything, we need at least a way to specify the serie we are tracking
<norsetto> seb128: for the series its a command line argument
<norsetto> seb128: --gnome 2.24 or --gnome 2.25 etc.
<seb128> norsetto: well, we need that in the file, because we might track gdm 2.20.n
<seb128> norsetto: and libcairo 1.7 and pango 1.23
<norsetto> seb128: in that case you simply add the correct watch file
<norsetto> seb128: and you blacklist ftp.gnome.org for those packages
<seb128> norsetto: ah, that makes sense, so 2.24 by default and we overwrite those where we need a different version
<norsetto> seb128: yep
<seb128> good
<seb128> we should probably move that somewhere in the ubuntu-desktop or desktop-bugs bzr
<norsetto> seb128: that would be cool
<nxvl> norsetto: what's the idea behind that list?
<norsetto> nxvl: to generate this: http://norsetto.890m.com/desktop_packages.php
<seb128> norsetto: let me ask on #ubuntu-desktop if people have an opinion on the bzr to use
<nxvl> nice
<nxvl> mathiaz: ^^
<Laney> norsetto: What about "last Ubuntu uploader" and "number of open sponsorship bugs"?
<Laney> Or some kind of indicator that there are bugs awaiting sponsorship
<seb128> Laney: the first column has the usual uploader
<Laney> seb128: I see that, but it's not filled in very much. Or can we assume that if there is nobody there then it's free for anyone to do?
<norsetto> Laney: if you give a bug number in the comment field, you will get a link through the package name, othewrise that will point to the relative sponsoring queue for bugs on that package
<MacSlow> pitti, can I bother you a bit with ConsoleKit-related questions?
<seb128> Laney: right that's the idea
<Laney> norsetto: I'm just thinking that it might make it easier for sponsors if there was a way to scan down the page and see if there is anything pending. Maybe use the LP API to colour the links or something?
<pitti> MacSlow: what's up?
<seb128> Laney: the page is still under work, we will file informations
<Laney> seb128: I know, just giving you guys suggestions :)
<seb128> ok ;-)
<seb128> this page is mainly for tracking versions
<Laney> Personally I'd always be wary of doing an update without pinging someone first, hence the last uploader field.
<seb128> I think we should rather use harvest or similar to track sponsor request, etc
<MacSlow> pitti, I wonder if $PREFIX/sbin/ck-log-system-restart & Co are meant to be called directly via a terminal
<MacSlow> pitti, I'm trying to figure out why my graphical-greeter isn't able to trigger a reboot or shutdown
<norsetto> Laney: I can add a last uploader if its required, but note that its just one click away now
<seb128> Laney: consider #ubuntu-desktop as being the contact when nobody is specifically listed, maybe that should be mentionned somewhere on the page too
<pitti> MacSlow: ck-*log*-? that won't actually restart
<MacSlow> pitti, I understood taht to be logging also ... not only logging
<pitti> MacSlow: gdm should use the d-bus calls
 * Laney nods
<MacSlow> pitti, that's what I do in my greeter... but nothing happens
<pitti> MacSlow: what's the result of the call, PermissionDeniedByPolicy or so?
<pitti> MacSlow: did you try in a terminal with dbus-send? do you have a CK session (ck-list-sessions)?
<MacSlow> pitti, I don't know... there's nothing logged
<MacSlow> pitti, dbus-send ... uff... what a monster
<MacSlow> one sec
<pitti> MacSlow: hm, I'm not actually sure which d-bus call is used for reboot/shutdown
<pitti> MacSlow: there's Restart() and Stop(), not sure what they do (I don't want to reboot right now)
<norsetto> seb128: what about adding: "If no usual updater is listed, consider pinging the last updater or #ubuntu-desktop." ?
<pitti> MacSlow: you can use d-feet :)
<pitti> MacSlow: nice interactive d-bus browser
<MacSlow> pitti, I'll try to salvage the needed dbus-path/interface from the sources
<pitti> MacSlow: f-u-s-a and gnome-session do the same CK calls, so shouldn't be hard
<seb128> norsetto: looks good
<pitti> MacSlow: give a try to d-feet first, that's much easier, and once it works, you can copy&pate the object paths from it
<norsetto> seb128: added
<seb128> norsetto: thanks
<norsetto> seb128: welcome, I really hope this tool can be usefull
<seb128> norsetto: no doubt about that, it's already useful now since it lists things which are not update and that we need to update after beta
<seb128> norsetto: we are doing quite ok looking at the list ;-)
<norsetto> seb128: cool :-) let me know if you get any problem, I'm sure there are still bugs lurking somewhere
<amikrop> Could anybody suggest my a Python package that uses distutils and cdbs, and another which uses distutils and debhelper, to study, please?
<amikrop> * me
<ion_> Heh. It seems like every time i look at this window, thereâs a âsuperm1 is now known as superm1|awayâ on the screen.
<bdmurray> tedg: I've updated bug 261084 for you, let me know if I didn't get what you needed
<ubottu> Launchpad bug 261084 in gnome-power-manager "Suspends again right after resume" [High,Confirmed] https://launchpad.net/bugs/261084
<tedg> bdmurray: Hmm, so the code that was stopping you from unplugging your laptop and then doing suspend, which got removed, was probably hiding a debounce issue.
<tedg> bdmurray: Seems silly that GPM should have to debouce keys.
<s0u][ight> what module is used for hotkeys?
<s0u][ight> or better: keyboard shortcuts
<bdmurray> tedg: what code?
<pitti> ogra: you recently added 10-samsung-Q1-keymap.patch to hal-info; that isn't upstream yet, can you please send it to the hal list?
<tedg> bdmurray: GPM used to have a mis-feature that it wouldn't allow power events to happen within a couple seconds of each other.  Supposedly this was to avoid breakage on some obscure laptops.  The result of that was that if you unplugged your power adapter and then closed the lid your computer, it wouldn't suspend.  That code was removed.  But it seems that it was likely hiding this debounce issue.
<bdmurray> tedg: there's always something exciting
<tedg> It's still odd to me that a computer would have a suspend button.  I mean, isn't that what the monitor is for?  Seems PC manufacturers get paid by the LED/Key.
<cjwatson> tedg: if the computer and monitor were integrated, like Apples did ...
<bryce> bah, who needs monitors?
<liw> all the geeks who otherwise don't get a tan
<tkamppeter> kirkland, hi
<kirkland> tkamppeter: hey, hit a cups regression, was trying to debug
<tkamppeter> kitkland I have seen your bug report
<kirkland> tkamppeter: k ...  the gutenprint driver works for me
<tkamppeter> kirkland, it is most probably not CUPS, but the driver, HPLIP.
<kirkland> tkamppeter: ah, right
<tkamppeter> kirkland what you should do is at first to update to the current state of Intrepid.
<kirkland> tkamppeter: i'm already there ;-)
<tkamppeter> Then start system-config-printer and there call the troubleshooting wizard in the Help menu.
<kirkland> tkamppeter: cool, i'll do that
<tkamppeter> This sets CUPS to debug log mode and coillect a lot of useful info in one text file.
<tkamppeter> Before starting the wizard, have a print queue handy which uses the default driver, where the bug occurs.
<kirkland> tkamppeter: k
<tkamppeter> You do not need to try with the Generic PostScript driver any more, as your printer is not a generic PostScript printer.
<kirkland> tkamppeter: ;-)  right
<kirkland> tkamppeter: that was my second attempt to get something to go to the printer
<tkamppeter> when you reach the step of the wizard where you get asked for printing something, print a job which causes the bug.
<kirkland> tkamppeter: shortly after "telnet officejet 9100; asdfasdfasdfashjas;dihfwjfnaskdjf"
<kirkland> :-)
<kirkland> k
<tkamppeter> To get data sent to a network printer so that the printer prints it, you must do
<tkamppeter> nc -w1 <IP> 9100 < <input file>
<tkamppeter> Perhaps also the telnet works. The text must have an end-of-page in the end to let the printer print the plain text page.
<tkamppeter> Now back to the wizard. Doing investigations with the wizard only works if you send the job through the queue with the broken driver, so that the errors of the job get captured in the error_log of CUPS.
<kirkland> tkamppeter: nah, the telnet just sent it garbage, but it proved i could talk to it over 9100
 * kirkland changes the driver back to the hplip foomatic
<kirkland> foomatic/hpijs
<tkamppeter> When the job has finished (or got stuck) then you complete the wizard which generates a file. This file please attach to the bug report.
<tkamppeter> Riddell, have you already ported the troubleshooting wizard of system-config-printer to the KDE version?
<kirkland> tkamppeter: the troubleshooter error messages dialog shows: http://pastebin.ubuntu.com/52894/
<tkamppeter> kirkland, nothing else? Therer must be other messages before that concerning the Job 59.
<kirkland> tkamppeter: i just attached the troubleshoot.txt to https://bugs.launchpad.net/ubuntu/+source/cups/+bug/276573
<ubottu> Launchpad bug 276573 in cups "P2POutputStream: write error" [High,New]
<bdmurray> tedg: when did this change happen?
<kirkland> tkamppeter: shall I'll move the bug from 'cups' to 'hpijs' ?
<Riddell> tkamppeter: no
<\sh> can someone let ia32-libs*ubuntu15 go through the buildds pls?
<\sh> will be up on ftp. in no time
<tkamppeter> kirkland, yes.
<kirkland> tkamppeter: done
<tkamppeter> Riddell. the troubleshooting wizard is very useful.
<tkamppeter> Riddell, what about s-c-p-kde in general, will it be the default printer setup tool in Intrepid? Now where KDE Printing Manager is gone?
<tkamppeter> kirkland, it seems that the troubleshooting wizard did not cope well with your job. the piece of error_log it supplied did not help much.
<kirkland> i just printed a test page...  should i print something more complex?
<tkamppeter> Please do the following: In s-c-p, select "Settings" in the "Server" menu and activate the debugging info (last checkbox).
<tkamppeter> kirkland, then print a job, the test page is enough.
<tkamppeter> Or better, to make sure that all works right, do "cancel -a" before sending the job.
<tkamppeter> After your new job is ready or stuck, copy the /var/log/cups/error_log to your home directory.
<tkamppeter> Open the copy with an editor and look for the last occurrence of "P2POutputStream: write  error".
<tkamppeter> Look for the [Job xx] signature in this line and then go back to the first line with this job signature. Go some more lines back to see the two [Job ??] lines.
<kirkland> tkamppeter: better error log posted to https://bugs.launchpad.net/ubuntu/+source/hplip/+bug/276573
<ubottu> Launchpad bug 276573 in hplip "P2POutputStream: write error" [High,New]
<tkamppeter> Delete all before these lines and save.
<Riddell> tkamppeter: yes, s-c-p-kde is the printer setup tool we're using, it misses quite some features still but the basics are there
<tkamppeter> Riddell, can PPD option defaults (PageSize, input tray, ...) be set?
<tkamppeter> kirkland, I have found the problem, see the line
<tkamppeter> D [01/Oct/2008:11:36:06 -0500] [Job 61] Could not create temporary file: Permission denied
<kirkland> tkamppeter: yup
<kirkland> tkamppeter: what is that path, where it can't create the temp file?
<Riddell> tkamppeter: not yet I'm afraid
<tkamppeter> It seems CUPS stopped setting the TMPDIR variable. I will add a foomatic-rip task asking to support this case.
<tkamppeter> kirkland, this requires a fix in CUPS or a compatibility enhancement in foomatic-rip, I think the latter is easier to do for Intrepid (there I am upstream).
<kirkland> tkamppeter: nice ;-)
<kirkland> tkamppeter: my wife says she's excited that she found a "real bug"  :-)
<radix> mathiaz: sorry for bugging you, but we have another source bug fix in landscape-client, this one much smaller than the last: Bug #260230
<ubottu> Launchpad bug 260230 in landscape "sysinfo disk plugin prints unnecessary warnings about the / device when over capacity" [Critical,Fix committed] https://launchpad.net/bugs/260230
<radix> I've already done the upstream release and prepared the branch for the debian update
<mathiaz> radix: ok - could you look at lp:~ubuntu-core-dev/landscape-client/ubuntu ?
<radix> mathiaz: sure, that's the branch I based mine on
<mathiaz> radix: I merged a fix from kirkland yesterday
<mathiaz> radix: great !
<radix> mathiaz: oh, you want me to review that change?
<radix> mathiaz: I think I already did, but I'll check the branch to make sure it's the same
<mathiaz> radix: ok - it adds a timestamp to the -sysinfo wrapper
<radix> mathiaz: yep, that's the change I already reviewed, looks good
<radix> ok, lunch time
<tedg> bdmurray: In the Intrepid cycle, I don't remember the version exactly.
<tedg> bdmurray: We actually discussed distro patching it at UDS, and then upstream did it :)
<bdmurray> tedg: you think it is in g-p-m now though?
<tedg> bdmurray: Correct, currently it does not suppress duplicate events.
<tedg> bdmurray: So I think we now need to add code to debounce the keys.
<tedg> bdmurray: Or, perhaps it would be better to just clear all keys entered before a suspend.  Hmm, not sure how to do that one.
<ScottK> slangasek: Due to being briefly included in kdepim, kmobiletools got binary promoted to Main.  I just did an upload (not noticing that).  It needs to get demoted to Universe and then accepted if you would ...
<slangasek> ScottK: kmobiletools is still a recommends: of kubuntu-desktop in the archive and in the seed; how does an upload of kmobiletools change any of that?
<hwilde> hello, how can I bypass the graceful shutdown and make it just die when the power button is pressed?  (without disabling acpi)
<johanbr> hwilde: edit /etc/acpi/events/powerbtn
<johanbr> Or rather, the shell script that it calls.
<hwilde> hmm
<hwilde> it calls /etc/acpi/powerbtn.sh
<hwilde> that just says
<hwilde> /sbin/shutdown -H now "Power button pressed"
<hwilde> but why does it take 7-9seconds
<hwilde> I want it to shutdown -H now
<slangasek> shutdown changes the runlevel, for a graceful shutdown
<slangasek> you could do 'poweroff -f' instead, I guess
<slangasek> not that this is good for your data integrity
<hwilde> yeah i know i know
<hwilde> :/
<hwilde> not good for the electrical system if people expect immediate shutdown
<hwilde> then they start hitting the button repeatedly and power flickers
<bdmurray> \sh: you mentioned a new ia32-libs upload does that fix bug 271550?
<ubottu> Launchpad bug 271550 in ia32-libs "ia32-libs missing libQtDBus, others?" [Unknown,Fix released] https://launchpad.net/bugs/271550
<slangasek> hwilde: if the button is under ACPI control, how does hitting it repeatedly cause the power to flicker? :)
<ogra> its probably a special button that accumulates the shutting down ... and in the end you shut down your whole house/office, who knows
<norsetto> bryce: re. bug 177658, I'm currently unable to boot into intrepid, so, can't help I'm afraid
<ubottu> Launchpad bug 177658 in xserver-xorg-driver-ati "[hardy] Blank GDM screen with ATI R420 [X800XT PE]" [Unknown,Confirmed] https://launchpad.net/bugs/177658
<tedg> hwilde: "kill -9 0"
<hwilde> tedg heh
<hwilde> poweroff works good
<bryce> norsetto: ok thanks for letting me know
<tedg> bryce: Is the "X not finding HAL" issue an already reported bug?
<bryce> norsetto: could you comment onto the bug to this effect, so we can keep it open until you're able to boot?  Else since it's been a while since you commented someone might close it inadvertantly
<norsetto> bryce: sure
<bryce> tedg: m, not sure.  what in particular is the problem?
<ion_> tedg: LP #275825
<ubottu> Launchpad bug 275825 in hal "After an upgrade to intrepid, HAL prefers old fdi-cache to new FDI files" [High,Confirmed] https://launchpad.net/bugs/275825
<bryce> tedg: in general it doesn't hurt to file extra bugs; duping is cheap
<tedg> bryce: Boot up, in GDM but not keyboard or mouse activity.  Then I can drop to a console, restart X, and everything is happy-happy again.  But it's annoying to do that after every reboot.
<tedg> bryce: The problem is that X doesn't find HAL, and so it thinks there are no input devices.
<ion_> Oh, if restarting X makes it work, itâs probably a different bug.
<hwilde> tedg, /etc/rc.local   sleep 5 && /etc/init.d/gdm restart   :)
<bryce> tedg: is this after an upgrade or a fresh install?  If it's after an upgrade then yeah sounds like the bug ion pointed to
<ogra> "doesnt find" ?
<tedg> bryce: So X needs to listen on DBus for when HAL comes on.
<tedg> ogra, I'm guessing it hasn't started to the point of publishing a name on DBus yet.
<bryce> tedg: I've not seen that issue myself on any of my machines, but go ahead and file a bug on it.
<tedg> bryce: It was much worse with nvidia drivers 177, better with 173.  I guess the 177 ones are faster ;)
<ogra> probably gdm needs a later bootsequence number (until we have full upstart) sounds hard to implement ot make X listen on dbus
<bryce> tedg: oh this is with -nvidia, hmm
<bryce> tedg: can you reproduce the issue with -nv or -vesa?
<tedg> ogra, well it's already listening on DBus to get device insertions.  It is just a matter of adding listening for DBus name change events.
<tedg> That is, if I'm correct in assessing the problem :)
<ogra> oh, i wasnt aware, i thought it leaves that part completely to hal
<tedg> It does, but HAL reports that as a dbus signal.
<tedg> bryce: I can try.  Painful drivers those be.  I can't think of a time it's happened with bulletproof X though.
<tedg> bryce: Which seems to come up on every kernel upgrade.  I'm unsure why DKMS isn't rebuilding my modules -- but I haven't looked into that at all.
<tedg> bryce: BTW, nice work on the new menu system there.  Lots more useful stuff, I was playing with it last kernel update :)
<bryce> tedg: thanks
<bryce> tedg: yeah I have a system that's been failing to rebuild a module for a while too; haven't had a chance to investigate
<superm1> tedg, bryce generally if you are missing the matching -headers package for a kernel
<superm1> but the latest meta should always be pulling them in
<mdz_> I'm finding both gb.archive and cdimage very slow at the moment; is that true for others as well?
<Laney> mdz_: I've been finding archive very slow - from 2200K/s (my limit) to ~100K/s in the last two days
<Laney> dont' know if that's related
<kees> ieeee hyptonic brown poka-dot spiral!
<Nafallo> kees: sounds like a new exploit ;-)
<norsetto> seb128, slangasek: should I raise an FFe for totem 2.24.1? It fixes 2 bugs + 1 typo.
<slangasek> norsetto: typoes are also bugs, so that doesn't sound like there are any new features that need excepting
<norsetto> slangasek: ok, thx for confirming
<kees> Nafallo: "must ... install ... malware"
<Nafallo> lol
<Nafallo> kees: that's better than "must ... upload ... ubuntu" :-)
<hwilde> I love ubuntu :)
<\sh> bdmurray: the problem was libqt4-{core,gui} -> has no content then "transitional"...I fixed that now again
<bdmurray> \sh: okay, great!  I just hadn't seen the bug updated but saw you mention a new package here
<\sh> bddebian: libqt4-dbus etc. were included in -14...but I wasn't realizing that half of the packages of libqt are now named differently
<\sh> it should be working now..(at least I hope so)
<bddebian> Sweet thanks. ;-P
<kirkland> jcastro: yo, i linked as many virt-manager bugs to upstream bugs in rh/fedora as i could
<bryce> slangasek: just a heads up, I have some patches for -ati pending independent validation
<bryce> slangasek: all patches are cherrypicked from upstream and correspond to LP bugs.  Just waiting on testing confirmation that they do fix the issues.  http://www.bryceharrington.org/ubuntu/Ati/xserver-xorg-video-ati_6.9.0+git20080826.a3cc1d7a-2ubuntu4~bwh2.debdiff
<ScottK> slangasek: Urgh.  I'll work with Riddell on seeds then.
<gggggig> hi
<gggggig> What's the best way to produce a deb from a ruby script?
<stgraber> Who should I talk to for weird udev behavior ?
<jcastro> kirkland: thanks for that, it's no longer at the bottom. :D
<kirkland> jcastro: \o/
<gggggig> A question for packaging a deb
<gggggig> plz
<jcastro> kirkland: in cases where you're sure it's upstream but there is no corresponding bug, you can open an upstream task, and leave it as "I have no way to link it" - that generates a target list to upstream so we can batch submit later
<jcastro> kirkland: basically, if you can just make a determination that it is upstream I can go in and file those for you
<kirkland> jcastro: ah....  well there's a ***ton*** i can do that for
<gggggig> What's the best way to produce a deb from a ruby script?
<kirkland> jcastro: about 20+ of those are trivial gui interfacy changes that should be upstreamed
<gggggig> I used checkinstall and dpkg-deb which one is better?
<jcastro> oh, I can bust those out easily if you just mark them as you see them. :D
<kirkland> jcastro: okay, i moved onto a couple of other things at the moment, but i'll get back to it ;-)
<jcastro> no worries.
<ScottK> slangasek: I just unseeded kmobiletools, so it should demote itself eventually.
<slangasek> ScottK: ok
<henux> good evening
<henux> i am an able linux programmer and i might want to contribute into ubuntu project even thought i dont use ubuntu myself
<henux> i would just need a push to right direction from a friendly mentor
<henux> i can do C, C++, C#, Java, Python, Lua, Bash, HTML, MySQL, Javascript ...
<henux> PHP
<henux> i have used Linux for many years and i have contributed to some open source projects before
<slangasek> ok, now come on, why did you even admit that last one :)
<slangasek> what is it you're hoping to contribute?
<henux> i dont know
<henux> anything
<henux> which involved programming
<henux> *involves
<henux> im from Finland
<henux> its actually the middle of the night here
<henux> i think i would like to start from small stuff
<henux> then if it goes well, go into bigger stuff
<henux> i dont expect to be paid or even thanked for
<slangasek> henux: well, there's a list of bugs that have been marked as 'bitesize', implying that they should be good places to get started: https://bugs.launchpad.net/ubuntu/+bugs?field.tag=bitesize
<henux> okay
<henux> i will take a look of that list
<henux> i would have to install ubuntu linux into my system to fix these
<henux> and these do not actually involve real programming, only scripting mostly
<henux> i was thinking if there were actually any small tools perhaps which the ubuntu community would need and i could do
<henux> but i will nonetheless take a look of these ...
<heno> *** New desktop images are appearing on http://iso.qa.ubuntu.com - any testing help would be appreciated! ***
 * Ng blinks at console-kit-daemon having 1024 file handles
 * slangasek blinks as well, and wonders if that hints at the cause of the fclose() crasher bug
<Ng> it's all /etc/ConsoleKit/run-session.d and /usr/lib/ConsoleKit/run-session.d over and over and over
<ogra> stop using your console :P use X
<slangasek> ogra: er?
<slangasek> only 199 fds here, but yes, definitely leaking
 * ogra is making silly jokes ...
<ogra> tedg, do you have a bug about the broken g-p-m icon ? (its not showing AC status at all here, i always have a battery)
<tedg> ogra, I haven't see one about the icon broken 100%, but there is a preference that it'll hide when there is no action.  Do you have that set?
<slangasek> ogra: have you restarted g-p-m lately?  there was a bug last week about the icon not reflecting reality
<ogra> no, i use my icon in tablet mode on my laptop, so i have it always on
<ogra> (i use it for suspend)
<ogra> slangasek, well, i think i rebooted after the last upgrade
<Ng> hmm, I'm seeing the last thing ogra is
<slangasek> ok, well, I can confirm a bug that fits that description in the previous g-p-m, and it's fixed for me in the current one
<Ng> I noticed the other day that it wasn't updting to reflect AC changes well enough
<slangasek> -0ubuntu3, uploaded 29Sep
<ogra> it might be a theme issue though
<ogra> i sse it right on ubuntu-mobile where i use the gnome theme
<ogra> (human doesnt scale properly on 48px panels)
 * Ng stabs it in the TERM
<Ng> since it's possible I've not restarted with the new one
<slangasek> Ng: facile bug in console-kit's directory iteration; thanks for noticing that, I wonder if that doesn't fix bug #263245
<ubottu> Launchpad bug 263245 in consolekit "console-kit-daemon crashed with SIGSEGV in fclose()" [Medium,In progress] https://launchpad.net/bugs/263245
<Ng> slangasek: np :)
<Ng> hmm, should just killing g-p-m and re-running it be enough? doesn't seem to have helped
<Ng> it showed the correct status to begin with, but didn't change when I plugged AC in
<slangasek> yeah, that was enough to fix it for me
<ogra> Ng, kill it, run the power preferences
<ogra> that will start it again
<ogra> and as i just saw that resets your gconf preference
<ogra> so the icon is only shown on battery again
<ogra> meh, why does it reset
<Ng> it still doesn't seem to be updating the icon properly
<ogra> no, it doesnt
<ogra> it properly switches to battery if i unplug AC
<ogra> but doesnt switch back
<ogra> yup, not a theme issue, i see the same on ubuntu-mobile
<ogra> oh, no, its just slow there
<ogra> works with the gnome theme, just takes about 5 sec
<Ng> it was slow to switch to battery, but after it did that and I put AC back in it's not changed the icon
<Ng> and that was about a minute ago
<ogra> yeah
<ogra> same here on my laptop with human theme
 * ogra tries to switch themes on the laptop
<wgrant> Ng, ogra: It freezes for me for 42.5 seconds on an AC state change - but then recovers after that timeout.
<tedg> Ng: If you put your mouse over does it say that it's on AC?
<Ng> tedg: yep
<Ng> tedg: and if I bring up the full battery info it's correct
<ogra> tedg, same here, its only the icon
<wgrant> .
<wgrant> Er.
<wgrant> Oh.
<ogra> but switching themes didnt change it on the laptop
<ogra> i wonder why it works on ubuntu-mobile
<thvdburgt> I have a problem with launching matlab, using gnome-termal it works, but when I use ALT-F2 or a launcher it does not, it only shows the splash screen for half a second and disappears. I asked allready in ubuntu+1, but no-one was able to help, maybe someone here knows what is going on?
 * ogra points thvdburgt to #ubuntu-motu
<wgrant> ogra: Uh? NO.
<Ng> slangasek: do you want a bug about the consolekit thing btw?
<ogra> wgrant, ?
<wgrant> ogra: We are not support for proprietary software in there.
<ogra> wgrant, but motu packages it, no ?
<slangasek> Ng: I am assuming, with no evidence whatsoever, that it's the same as bug #263245
<ubottu> Launchpad bug 263245 in consolekit "console-kit-daemon crashed with SIGSEGV in fclose()" [Medium,In progress] https://launchpad.net/bugs/263245
<wgrant> ogra: MATLAB is an expensive inverse clone of Octave.
<ogra> wgrant, oh, right, i thought we had it in multiverse, sorry
<wgrant> We have Scilab.
<ogra> and octave
<wgrant> Right.
<wgrant> Scilab is the one in multiverse (though it won't be there much longer)
<ogra> right, i reviewed it once for edubuntu
<thvdburgt> wgrant, I understand you do not suport matlab, but you might be able to tell what the difference is between launching via a launcher or via a terminal
 * wgrant has no clue about that.
<slangasek> the difference is whether your process has a terminal
<thvdburgt> using the same command I expected the same result
<Ng> slangasek: on the basis that I know virtually nothing about consolekit, fair enough ;)
 * Ng looks for the g-p-m one instead
<Ng> slangasek: (fwiw c-k-daemon hasn't crashed on the machine I noticed it on, it's just erroring any time something asks it to do something)
<slangasek> Ng: pff, facts
<Ng> haha :)
 * ogra really doesnt get why he is seeing g-p-m DTRT on a samsung Q1 with ubuntu-mobile while it fails on the laptop
<wgrant> ogra: does it ever update the icon on your laptop?
<wgrant> Does anybody know why consolekit is reluctant to switch to a non-X VT the first couple of times it is tried?
<wgrant> The screen goes black, but then it jumps straight by to VT7.
<wgrant> Er, straight *back*.
<slangasek> haven't seen this
<wgrant> slangasek: It's easily reproducable for me.
<bryce> wgrant: I've seen that
<bryce> brb rebooting
<ogra> wgrant, nope
<ogra> it stays on battery
<wgrant> ogra: Huh. As I said above, mine hangs for 42.5 seconds (no tooltip, no context menu, tray icon doesn't rerender, etc.), but then it's perfect.
 * Ng confirms bug 275855
<ubottu> Launchpad bug 275855 in gnome-power-manager "on charge/discharge icon doesn't change" [Undecided,Confirmed] https://launchpad.net/bugs/275855
<ogra> wgrant, i have a proper tooltip and proper notificaions
<ogra> just the icon doesnt change
<ogra> i'll leave it on battery for a while to see if it shows the power state
<wgrant> slangasek: It seems that once it lets me change, it'll be OK for a few minutes. But after those few minutes it will be reluctant again.
<wgrant> Both of my g-p-m bugs seem to be brightness-related hangs, but I'd still expect to see your bug...
<slangasek> I don't know; it worked fine for me, other than the fact that it borked the permissions on my sound devices, woohoo
<wgrant> slangasek: Any hints on how to debug it?
<ogra> wgrant, dbus-monitor might help
<ogra> and the debug ode of g-p-m
<wgrant> ogra: I was speaking of the VT switching stuff, actually.
<ogra> oh, sorry
<wgrant> I've commented with the g-p-m debug log snippets on my bug, though.
 * ogra is talking in several channels
<slangasek> ah, and now I've tried to switch vts again and my machine has locked up
 * slangasek glares at wgr
<slangasek> wgrant, too
<wgrant> slangasek: Oh, lovely!
<slangasek> locked up hard, it doesn't ping anymore
<wgrant> Niice.
<ogra> woah
<wgrant> Wow.
<superm1> wgrant, re bug 261721, what machine you doing this on?  I've seen it a few times too, but i haven't been sure where to blame it
<ubottu> Launchpad bug 261721 in gnome-power-manager "LCD brightness OSD steals keyboard focus" [Undecided,New] https://launchpad.net/bugs/261721
<wgrant> superm1: It's a Dell Inspiron 630m.
<wgrant> I presume it's separate from (but made more noticable by) the hanging bug.
<superm1> wgrant, interesting.  i wonder if gpm is making too many smbios calls
<superm1> or moreover calls to the hal daemon for dell backlights
<superm1> if you kill of hal-addon-dell-backlight, do they persist?
<wgrant> superm1: In one case it makes what appears to be one 42.5 second call, in another (using brightness keys) it seems to receieve the events thousands of times.
<superm1> wgrant, looking over the time frame of when you started to see this, that bodes about when i was seeing it too
<wgrant> superm1: It still steals focus for ever, I think, but it doesn't hang.
<superm1> and VT switching was the only solution; same assertion I had
<wgrant> (I without hald-addon-dell-backlight running, I can now get a tooltip from the tray icon - before I couldn't)
<wgrant> s/I //
<wgrant> superm1: What hardware are you on?
<superm1> wgrant, this is unreleased hardware, but Dell hardware too
<superm1> which is what made me think gpm is calling that hal daemon too much
<wgrant> Ah.
<wgrant> Bug #261724
<ubottu> Launchpad bug 261724 in gnome-power-manager "Brightness OSD doesn't stop adjusting" [Medium,New] https://launchpad.net/bugs/261724
<superm1> it's hard to provide a useful data point with unreleased hardware though unfortunately
<superm1> (no stable BIOS yet etc)
<kees> can an archive admin please pocket-copy openssh from -security to -updates? (and anything else outstanding too?)
<wgrant> I'm away from AC power right now, but I'll try the state change without hald-addon-dell-backlight in a few minutes.
<superm1> wgrant, well fwiw, even without the hal daemon running, i can reproduce the really slow changing and loss of focus that's only recoverable from a VT switch
<wgrant> superm1: When you do what? Brightness keys, or AC state change?
<slangasek> TheMuso: same problem as before with PA, after a reboot; I suspect a race condition due to the new sound theme
<superm1> wgrant, brightness keys
<wgrant> superm1: Right.
<wgrant> OK, even without hald-addon-dell-backlight it hangs for 42.5 seconds when trying to set the brightness on startup or AC state change...
<superm1> i dont have the proper batteries for these machines, so I can't test an AC state change without the machine going down :)
<wgrant> Doing this:
<wgrant> TI:08:50:56	TH:0x8d7b640	FI:gpm-brightness-xrandr.c	FN:gpm_brightness_xrandr_output_set,324 - hard value=15125, min=0, max=15125
<wgrant> superm1: I just realised that I can see it on starting up g-p-m too.
<superm1> between this and the loss of my power button turning the machine off, i'm really not happy with gpm in intrepid right now :(
<wgrant> It's the only thing that's giving me trouble, but it's giving me lots of trouble.
<ogra> superm1, why do you blame g-p-m fo ryour power button ?
<superm1> that's what the bug triagers set it to
<ogra> not gpm's fault
<bryce> the power button is probably acpi not gpm
<ogra> yeah
<wgrant> g-p-m's preferences dialog is the one with the option for what to do when the power button is pressed.
<superm1> ogra,  bug 252795
<ogra> gpm is a silly frontend ... its either hl or acpi in the kernel
<ubottu> Launchpad bug 252795 in fedora "pressing the "Power" button shows a logout dialog" [Unknown,In progress] https://launchpad.net/bugs/252795
<superm1> the button itself works
<ogra> superm1, heh, thats gnome-session
<superm1> but the wrong dialog comes up now
<wgrant> I can never remember whether it's gnome-session or gnome-panel.
<ogra> on (upstreams) purpose
<wgrant> ogra: Or is g-p-m invoking the wrong one?
<ogra> no, its gnome-session
<ogra> upstream made that change
<superm1> to make the logout dialog come up when pressing the power button?
<ogra> yeah
<superm1> sorry, but that makes no sense?
<slangasek> Ng: well, of course I installed the package with the fd leak fixed before my laptop hung, so now it won't tell me whether my guess was right about the fd leak being connected to the crashes :)
<superm1> i want to turn off the computer so i press the power button
<TheMuso> slangasek: Right, I'll dig into it. I don't see it at all here, but I can probably put something in place to make sure things sort themselves out cleanly.
<ogra>  /apps/gnome-session/options/logout_option
<ogra> change it :P
<slangasek> TheMuso: ok.  It really does seem to be the case that PA never tries again to open the device, after the initial failure
<Ng> slangasek: doh!
<wgrant> superm1: Any idea why g-p-m seems to be trying to use xrandr to change my brightness, and failing? Do you see that too?
<slangasek> xrandr controls brightness?
<Ng> slangasek: I cheekily snuck it in as a new bug anyway, just in case it's not a dupe. I'm not sure how to reproduce it, but both my intrepid installs show it and have <2days uptime, so I guess it wil rear its head again if that doesn't fix it
<wgrant> It's calling gpm_brightness_xrandr_output_set, so I presume so
<wgrant> Or maybe it's changing the brightness of an xrandr output.
<slangasek> Ng: how to reproduce the fd leak?  Trivial: let cron run
<superm1> ogra, changing that option to shutdown and logging back in didn't appear to change the behavior when pressing the power button.  you sure it's the same thing?
<ogra> wgrant, btw, my battery seems to reflect the loss of power in the icon
<ogra> i'm at 89% and i see the icon has changed
#ubuntu-devel 2008-10-02
<wgrant> ogra: Interesting...
<wgrant> ogra: Default theme?
<ogra> superm1, yes, its a bug in gnome-session not bringing up the other dislog
<superm1> wgrant, i'm not sure what that actually means when it is calling that function
<ogra> *dialog
<Ng> slangasek: ah
<wgrant> superm1: I'll check the source.
<ogra> wgrant, nope, still the gnome theme, lets see, i'll change it
<ogra> wgrant, well, human has the right icon as well atm (battery with only about 80% green)
 * ogra plugs in AC
 * wgrant waits for g-p-m to get rid of its broken brightness dialog so he can read ogra's second-last line.
<superm1> i understand theres this big push for multiuserness and fast user switching, but don't most people associate power button with turning something on and off still?
<wgrant> There we go.
<wgrant> superm1: One would think so.
<wgrant>         XRRChangeOutputProperty (brightness->priv->dpy, output, brightness->priv->backlight, XA_INTEGER, 32,
<ogra> ok, i got a popup telling me about the state change, my brightness went to 100% as well but the icon stays at 80% charged battery ... no power plug or anything
<wgrant>                                  PropModeReplace, (unsigned char *) &value, 1);
<wgrant> So it seems that XRandR does actually do backlight. That I didn't know.
<wgrant> ogra: What if you make the icon disappear and reappear?
<ogra> no change
<ogra> same icon
<superm1> randr shouldn't be doing backlight - the interface on different laptops is not necessarily a software interface
<ogra> wgrant, what i dont get is that it works flawless on a freshly installed ubuntu-mobile image and even in the usb live session on that image
<wgrant> ogra: Run g-p-m with --verbose --no-daemon, and watch for where it reassigns the icon (you'll get 'Trying SOMETHING icon', then 'got-filename: something' then '** EMIT: icon changed: something'
<ogra> i get a fresh icon if i kill it
<wgrant> superm1: Well, g-p-m thinks it can.
<wgrant> ogra: Right, but try to get it into a state where it should switch the icon while you've got verbosity up.
<slangasek> well, that appears to be the second time in 15 minutes I've done something based on comments in this channel that has kicked me out of my computer
<slangasek> since when does choosing 'log out' immediately log you out with no warning?
<wgrant> slangasek: Hahaha.
<wgrant> Since fusa became stupid.
<TheMuso> Ouch.,
<slangasek> tedg: is this intended behavior?  When I choose 'Log Out' from the system menu, I get a dialog :P
<slangasek> also, when is someone in GNOME going to care about session saving? :P
<wgrant> ogra: You can get it to recalculate the icon by changing the icon policy.
<slangasek> hmm, didn't fusa also have icons before?
<wgrant> It did.
<wgrant> It had a presence state selector.
<ogra> oh, intresting
<ogra>  - no devices critical, so no icon will be displayed.
<ogra>  - emitting value-changed : '/apps/gnome-power-manager/ui/icon_policy'
<ogra>  - key : /apps/gnome-power-manager/ui/icon_policy
<ogra>  - unknown key /apps/gnome-power-manager/ui/icon_policy
<ogra> unknown key ???
<wgrant> Um.
<slangasek> wgrant: but no icons for "Log out", "Restart", "Shut down"?
<wgrant> slangasek: I don't recall it having them... but the applet is stupid so I got rid of it for a while.
<ogra> fusa is the evil
<slangasek> hmm
<wgrant> ogra: What did you change it from/to?
<ogra> wgrant, from "never" to "always"
<wgrant> ARGH WTF
<ogra> or critical to always rather
<wgrant> g-p-m's preferences now deny I have a battery.
<slangasek> well, I'm not terribly impressed with fusa; for starters, the design only looks good if it's to the far right on the panel, and I don't want it there
<ogra> its the evil
 * ogra massively hates fusa ... but thats because he develops ltsp where it breaks the world
<slangasek> and at this point, there's duplication between the menus and the applet... dunno if that's something that should be corrected?
<wgrant> ogra: Did you get any '** EMIT: icon-changed'?
<ogra> yes, remove fusa from the default install :)
<ogra> wgrant,  - ** EMIT: icon-changed: none
<slangasek> ogra: has this plan been run past the desktop team? :-P
<wgrant> ogra: But the icon stays there?
<ogra> slangasek, i tried it in gutsy but couldnt convince them
<ogra> wgrant, right
<RAOF> Is it possible/planned for the shiny new fluendo-codec-package(s) offered on the Canonical store to be better integrated into the codec-install dialog?  By that, I mean only showing the option when a plugin from that package will actually play the offending file.
<ogra> slangasek, i was told it would be a good thing that it shows you who you are
<ogra> as if i wouldnt know that :P
<ogra> and in real multiuser setups like ltsp its just broken
<slangasek> hmm? what's broken about it?
<bryce> I updated to latest code since about a week ago; now no sound works
<slangasek> my only problems with it are cosmetic and UI-related, I think
<bryce> although it did play the login sound...
<slangasek> bryce: kill pulseaudio and restart it, I bet you have the same bug I do
<ogra> slangasek, http://lists.freedesktop.org/archives/hal/2008-October/012312.html
<ogra> that might help the file handle issue
<slangasek> ogra: I already have a fix for the fd leak; that patch is unrelated
<ogra> ah, k
<wgrant> ogra: http://pastebin.com/m221a326f is what I get when I change the policy from charging to critical.
<slangasek> the only thing I haven't proven is whether the fd leak is connected to the fclose() crash
<bryce> slangasek: ok alsamixer liked that better... firefox is unhappy... restarting
<slangasek> bryce: restarting what?
<bryce> slangasek: restarting firefox
<slangasek> ok
<bryce> cool, ok all happy now
<superm1> slangasek, yeah i'm seeing that same thing too but i have to remove .pulse* every time it happens
<slangasek> TheMuso: ^^ bryce is another candidate for testing any fixes you have :)
<superm1> is there a bug about it yet?
<slangasek> superm1: I don't know; TheMuso pointed me earlier to a report that he thought was related
<ogra> wgrant, i dont get - ** EMIT: icon-changed: none
<ogra>  - ** EMIT: icon-changed: gpm-primary-080 is what i have
<wgrant> ogra: Even if the policy is critica
<wgrant> +l?
<ogra> unplugging AC gets me:
<ogra>  - Trying CHARGING icon: primary, ups
<ogra> TI:01:25:30	TH:0x97ca640	FI:gpm-cell-unit.c	FN:gpm_cell_unit_get_icon,211
<ogra> TI:01:25:30	TH:0x97ca640	FI:gpm-engine.c	FN:gpm_engine_recalculate_state_icon,590
<ogra> yes, even then
<TheMuso> Don't you just love it when you can't reproduce these problems locally at all? :)
<bryce> fwiw, the sound volume in youtube seems a heck of a lot better now
<TheMuso> I'll get intrepid set up on one more box with another different sound card and see if that gives me the same issues.
<ogra> wgrant, after a while i get:
<ogra>  - Trying CHARGING icon: primary, ups
<wgrant> ogra: Can you pastebin a trace of just switching from charging to critical?
<ogra> TI:01:26:10	TH:0x97ca640	FI:gpm-cell-unit.c	FN:gpm_cell_unit_get_icon,211
<ogra> TI:01:26:10	TH:0x97ca640	FI:gpm-engine.c	FN:gpm_engine_recalculate_state_icon,590
<bryce> TheMuso: Indeed
<ogra> but no actual change
<superm1> bryce, are you seeing it on the same hardware that I sent you w/ the AMD 3650 graphics?
<bryce> superm1: let me check
<superm1> okay so you saw it on something different then
<superm1> initially at least
<superm1> that's where i was seeing it
<ogra> wgrant, oh i get the  EMIT: icon-changed: none, i just missed it before
<wgrant> ogra: Do you get anything relevant after that?
<ogra> http://paste.ubuntu.com/53009/
<wgrant> There's a fairly deep stack after that.
<ogra> thats gnome-power-manager --verbose --no-daemon|grep icon for changing from always to critical
<wgrant> ogra: OK. So we can be fairly sure it executes                 gpm_tray_icon_show (icon, FALSE);
<bryce> superm1: nope, that laptop's sound is working fine with today's updates
<wgrant> WHich does this:
<wgrant>         g_return_if_fail (GPM_IS_TRAY_ICON (icon));
<wgrant>         gtk_status_icon_set_visible (GTK_STATUS_ICON (icon->priv->status_icon), enabled);
<bryce> fwiw, this sound issue was on the dell inspiron 1420
<wgrant> ogra: I really can't see how it can go wrong once you get no icon will be displayed
<ogra> wgrant, well, restarting gpm gets me the right icon, unplugging AC gets me a battery icon, replugging AC *doesnt* get me the AC icon back
<ogra> thats what i see here
<wgrant> ogra: Does the icon end up going away in the events shown in that log?
<ogra> yes
<wgrant> Hmmm.
<ogra> but it always returns the battery icon, never the AC one
<wgrant> OK, can I see the log for where it should give you an AC one?
<ogra> http://paste.ubuntu.com/53010/
<ogra> seems its stuck at gpm-primary-100
<ogra> while it should be gpm-primary-100-charging
<ogra> and here is a AC unplug/replug http://paste.ubuntu.com/53012/
<ogra> seem like gpm_engine_recalculate_state_icon is the prob
<wgrant> ogra: It must be escaping from there at 438.
<wgrant> Because we end up with an icon, but we don't see "Trying PRESENT icon".
<wgrant> Which might mean that gpm_cell_unit_get_icon is the problem.
<ogra> hmm, the last changelog entry refers to bug 274681
<ubottu> Launchpad bug 274681 in gnome-power-manager "g-p-m is reporting 2 separate voltage/power levels" [High,Fix released] https://launchpad.net/bugs/274681
<wgrant> ogra: The tooltip does say that it's charging, right?
<ogra> yes, tooltips and popups are fine
<wgrant> And you are fairly up-to-date?
<ogra> yep
<ogra> oh, wait
<ogra> i'm missing exactly that update
 * ogra updates
<ogra> bah
<ogra> fixes it
<ogra> yes, all fine, reproducable
<ogra> even the delays are gone, its updating much faster
<ogra> sigh
<wgrant> Heh.
<wgrant> Interesting.
<wgrant> It didn't look quite like that bug.
<ogra> do you have ubuntu3 installed?
<ogra> but it was a patch to gpm-cell-array.c
<wgrant> I do.
<wgrant> But I don't have this same bug.
<ogra> or rather it dropped one
<Socceroos> Is Ubuntu 8.10 Beta still on schedule to be released soon?
 * slangasek mumbles at the mangling of bug #273907's bug state
<ubottu> Launchpad bug 273907 in firefox-3.0 "[MASTER] abrowser-3.0 and others do not start: :$pkglibdir/abrowser link missing" [High,Confirmed] https://launchpad.net/bugs/273907
<slangasek> Socceroos: "soon", yes, but releases don't happen on Australian time :)
<Socceroos> ah ok, I was just looking at the Launchpad release schedule and it recons it was supposed to be released an hour ago. Is that because Launchpad is telling me the release time in my own timezone?
<slangasek> mm. which page are you looking at?
<slangasek> one hour ago was midnight UTC; but we don't target the releases that exactly
<Socceroos> https://launchpad.net/ubuntu/+milestone/ubuntu-8.10-beta
<Socceroos> ah, ok. I was just getting over excited to read all about it =P ....i can wait :)
<slangasek> ScottK: are there any key features in Kubuntu 8.10 that you think should be highlighted in https://wiki.ubuntu.com/IntrepidIbex/BetaAnnouncement ?
<slangasek> superm1|away, laga: ^^ same question, mythbuntu :)
<ScottK> slangasek: The big one is the switch to KDE4.
<slangasek> right, that's covered
<ScottK> slangasek: OK.  There's been some discussion on kubuntu-devel ML about it.  https://wiki.kubuntu.org/IntrepidIbex/Beta/Kubuntu is the current state of the Kubuntu specific writing.  Dunno if you want to borrow anything from there.
<slangasek> persia, TheMuso: what should https://wiki.ubuntu.com/IntrepidIbex/BetaAnnouncement say about UbuntuStudio?  Is there any sort of webpage that we should be linking to?
<bryce> kees: confirmed fix to -evdev for that tty security issue is uploaded.  Maybe too late for beta though.
<slangasek> ahem, slightly
<bryce> slangasek: dunno if it's worth mentioning, but the failsafeX stuff is all majorly reworked
<ScottK> slangasek: You did some work on the kphotoalbum build-dep on libkexif in Bug 269916.  Did you want to finish and do the upload or would you rather I take care of it?
<ubottu> Launchpad bug 269916 in kphotoalbum "Please remove libkexif source and libkexif1, libkexif1-dev binaries from Intrepid" [Medium,In progress] https://launchpad.net/bugs/269916
<TheMuso> slangasek: Afaik we don't really have anything in particular in terms of a webpage, however, the one thing that has changed for this release is no realtime kernel, and we are encouraging people with low latency requirements to stick with hardy. I can have a look at whats there for studio and make changes appropriately if you like.
<cody-somerville> I imagine I need to write something up for Xubuntu
<nxvl> were are the bugs milestoned for beta?
<TheMuso> As it is, I am not sure if we should announce a regression like that, but just encourage people to stick with hardy if they have specific performance requirements.
<slangasek> ScottK: please do so, I was just trying to establish whether bringing back libkexif was the right course of action
<ScottK> slangasek: OK.  Will do.  Thanks for doing it.
<slangasek> TheMuso: currently there's a big "TBD" for UbuntuStudio.  I'm not sure if we want this announcement to say things like "don't use this variant"... :)
<slangasek> bryce: I'm not thinking that belongs in the top three, but maybe you can add something to https://wiki.ubuntu.com/IntrepidIbex/TechnicalOverview ?
<ScottK> slangasek: I think though for the RT needing people it's better to warn them up front.
<TheMuso> slangasek: I agree, but persia or Cory might have somethign else to say. Unfortunately it seems that _MMA_ is not in here. I'll poke him.
<slangasek> ScottK: but probably in the release notes, not in the beta announcement?
<slangasek> cody-somerville: I emailed xubuntu-devel, perhaps my mail is still stuck in the moderation queue :P
<ScottK> slangasek: Do you want those people testing the beta?
<slangasek> ScottK: I don't think the beta announcement is the right place to warn them off; we have the web page that tells people about errata, and we have the release notes for identifying issues that people need to pay attention to when upgrading
<slangasek> (though the latter isn't live yet)
<ScottK> OK.  Your call.  I know we say these aren't suitable for general users, but I think it's reasonable to say "It's particularly not suitable for ...".
<cody-somerville> slangasek, there she goes.
<tedg> slangasek: Yes, the reason you need a dialog is to choose, but we've already provided the choices on the menu.
<slangasek> tedg: well, I guess I would expect a confirmation dialog
<tedg> slangasek: The icons not being there is more of an aesthetic thing.  Trying to clean up the menus in general, use icons for accent instead of "everywhere someone could think to put one" which seems to be the current philosophy :)
<slangasek> hmm
<slangasek> is this a new UI principle being followed?
<slangasek> because I learn the icons associated with actions and find that preferable to having to read the text
<tedg> slangasek: The start of one.  Not fully formed yet.
<tedg> Yes, but the problem there is when you have lots of icons, you really end up reading the text anyway.
<tedg> Because, for the most part, the icons are arbitrary.
<wgrant> I agree with not having icons for all items, but I think that many is suited to having them.
<tedg> I personally thing we've probably gone a little bit to the sparse side, but definitely it was cluttered before.
<slangasek> for application menus, sure; for system menus, I'm not convinced
<slangasek> tedg: ok, at least we agree on that then :)
<wgrant> s/many/menu/. I suck.
<ScottK> tedg: You might want to explain this principle to some LP developers too.
<tedg> Just change your default font to wingdings, then you'll have all the icons you could want ;)
<slangasek> I don't think that's compatible with my definition of "icon" :)
<tedg> Sadly, probably more descriptive/intuitive than many of them...
<tedg> ScottK: Well, the goal is try to use some of the same design philosophies in everything, so hopefully it'll help Launchpad also.
 * slangasek flips through menus and blinks
<slangasek> why does "Bazaar Preferences" belong in System->Preferences?
<ScottK> tedg: Right, I'm just thinking they've recently taken a major step in the direction of icon mania, and so perhaps they'd benifit from the discussion.
<tedg> slangasek: No other place to put it?
<slangasek> tedg: if there's no other place to put it, then why does it need to be there at all?
<slangasek> if I'm doing everything else with bzr from the commandline, why do I need to be able to /configure/ bzr from the menu?
<tedg> ScottK: My favorite launchpad thing is the tiny icons, in general, you can't express anything in under 200 pixels :)
<StevenK> tedg: The team membership icons?
<tedg> slangasek: Well, you could use Olive.  But, I would say in that case probably calling it from Edit->Bazaar Preferences in Olive is sufficient.
<tedg> StevenK: Yeah, and I think some others.
<tedg> They're very cryptic.
<slangasek> tedg: precisely - since I don't have that installed, it doesn't make any sense to have it in my System menu...
<slangasek> now if I can figure out which package to blame, I'll file a bug :)
<nxvl> slangasek: is there any chance for new revision (as in upstream svn revisions) in main now?
<Hobbsee> nxvl: right now, while ther'es a beta happening?  no.
<nxvl> ugh
<nxvl> network-manager-openvpn is FTBFS because of unment deps
<nxvl> and that unment dep is network manager
<slangasek> well, it can stay FTBFS until after beta
<nxvl> slangasek: i mean from now until release
<slangasek> though that seems to imply that someone accepted half of the batch of nm uploads :)
<nxvl> slangasek: not now as in right now
<slangasek> nxvl: NM 0.7 is going to be allowed in immediately after beta
<nxvl> \o/
<slangasek> it's already in the queue and has been discussed
<nxvl> 0.7~~svn20080928 is needed
<nxvl> were is the queue btw
<Hobbsee> it's non-public, last i knew.
<Hobbsee> well, not visible to !archive admins
<StevenK> Hobbsee, slangasek: Can one of you pretty please approve Kourou 0.4 in unapproved?
<Hobbsee> and used to be visible at http://people.ubuntu.com/~ubuntu-archive/queue/ but apparently no longer
<Hobbsee> s/visible/mirrored/
<slangasek> StevenK: done
<Hobbsee> bah
<StevenK> slangasek: Thanks
<slangasek> wait
 * Hobbsee waits for launchpad, again.
<slangasek> no, I said that blindly after typing the command
<slangasek> StevenK: not in the queue :P
<Hobbsee> oh, there we are.  it only took 15 seconds to load that.
<StevenK> Hm.
<StevenK> I uploaded it
<slangasek> did you get an acknowledgement email back?
<StevenK> Not yet, which makes me suspect I'll get it in 30 seconds
<nxvl> need to run, see you in the morning
<slangasek> StevenK: let us know when you've gotten an ack email; until then it's still processing
<cody-somerville> slangasek, when are you planning on releasing? (ie. # of hours)
<slangasek> cody-somerville: it'll be > 12:00 London time; how much later depends on how things fall into place
<StevenK> Sigh. LP, I'd like the new Kourou in this publisher run. Looks like I lose.
<Hobbsee> slangasek: beat you :)
<slangasek> heh :)
<Anon9050> Does anyone out there know how to edit the home directory. I want to change the name of said directory !
<cody-somerville> #ubuntu for support please
<nixternal> change your nick :P
<nixternal> err, login name
<Anon9050> does not work !!
<superm1> slangasek, there's some sort of bug that crept up related to the mythbuntu-backend-master task that is preventing the alternate cd from working right.  it's trying to pull apache2-mpm-prefork & apache2-mpm-worker from the task.  i'm a bit confused by why though.
<superm1> http://pastebin.com/f557ba44f
<StevenK> TheMuso: Nice work on mplayer, it built everywhere.
<TheMuso> StevenK: I know. :)
<cody-somerville> slangasek, ping
<slangasek> superm1: hrm, I don't seem to be able to install the mythbuntu-backend-master task with 'apt-get install mythbuntu-backend-master^'; hints on reproducing this?
<slangasek> cody-somerville: pong
<cody-somerville> slangasek, can you push ubuntu-restricted-extras through?
<slangasek> cody-somerville: and then what?
<slangasek> is that on the CDs?
<cody-somerville> I hope not :P
<cody-somerville> (no)
 * StevenK kicks Sam, and gtklookat
<slangasek> cody-somerville: ah, multiverse; yah, pushing
<StevenK> slangasek: With your Debian hat on, have you heard anything about gtklookat?
<slangasek> StevenK: mmno
<StevenK> Damn it libopenvrml, document your API changes!
<slangasek> superm1: are the mythbuntu tasks in the archive's Packages files?
<TheMuso> slangasek: afaik only the ubuntu tasks are in the archive packages files, but I could be wrong.
<slangasek> well, xubuntu and kubuntu ones are too; if the mythbuntu ones aren't, I don't know where they are, so it's hard to help debug
<superm1> slangasek, they should be
<superm1> slangasek, cjwatson would know for sure where they are though
<superm1> tbh the way these tasks work is black magic to me.  laga worked with cjwatson to get them functional
<slangasek> ok; the tasksel data shows mythtv-backend-master is the key package, and I don't see any other packages in the archive with the task field set... let's see what I get with just the one package
<slangasek> superm1: reproducible with 'aptitude --with-recommends install mythtv-backend-master'
<superm1> slangasek, is that what tasksel ends up using for it's backend then (aptitude rather than apt-get)?
<superm1> i would imagine that similar server apache tasks ran into the same thing though
<slangasek> superm1: is it /meant/ to pull in apache? is the bug only the conflict, or is the bug that there shouldn't be a webserver at all?
<superm1> there should be a webserver, yes
<superm1> it sets up a website (mythweb) with the master backend task
<slangasek> superm1: nah, tasksel uses apt-get AFAIK, I'm just using aptitude because it has a simpler switch for toggling recommends
<superm1> and that's what pulls apache
<slangasek> ok - then I guess it's not reproducible, I only see apache2-mpm-prefork being pulled and not apache2-mpm-worker
<superm1> well not reproducible outside of the alternate disk env you mean.  i can consistently make it happen on the latest daily
<slangasek> yes, that's what I mean
<slangasek> let me have a look at the build log; apache2-mpm-worker shouldn't even be on the CD, by all rights
<StevenK> gtklookat.cpp:619: error: 'cout' is not a member of 'std'
<StevenK> gtklookat.cpp:619: error: 'cerr' is not a member of 'std'
 * StevenK kicks C++ more
<slangasek> superm1: ah - apache2 prefers worker, but something else is also pulling in php5, which requires prefork
 * StevenK sighs that php5 requires prefork
<superm1> slangasek, well mythweb would be pulling in libapache2-mod-php5 or php5
<StevenK> I thought std::cout and friends still worked?
<slangasek> StevenK: yeah, such a tragedy that php5 doesn't work with threaded webservers so that PHP can be more widely adopted ;P
<StevenK> Haha
<slangasek> superm1: then something needs to be hard-coded in the dependency ordering to ensure that apache2-mpm-prefork is always seen first
<superm1> slangasek, so probably hack on the the mythweb depends
<StevenK> Isn't it because one library isn't thread-safe?
<wgrant> It's probably just because PHP is awful and wants to die.
<slangasek> StevenK: it's because the last time I tried to turn on the thread-safe SAPI for PHP, upstream bitched at me that this was only supported on Windows, and we were doing a horrible thing by breaking binary compatibility with the all-important proprietary accelerators
<superm1> slangasek, would just making the depends apache2-mpm-prefork | apache2 cover it then likely?
<slangasek> superm1: why have an alternative at all?
<kees> bryce: very cool!  does that fix me too (even though I didn't show evdev?)
<superm1> slangasek, well i guess in case worker is ever supported in php5
<superm1> but i suppose you're right
<slangasek> superm1: also, please fix mythweb to not list 'libapache2-mod-php4 | php4 | ' in the alternatives list, those packages are dead and buried and I doubt the current code would even work with them :)
<slangasek> ditto 'php4-mysql | '
<superm1> slangasek, that was there mostly for backportability
<slangasek> well, unless someone is backporting to dapper, they're redundant
<bryce> kees, yes; you're probably using evdev even though kbd was shown in your xorg.conf
<superm1> current code does still work with the php4 stuff, but i'm not sure how far back we'll be backporting, probably not to dapper anymore; you're right
<slangasek> superm1: and if you think they're still needed, I would recommend moving them last
<kees> bryce: ah-ha, yeah, reading the new comments in the bug report.  nice.
<superm1> i'll drop them
<slangasek> ok
<superm1> thanks for the quick help slangasek
<slangasek> superm1: sure.  will you be doing an upload tonight, that I should watch for?
<superm1> slangasek, yeah i'll do it in a few moments
<slangasek> ok; I'll stick around to push it through the queue
<superm1> thanks
<cody-somerville> slangasek, I have a few things I need pushed as well
<slangasek> cody-somerville: uh.  that's... not good?
<slangasek> cody-somerville: are we talking beta showstoppers?
<cody-somerville> slangasek, no
<slangasek> ok
<cody-somerville> but it would be nice to offset the barage of inevitable bugs reports and e-mails I'll get if I don't get the fixes into the archive :)
<slangasek> in the archive, but not on the CDs, yes?
<cody-somerville> Right.
<cody-somerville> They can be rolled in for the release candidate
<kees> sabdfl or mdz: hi! can you renew my ubuntu-dev membership when you get a chance?  I just got a reminder email.  :)
<cody-somerville> kees, whats your launchpad id?
<wgrant> kees: You're not meant to keep your direct membership; you should be in motu or core-dev instead.
<kees> cody-somerville: "kees"
<kees> wgrant: oh.  :P
<StevenK> I thought I got renewed in -dev. I'm not sure.
<cody-somerville> kees, you probably want to be renewed in core-dev, not dev :P
<kees> sabdfl and mdz: never mind :)
<kees> cody-somerville: no, I seem to be in both.
<kees> my ubuntu-dev is just redundant.
<wgrant> Right.
<cody-somerville> Right
<dholbach> good morning
<cody-somerville> but your membership is core-dev is about to expire too
<kees> heya dholbach :)
<wgrant> ubuntu-dev should in the end consist of ubuntu-core-dev and motu.
<cody-somerville> (in
<cody-somerville> guh
<cody-somerville> *in
<kees> cody-somerville: well, in 2 months
<wgrant> Isn't core-dev self-renewable?
<dholbach> hi kees
<cody-somerville> kees, Thats like next week :P
<kees> wgrant: I think so
<slangasek> superm1: ping me when you've uploaded, please
<superm1> slangasek, should have been uploaded now
<slangasek> ok
<FatalError> not sure if this is the correct place to ask -- but how do I find out who owns a package? that, or how would I go about contributing an updated package for something?
<RAOF> FatalError: Generally, no one owns packages in Ubuntu.
<liw> FatalError, to contribute, make an updated package, and file the patch or debdiff as a bug in Launchpad
<FatalError> oh, right on
<FatalError> because the current xchat has a nasty file descriptor leak ( which has since been fixed ) :) I'll go take a look at launchpad
<pitti> Good morning
 * slangasek waves
<StevenK> Morning pitti
<geser> Guten Morgen pitti
<cody-somerville> Oh lovely
<cody-somerville> I guess people don't listen to music much on Xubuntu or our testers completely missed the fact that Audacious has pulseaudio set as the default output plugin when Xubuntu uses alsa...
<TheMuso> cody-somerville: How does audacious store its default settings?
<RAOF> Whoops.  It seems the latest ubuntustudio-menu upload broke compiz :)
<TheMuso> RAOF: how?
<TheMuso> RAOF: and why do you have ubuntustudio-menu installed?
<RAOF> TheMuso: Someone set XDG_CONFIG_DIRS, and the compiz wrapper script is broken.
<RAOF> TheMuso: I don't, but someone on ubuntuforums does.
<TheMuso> RAOF: how does that break the compiz wrapper script?
<RAOF> The compiz wrapper script stores stuff in /etc/xdg/compiz/compiz-manager.  However, it doesn't handle XDG_CONFIG_DIRS correctly; it only handles a single setting there.
<TheMuso> Riiiiight.
<RAOF> It's always been broken, it's just that practically no one sets a list of dirs in XDG_CONFIG_DIR.
<TheMuso> So that sounds more like a compiz wrapper scrit problem then.
<RAOF> Right.
<TheMuso> RAOF: Well both edubuntu and now ubuntustudio do.
<RAOF> Indeed.
<TheMuso> The ubuntustudio package got the code from edubuntu menus.
 * RAOF goes of to fix the compiz wrapper.
<cody-somerville> TheMuso, not sure
<TheMuso> cody-somerville: I'll have a dig if you like.
<cody-somerville> TheMuso, I've had some complaints about audacious anyhow
<cody-somerville> TheMuso, I'm thinking rhythmbox or exaile would be better candidates for Xubuntu
<TheMuso> ah man, it patches a c file? *sigh*
<TheMuso> cody-somerville: Right. You already have gstreamer there for totem correct? Then thats an almost no-brainer.
 * cody-somerville nods.
<RAOF> So, I want to iterate over a colon-separated list.  Setting IFS to : and then looping with for is a perfectly sane implementation, right?
<TheMuso> RAOF: Sounds sane, jjust make sure to store the old IFS and set it back to how it was.
<RAOF> Right.  That's how I've done it in the past.  Just checking that there isn't some magical shell tricks that everyone else knows that I don't :).
<siretart> lool: if you are OK, I'd like to upload the debdiff attached to bug #97721
<ubottu> Launchpad bug 97721 in mpeg2dec "[apport] vlc crashed with SIGSEGV in mpeg2 module" [Medium,New] https://launchpad.net/bugs/97721
<siretart> lool: oh, ignore me. that fix is already in the package
<cody-somerville> rhythmbox doesn't seem to accept cdda:/ has a URI. What URI would I pass to rhythmbox to get it to play a CD?
<TheMuso> cody-somerville: give me a bit and I'll find out.,
<TheMuso> cody-somerville: from my test here its cdda://scd0 but I am not sure what represents the scd0 in terms of the device node. I'd say its in the gconf schemas somewhere. :)
<cody-somerville> TheMuso, that doesn't work for me
<cody-somerville> TheMuso, Failed to load cdda://scd0: No registered source can handle URI cdda://scd0
<RAOF> Does Xubuntu have gnome-vfs or gvfs installed?  That'd be a fair guess as to what provides cdda:// URIs.
<roachmmflhyr> what causes my ubuntu graphics to look very windows 98ish??
<RAOF> So, how does the compiz team like their bzr branch merge requests?
<henux> maybe a gtk theme?
<cody-somerville> RAOF, yea
<roachmmflhyr> henux, im using the human clear looks theme
<wgrant> roachmmflhyr: What do you mean it looks Windows 98ish?
<RAOF> seb128: Aha.  As the only member of ~compiz on irc at the momen, you're my target :).  How would you like a bzr branch of the Compiz packaging to be presented?
<RAOF> Just as soon as the launchpad/bzr unholy duo stop being crazily slow.
<seb128> that's a mistake, I should unsubscribe of this team, you want to talk to mvo when he will be there
<roachmmflhyr> like in nautilus or any notification windows that pop up there are gray and boxy--what package is gtk in? I want to reinstall it
<RAOF> Heh.  Fair enough.
 * roachmmflhyr fixed it..... wgrant 
<cody-somerville> How stable is elisa?
<RAOF> It seemed to work OK for me.  It's been uninstallable for quite some time, though.
<roachmmflhyr> wgrant, just reinstalled libgtk2.0.0.0, turned off desktop effects and then turned them back on...all good to go now
<seb128> reinstalling is not likely to make any difference
<dholbach> hey seb
<dholbach> seb128: I sponsored the new totem - do you think you can take a look at the libgnomecanvas sponsoring item?
 * wgrant hopes seb128 is right.
<seb128> dholbach: we are frozen I'm not going to sponsor anything today
<seb128> dholbach: thanks for the sponsoring though, I'll look at other items after the beta freeze if I can connect to launchpad again ;-)
<dholbach> ok
<seb128> dholbach: and out of the freeze I've connectivity issues today, can't reach any of the canonical or gnome boxes
<dholbach> that sucks :-/
<lool> siretart: So it's fixed as a side effect of not enabling optimizations?
<seb128> indeed, I can't read my mails or do bug triage
<pitti> seb128: ssh and mutt FTW :)
<siretart> lool: no, it was a patch that you already imported from somewhere else
<seb128> pitti: well, you need a box you can ssh to which has access to mail.canonical.com and that's not my case right now ;-)
<siretart> lool: it turns out that the version in hardy is still affected but not the version in intrepid. the package was synced too late
<roachmmflhyr> nevermind some of my windows and menus are still win 98ish looking  check it out here http://pichostonline.com/u/081002/9e101d34b4.png
<StevenK> seb128: Routing issues?
<seb128> it seems so
<seb128> it stops after "ae-1-100.ebr2.Amsterdam1.Level3.net (4.69.133.86)     80.442ms asymm 10" on no reply apparently
<pitti> superm1: http://cdimage.ubuntu.com/mythbuntu/daily/20081002.1/ hot and fresh
<StevenK> pitti: Z3r0-d4y w4r3z?
<lool> siretart: Oh ok
<pitti> StevenK: shh, s3kr1t!
 * StevenK grins
<lool> seb128: Happened to me some weeks ago, I was really in trouble
<StevenK> seb128: Can you get to mangled.wedontsleep.org? I can set up a mail tunnel, if you wish
<lool> seb128: We could work on some proxying for you
<seb128> lool: what that an isp issue and did you have to tell them about it?
<lool> seb128: My ISP is Free, I did try to contact them and even used in house contacts
<lool> Nobody understood the issue I was raising and they told me to wait
<lool> It was fixed a couple of days after it started
<lool> My in house contacts replied too late
<seb128> thanks guys but don't bother for now, I can access to cdimage.ubuntu.com (but not launchpad, debian.org or gnome.org) so I just synced a new iso
<lool> As in didn't pick the phone and got to my email hours after it was fixed
<lool> SOMEONE GIVE ACCESS TO BUGS.LAUNCHPAD.NET TO seb128!
<seb128> I will do some iso testing for a while, if internet is still not back after that I might ping you for the proxy thing ;-)
<mdz> what does the "PIIX3...enabling passive release" message mean which comes up in KVM?
<lool> seb128: :-P
<mdz> sorry, meant that for -kernel
<cjwatson> roachmmflhyr: you were installing libraries from source last time I heard - if you broke your system that way, you'll have to fix it yourself, we have no idea what you did and can't in general support people doing that sort of thing
<cjwatson> kees: done your pocket-copies
<mdz> dholbach: I have a small tool which I'd like to add to ubuntu-dev-tools. it depends on bsdtar.  should I make that a depends or a recommends?
<RAOF> mvo: I've got a bzr branch of compiz that fixes compiz-manager's handling of XDG_CONFIG_DIRS.  How would you like it?
<mvo> RAOF: if its a branch, then just give me the location and I merge
<mvo> RAOF: you should be part of the compiz team :)
<RAOF> mvo: it's lp:~raof/compiz/wrapper-fix
<RAOF> I haven't touched compiz packaging for _ages_ - I'd be afraid of stepping on your toes :)
<mvo> RAOF: I have big shoes :) help in the team would be very welcome!
<dholbach> mdz: if you make it a recommends, it'd be nice if the tool would not explode if it's not installed :-))
<dholbach> mdz: what kind of tool is it?
<mvo> RAOF: thanks, commited
<mdz> dholbach: just a simple script which extracts the version info from an .iso, I use it during testing
<mdz> mizar:[.../canonical/ubuntu-dev-tools] ./isoversion /space/tmp/mdz/tmp/hardy-server-i386.iso
<mdz> Ubuntu-Server 8.04 "Hardy Heron" - Release i386 (20080423.2)
<cjwatson> I use 'isoinfo -R -i foo.iso -x /.disk/info'
<mdz> cjwatson: I used to use that, too, then I decided it should be a script :-)
<mdz> it could as easily use isoinfo, I suppose
<cjwatson> oh, sure :-) I just meant if you thought genisoimage was less exotic than bsdtar
<cjwatson> although bsdtar is certainly very useful
<cjwatson> genisoimage is in main though
<mdz> cjwatson: I was thinking of adding some additional options to the script and bsdtar seems more flexible
<mdz> it does whine about out-of-order files a lot though
<mdz> and isoinfo is a lot faster. it wins
<mdz> dholbach: same question, though; depends or recommends?  I notice that bzr is only a recommends, though some of the tools use it
<dholbach> I'd probably make it a recommends and let the tool print a "Please run: sudo apt-get install ...." if it can't find the package
<dholbach> but I didn't write a "ubuntu-dev-tools rulebook" :)
<mdz> pitti: do you have thoughts on whether bug 264696 should be fixed in consolekit or gnome-session?
<ubottu> Launchpad bug 264696 in gnome-session "usplash is not started on shutdown/reboot" [Medium,Triaged] https://launchpad.net/bugs/264696
<pitti> mdz: gnome-session can't do that, and  CK is unrelated; according to the comments in usplash's init script, "it expects the display manager to have started the daemon with usplash_down", so it should either be in gdm, or we should fix usplash's init script
<pitti> mdz: in my test installation I did see a splash down, although only a very short one
<pitti> (in kvm, it doesn't work on my workstation)
<pitti> mdz: I'll reassign it to usplash for now
<mdz> pitti: I don't think it can be fixed in usplash; how would it know when X has exited?
<mdz> pitti: it gets started in init.d/sendsigs or something, for the last 1 second of shutdown, which is pointless and should probably be removed
<pitti> oh, right, that's yet another bug
<pitti> gnome-session doesn't actually shut down the session any more, it just triggers the reboot
<pitti> if it would do that, X would already be shutdown when /etc/rc0.d/K01usplash runs, or not?
<mdz> pitti: what should happen is that X shuts down, and *immediately* after that, usplash_down is run
<pitti> right
<mdz> pitti: otherwise the user sees a bunch of console message garbage in between
<mdz> this used to work properly ca. gutsy, I think it may be somewhat broken in hardy
<pitti> so previously, GDM_LOGOUT_ACTION_SHUTDOWN caused gdm to call usplash_down?
<pitti> seb128: WDYT, should we change that to just call usplash_down and quit X, but not shutdown? and change gnome-session to call ACTION_SHUTDOWN for the CK shutdown path, too?
<seb128> pitti: no real opinion on the topic, gnome-session is not the only way to shutdown the box nowadays, would that work for the fast user switch applet for example?
<pitti> seb128: they all just call ConsoleKit?
<seb128> pitti: dunno, I didn't look at what ted did in the new fast-user-switch-applet
<mdz> pitti: I filed bug 277058 about that
<ubottu> Launchpad bug 277058 in sysvinit "sendsigs should not start usplash_down" [Undecided,New] https://launchpad.net/bugs/277058
<seb128> pitti: same about the restart now notification
<pitti> I'm only afraid that adding usplash_down to /usr/lib/ConsoleKit/scripts/ck-system-stop won't work either
<seb128> why not?
<pitti> at least not until we can actually make sure that gnome-session stopped the session and gdm killed X before ck-system-stop runs
<mdz> pitti: yes, that's what previously happened
<pitti> otherwise we could just add it to /etc/rc0.d/K01usplash
<mdz> (gdm called usplash_down)
<pitti> (which would be more correct then)
<mdz> I would go ahead and fix bug 277058, but it would look like a regression without fixing bug 264696 first
<ubottu> Launchpad bug 277058 in sysvinit "sendsigs should not start usplash_down" [Medium,Triaged] https://launchpad.net/bugs/277058
<ubottu> Launchpad bug 264696 in gnome-session "usplash is not started on shutdown/reboot" [Medium,Triaged] https://launchpad.net/bugs/264696
<pitti> so how about we add it to /etc/rc0.d/K01gdm then?
<mdz> pitti: my only concern there would be the use case of "sudo /etc/init.d/gdm stop"
<mdz> it would be pretty weird for usplash to start unless the system is actually shutting down
<pitti> mdz: it could check if the runlevel is 0 or 6
<mdz> pitti: does upstart have runlevels?
<pitti> $ runlevel
<pitti> N 2
<pitti> mdz: I think as long as we use rc0.d/, it will
<mdz> where is Keybuk?
 * pitti fires up kvm and tests
<pitti> "This tool is provided for compatibility with the traditional  System  V
<pitti>        init(8).   Upstart  has  no  notion  of  runlevels itself, this and the
<pitti>        telinit(8) tool are provided to emulate their behaviour."
<mdz> Keybuk: pitti and I were talking about how best to fix bug 264696
<ubottu> Launchpad bug 264696 in gnome-session "usplash is not started on shutdown/reboot" [Medium,Triaged] https://launchpad.net/bugs/264696
<mdz> Keybuk: he made the suggestion to add code to /etc/init.d/gdm:stop which would check the current runlevel, and if 0 or 6, then start usplash_down after gdm finished shutting down
<mdz> I don't know how kosher that is in upstart-land
<Keybuk> that seems perfectly valid
<Keybuk> though is gdm stop called on shutdown?
<Keybuk> the same effect could be made by just making "usplash stop" actually start usplash
<Keybuk> since there's a K01usplash in 0 and 6
<pitti> that's what I just tried
<mdz> Keybuk: yes, it installs K01gdm
<pitti> I do get some seconds of text mode with an empty screen and cursor until usplash starts, though
<pitti> so if we could start it just a little earlier, that would be perfect
<Keybuk> wouldn't you get the same seconds by doing it at the end of K01gdm?
<Keybuk> there isn't anything between the two
<pitti> can we actually call usplash_down *before* killing X? this should already switch VT, and thus if X can be killed without interfering with VTs, it would be seamless
<pitti> Keybuk: right, thus ^
<Keybuk> that's what we did before, no?
<mdz> Keybuk: that might work, until we get a display manager whose name begins with 'v'
<mdz> pitti: possibly, but not for intrepid
<cjwatson> mdz: (xdm!)
<mdz> too many races
<mdz> cjwatson: ha!
<pitti> architecturally, K01usplash would be the right solution, to not clutter gdm and kdm init scripts with usplash knowledge
<cjwatson> actually there's wdm too
<Keybuk> where was usplash invoked before?
<mdz> Keybuk: from gdm itself
<pitti> Keybuk: directly from gdm
<pitti> and kdm, I suppose
<Keybuk> that patch no longer works because CK does the shut down?
<mdz> pitti: the gdm and kdm init scripts already have usplash knowledge, to make sure that it's shut down before they start
<mdz> this is actually a use case for making them upstart jobs
<mdz> but at this point I'm just looking for a way to restore the old behaviour for intrepid
<mdz> it's been ripped out of gdm because it doesn't handle shutdown anymore, that goes gnome-session->consolekit
<pitti> doing usplash_down right before gdm doesn't even help, too many VT switches
<Keybuk> it doesn't look like consolekit makes any special effort to stop gdm
<pitti> so, a safe 80% fix is to add it to K01usplash
<pitti> Keybuk: no, just through the standard init scripts
<Keybuk> so the only way to do it is to add the code to K01gdm, K01kdm, etc.
<Keybuk> or have a K02usplash (yes, I just renumbered it :p)
<cody-somerville> heh
<Keybuk> at least, that's the only immediately apparent way that doesn't involve the red VT switch and the blue VT switch having a race
<mdz> and conditionalize it based on the runlevel?
<cjwatson> Keybuk: *earworm*
<Keybuk> well, if it's done in usplash stop, you wouldn't need to do that?
<pitti> mdz, Keybuk: I added my findings as followup to bug 264696
<ubottu> Launchpad bug 264696 in gnome-session "usplash is not started on shutdown/reboot" [Medium,Triaged] https://launchpad.net/bugs/264696
<pitti> was it actually seamless in hardy? ISTR those couple of seconds of text terminal as well
<cjwatson> (for those lacking the earworm: http://darkaeon.wordpress.com/2008/05/02/the-red-car-and-the-blue-car-had-a-race/)
<Keybuk> pitti: it was more seamless, but then also quite racey
<mdz> Keybuk: it wasn't racy IIRC
<Keybuk> I quite often saw a shutdown where the first stage usplash never made it
<mdz> oh, yes, I think that was possible, but the vt switching wasn't racy at least
<Keybuk> I always put it down to a vt switch race
<Keybuk> but I only really did cursory debugging
<asac> zul: to get the current openvpn in the network-manager PPA for hardy, is it just openvpn that needs to be backported or also some build-deps?
<zul> asac: both maybe I havent looked at it :)
<asac> zul: what is "both"?
<zul> asac: er....build-deps
 * zul just rolled out of bed
<lool> pitti: I've pushed facile_1.1-6.1ubuntu1; I did some additional changes aside of the published debdiff:
<lool>   * Set DEB_MAKE_CHECK_TARGET to check || true to not fail the build if the
<lool>     testsuite doesn't pass; NB: it does seem to pass currently.
<lool>   * Use Vcs-* headers instead of XS-Vcs-*.
<lool>   * Bump up Standards-Version to 3.8.0.
<lool> It pbuilt fine and is now lintian -I clean
<lool> pitti: Could you please accept it, and I'll set the MIR to In progress :)
<pitti> lool: I accepted all pending universe stuff, thank you
<pitti> lool: why ||true'ing the test suite then, if it works?
<Koon> asac: about n-m-openvpn, I could reproduce bug 275608 -- not sure it isn't fixed on the pending release though. I am a little lost in the panel building subtleties
<ubottu> Launchpad bug 275608 in network-manager-openvpn "nm-openvpn swaps ca-cert and user-cert labels when using "Passwords with Certificate (TLS)" mode" [High,Confirmed] https://launchpad.net/bugs/275608
<asac> Koon: i saw a patch for that somewhere
<asac> i think on NM mailing list
<Koon> asac: noted
<asac> Koon: http://mail.gnome.org/archives/networkmanager-list/2008-September/msg00287.html
<asac> Koon: can you test that and confirm that with that patch everything is ok?
<Koon> asac: sure.
<lool> pitti: I wasn't confident that it would remain working and preferred having the package build succeed if it starts not doing so
<pitti> lool: hm, I usually prefer having the test suite fail the build, so that regressions become immediately obvious
<lool> pitti: Ok; I will probably commit the testsuite failing the build in Debian then
<lool> I think I did it from experience with the heavy testsuites in GNOME libs or using xvfb which had a tendency to break over time or on some arches, but this doesn't apply to this one
<lool> I just had a bad feeling about the testsuite upstream implementation that I didn't want the build to fail if upstream didn't care about it
<lool> (The ./configure hackery and upstream custom Makefile felt fragile)
<ogra> cjwatson, hmm, when did the auto-login fix in ubiquity get in ?
<ogra> i dont see an upload for it, but its definately working on todays mobile image
<cjwatson> ogra: 1.10.2; you didn't see it on -changes because that was rejected and only 1.10.3 was accepted, but the latter contained the former
<ogra> cjwatson, ah, i think debcommit -r wasnt intelligent and just didnt include the changelog entry, i see it in the package changelog
<cjwatson> debcommit doesn't generate the .changes
<ogra> ah, or that :)
<ogra> oh, indeed, it doesnt
<ogra> anyway, bug fixed, works fine ;)
<cjwatson> I could have used debuild -v1.10.1, but I expected both 1.10.2 and 1.10.3 to be accepted in which case both would have shown up on .changes
<liw> asac, when testing an upgrade of xubuntu from hardy to intrepid, I get (at least) four windows saying "The NetworkManager applet could not find some required resources. It cannot continue". (Make that five, another popped up just now)
<liw> asac, does that sound familiar?
<asac> liw: you tried to manually restart things? or did you reboot?
<liw> asac, the ugprade is still running (six windows now)
<liw> asac, I haven't touched anything, except to move the windows so I can count them (seven)
<asac> liw: so was NM already unpacked?
<liw> asac, how do you mean? it was running in the system from which I started the upgrade
<liw> asac, this is under kvm, if that matters (though it shouldn't)
<asac> liw: what i wonder about is whether this happens before or after the NM bits have been unpacked during upgrade
<liw> asac, hmm, I don't think I can figure that out anymore
<liw> asac, unless there's some log file I can grep for you
<liw> asac, this is a guess, but based on the timestamps in dpkg.log, I would guess the problems started happening approximately when network-manager(,-gnome} were unpacked; I can't verify that that's true, but my internal clock would indicate it is
<liw> (but my internal clock thinks it is about 22:57 right now, where as NTP tells me it is 15:18 local time)
<asac> liw: ok. strange that it happens in xubuntu.
<asac> liw: did the upgrade restart dbus or something?
<asac> liw: ok that error message comes from 0.7 applet
<asac> liw: this means that you restarted the applet
<asac> (if not you something else restarted it)
<asac> which must not happen
<asac> liw: maybe the xubuntu xsession does some magic to restart binaries?
<liw> asac, I don't know what xubuntu does, I just test this :)
<asac> cody-somerville: ^^
<cody-somerville> We don't do any magic
<asac> liw: can you see when the nm-applet process was started?
<liw> asac, long before the problems
<asac> liw: question is if it was started long before the unpack :)
<liw> (ps says it was started 14:26, problems started around 15:00)
<liw> unpack also approximately at 15:00
<asac> liw: so 14:26 is about the time you logged into xubuntu?
<liw> asac, yeah
<asac> liw: and you did nothing? e.g. not even tried to start the connection editor or something?
<liw> asac, nope, I only ran the upgrade command
<liw> (sudo update-manager -d -c)
<asac> mvo: does update-manager try to restart things?
<Koon> asac: patch works (slightly modified so that it picks up translations correctly), needs to be refreshed to apply to pending release though. Will do whenever the dependant packages are released. Commenting on bug right now.
<mvo> asac: restart what? firefox?
<mvo> liw: sudo is not needed (but shouldn't hurt either)
<asac> mvo: no restart nm-applet (which usually gets auto started by the session)
<liw> mvo, ok, I just copy paste from https://wiki.ubuntu.com/Testing/Cases/DesktopUpgrade (I'll get that fixed)
<mvo> asac: no, it can't because the actual installation runs as root
<asac> mvo: myterious then. liw logged into xubuntu. ran upgrade and without doing anything suddenly sees applet error dialogs from 0.7
<mvo> asac: however it seems that network manager kills the network when it gets upgraded sometimes (or all th time?)
<asac> mvo: thats not done anymore
<asac> mvo: dbus restart could cause something though
<asac> but i dont see how it can restart the applet :(
<mvo> asac: we don't do that
<mvo> asac: it might be that the applet probably restarts itself (or gets restarted by something like the session) because it crashes when the new n-m gets installed
<liw> asac, if the applet has been running since I logged in and before I started the upgrade, did it really get upgraded?
<asac> liw: yeah.
<asac> liw: my grep was bogus ... 0.6.6 applet will complain like that too in some cases
<asac> liw: do you see if NM restarted was restarted?
<asac> (the daemon)
<liw> asac, it has also been running since 14:26, i.e., hasn't been restarted, as far as I can see
<asac> liw: ok looks like it happens if NM tries to use icons that it didnt use previously
<asac> liw: so most likely would just be the case if you have more or less a fresh started session
<liw> asac, ok, that sounds reasonable; shall I continue with the upgrade, then, or do you want me to grep for something more? also, should I file a bug?
<asac> liw: you could strace -eopen -p PID
<asac> and tell me which file it tries to open when it complains
<liw> asac, the applet?
<asac> yeah
<asac> liw: we could consider to create compatibility links ... and then see what other resources nm-applet would complain when the icons are still available
<asac> maybe there would be a missing .glade resource too ... which would be harder to fix
<liw> asac, I can't seem to be able to trigger the applet to open the icon anymore, hmm
<liw> ah, no, got it now
<liw> asac, it's (at least) /usr/share/icons/gnome/16x16/actions/gtk-edit.png and gtk-about.png
<liw> asac, though both now succeed, hmm
<asac> yeah those are not NM icons
<asac> liw: http://paste.ubuntu.com/53182/
<asac> those are the ones i suspect to be missing
<asac> liw: seems like the only one missing is vpn-lock
<asac> can you confirm that?
<asac> yeah thats vpn-active-lock now from what i can see
<liw> there is no file matching vpn-lock* under /usr/share/icons
<asac> liw: right
<asac> thats gone ... and thats why you get this
<asac> ln -s /usr/share/icons/hicolor/22x22/apps/nm-vpn-active-lock.png /usr/share/icons/hicolor/22x22/apps/nm-vpn-lock.png
<asac> might be what we want
<liw> in fact, no icon matching vpn*
<liw> oh, nm-vpn*
<asac> liw: dpkg -L network-manager-gnome | grep vpn.*png$
<MacSlow> pitti, what apart from d-feet can I use to monitor/query all this DBus-"stuff"
<asac> liw: i will ask NM folks why that icon was renamed ;)
<asac> liw: everyother icon is there right?
<MacSlow> pitti, of would d-feet work if I export its display to another machine where I have X.org up constantly? I mean on the machine I test/debug my gdm-graphical-greeter on I start and stop X11 all the time.
<liw> asac, nm-device-wired-autoip seems to be missing, too
<liw> asac, so, do you need a bug report filed, or do you remember this anyway?
<asac> liw: yes please. what i need is a list of icons that are used in nm 0.6 but that are not there in 0.7 anymore (at best from the list above)
<asac> liw: most likely its those two icons
<liw> asac, OK, I'll quote much of the above discussion, for clarity
<asac> liw: yeah. just state in the beginning the list of icons we just found
<asac> subscribe me to the bug and milestone :)
<asac> thanks!!
<pitti> MacSlow: that would work, yes (ssh -X)
<pitti> MacSlow: for monitoring, dbus-monitor --system is useful
<MacSlow> pitti, thanks
<MagicFab> siretart, around ?
<siretart> MagicFab: sort of, yes?
<liw> asac, https://bugs.launchpad.net/ubuntu/+source/network-manager-applet/+bug/277084 (I don't seem to be able to milestone it, but you're subscribed (twice?))
<ubottu> Launchpad bug 277084 in network-manager-applet "nm-applet confused by icon name changes during hardy-intrepid upgrade" [Undecided,New]
<MagicFab> siretart, I am cleaning up a bunch of AMR codec related bug
<MagicFab> bugs*
<MagicFab> siretart, if/when you have a couple of minutes (*not* urgent by anymeans) I'd love to discuss some of them
<MagicFab> *quick* cleanup :)
<siretart> MagicFab: sure. what's up?
<MagicFab> siretart, I see bugs related to "AMR free support in ubuntu in general"
<siretart> MagicFab: I think I even have a patch that would allow us to enable amr in ubuntu. it mainly needs testing
<MagicFab> and others "ffmpeg-specific AMR support"
<MagicFab> and others "AMR in medibuntu not working"
<siretart> yes. that sucks
<MagicFab> in the first group free meaning "GPL or similarly licensed" to men
<MagicFab> to me * :)
<siretart> there is not GPL licensed amr implementation TTBOMK
<siretart> at least not yet
<MagicFab> siretart, agreed
<asac> liw: thanks
<MagicFab> so any patch leading to something we can't package/push as an update is not advised now unless
<MagicFab> 1) it's some sort of plugin to external sources (like flash or decss I guess)
<MagicFab> or
<MagicFab> 2) it's not packages but remains as a binary somewhere else
<siretart> there is a 3rd approach
<siretart> the altlinux folks have crafted a patch that allows ffmpeg to load the amr libs at runtime
<siretart> this means that we could compile ffmpeg with amr support, but it would only be useful if the user has the libamr libraries installed on his system
<siretart> and this is the patch I've been talking a few lines above
<MagicFab> siretart, ah, correct - so the libraries would come from..?
<pitti> cody-somerville: do you need that new xubuntu-meta on beta? i. e. does it need a publisher run and new CDs?
<MagicFab> siretart, and could that be implemented in the current automatic-codecs gui?
<siretart> MagicFab: I don't really care as long it's not ubuntu. medibuntu already distributes them and I'd expect them to work
<siretart> MagicFab: possibly. but before thinking about the automatic-codecs gui I'd suggest first working on the ffmpeg side
<MagicFab> siretart, ok, so I tend to block dev when legal issues arise
<siretart> 'block dev'?
 * siretart suspect thats not 'block device' here :)
<cody-somerville> pitti, I'm starting to fear so
<siretart> MagicFab: are we finished with that topic?
<MagicFab> siretart, yes, that'll help me decide. Just so you know I'll be changing those bugs statuses today
<MagicFab> siretart, thank you
<MagicFab> block dev -> not involve developers unless legal issues have been cleared
<pitti> cody-somerville: well, release is supposed to happen in a few hours, so you better decide quickly :)
<cody-somerville> davmor2, can you help test the respin?
<davmor2> What respin
<cody-somerville> davmor2, Xubuntu
<davmor2> pitti, cody-somerville: is this just desktop cd's or both?
<cody-somerville> both
<pitti> cody-somerville: note, I didn't do it yet, I was just asking since I accepted it from unapproved, and it looked kinda important
<davmor2> cody-somerville: if we take it that wubi works as it's been tested a boat load on other cd re-spins then that's 16 tests I gotta go off for about 30< in a bit so it's plausible have a word with slangasek though first
<pitti> cody-somerville: the current CDs are too broken to release them?
<terminator__> When Approximately be released today?
<pitti> current plan is slangasek's noon, as far as I understood
<terminator__> I mean 8.10 Beta?
<pitti> we could release xubuntu beta a bit later, I guess, but it would look a bit weird
<cjwatson> what's the justification for the respin?
<cjwatson> I see you've made a bunch of changes (and that you aren't using current germinate ...)
<terminator__> When the 8.10 beta release is made, what http page on Ubuntu will it be found.  I'd like to set it up in advance?
<davmor2> cody-somerville: we can probably test it all but we'll need the cd's sooner than latter
<cody-somerville> pitti, I wouldn't say too broken but there has been more than just some minor modifications
<cjwatson> cody-somerville: which ones are beta-critical?
<pitti> cody-somerville: well, the amount of modifications isn't really interesting
<slangasek> pitti: oh, well, I had said London's noon or thereabouts; but this is certainly not done yet.  What's the context for the current xubuntu discussion?
<cjwatson> there are lots of other things stacked up for *after* beta
<pitti> cody-somerville: but if the current CDs break installation in a way which cannot easily be fixed with a system upgrade
<cody-somerville> a respin would only be to take advantage of the extra testing thats available
<pitti> slangasek: good morning; darn, I hoped to be able to start that release upgrade wiki page before you get up (got sucked into bug fixing and meeting now)
<slangasek> pitti: no worries
<mpt> cjwatson, excuse my ignorance, but is there a chart anywhere showing how much of the CD image is taken up by each package included on it?
<cjwatson> cody-somerville: at the moment you're asking for testers to put in more hours after already spending a few days testing, so it needs a justification
<slangasek> pitti: I didn't exactly warn you that I was getting up early :-)
<pitti> cody-somerville: pretty much everyone who installs beta needs to keep the isntall up to date afterwards anyway
<cjwatson> mpt: not in a single place, unfortunately
<jdstrand> asac: would you mind peeking at bug #264104? people are suggesting it's the kernel, but feels like the last nm update triggered it...
<ubottu> Launchpad bug 264104 in linux "ipw2200 driver no longer works with wpa2 network" [Medium,Triaged] https://launchpad.net/bugs/264104
<cjwatson> cody-somerville: if there's a justification of the form "eats people's disks", "will break upgrades from beta to final", etc., that sort of thing could be discussed
<jdstrand> asac: hi btw!
 * cody-somerville isn't pushing for a respin. 
<pitti> cody-somerville: I'd primarily be concerned about installation failures; everything else can be release-note'd, and fixed with a dist-upgrade
<pitti> cody-somerville: (not urging you into either direction, just telling you our experience and practice)
<cody-somerville> Okay, no respin
<mvo> mpt: you could try baobab on a cd, not sure if you are happy with the resulting chart (or if it is very useful) but might be worth a try
<liw> . o O (a podcast (series) on release management, by Debian and Ubuntu release management teams, would be really interesting)
<pitti> liw: darth debian and Luke Spacewalker?
<cjwatson> cody-somerville: you should be able to get plenty of testing from now until final
<davmor2> so no respin?
<mpt> mvo, interesting idea, but it says that 98.4% of the disc is taken up by casper, and I'm sure that's not true :-)
<slangasek> mpt: it's taken up by the livefs which is in the casper dir :)
<mvo> mpt: heh :) sorry, I was thinking about the alternate disk
<mpt> ah I see, filesystem.squashfs
<mpt> oh well
<liw> can you run baobab from within the live system?
<cjwatson> you'd want some way to aggregate the results into packages
<mvo> liw: I guess the problem is that the package are uncompressed there
<cjwatson> germinate output would probably be more useful all told
<mpt> I thought a chart of that might help in deciding which packages should be kicked off and which let on
<cjwatson> but it's split up into lots of bits
<mvo> mpt: you could use synaptic in the livecd
<mvo> mpt: than add the "installed size" column and sort by that
<cjwatson> mpt: we typically use germinate output for that but it usually ends up being nowhere near that simple
<slangasek> mpt: I think what we want is for all packages to go on a diet instead
<mvo> (if you are intressed in the top size packages)
<cjwatson> packages don't exist in isolation
<cjwatson> http://people.ubuntu.com/~ubuntu-archive/germinate-output/ubuntu.intrepid/
 * liw doesn't suggest solving all space problems by removing OO.o from default installation
<cjwatson> within that you want the required, minimal, boot, standard, desktop-common, desktop, and live files
<mpt> slangasek, do you have specific ideas in mind?
<cjwatson> there may be some overlaps
<slangasek> mpt: no, because unfortunately we're not keeping good track of how individual packages change in size over time
<cjwatson> but deciding whether removing a package or set of packages makes a big size difference also depends on whether that would allow some dependencies to drop out, not only on the size of the packages themselves - and that often makes a big difference
<mpt> fair enough
<cjwatson> it would be lovely to have some magic interface that let us visualise this
<mpt> yes, just what I was imagining :-)
<liw> make a list/graph that shows for each package how much space can be saved if you remove that, plus all deps+recommends that aren't dep/recommended by any other package?
<liw> something like that?
<cjwatson> it'd need to be at least as smart as germinate
<mvo> playing with synaptic on the livecd helps a bit to get idea, it will have a little status line saying "198 MB will be freeed"
<cjwatson> or possibly it could get away with using germinate's output
<mvo> when clicking on remove on OOo
<asac> jdstrand: ipw2200 is a legacy driver
<asac> jdstrand: well old not legacy ;)
<cjwatson> liw: I think in many cases you would want to be considering small groups too
<asac> jdstrand: do you see something like "scan_capa" in the syslog ? is that 0x00?
<jdstrand> asac: alright, so you have identified I have an old laptop ;)
<asac> jdstrand: actually 2200 shouldnt be that bad. i think 2100 is worse
<mvo> together with the automatic dependency information, that should be a useful first approximation
<jdstrand> with the occassion glitch after suspend, it's worked well for me for sometime
<liw> cjwatson, yeah, good point
<asac> jdstrand: oh so just after suspend?
<jdstrand> asac: hibernate never really seemed to be a problem no-- but I don't use it all the time, and only hibernate when travelling
<liw> cjwatson, that makes it less easy to present as a static list, though... some kind of interactive app might be helpful
<jdstrand> asac: as for scan_capa, don't have any of those
<jdstrand> asac: also, wouldn't you know it-- this morning, after doing *nothing*, it isn't symptomatic...
<jdstrand> :/
<asac> jdstrand: sigh
<asac> jdstrand: does associate=0 fix that for you?
<asac> (kernel module parameter)
 * jdstrand wonders if it needed a cold reboot after those updates from the other day...
<jdstrand> asac: I read that in the report, but haven't tried it
<jdstrand> asac: if I can reproduce it reliably, I'll try that
<asac> jdstrand: well associate must not be 1
<asac> for old things like ipw2200
<asac> we had the same issue before ... so its a deja-vu ;)
<asac> jdstrand: ok asked for feedback and assigned to rtg directly with the hint that we should change associate default to 0
<jdstrand> asac: I did a modinfo ipw2200, and it claims auto associate is on by default.
<asac> jdstrand: yeah. thats bad
<jdstrand> I don't see anything in /etc/modprobe.d to override that
<asac> ok milestoning that bug
<asac> jdstrand: no its the default in the kernel source
 * jdstrand nods
<asac> jdstrand: we should patch that or add something to modprobe.d
<asac> i leave that to the kernel team
<jdstrand> asac: it does seem to work sometimes (like this morning). is that consistent with your experience with this driver?
<asac> jdstrand: yes auto associate will cause randomness
<jdstrand> asac: cool-- thanks for looking into it!
<asac> jdstrand: well we had really severe issues due to races with ipw3945 which turned out to be caused by auto associate. this makes sense to me
<asac> jdstrand: thanks for pointing me at this bug ;)
<jdstrand> asac: np :)
<slangasek> pitti: on consolekit crasher, Ng found a fd leak yesterday; I'm trying to establish today whether it's related, I haven't yet leaked out all of my fds since my last reboot so I'm waiting to see
<pitti> slangasek: I saw Ng's bug report and answered; ATM I'm nto sure whether it's related either
<slangasek> I have the one-liner patch for the fd leak, I'm just waiting to get some evidence the two are related before uploading
<pitti> slangasek: I spent 1.5 hours today to clean up the CK crashers, and in the end it's just three really different ones (of which one is the double close() I uploaded to intrepid now)
<slangasek> oh, you found a double-close?
<pitti> slangasek: oh, nice! so there was a double close *and* a forgotten close()?
<slangasek> yes... :)
<jcristau> doesn't that even out?
<pitti> slangasek: yes, see bug 263245 and the upstream bug I created for that (linked from there)
<ubottu> Launchpad bug 263245 in consolekit "console-kit-daemon crashed with SIGSEGV in fclose()" [Undecided,In progress] https://launchpad.net/bugs/263245
<pitti> jcristau: if it would be that easy...
<slangasek> pitti: ok - in that case I don't need to test anymore, I can just send you the patch
<slangasek> after I take care of a few other things first
<slangasek> like the beta
<slangasek> :-)
<pitti> slangasek: I noticed a lot of other crashes which are not really "obvious"; I wonder if a double close() can cause memory corruption which wreaks havoc in the process later on
<pitti> slangasek: details :)
<slangasek> what's the package for the CD bootloader? syslinux?
<pitti> slangasek: I think so, yes
<pitti> seb128, tedg: I just added a stanza about the logout applet to https://wiki.ubuntu.com/IntrepidReleaseNotes; can you please take a look at it that I described the situation correctly?
<cjwatson> slangasek: which bit of it?
<cjwatson> slangasek: the UI is gfxboot-theme-ubuntu + gfxboot
<slangasek> cjwatson: the bit for bug #277033 :)
<ubottu> Launchpad bug 277033 in syslinux "intrepid daily livecd 20081001 hangs in grub on amilo XI2428 after hitting return" [Undecided,New] https://launchpad.net/bugs/277033
<slangasek> so possibly should be gfxboot instead
<cjwatson> god, could be anything
<slangasek> ok :-)
<slangasek> (but not grub!)
<tedg> pitti: Looks good.
<jdstrand> asac: for giggles, I looked in /sys/module/ipw2200/parameters/associate on hardy, and it is on by default as well
<jdstrand> which actually may explains a few things about wireless on that system...
<seb128> pitti: looks good to me, I just commented on the bug to list what I think are the options we have for upgrades
<slytherin> I am seeing this error when using latest alternate CD image (which I suppose is for beta) with apt-get. - W: Failed to fetch file:///media/ubuntucd/ubuntu/dists/intrepid/Release  Unable to find expected entry  main/binary-i386/Packages in Meta-index file (malformed Release file?)
<slangasek> error, or warning?
<cjwatson> slytherin: known bug
<slangasek> W: - warning
<slytherin> oops, warning
<cjwatson> it's non-fatal
<slytherin> cjwatson: non-fatal in what sense? Will users be able to install using alternate CD?
<cjwatson> yes
<cjwatson> it's bug 276349
<ubottu> Launchpad bug 276349 in apt "intrepid alternate CD make apt print out a warning" [Low,Triaged] https://launchpad.net/bugs/276349
<slytherin> Ok. Then why doesn't upgrade work. I am already using intrepid and was trying to upgrade it with this image.
<cjwatson> upgrade is a different matter, I suspect
<cjwatson> mvo: ^-
<slytherin> cjwatson: The bug says upgrade works but does not specify which upgrade path. Let me try once ahain.
<mvo> slytherin: in what way does it not work? did you added file urls manually to the sources.list (instead of using apt-cdrom add)?
<mvo> slytherin: if so, please try using "apt-cdrom add"
<slytherin> mvo: I am not using CD. I am using image. So yes I have added file:// url.
<superm1> slangasek, pitti i just tested the mythbuntu alternate generated last night.  appears to work properly now
<pitti> superm1: "last night" as in "the ping I sent you 7 hours ago"?
<mvo> slytherin: aha, thanks. could you please add this use-case and the failure to the bugreport. I think this is going to be difficult (or even impossible) to fix
<pitti> superm1: great to hear, thanks for testing
<mvo> (this == this use case)
<superm1> pitti, yeah after the ping you sent me
<slytherin> mvo: will do.
<mvo> slytherin: thanks!
<mvo> cjwatson: then can of worms grew another head :/ how bad would it be to re-add the uncompressed files?
<mvo> s/then/the/
<cjwatson> mvo: find me 2MB? :-P
<cjwatson> or whatever it was
<superm1> slangasek, for release notes, can you just add a pointer to http://mythbuntu.org/8.10/beta ?  We'll be opening that page up as soon as our live disk makes it to mirrors
<cjwatson> mvo: I guess we can if it's really too bad, but I want commitment that we're going to be able to do this at some point in the future
<cjwatson> because sources of megabytes on the CD are like gold dust
<mvo> cjwatson: right, I absolutely agree, I will look hard into it before making a call
<mvo> cjwatson: its just that its quite a few problems (and the file:/// uri one might be a really difficult one)
<asac> jdstrand: yeah. the reason why the race isnt that bad on hardy is that i have a hack that enforces the essid
<mvo> (also its a unusual use-case)
<jdstrand> asac: interesting-- it's only very occassionally that my wife's laptop has problems associating-- I'm gonna try associate=0 there too
<cjwatson> mvo: hmm, interesting. Why is file:// different? I had expected it to work the same kind of way as http://
<asac> jdstrand: yes do that
<asac> jdstrand: the hack doesnt help in all cases. just was added so that you can connect more regularly
<slangasek> mvo: talk to the GNOME uploaders if you want the space back... :)
<mvo> cjwatson: it does, there we have the (uncompressed) Packages file in the Release file (but on the CD we don't)
<cjwatson> right, so can we fix the bug that means we can't put the uncompressed file's information in the Release file?
<mvo> cjwatson: it may be easier to re-add the uncompressed Packages file to Release file info again in debain-cd and add code in update-manager that deals with that (+ a backport of apt so that people on hardy can still use apt-cdrom add)
<cjwatson> mvo: apt/hardy-updates ...
<mvo> cjwatson: yes, that is pretty straightforward and might be the best option
<mvo> (where backport just means backporting the small fix)
<slangasek> superm1: link added; you don't want to give me a one-liner blurb in addition?
<mvo> cjwatson: thanks, I outlined a plan in the bug
<slangasek> persia: did you have any thoughts on what we should highlight for UbuntuStudio 8.10 in https://wiki.ubuntu.com/IntrepidIbex/BetaAnnouncement ?
<slangasek> or even a link to a page?
<persia> _MMA_ was discussing that earlier, and some target language was mentioned.  Let me see if I can track down a link or anything.
<superm1> slangasek, na, there's nothing big and exciting in the alternates, just bug fixes
<stgraber> ogra-maemo, ogra: http://paste.ubuntu.com/53211/
<ogra-maemo> stgraber, uuh
<ogra-maemo> did you use --copy-sourceslist there ?
<stgraber> ogra-maemo: that's d-i
<stgraber> when selecting the LTSP option on Beta candidate cdimage
<ogra-maemo> hmm
<ogra-maemo> stgraber, are the files mentioned there in the right places ?
<stgraber> nope, only Packages.gz is there
<stgraber> no Packages
<ogra-maemo> sounds to me like the cd is broken
<philn> hi
<cjwatson> ogra-maemo,stgraber: see the above discussion with mvo; removing Packages (uncompressed) was deliberate
<philn> can someone please review #276107 ?
<cjwatson> but turns out it needs some more apt work
<cjwatson> philn: please mention what it's about, otherwise every developer has to look in order to find out :)
<philn> cjwatson: it's a MIR for cssutils
<cjwatson> philn: it already has the ubuntu-mir team subscribed; it is in the queue
<philn> okay
<kirkland> bryce: ideas?  glxinfo says:
<kirkland> Xlib:  extension "GLX" missing on display ":0.0".
<kirkland> Segmentation fault (core dumped)
<kirkland> bryce: xorg-less, intrepid on a thinkpad x61
<ogra-maemo> cjwatson, any option we could use as workaround ?
<cjwatson> ogra-maemo: with the current images, I don't think so, although mvo might have an idea
<ogra-maemo> mvo, ??
 * ogra-maemo wonders why this foldable keyboard doesnt have an alt key ... tsk, they put a windows key on it, even altgr ...
<ion_> ogra: Make caps lock a control and make the control an alt.
<ogra-maemo> ion, yeah, i indeed can remap, i just wonder what the heck the manufacturer was smoking
<ion_> Heh
<ogra-maemo> it has keys for pond, yen and internet explorer, but no alt
<ion_> :-D
<henux> How or where can I find a mentor for me?
<henux> There is an Ubuntu wiki page about becomming a mentor
<norsetto> henux: https://wiki.ubuntu.com/MOTU/Mentoring (and this is the wrong channel to ask, use #ubuntu-motu pls.)
<persia> slangasek: Beta Announcement updated.  Not much to say, and the language previously discussed was far too much spin in the context of the real improvements to some flavours.
<henux> norsetto: point taken
<ogra-maemo> stgraber, i guess you see the same on i386 ?
<slangasek> persia: ok.  That does seem rather bland; you have the option of not having an explicit US mention at all there, if you prefer
<persia> slangasek: I think it's better to have a mention.  While many users aren't going to be very excited because of the regressions (no -rt), and lack of new stuff (no ffado, not much more LASH, missing some targeted applications), others will find it useful (audacity works now).
<mvo> ogra-maemo: is lts the issue?
<mvo> ogra-maemo: the only workaround that may work is --allow-unauthenticated
<ogra-maemo> mvo, that would ignore a missing Packages file ?
<stgraber> ogra-maemo: I'd think so yes
<mvo> ogra-maemo: the error comes from the release file
<norsetto> tseliot: will the -qt gui drag in the whole kde desktop?
<tseliot> norsetto: ???
<tseliot> care to explain?
<mvo> ogra-maemo: it should DTRT when it finds a compressed file and uncompres it into var/lib/apt/lists
<norsetto> tseliot: what does it depends on? What qt/kde libraries will it drag?
<tseliot> norsetto: python-kde and the oxygen icons
<norsetto> tseliot: there is no python-kde package?
<tseliot> norsetto: python-kde4
<norsetto> tseliot: did you see what that depends on?
<tseliot> norsetto: yes, but there's nothing I can do about it
<norsetto> tseliot: so, if you make the -gtk gui install the -qt gui, somebody on gnome will see almost the whole kde desktop installed on his machine
<norsetto> tseliot: of course you can, don't impose it, leave it as a choice to the user
<tseliot> norsetto: the gtk package is a transitional package because I don't have the time to finish the GTK ui
<norsetto> tseliot: I inderstand, but don't let it point to the qt one
<tseliot> norsetto: a choice between what?
<norsetto> tseliot: between not having a gui or installing the -qt one
<ogra-maemo> mvo, will that be fixed after beta _
<ogra-maemo> ?
<tseliot> norsetto: currently the gtk ui crashes and doesn't start at all
<norsetto> tseliot: I understand, and thats not my point, my point is that you are forcing somebody who is upgrading from hardy to install tons of libraries, not even informing him about it
<tseliot> norsetto: envyng-core (the textual interface) can still be installed without having to download any dependency on kde
<tseliot> norsetto: shall I remove the gtk version?
<tseliot> and maybe add it back in Jaunty?
<norsetto> tseliot: personally, between forcing the -qt one and removing I'd rather remove it, yes
<norsetto> tseliot: if somebody still wants a gui he/she can install (but its their choice) the -qt one
<tseliot> norsetto: ok, ScottK was dealing with the bug report. Can you remove the gtk package from the archive and update the rest, please?
<norsetto> tseliot: that bug report is not approved, nothing has been uploaded
<tseliot> ah, ok
<ScottK> tseliot: Once there is an upload that doesn't build the gtk package it'll be NBS and removed semi-automatically.
<cody-somerville> Can an archive admin push exo through?
<tseliot> ScottK: ok, thanks for the information
<Riddell> cody-somerville: is it important for beta?
<cody-somerville> Its a universe package
<slangasek> cody-somerville: that's not an answer, plenty of xubuntu stuff is universe packages ;)
<cody-somerville> hehe
<cody-somerville> Its not reroll worthy material, if thats the question
 * davmor2 puts down the big hammer.  Doesn't need to hit cody-somerville with it any more
<lool> ogra-maemo: Re: gvfs not handling obex:// do you have gvfs-backends?
<lool> I was pretty sure it was supported
<superm1> ogra-maemo, lool especially since we had to patch gvfs for the bluez 4.x support....
<seb128_> superm1: there is a patch for the new bluez in the upstream gvfs svn
<cody-somerville> slangasek, charlie-tca is owning Xubuntu release notes
<cody-somerville> (for this beta)
<slangasek> cody-somerville: ok
<superm1> seb128_, i would suspect it's pretty similar to what we put together.  do you have a link?
<seb128_> superm1: http://svn.gnome.org/viewvc/gvfs?view=revision&revision=2035
<ogra-maemo> lool, i was only talking about the existing situation
<ogra-maemo> there we definately dont have it
<seb128_> superm1: it's quite some change, it's a shame if you duplicated the work rather than looking upstream if they worked on the upgrade
<superm1> seb128_, well per the date on that, our work was done before it landed upstream
<seb128_> superm1: it was in bugzilla for a while before being pushed to svn
<superm1> seb128_, i'll update the gvfs package to their patch and test it then
<seb128_> superm1: the patch is coming from fedora, I guess they are using it
<superm1> seb128_, it's likely very close to what we have then too.  ours was initially based off the one in fedora
<superm1> ill look
<pitti> superm1: hi
<superm1> hi pitti
<pitti> superm1: did you check whether your wifi card matches any of the modaliases of b43/b43legacy?
<jg> hi superm1
<superm1> pitti, there's no reason it should have stopped matching... it did match in hardy just fine
<superm1> i'll double check though
<superm1> hi jg
<jg> did you see the powertop bug I filed?
<superm1> jg, yeah i saw it pass by bug mail at some point
<lool> pitti: Re: debian #500916 urgh!  are many packages providing these?
<ubottu> Debian bug 500916 in hal "hal: FDI cache does not get updated when installing .fdi files" [Unknown,Open] http://bugs.debian.org/500916
<lool> pitti: We could quickly add some touch calls in the postinst to update the timestamps
<pitti> lool: I don't know how many do; I don't expect more than five, though
<lool> Or just rm the cache in these postinst
<lool> pitti: That sounds like a not too hard transition
<pitti> lool: rm the cache, or call the fdi cache builder, yes
<pitti> lool: the patch I sent is a quickfix which people should immediately get after teh 8.10 beta announcement, that's why I uploaded it already
<pitti> lool: I know it's not the best, but we can revert it safely, and at least it won't totally break X.org input on upgrade
<lool> pitti: Sure, I think it was the best short term thing to do
<lool> I'm looking at other options because I wouldn't want us to regress on startup time of hal
<lool> It's needed to start Xorg, so really on the critical path to login screen or desktop
<pitti> lool: right, I'm happy with getting a better solution in by hardy final
<lool> *intrepid  ;)
<genii> Does pastebinit use some hardcoded url or so? If so anyplace to easily change it. I'm currently getting http://error.000webhost.com/not_found.html                as the return url
<mvo> ogra-maemo: yes, one way or the other
<superm1> BenC, pitti and I were discussing some things about wl vs b43.  how come b43 "succeeds" to load and stays loaded even if firmware isn't found?
<superm1> BenC, it would really seem to make more sense to have it leave it's message in dmesg and then unload itself
<genii> nvm man pastebinit shows syntax to change default site
<kees> pitti: hi!  what's let to get the hardy-proposed kernel out the door?  It's (kind of) blocking security publications
<pitti> kees: slangasek needs to accept my jockey SRU to enable configuration for the new 'wl' module, then superm to verify it
<pitti> kees: I was asked to not move -21 to -updates until we have the wl configuration module as well (by the kernel team)
<slangasek> and what about verification of the other SRU bugs?
<pitti> haven't checked recently, so far rtg told me that it looked good now
<liw> "incomplete" is such a badly named bug state
<superm1> well the LBM that accompanies it needs to be uploaded still
<superm1> the one there breaks things
<superm1> rtg has had some issues with uploading the new one as i understand
<liw> calling it "needs more information" would be more descriptive and less insulting of the bug reporter's efforts to make a good report
<sbeattie> slangasek: I couldn't reproduce bug 104837 or bug 221351, and don't have enough ram for bug 257293
<ubottu> Launchpad bug 104837 in linux "kernel warns BUG: at fs/inotify.c:172 set_dentry_child_flags()" [Medium,Fix committed] https://launchpad.net/bugs/104837
<ubottu> Launchpad bug 221351 in linux "TSC Clocksource can cause hangs and time jumps" [Medium,Fix committed] https://launchpad.net/bugs/221351
<ubottu> Launchpad bug 257293 in linux "USB mouse/keyboard do no respond after resume from suspend-to-RAM on x86_64 systems with >4GB RAM" [Medium,Fix committed] https://launchpad.net/bugs/257293
<sbeattie> slangasek: for bug 236699, I'm concerned that there's a second fix that also needs to be applied; I left a comment to that effect.
<ubottu> Launchpad bug 236699 in linux "Hardy: [NETFILTER]: {ip,ip6,nfnetlink}_queue: fix SKB_LINEAR_ASSERT when mangling packet data" [Medium,Fix committed] https://launchpad.net/bugs/236699
<sbeattie> kees: got any ideas on what to test for with bug 246663
<ubottu> Launchpad bug 246663 in linux "Hardy: Reinstate ZERO_PAGE optimization in 'get_user_pages()' and fix XIP" [Medium,Fix committed] https://launchpad.net/bugs/246663
<slangasek> sbeattie: does 236699 regress any, without the additional fix?
<kees> sbeattie: not really.  All I know is that the original fix broke VMWare somehow, but I think -proposed contains the fix for that too.
<kees> 17:03 < kees> sbeattie: not really.  All I know is that the original fix broke VMWare somehow, but I think -proposed contains the fix for that too.
<kees> smb_tp: ^^ is that right?
<sbeattie> hmm, well, vmware is working here.
<smb_tp> kees, I only got the last. But I guess it is about the one thing I have to have a closer look. The first change was there IIRC but the fix for VMWARE I am not sure
<kees> smb_tp: okay.  if it turns out it's needed, we can include it in the -security build maybe?  sounds like normal vmware is okay
<smb_tp> kees, Maybe it was fixed by other (later) changes.
 * kees nods
<kees> okay, so, it sounds like rtg is needed to sort ouf the lrm upload?
<kees> s/ouf/out/
<smb_tp> kees, might be. I think he was last one touching it
<superm1> asac, what is the actual purpose of the "Create wireless network" option in NM 0.7?
<sbeattie> slangasek: re 236699 I don't know, I just happened to come across the added fix while googling to understand the original fix and how I might test it.
<pitti> superm1: at least in previous versions it was for setting up an ad-hoc network (has never really worked for me, though)
<kees> 16:57 < superm1> rtg has had some issues with uploading the new one as i understand
<kees> rtg: where "new one" was LRM
<kees> rtg: which is required for wl, and jockey
<kees> I'm lost.  :)
<sbeattie> slangasek: actually, re-reading http://lkml.org/lkml/2008/5/13/392 I think the first fix for bug 236699 does introduce a regression for reinjected larger ipv6 packets.
<rtg> nope, new one was LBM
<ubottu> Launchpad bug 236699 in linux "Hardy: [NETFILTER]: {ip,ip6,nfnetlink}_queue: fix SKB_LINEAR_ASSERT when mangling packet data" [Medium,Fix committed] https://launchpad.net/bugs/236699
<kees> rtg: oh! sorry, lBm
<rtg> I have a build issue with LBM that I need to figure out. It fixes symbol collisions with LRM
<sbeattie> the referenced git commit (e2b58a67) is the one that is being applied in 236699
<superm1> pitti, thats what I thought too, but I have never seen it work either.  I wasn't really sure how it was supposed to work anyhow though if you weren't running a dhcp server on the network you created
<kees> rtg: okay, do you have any kind of ETA?  I'd love to get the -proposed kernel out today or monday so smb_tp and I can focus on getting the -security kernels built next week for hopefully a publication on the 16th
<sbeattie> but I have no idea how to actually prove that it does or doesn't introduce that regression, not being particularly ipv6 netfilter injection knowledgable.
<rtg> kees: its next on my todo list
<kees> rtg: \m/  very cool, thanks muchly :)
<pitti> kees: \m/ ???
<pitti> you have weird ears :)
<jdstrand> pitti: does this help:
<jdstrand> \m/ *rock* \m/
 * pitti squeezes his eyes to interpret the m, knowing only \o/
<jdstrand> pitti: think back to the 80's, and headbanging
<seb128_> doing a work break now bbl
<pitti> ah :)
<jdstrand> \m/ <head goes up and down to beat of awesome tune> \m/
<jdstrand> :)
<slangasek> sbeattie: --> verification-failed, then?
<superm1> rtg, perhaps in BenC's absence, can you try to field the question that pitti and I were posing about b43/wl?   how come b43 "succeeds" to load and stays loaded even if firmware isn't found? it would really seem to make more sense to have it leave it's message in dmesg and then unload itself, and that would mean that wl could take over at that point.
<pitti> ogra-maemo: can you please forward 10-samsung-Q1-keymap.patch upstream? seems you have the hardware, and you applied the patch
<rtg> superm1: its because SSB has already claimed the PCI ID.
<superm1> rtg, but why is SSB claiming it if nothing is being done with it?
<superm1> moreover - why is ssb still loaded then?
<rtg> superm1: thats something else we need from Broadcom, e.g., get them to play nicer with upstream.
<ogra-maemo> pitti, sigh, yes, i dont want the same flaming from dannyk again i had when i asked for evtouch fdi inclusion
<superm1> right, but why is upstream doing it this way in the first place?
<ogra-maemo> pitti, i dont think he will like the layout
<superm1> it just causes spam messages up and down dmesg about how you don't have firmware, you don't have firmware
<rtg> superm1: SSB believes deep in its heart that it owns all PCI devices connected to its PCI interface.
<ogra-maemo> its specific to mobile/mid
<pitti> ogra-maemo: well, I'd say that *everything* in hal-info is specific to particular hardware :)
<superm1> rtg, pitti is that how other firmware loading drivers operate too though?
<rtg> superm1: SSB is a mezanine bus driver that arbitrates access to SSB based devices, such as b44 and b43.
<rtg> superm1: those are the on;y devices that I know of so far.
<superm1> rtg, right but it's only fair to question if that model is correct about upstream's take on this, has this discussion been challenged to them in the past?
<rtg> superm1: dunno. it happened a couple of years ago IIRC, and I don't see it changing any time soon just to accommodate a binary driver.
<bryce> kirkland: I see you mentioned an xorg problem earlier, but didn't give details... lp#?
<kirkland> bryce: hadn't filed one yet, taking a pulse if this is a new issue
<kirkland> bryce: i switched to my wife's x61 (again)
<kirkland> bryce: xorg-less worked well for me this time :-)
<kirkland> bryce: was trying to 3d acceleration working right
<bryce> kirkland: well, it's sort of a generic error - mesa failed for some reason, GLX didn't initialize, and the 3D apps could run
<bryce> kirkland: Xorg.0.log might tell you what the failure was
<kirkland> bryce: cool, thanks, i'll dig a bit deeper when i get a chance
<bryce> ok cool
<bryce> kirkland: btw, if you file a bug via `ubuntu-bug mesa` it should attach all the necessary files automatically
<kirkland> bryce: okay, I'm an idiot...
<kirkland> bryce: it seems i had to reboot (or at the very least restart X) after I uninstalled all of the nvidia extensions
<kirkland> bryce: now, 3d (compiz) seems to be working correctly
<kirkland> cjwatson: i added some basic, sticky support for browsing/searching manpages.ubuntu.com for other languages
<kirkland> cjwatson: in doing so, i looked a bit closer at some of the "language" directories where some manpages get installed
<kirkland> cjwatson: funnily, "py" and "sh"  :-)
<kirkland> cjwatson: http://manpages.ubuntu.com/manpages/intrepid/
<bryce> kirkland: gotcha
<kirkland> bryce: my bad ;-)
<tedg> pedro_, bdmurray: Could you guys try gpm-2.24.0-0ubuntu4~ppa2 in PPA to see if it fixes your respective bugs?
<tedg> cody-somerville: Could you try ^ to ensure that it doesn't break Xubuntu?  You guys use your own session manager, right?
<cody-somerville> tedg, yup
<pedro_> tedg: yep
<cody-somerville> what ppa? :P
<tedg> cody-somerville: Okay, well the patch changes GPM from using XSMP to trying GSM's DBus protocol and then falling back.  Should work...
<tedg> http://launchpad.net/~ted-gould/+archive
<tedg> Oh, wait, hasn't finished building yet..
<kirkland> DktrKranz: hey, i was trying to fix a trivial manpage bug in kmediafactory, but I can't get it to build for intrepid, depends on libdvdread3-dev, which doesn't exist
<tedg> Sorry, getting ahead of myself.
<kirkland> DktrKranz: -> #ubuntu-motu
<mvo> is someone here who has a interesst in the ghc6 packages?
<cody-somerville> mvo, I did a merge once
 * Laney does too
<cody-somerville> sistpoty loves ghc6
<mvo> excellent, I noticed a hardy -> intrepid upgrade issue that is caused by the way the ghc-pkg script is run
<mvo> I will file a bug with all details
<mvo> I was just not sure how many ghc6 users we actually have :)
<pedro_> brb
<pedro_> tedg: yes it does fixes it, it now display the right dialog ;-), thanks you!
<tedg> pedro_: Cool, let's see if it break Xubuntu now :)
<cody-somerville> Can someone please push exo through? I already have another upload to sponsor for that package :P
<TheMuso> slangasek: I am reliably able to reproduce that audio bug on another box here. Its a race purely because everything gets loaded at once, without any clear delay for one thing to wait for another. Thats the impression I get anyway.
<ogra> superm1, i cant get your ppa packages installed, bluez-audio removes everythig
<persia> ogra: What's the dpkg error?
<ogra> well, one package just removes the other
<ogra> no errors
<ogra> installing bluez-audio removes all other bluez packages
 * persia looks at the branch, suspecting the versioned conflicts have an issue
<ogra> installing bluez-utils pulls in bluetooth, bluez, bluez-alsa ad bluez-gstreamer but removes bluez-audio
<ogra> beyond that bluetoothd is constantly crasing after the first click on the applet
<ogra> installing them results in a ton of mknod errors
<slangasek> I thought bluez-audio was supposed to go away along with bluez-network and bluez-serial
<ogra> well, its in the ppa
<ogra> the instructions from marios mail left me with a half installed BT stack
<ogra> i.e. apt-get upgrade doesnt work since it needs to remove parts
 * ogra is more worried bout the about 100 lines of mknod cannot create blah, mkdev blah failed
<ogra> the applet lets me open the "add device" dialog and then crashes immediately
 * ogra reboots the device 
<ogra> no, no go
<ogra> persia, is there a list anywhere of the packages i actually need installed ?
<persia> ogra: If you enable the PPA, and upgrade an existing system, it should pick the set of packages that's right for you.
<persia> RIght.  bluez-audio was dropped.  Now there is bluez-alsa and bluez-gstreamer.
<persia> Not having bluez-audio is fine.
 * norsetto has the bluez
<persia> norsetto: 3.x or 4.x?
<norsetto> 46.x ...
<sebner> norsetto: where is your harmonica? :)
<TheMuso> lol
<norsetto> ah TheMuso is alive!
<TheMuso> Yes, but I am not normally around at this time.
 * norsetto wonders if he can ask TheMuso about his dmraid problem
<TheMuso> norsetto: Sure.
<norsetto> TheMuso: well, I can't boot into intrepid, I get thrown to a busybox prompt with the error: can't find the raid partition
<norsetto> TheMuso: if I give dmraid -ay in the busybox it continues but hen it fails becauise the fs is mounted readonly
<TheMuso> norsetto: Ok, to get passed that, run the command "dmraid -ay" then press Control + D to exit the prompt. Once you are booted, I can work with you to work out the problem/
<TheMuso> norsetto: ah ok.
<ogra-Q1> bluetoothd[5239]: segfault at 0 ip b7dfe2c3 sp bfa4ad1c error 4 in libc-2.8.90.so[b7d87000+158000]
<TheMuso> norsetto: Can I ask when this system was installed?
<ogra-Q1> persia, ^^^
<norsetto> TheMuso: hmmm, long ago, it went from Gutsy->Hardy->Intrepid
<persia> ogra: Cool!  Can I have a stacktrace with symbols?
<ogra-Q1> meh
<TheMuso> norsetto: Right...
<ogra-Q1> why alsways me
<norsetto> TheMuso: It was working fine with intrepid but after some update it stopped (about, hmmm, 2 months ago or similar)
<TheMuso> norsetto: If the system is not critical, I suggest installing with the latest alternate CD, and checking to see if the problem remains. If so, then we have more debugging work to do.
<TheMuso> As there have been a lot of dmraid fixes since then.
<norsetto> TheMuso: well, thats anoter problem, my cd-rom writer is not recognised by the kernel
<ScottK> norsetto: Perhaps try with a live cd to see if the newer kernel sees it?
<TheMuso> norsetto: ah lovely. Ok. This is interesting.
<norsetto> TheMuso: its not critical, I'm happy to use it as a chroot, but I need to boot to check another bug for bryce
<TheMuso> norsetto: Right.
<TheMuso> norsetto: What I don't understand is why it halts because the fs is read only. The root fs is always mounted read-only at first.
<norsetto> ScottK: right, and how do I burn that cd :-)
<ScottK> Ah.  Good point.  I'd assumed from your other working system.
<ogra> persia, starting it manually makes it survive
<persia> ogra: OK.  How did you break it?
<ogra> no idea
<ogra> but /etc/init.d/bluetooth start made it
<ogra> work
<ogra> err
<ogra> no not really
<persia> OK.  I'm calling this UNREPRODUCIBLE.  If you can reproduce it, I want a stacktrace, and I'll fix it.
<ogra> it crashed again now, but before it paired successfully with my freedom kbd
<TheMuso> norsetto: Oh BTW, what raid setup is it, i.e is it raid0, raid1, etc.
<persia> ogra: Very odd.  It was working fine for me on last test cycle.
<norsetto> TheMuso: raid 0
<TheMuso> norsetto: Ok. Could you boot the system, and when you get to the busybox prompt, cat /proc/modules and tell me if dm_mod is loaded?
<TheMuso> As well as any other errors you get related to raid?
<norsetto> ok, have to reboot then ... be back soon
<ogra> ok, it works with my phone
<ogra> persia,
<ogra> i can browse files
<ogra> it crashes with the gps reciever
<ogra> and the keyboard doesnt work, though it connects
<persia> ogra: Does your GPS receiver work with 3.x ?
<ogra> no
<persia> For the keyboard, wait about 30 seconds after connecting.
<persia> OK.  Not a regression then.
<ogra> nothing worked with 3.x
<persia> I could browse my phone with 3.x.  Not transfer anything, but browse.
<ogra> the icons in the device dialog are quite meaningless
<ogra> what does the star mean ?
<ogra> and is the plug a connect or a disconnect ?
<slangasek> superm1: care to unblock the mythbuntu beta page?
* slangasek changed the topic of #ubuntu-devel to: Intrepid beta released | archive: Feature Freeze | Development of Ubuntu (not support, not application development on Ubuntu) | #ubuntu for support and generaldiscussion for dapper/feisty/gutsy/hardy, #ubuntu+1 for intrepid | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<persia> ogra: The plug is disconnect.  The star is trust.
<Nafallo> zo/
<ogra> ok
<Nafallo> MEEH! FAIL!
<Nafallo> \o/
<persia> Nafallo: Are you sure it wasn't a combination of salutes from several places?
<ogra> persia, so it immediately crashes if i switch the kbd to SPP mode
<ogra> in HID it connects but doesnt work
<Nafallo> persia: not even sure what you mean, so no :-P
<persia> Hmm.  I didn't test SPP.  HID should work, but you may have to trust the keyboard (the star).
<persia> For the crash, I need a stack trace.
<ogra> right, but not today anymore
<ogra> really, i'm done
<norsetto> TheMuso: yes, all dm_ modules are loaded (7 of them)
<maix> hi, just one question: will python2.6/python3 appear in intrepid?
<slangasek> python3 is in intrepid.
<TheMuso> norsetto: Oh I'm sorry, I didn't realise thats the system you are using. So when it halts, how do you continue to boot?
<TheMuso> as in, after you run dmraid -ay in initramfs
<maix> oh ;)
<norsetto> ctrl+D or exit
<norsetto> TheMuso: ctrl+D or exit
<maix> ok sry i just searched for 2.6 one the packages website
<TheMuso> norsetto: And then it just works? Hrm.
<maix> so 2.6 won't be in intrepid?
<norsetto> TheMuso: well, it stops will the read-only fs error at one point
<slangasek> maix: correct
<TheMuso> norsetto: so how do you get through that?
<maix> :(
<norsetto> TheMuso: I don't
<ogra> persia, but s far the onl device that doesnt make the daemon segfault is my phone, all others just cause the daemon to die immediately
<TheMuso> norsetto: oh right.
<TheMuso> norsetto: So am I right in guessing that the dmraid install is on the same machine you are usin now?
<norsetto> TheMuso: indeed
<TheMuso> norsetto: Ok thats somewhat helpful. Mind pastebinning your /etc/fstab?
<ogra> persia, and i dont get why it wants me to input a PIN on the keyboard, there is no way to do such a thing
<norsetto> TheMuso: for the partition I'm using right now or the one I'm trying to boot into?
<TheMuso> norsetto: For the one you're trying to boot into. If you have dmraid installed on that install, you should just be able to mount the /dev/mapper device.
<persia> ogra: Are you sure?  My keyboard allows PIN input using the number keys and the enter key.
<ogra> my leyboard has a predefined 0000 PIN
<norsetto> TheMuso: well, in one of the attempts I made to recover, I also deleted the whole fstab, have to see if I kept a backup
<ogra> but bluez generates one for it
<persia> Oh.  Bad keyboard.
<TheMuso> norsetto: Ok.
<ogra> bad bluez i'd say
<ogra> kbd wrks fine on the n800
<persia> Why?  hardcoded passwords are inherently insecure.
<persia> Yes, but anyone can snoop your keystrokes.
<persia> (and no, it's *not* hard to brute-force bluetooth, but that's not the point)
<ogra> well, it tells me it is connected while it isnt
<ogra> oh, this time it actually said it failed
<norsetto> TheMuso: no backup, so, its empty right now; it used to be /dev/mapper/via_ceecdjfcj2 / ext3 defaults 0 1
<TheMuso> norsetto: Ok thanks, I now know what dmraid metadata format you are using, which possibly explains the failure.
<TheMuso> norsetto: Do you have dmraid installed on the install you are using now?
<norsetto> TheMuso: yes
<TheMuso> norsetto: Ok, if you could pastebin the output of "sudo dmraid -s" plesae
<TheMuso> please
<norsetto> TheMuso: http://ubuntu.pastebin.com/d461415f
<pitti> slangasek: yay, congrats to the beta release!
<slangasek> pitti: I believe I now owe you a consolekit patch :)
<pitti> slangasek: no hurry, I'm about to go to bed, and won't be at home over the weekend anyway
<slangasek> ok; then maybe I owe you a consolekit upload instead
<TheMuso> norsetto: Ok, if you could also pastebin "sudo dmraid -n", and then create a temporary dir, go into it, and run "sudo dmraid -rD", tar the dir up, and email it to me, that would be great. That gives me a dump of your metadata so I can work things out more easily on my end.
<pitti> slangasek: as you prefer; mailed patch is fine, too
<TheMuso> norsetto: One more thing, how old is the motherboard?
<norsetto> TheMuso: dmraid -n: http://ubuntu.pastebin.com/d51f11ef9
<soren> What do I do if I want a package to be built by a different source package? Obviously, I just start building it in the new package, but will soyuz just let the binary package automatically replace the one built by the old source package?
<slangasek> pitti: well, I would like *my* console-kit-daemon to stop crashing too, so I'll probably upload :-)
<slangasek> pitti: where should I send the patch upstream?
<norsetto> TheMuso: I think I bought it end 2004/beginning 2005
<pitti> slangasek: I'm pretty sure I fixed your's with the upload which is sitting in unapproved
<TheMuso> norsetto: ok.
<slangasek> pitti: oh, right
<pitti> slangasek: I sent mine to bugzilla.freedesktop.org, and it got committed within hours
<slangasek> pitti: let me get that first, then :-)
<pitti> slangasek: you should have some bug mail about bug 263245, with the link to upstream, and details
<cjwatson> soren: yes, if the version is higher
<ubottu> Launchpad bug 263245 in consolekit "console-kit-daemon crashed with SIGSEGV in fclose()" [Undecided,In progress] https://launchpad.net/bugs/263245
<cjwatson> soren: obviously please stop building it from the old one too
<slangasek> pitti: right; fwiw, I tried the test you provided, and also couldn't reproduce the crash that way
<soren> cjwatson: It's the only binary the old source package built, so I just file a removal request?
<cjwatson> soren: yeah
<soren> cjwatson: Great. Thanks.
<pitti> slangasek: I never actually saw that crashing, apparently glibc uses the moon phase divided by the dollar conversion rate to decide whether it returns EBADFD or a segfault :/
<pitti> slangasek: but the stack trace on the bug was pretty clear
<norsetto> TheMuso: themuso@ubuntu.com ?
<TheMuso> norsetto: Thats fine, thanks.
<pitti> slangasek: (on that bug and on all the gazillion dupes)
<slangasek> pitti: heh
<TheMuso> norsetto: Basically the problem is that dmraid used to use an init script for initramfs and latre in the boot to load everything, however I switched it to using udev. I'm guessing that udev's vol_id can't correctly identify your dmraid array, hense the droppign to an initramfs prompt.
<pitti> slangasek: the fun thing is, that we don't even *have* logrotation for that history file (which is a bug of its own), so I don't see why the file should change underneath consolekit so often
<slangasek> right
<pitti> slangasek: but anyway, please give it a try and let me know
<TheMuso> norsetto: So I am going to have to get vol_id to use dmraid somehow.
<norsetto> TheMuso: I see, that could indeed explain it
<TheMuso> norsetto: However, that doesn't explain the read-only fs error you get later in the boot.
<TheMuso> norsetto: Thanks. I'll get back to you when I find something.
<TheMuso> norsetto: Looks like I'll be able to test this metadata in a vm, which is useful.
<norsetto> TheMuso: thanks Luke, you are GREAT!
<TheMuso> norsetto: You're welcome.
<psusi> TheMuso: ping
<TheMuso> psusi: pong.
<psusi> TheMuso: hey... I do a little work on dmraid sometimes and since it looks like the general trend these days is to move to bzr, and I noticed that you had imported dmraid into bzr, I decided to try to learn to use it for future work on the package, but now that I have it checked out, it only contains the debian/ directory
<psusi> what gives?
<TheMuso> psusi: Yes thats how many packages I've seen have their bzr packaging done. However, I kinda don't use it any more, because I just forgot to update it. As it is, I am now going to be working on the dmraid packaging for Ubuntu and debian on alioth. The plan is to do everything in debian, and sync the dmraid package. I co-maintain it with a prospective DD from debian.
<psusi> ahh, I see
<psusi> I thought the idea was for the lp bazzar repo to contain branches for each upstream release for easy merging back and forth with the current ubuntu code base which could then just be checked out and tarballed to make a package
<psusi> which is why I was very confused to only see the contents of debian/ in the repo
<TheMuso> psusi: Until we use bzr for all packages, everyone works differently.
<TheMuso> as in, everyone uses bzr for packaging somewhat differently.
<ogra> persia, the headset actually connects, uses the proper 0000 PIN, but fails to play any sound
<psusi> hrm.... then in the future I guess I should go back to just hacking on the debian source package and attach the debdiff to the bug report?
<persia> ogra: Using aplay -D ?
<psusi> for dmraid that is
<ogra> persia, yep, following the instrictions in superm1's mail
<ogra> i think its not happy about the 44.1KHz
<persia> Odd.  I'll admit to not getting my handset to play sound, but that's the same as what I had with 3.x
<ogra> well, at least it airs and doesnt crash the daemon
<persia> Honestly, the only improvement I see with 4.x over 3.x is the better interface, my keyboard works, and there's a bit more support for OBEX.
<ogra> i even get a notification
 * ogra wishes his kbd would work 
<persia> Yeah.  Not crashing the daemon is one of the big improvements between 3.x and 4.x :)
<ogra> but the PIN generation definately prevents that
<TheMuso> psusi: yeah sounds sane, or at least a diff against the latest svn. When things are going properly, I'll let you know where to find the svn.
<ogra> and SPP just kills the app
<persia> There must be some hint somewhere.  I'm annoyed that I don't get PIN generation for my handset, and have to use 0000.
<psusi> TheMuso: ok
<ogra> why the heck do you need a PIN there ? i have only seen PIN input at the host yet, never at the device
<persia> Because I have buttons on it, and so I don't see the reason to not enter a PIN?
<ogra> and how are you supposed to put in a PIN on a hedset ? morse it with the power key ?
<persia> (It's a little phone for your phone, complete with it's own address book and microSD slot)
<ogra> my headset is a headset
<persia> Depends on the device.  Mine is a handset
<ogra> it has three buttons
<ogra> power, vol up and down
<persia> for that, I can see hardcoding a PIN.
<ogra> so how would i be supposed to type in a pin for it
<persia> Anyway, the point being that I want to enter a PIN for both my handset and my keyboard, and you want to not enter a pin for your headset and your keyboard.
<ogra> no, it *has* a hardcoded PIN builtin
<ogra> but there is no way to type in the pin on the computer side
<persia> Since the code sets 0000 for all audio, and NNNN for all keyboard, there must be a key somewhere we can hint.
<ogra> same goes for my gps and my keyboard
<ogra> they all have factory hardcoded PINS
<ogra> and i cant type in a PIN in bluez anywhere
<ogra> its the wrong way round is what i try to say
<ogra> the only device where it makes sense is a phone
<ogra> where you have a numbepad
<ogra> *number
<ogra> persia, oh, i didnt mention, there is a public holiday in germany tomorrow, i might be around less than normal
<bryce> slangasek: do uploads need to get bumped in still, or is the queue just backed up?  I uploaded -ati this morning but seems to have not gone through yet?
<persia> ogra: I'll just chalk it up to latency then.
<ogra> no, i mean i didnt tell lool or davidm
<ogra> in cae someone looks for me
<davidm> what's up?
<NCommander> persia, so, I'm a member of ~bluetooth now ;-). libpam-blue is fixed
<persia> NCommander: Excellent news both.  Any of the rdepends still outstanding?
<NCommander> persia, that was the lastone
<NCommander> superm1 posted that they were doing beta testing, and then it would get dumped into the archive post BetaFreeze
<persia> Well, it needs more test reports.  Do you have hardware?  Does it work for you?
<NCommander> persia, I'll test it with my cell phone this weekend
 * NCommander finds getting GSM DUN to work is like trying to pull teeth out of your skull
 * TheMuso hopes to test with his phone, and some Braille displays this weekend.
<NCommander> So I'll be testing OPP, voice gateway, and DUN/SPP
<ogra> slangasek, hmm, if the freeze is lifted, could you let midbrowser out of its jail ? (i uploaded shortly before your announcement) ... i'd like to have it in tonights image
<Ng> something changed very recently wrt thinkpad hotkeys, didn't it? mine stopped working today
<persia> TheMuso: Would you mind also checking the Braille displays both with the intrepid stack, and with the intrepid stack + crevette's bluez-gnome 0.28?  If there's a regression with 4.x, I'm curious if there is also a regression with 0.28, which fixes some (but not all) of the issues.
<Ng> hmm, ish, some are working that weren't, but at least one that was working, isn't
<nxvl> Ng: on my T61 they work fine, which hotkey is not working for you?
<TheMuso> persia: I intend to test with the current stack in intrepid, and then the stack in the ppa.
<Ng> nxvl: Fn-F4 (suspend)
<Ng> nxvl: I use it regularly, and this afternoon is the first time it's not worked
<nxvl> i will need to suspend my machine
<nxvl> ugh
<nxvl> here we go
<Ng> I don't seem to get anything in /var/log/acpid either for the last month or so
<slangasek> bryce: the queue is not unblocked yet; I'm tying up lose ends and will flush the queue ASAP
<ogra> Ng, are you sure uswsusp isnt installed ? its known to break suspend and friends
<nxvl> working
<ogra> and gets pulled in by a recommends at
<ogra> m
<Ng> ogra: I would never install uswsusp ;)
<ogra> Ng, but gpm would ;)
<persia> TheMuso: OK.  If you end up with extra time and could also test bluez-gnome (but not gnome-user-share) from https://launchpad.net/~bmillemathias/+archive in the case that 4.x has significant regressions, I'd appreciate it.  We've held back the update to 0.28 in anticipation of the 4.x transition, but we really need to update at least one of them (except I don't want to break things that work without updating)
<nxvl> Ng: are you with intrepid already?
<Ng> nxvl: yep, have been for a couple of months
<NCommander> persia, anyway, I just installed the transition packages :-)
<nxvl> yeah, it worked here on my T61
<nxvl> with intrepid
<TheMuso> persia: Sure, I'll make time. These displays aren't mine, but I will have access to them, so I will want to get as much good testing as possible.
 * NCommander notes that this bluetooth transition really waited to the very end of the cycle ;-)
<bryce> slangasek: ok cool
<nxvl> wow it even suspended the KVM i was running
<nxvl> that didn't happend in hardy
<nxvl> \o/
<persia> TheMuso: Thank you.
<Ng> nxvl: hmm, thanks for checking that. i guess I need to dig around for whatever it was that changed
<torkel> Ng: https://bugs.launchpad.net/ubuntu/+source/hal/+bug/267682
<ubottu> Launchpad bug 267682 in hal "Hotkeys no longer working in Intrepid on Thinkpads" [Critical,Fix released]
<Ng> torkel: nice, thanks
 * calc sees the lwn article about 5s boot and wants that in 9.04 :)
<superm1> ogra, that's correct, bluez-audio should be no longer there
<superm1> ogra, it's replaced by bluez-alsa and bluez-gstreamer (fully intended)
<ion_> calc: Mind sharing the URL for the lazy ones among us? :-)
<calc> http://lwn.net/Articles/299483/
<superm1> ogra, and apt-get upgrade should do the trick since bluez-utils depends on bluetooth which recommends bluez-alsa/gstreamer and conflicts bluez-audio
<ion_> Thanks
<calc> apparently they have the kernel boot bit down to 1s now and will be .5s for 2.6.28
<slangasek> calc: the 5s boot was a kludge, it wasn't done with a generic kernel on arbitrary hardware
<Nafallo> meeh. I was just about to suggest we move to 2.6.28 for the Ibex ;-)
<calc> slangasek: true, though they mention that by including some modules in the kernel directly and subbing one with initrd for uncommon hardware it would work for most
<superm1> slangasek, it will be unblocked after our mirrors are fully synced
<slangasek> superm1: ok
<calc> i'm still reading the article though so perhaps they did other cheats, not sure
<superm1> ogra, the  trick is don't try to install bluez-audio now :)
<superm1> NCommander, don't expect much out of voice gateway yet.
<superm1> NCommander, and for DUN, you'll need to use rfcomm
<NCommander> superm1, yes, I know, I've done rfcomm
<NCommander> How's A2DP looking these days?
<NCommander> (aka, still a **** to setup?
<superm1> NCommander, well i've got a stereo headset that works pretty well
<NCommander> Yeah, but its still tricky to get the headsets to work just right
<superm1> the problem is that ALSA doesn't make virtual devices that can be offered to apps at the moment when queried
<superm1> so the current experience is  this:
<superm1> 1) Pair device through gui
<superm1> 2) set app to use the device called "headset"
<superm1> if you make an asoundrc you can redirect all output to this device
<TheMuso> superm1: What needs to be done to correct this?
<superm1> TheMuso, upstream is adding in a new framework for the rest of it
<TheMuso> Unfortunately I don't have a headset, but I could try bluetooth from one computer to another and make an audio service available..
<TheMuso> superm1: Right. Pulseaudio is also going to support bluetooth natively in a future version.
<superm1> TheMuso, yeah there are three fronts for audio that need the improvement
<superm1> pulseaudio is one of them
 * TheMuso nods.
<superm1> gstreamer and alsa both still need pieces to that framework too.
<superm1> but nonetheless, this is still an improvement over the last set through
<TheMuso> Agreed.
<slangasek> superm1: "if you make an asoundrc" - that's improved then, last time I tried that I couldn't get things like ekiga to work with bluetooth even using an asoundrc
<superm1> slangasek, i was able to get non mplayer, vlc, and myth to all handle it
<superm1> slangasek, mplayer w/o the asoundrc too (it supports specifying device on command line)
<slangasek> it's conceivable that ekiga is special :P
<superm1> does it use gstreamer?
<slangasek> no
<superm1> oh hum.  i say special then too.
<TheMuso> Can I assume that the bluetooth stack has an alsa plugin that it uses?
<kirkland> superm1: hmm, regarding bluetooth....
<superm1> TheMuso, yeah it does
<superm1> TheMuso, part of the NEW bluez-alsa package
<slangasek> TheMuso: yes; however, some apps run afoul of the fact that you can't enumerate bluetooth alsa devices
<kirkland> superm1: i don't see my bluetooth device, on my laptop
<kirkland> superm1: it doesn't appear in lspci or lshw
<TheMuso> slangasek: Right. I wonder if thats the apps, or the plugin. This used to be a problem with the pulseaudio plugin.
<superm1> kirkland, generally lsusb is where you'll see it
<superm1> TheMuso, its a problem with the plugin right now
<kirkland> superm1: ah, okay, Bus 001 Device 005: ID 0a5c:2110 Broadcom Corp. Bluetooth Controller
<TheMuso> superm1: Right I thought as much.
<superm1> their changes will allow it to be part of the enumerated device eventually, by creating virtual devices
<slangasek> TheMuso: problem with the plugin that you can't enumerate outputs; problem with the apps that you can't manually specify an output...
<TheMuso> slangasek: Right, I know ekiga is one of those culprets.
<TheMuso> Unless thigns have changed this cycle.
<slangasek> maybe it's changed in the ekiga ppa package :)
<kirkland> superm1: i don't see any devices when i tell it to "Setup New Device"
<TheMuso> superm1: I assume setting up an audio service on one machine, and making it available by bluetooth to another is a good way of testing?
<superm1> TheMuso, depending on which direction the audio service is providing on the other machine sure
<superm1> TheMuso, there are multiple audio services available
<TheMuso> superm1: right
<superm1> TheMuso, linux<->linux you won't get the correct audio services provided yet
<TheMuso> right
<superm1> kirkland, check that the daemon is running, and make sure you have all 4.x packages now - one of the guys wasn't getting bluez-utils to update correctly
<superm1> until he manuall did apt-get install bluez-utils
<charlie-tca> I downloaded the MD5SUMS text file on http://cdimages.ubuntu.com/xubuntu/releases/intrepid/beta/ to verify md5sums
<kirkland> superm1: packages don't look right: http://paste.ubuntu.com/53303/
<charlie-tca> on the CD downloads. I got an html file that is a 404 error page.
<superm1> kirkland, yup that's your problem
<superm1> kirkland, apt-get install bluez-utils and it should go
<charlie-tca> Does it take time for the server to generate the file?
<kirkland> superm1: odd, okay, installing
<superm1> kirkland, i suspect its because the PPA is still providing an "old" bluez-audio binary package
<superm1> and its confusing apt
<TheMuso> NBs packages in PPAs are quite possible AFAIU.
<wgrant> tedg: Regarding bug #261084, I think there might actually really be lots of keypresses. I'm not sure who to blame for them, however.
<ubottu> Launchpad bug 261084 in gnome-power-manager "Suspends again right after resume" [High,Confirmed] https://launchpad.net/bugs/261084
<wgrant> Er.
<wgrant> Not that one.
<wgrant> Bug #261724
<ubottu> Launchpad bug 261724 in gnome-power-manager "Brightness OSD doesn't stop adjusting" [Medium,New] https://launchpad.net/bugs/261724
<RAOF> Hm.  Now that I've paired this mouse with the new bluetooth stack, how do I actually make it work as a _mouse_?
<tedg> wgrant: Yeah, I realize.  But, I think debouncing them in GPM will work.
<cjwatson> charlie-tca: not to generate it, but if you're using a mirror then it might not have copied over yet
<tedg> wgrant: It may even be funky keyboard controllers handling those differently.
<wgrant> tedg: OK. Testing now.
<tedg> wgrant: It's odd that there are SO many in some of the reports.
<charlie-tca> Thanks
<wgrant> tedg: Has something changed recently? It worked fine in Hardy.
<charlie-tca> I'll wait a bit and try again
<cjwatson> charlie-tca: (technically, cdimage.ubuntu.com is a mirror of the hidden master site)
<charlie-tca> Thank you. I didn't know that
<cjwatson> charlie-tca: I can confirm the file is there on the master, though
<cjwatson> charlie-tca: and if you go to http://cdimage.ubuntu.com/ you'll see an Archive-Update-in-Progress-... file
<charlie-tca> Then I should wait
<tedg> wgrant: I think there could be two things.  One is the new X input stuff has changed drastically.  Two, GPM used to limit the number of events that it would accept.  But that was causing other problems and got removed.  I think it should be removed, but it might have been hiding this keypress problem.
<cjwatson> cody-somerville: can we link to cdimage.ubuntu.com in the Xubuntu announcement rather than cdimages.ubuntu.com? the former has generally been preferred
<johanbr> RAOF: Does your mouse show up under "Input devices" in the bluetooth applet? If so, I think it should just work.
<RAOF> johanbr: Where would this magical "Input Devices" be in the bluetooth applet? :)
<RAOF> johanbr: Note, this is the bluez 4.x stack from the PPA I'm testing.  I know how to do this with the old stack.
<cody-somerville> cjwatson, Certainly.
<cjwatson> thanks
<johanbr> RAOF: Ahhhh. I didn't realize that. Still, try the Services tab in the bluetooth applet.
<RAOF> johanbr: "Services" tab? :)
<johanbr> Oh, that's changed too? :)
<johanbr> Then I'm no help, I'm afraid.
<johanbr> Which PPA is this, by the way?
<RAOF> The one from ubuntu-devel(-discuss?)
<RAOF> Behold, your new bluetooth overlords! http://img56.imageshack.us/img56/4409/screenshotbluetoothprefbs0.png
<kirkland> superm1: okay, i've got the new packages installed, and the daemon is running
<wgrant> tedg: I'm afraid it doesn't help.
<kirkland> superm1: bluetooth-applet doesn't seem to see the local hardware though
<tedg> wgrant: :(
 * TheMuso goes to install the new bluetooth stack on his notebok.
<TheMuso> notebook
<kirkland> superm1: spoke too soon .....
<RAOF> kirkland: You're also playing with the new bluez stack?
<kirkland> RAOF: true dat
<TheMuso> The only bluetooth hardware I have currently is my phone.
<TheMuso> superm1: when I run apt-get dist-upgrade for the bluetooth stuff, I am told that bluez-utils wants to be kept back?
<TheMuso> superm1: that doesn't sound right...
<nxvl> schroot is equivalent to pbuilder or the difference between them is that pbuildes is meant to be use for development/package build, and schroot as a normal chroot?
<persia> RAOF: Open the preferences panel.  Highlight your mouse.  Click the star to trust it.  Wait 30 seconds or so, and it ought act like a mouse (or at least this works for my keyboard)
<persia> nxvl: They aren't exactly equivalent, but they serve many of the same use cases.
<wgrant> nxvl: IMO the difference is that pbuilder is crap :P
<wgrant> nxvl: schroot is often used with sbuild.
<johanbr> RAOF: Well, when I upgrade the stack it wants to remove (among other things) bluez-input. That could be related to your problem. Unless that functionality is now folded into bluez itself.
<nxvl> wgrant: sbuild?
<nxvl> hmm, interesting
<slangasek> johanbr: yes, it's folded into the main package because the package split was gratuitous
 * nxvl HUGS wgrant 
<wgrant> nxvl: Somewhat like pbuilder, except it's what the buildds use, and is nice.
<nxvl> persia: yes, i'm just checking schroot and i'm thinking in removing all my pbuilder envs, but wanted to check if i will be able to build my packages as easy as with pbuilder
<wgrant> sbuild -A -d intrepid something.dsc
<nxvl> ugh, why is it trying to install exim
<persia> nxvl: Indeed.  I like to use both sbuild -A -d intrepid-i386 and sbuild -d intrepid-amd64 ever since I got hit with my first FTBFS for not building arch-all.
 * nxvl hates exim
 * wgrant loves postfix
<superm1> TheMuso, i just deleted the old binaries from the PPA, hopefully this should be fine now and allow you to dist-upgrade
<persia> nxvl: It just wants an MTA.  Give it *any* MTA, and it will be happy.  It wants to mail you build logs.
<nxvl> wgrant: yes, postfix is kewl
<superm1> TheMuso, i believe bluez-audio was throwing things off
<superm1> its being available
<cjwatson> nxvl: yet you don't have it installed ;-)
<nxvl> cjwatson: i didn't need it still :D
<TheMuso> Ok I'll wait a bit.
<superm1> johanbr, yes it is folded into bluez itself now
<nxvl> persia: that's what i thougt, but i still hate that the first option for an mta for every package that needs one is exim
<slangasek> apachelogger: erm, your kgrubeditor upload has references to LP bugs in the upstream changelog, but none in the debian/changelog :)
<slangasek> apachelogger: and the diff is large; why did this not go through a FFe?
 * wgrant creates a bugfix release that is a complete rewrite.
<nxvl> sbuild looks interesting
<nxvl> how wasn't i aware of that tools before
<johanbr> RAOF: My BT mouse worked straight away after using the pairing wizard thingy.
<johanbr> With the new stack, I mean.
<mathiaz> nxvl: be sure to check this howto: https://help.ubuntu.com/community/SbuildLVMHowto
<wgrant> mk-sbuild-lv makes things nice and easy
<mathiaz> nxvl: that's what kees and I (and sure others...) are using for our build environment.
 * TheMuso uses sbuild + LVM snapshots.
<Ng> hmm, how does g-p-m get keyboard standby/suspend events?
<persia> Mind you, pbuilder is handy to have around: sometimes it exposes bugs in sbuild (and the converse is slightly more frequent)
 * nxvl will NOT use LVM
<nxvl> :D
<superm1> TheMuso, in case that wasn't the actual root cause of why bluez-utils isn't offered in a dist-upgrade (but works if you apt-get install bluez-utils), how else can such a thing be debugged?
<nxvl> mathiaz: but thanks :D
<kees> nxvl: aw, why not, it rocks?
<nxvl> mathiaz: i will give it a look
<persia> nxvl: Using schroot without LVM is frustrating and annoying.  Just use LVM for 20G or so for schroot.
<wgrant> LVM is great.
<slangasek> doko: python-reportlab> 275kloc debdiff, no FFe?
<slangasek> nxvl: LVM is teh aewsum
<nxvl> kees: a) i don't like it b) i'm not going to resintall my system
<nxvl> :D
 * nxvl hates it
<slangasek> weirdo
<wgrant> nxvl: Why?
<nxvl> reinstall*
<persia> nxvl: Do you have a reason, or have you just not tried it.
<persia> No need to reinstall.
<slangasek> I wouldn't reinstall, anyway; 1) shrink root partition, 2) create LVM, 3) move root to LVM
<persia> Resize a partition: get some space free.  Put it in a volume group.
<kees> nxvl: heh. why don't you like it?  (I can understand the latter, but you can always add a drive for it or resize down an existing partition)
<nxvl> i actually had a bad experience with it a while ago involving data lost
 * wgrant has migrated a few systems that way.
<TheMuso> superm1: I'm not sure.
<kees> nxvl: ah, I put all my LVM physical drives on md devices.
<slangasek> nxvl: it's not reiserfs... :)
<wgrant> Heh.
<kees> nxvl: or XFS.  :)
<slangasek> indeed!
<nxvl> slangasek: for me those are the same
<nxvl> i promise to try it when i buy my desktop, after the summer
<nxvl> :D
 * wgrant uses boring old ext3.
<nxvl> but on my laptop there is no way
<nxvl> :D
<nxvl> ext3 ftw
<kees> wgrant: me too!  after I found out it has a resize _count_ limit of 1024.
<wgrant> (on crypto-LVM, though)
<wgrant> kees: Does it really? I don't think I'm ever likely to hit that, but that's interesting...
<slangasek> nxvl: well, your experience is not at all typical, fwiw.
<nxvl> that reminds me that i need a bigger HD and an UDS to IDE/SCSI connector
<Twigathy_> woooo, bugtastic - my hpt374-based SATA controller doesn't work in Hardy because hpt366 loads on boot. Blacklisting it doesn't work either!
<kees> wgrant: yeah, I had avoided ext3 because I thought the limit was like, 4, or something.
<nxvl> s/UDS/UDB
 * ion_ uses trustworthy old ext3. Donât feel like usin XF\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0
<nxvl> ugg
<kees> wgrant: no idea where I got that idea.
<nxvl> USB*
<nxvl> i need to sleep
<kees> ion_: *rofl*
<wgrant> ion_: Hahahah
<slangasek> kees: blink, why would you have a resize count limit at all? :)
<wgrant> slangasek: I am wondering the same.
<kees> slangasek: due to the on-disk structure limits.  ext3 grows by chaining superblocks or something crazy.
<wgrant> Ah.
<slangasek> ah, doh
<wgrant> What do shrinks do?
<slangasek> shrinks can't be done on-line
<nxvl> btw, why is LVM better/cooler?
<kees> wgrant: those do a "real" resize, and can't be done on a live fs.
<slangasek> perhaps this is why :)
<cjwatson> kees: is that just an online resize count limit?
<slangasek> nxvl: better/cooler than what?
<kees> nxvl: because it makes partitioning, growth, and disk additions nearly trivial.
<slangasek> nxvl: there's nothing else even comparable to LVM :-)
<wgrant> I knew they couldn't be done online.
<wgrant> But I guess that makes sense.
<wgrant> slangasek: ZFS!
<nxvl> slangasek: heh
<kees> cjwatson: I *think* so, but I'd have to ask my ext3 knowledge-source: val
<wgrant> Live disk migrations, too.
<cjwatson> LVM> because you don't have to repartition - you can just say "I have some more space, please shove it on the end of this LV"
 * nxvl love the sarcastic slangasek better than the grumpy one :D
<cjwatson> you don't get stuck in the situation where you have to move a partition before you can grow the one before it
<nxvl> loves*
<superm1> TheMuso, yeah i'm pretty convinced that will resolve it.  bluez already conflicts/replaces bluez-audio, so the only thing that could be left to do is make the transitional package bluez-utils conflict/replace if it doesnt improve
<slangasek> also, "please give me a snapshot of my workspace so that I can fiddle around with package builds"
<slangasek> :-)
<nxvl> kees: and what if i don't have the need of that
<TheMuso> superm1: Right.
<wgrant> Or "please give me a snapshot so I can work out whether I am going to kill something by upgrading to Intrepid"
<cjwatson> nxvl: obviously if you never ever change your partitioning then you don't need LVM
 * nxvl has a 10Gb partition for the system and the rest for home
<nxvl> no need for more
<slangasek> except you're missing out on snapshots
<slangasek> you don't know what you're missing :)
<wgrant> Snapshots are awesome.
<nxvl> then i can add cjwatson's rationale to my why-i-don't-use-lvm list
<nxvl> :D
<cjwatson> (note: I haven't got round to trying snapshots yet ...)
<RAOF> Snapshots are great fun when doing big infrastructure testing.
<sjoerd> 8/window /window
<cjwatson> I use LVM on my server because it lets me allocate space from multiple disks without having to have partitioning constrained by what sizes the disks happen to be
<RAOF> The big trick is to remember to change fstab to mount the snapshot as / rather than your _real_ /
<wgrant> RAOF: I'm not going to forget that again...
<cjwatson> and when one disk is getting old or too small, I can move everything off it with pvmove and stick a new one in
<nxvl> so i can have a snapshot of my whole disk, so when i break something upgrading to the development release i can downgrade in a bit and it the same state it was before?
<cjwatson> it's a little like discovering a corkscrew and wondering why you spent years opening bottles with your teeth
<RAOF> nxvl: Absolutely.
<wgrant> nxvl: Snapshots are of LVs, not disks, but yes.
<cjwatson> ... I hypothesise
<wgrant> cjwatson: Heh. Perhaps.
<nxvl> cjwatson: i use lighters :D
<nxvl> cjwatson: or the table
 * cjwatson makes a note not to stand anywhere near nxvl when he opens a bottle of champagne
<nxvl> todays has been a day, i discovered 2 things i want to try in a row
<nxvl> :D
<cjwatson> though I do have friends who have done the trick of opening a bottle of champagne with a sword
<nxvl> cjwatson: heh, i was thinking more on beer bottles
<nxvl> for the taking the corks out we use to push them to the bottom :D
<nxvl> so we make them go in instead of out
<kirkland> cjwatson: Napolean style!
<nxvl> one time we break a bottle making that, it didn't stand the pressure
<TheMuso> ok this is weird. The bluetooth device setup wizard looks correct, but when I review it with orca, every line of text is being read to me wice.
<TheMuso> twice
#ubuntu-devel 2008-10-03
<nxvl> TheMuso: the problem is, it is an orca or a bluethooth wizard bug
<TheMuso> nxvl: I'd say the latter.
<TheMuso> Ok, so I choose forward in the wizard, and it asks me for a device to set up, yet there is nothing listed.. Has something gone wrong somewhere.
<nxvl> heh, kees twittered parts of the conversation
<TheMuso> s/./?/
<nxvl> :D
<TheMuso> and this is after a reboot mind you, so everything is running.]
<superm1> TheMuso, can this be caused by the translation system in use for the wizard?
<TheMuso> superm1: I wouldn't think so, but am unsure.
<superm1> TheMuso, the source is pretty small for that wizard (single file), in ./wizard/main.c
<superm1> TheMuso, so if you've seen this happen before and recognize it
<TheMuso> superm1: I haven't seen it, but I'll have a dig.
<TheMuso> The preferences applet is also not entirely accessble, in that the device visability doesn't appear to be available in the tab order.
<TheMuso> visability
<TheMuso> visibility damn typing
<kees> nxvl: cjwatson totally cracked me up on the corkscrew quote.
<nxvl> kees: heh
<nxvl> :D
<nxvl> been there
<kirkland> superm1: okay, i've successfully associated both my treo and a wireless headset via bluetooth
<kirkland> superm1: i'm trying to do something useful with that now.....
<TheMuso> ok I have set my notebook bluetooth to always be visible, yet my phone can't find it.
<kirkland> i used the bluetooth-applet to send a simple test.txt file to my phone, and the phone turned on, like it was going to do something, but nothing happened
<cody-somerville> TheMuso, it might not be offering a service your phone knows how to interact iwht
<TheMuso> cody-somerville: Right.
<kirkland> i also paired my BT headset, and expected to see new alsa devices
<kirkland> not yet, though
<kirkland> on the bluetooth-applet preferences page, what's the blue "i" information looking icon do?
<superm1> kirkland, you wont see a new alsa device
<TheMuso> hrm ok trying to run hcitool scan gives me a connection timed out, even though there is a device in range thats visible.
<kirkland> superm1: okay, how can i test something useful, now that i've paired a couple of devices?
<superm1> kirkland, so audio devices, aplay -D headset FILE
<superm1> headset is the name of the device made by the ALSA plugin that isn't enumerated
<superm1> TheMuso, multiple scans back to back will cause that i believe
<TheMuso> superm1: this is the first one after a fresh reboot
<superm1> TheMuso, then your bluetooth device might need to be reset
<superm1> a lot do (this means a small kernel quirk is necessary too)
<TheMuso> right
<superm1> hcitool reset should do the trick i think
<TheMuso> ok will try that in a sec.
<kirkland> superm1: where do i find that device name?
<superm1> kirkland, for sending it to your phone, your phone needs to be expecting the transfer generally
<superm1> kirkland, that "is" the device name
<superm1> headset
<superm1> it's hardcoded in /usr/share/alsa/bluetooth.conf
<kirkland> hrm, that's not working
<apachelogger> slangasek: Riddell told me to go ahead with upload, I guess he was going to grant FFe. As for the LP bugs, I have to have a talk with upstream about bugs affecting ubuntu packages and bugs affecting upstream projects, but yes, in general closing them in the changelog would have been healthy ;-)
<TheMuso> superm1: what referrs to /usr/share/alsa/bluetooth.conf in terms of making sure that file gets included?
<superm1> TheMuso, /usr/share/alsa/alsa.conf
<kirkland> superm1: okay, i gotta run...  i'll be back online later tonight and try some more
<TheMuso> superm1: ah.
<superm1> TheMuso, alsa-lib was one of  the patched apps on the PPA
<TheMuso> well I didn't get it.
<TheMuso> Ah I know why, I am running a test version of libasoudn2.
<superm1> TheMuso, should have seen 1.0.17a-0ubuntu4~ppa1
<TheMuso> libasound2
<superm1> ah there you go
<TheMuso> Yeah testing a fix that I will be likely uploading in the next day or so.
<TheMuso> superm1: hrm ok, a hcitool reset made no difference. still connection timeout for hcitool scan, and it also seems looking more closely that I can't set the visibility in the preferences...
<TheMuso> I haven't tried any of this with the old stack either, so wasn't sure if it was working prior to this or not.
<superm1> TheMuso, do you have a tray icon present?
<TheMuso> superm1: Yes.
<superm1> TheMuso, hum.  if you want to look a little closer, try stopping the service and  running sudo bluetoothd -nd
<superm1> you can see if there are errors from the daemon
<TheMuso> superm1: ok.
<TheMuso> bluetoothd[7370]: Can't set link policy on hci0: Device or resource busy (16)
<TheMuso> bluetoothd[7368]: Can't read class of adapter on /org/bluez/hci0: Input/output error (5)
<superm1> TheMuso, that would sound to me like problems directly with your device then
<superm1> TheMuso, there is a handful of quirks to experiment with btusb (see modinfo btusb)
<TheMuso> superm1: Right. What device nodes are usually used? USB nodes directly?
<TheMuso> superm1: ok will ahve a play.
<superm1> TheMuso, there is no /dev node made afaik.
<TheMuso> right
<superm1> (or used for that matter)
<superm1>  okay i'm taking off for a bit, if you've got some other questions kirkland or TheMuso, feel free to leave some more pings
<TheMuso> ok.
<RAOF> Aha.  Bluetooth mice don't like being paried with two systems at once, it seems :)
<kirkland> superm1: no prob, i'll be back online around 9 or 10 pm
<slangasek> Riddell: ping (re: kgrubeditor upload mentioned up there ^^)
<slangasek> bryce: s/Standby/Stand by/
<bryce> slangasek: huh?
<slangasek> bryce: the xorg patch
<slangasek> debdiff, rather
<slangasek> "Standby" is not a verb :)
<bryce> still not sure what you're referring to
<slangasek> bryce: the new zenity line in the just-unblocked xorg upload
<bryce> ah, alright I'll put that on my todo to fix
<slangasek> ok :)
<bryce> that's a pretty old patch ;-)
<bryce> er old upload
<slangasek> heh
<bryce> slangasek: pushed to git
<slangasek> ok :)
<Hobbsee> you know, there's only one problem in posting the beta in the same calendar month as the final.
<Hobbsee> it really is quite poor planning.
<slangasek> ?
<Hobbsee> you can't use up the monthly bandwidth on torrenting, twice.
<slangasek> oh, yes
<Hobbsee> last cycle, i'm fairly sure we had the beta the month before.
<slangasek> yes, we did; the last Thursday of the month falls late this month
<Hobbsee> ahhh
 * jdong caps his ubuntu beta torrents at a more neighbor-friendly 1MB/s
<Hobbsee> jdong: i'm jealous.
<slangasek> you mean your neighbors aren't all torrenting it from you?!
<jdong> slangasek: hehe they probably are, but I feel bad for using 7.5MB/s of upstream...
<Adri2000> slangasek: time to take a look at an sru?
<Adri2000> slangasek: if you do, it's vsftpd
<Adri2000> now, I need to get some more sleep during the couple of hours left in the night :)
<slangasek> bryce: how does it work that xserver-xorg-video-ati adds one patch file and mentions one patch in the changelog, and has three new entries in debian/patches/series?  Is this going to FTBFS as soon as I unblock it? :-)
<bryce> slangasek: yeah those extra two can be removed.  I wasn't able to get validation on them
<slangasek> bryce: ok; expect build failure mails soon, I guess :)
<bryce> although I still think they're good fixes
<StevenK> slangasek: It might take a while on i386, there's nearly 1,000 builds in the queue
<slangasek> yeah, but those are langpacks
<ScottK> slangasek: The firefox3.0 package in Gutsy is not being updated by mozillateam.  It's in Universe, so it's not technically required, it is still sitting there with known vulnerabilities.  Given the licensing restrictions on Firefox, I do not think that package is supportable by MOTU.  What are the odds of getting it removed?
<slangasek> ScottK: would pulling in 3.0.3 from hardy-updates (as a backport, or just pulling the upstream tarball) not work?  That seems straightforward to me and doesn't fall afoul of any license restrictions, assuming those apply to the gutsy version, and as we don't have a general policy of pulling packages post-release (for lack of security support or otherwise), I think that ought to be investigated first
<slangasek> on a technical level, I'm not sure what it takes to actually get a package removed from the release pocket
<ScottK> slangasek: jdong said he was going to look into updating the backport in Gutsy.
<ScottK> So if 3.0.3 is backportable, it's presumably updatable.
<ScottK> I just don't think it's reasonable to ask MOTU to deal with the Mozilla corp 'mother may I' restrictions.
<ScottK> That and I find the multiple presentations of the "Known your rights" pop-up annoying, but that's an separate issue.
<slangasek> I'm not convinced those restrictions are a problem in practice if all we're doing are security updates; but is there something else we should be doing pre-release to ensure we don't wind up with packages in universe for a release that are explicitly unsupported by MOTU?
<ScottK> slangasek: Fundamentally there is a process for getting patch approval that is not supportable by the general MOTU community.
<ScottK> I did get a committment from asac to support firefox (the 2.0 one) in Universe for Hardy when it was added back.
 * ScottK goes to look at that one.
<ScottK> Yep.  That one is updated.
<kirkland> superm1: i'm still struggling to sync my treo via bluetooth
<ScottK> We did not get a similar agreement on firefox-3.0 in Gutsy since it wasn't added in a FFe period where I had leverage.
<ScottK> slangasek: We probably ought to remove firefox before Intrepid releases for one thing.
 * ScottK files a bug.
<slangasek> ScottK: file a bug, subscribe mozilla-team and ubuntu-archive?
<ScottK> Sure thing.
<ScottK> It's FTBFS now in any case.
<ScottK> I'll do something similar on Gutsy for firefox-3.0
<nxvl> slangasek: you must know, the actual intrepid's wallpaper is the final one?
<slangasek> oh, I /must/ know? :-)
<slangasek> I haven't been told that it isn't final - but that doesn't mean I know that it is :)
<nxvl> you are the release manager
<nxvl> :D
<superm1> kirkland, what sort of struggles now?
<nxvl> i hate it :D
<kirkland> superm1: i'm just trying to sync my treo to my laptop, which I've ***always*** accomplished via dund
<kirkland> superm1: what is dund's replacement?
<superm1> syncing via dund?  dund is for creating a dial up connect?
<slangasek> did dund even work/exist in intrepid?
<kirkland> superm1: they each get a private ip address, and it syncs
<superm1> kirkland, you mean setting up a pan?
<slangasek> man, bluetooth is the shop of 31 different flavors of crack
<kirkland> superm1: http://elijah.pinoguin.com/blog/blog-view/article/sync-treo-650-on-ubuntu-linux.html
<superm1> kirkland, look at ifconfig pan0
<kirkland> superm1: k
<superm1> you should have a pan device that you can do such things if you wanted
<superm1> slangasek, the biggest problem is that it has changed SO much over the last revisions and no one's documentation accounts for changes from revision to revision
<ScottK> slangasek: Done in Bug 277401 and Bug 277403.
<ubottu> Launchpad bug 277401 in firefox "Please remove firefox source and related binaries" [High,Confirmed] https://launchpad.net/bugs/277401
<ubottu> Launchpad bug 277403 in firefox "Firefox-3.0 in Gutsy has multiple open security vulnerabilities and should be updated or removed" [High,Confirmed] https://launchpad.net/bugs/277403
<slangasek> superm1: I was referring to the umpteen bazillion ways to implement syncing
<ScottK> slangasek: I also subscribed ubuntu-security since ultimately that's the only reason it's a concern.
<slangasek> ok
<kirkland> superm1: on the plus side, i was able to send files from my laptop to my palm
<superm1> kirkland, if pan0 isn't doing to do the trick, http://wiki.bluez.org/wiki/HOWTO/SerialConnections
<superm1> that bottom one is the proper way to generate a new serial device that does dun specifically
<superm1> kirkland, very good
<kirkland> superm1: ooooh, let me try that
<superm1> kirkland, and if all else fails, we do have a final alternative to have a bluez-compat package that is not installed by default that provides the legacy dund pand and hidd, but i'm not sure how well they operate with the 4.x stuff
<milli> fglrx not supported in the beta?  (selecting it in apt marks xserver-xorg-core as broken)
 * milli noticed fglrx is gone from linux-restricted-modules too
<ScottK> milli: There was a new X uploaded just after the beta released.  Do you have that?
<superm1> fglrx is not supported in beta milli
<milli> ScottK: 7.4~2ubuntu5 ?
<milli> superm1: alright.
<superm1> bug 247376
<milli> using radeonhd for the time being, works ok
<ubottu> Launchpad bug 247376 in ubuntu-release-notes "undefined symbols when trying to load fglrx" [Undecided,Confirmed] https://launchpad.net/bugs/247376
<ScottK> There you go.
<superm1> milli, it's completely outside the control of ubuntu developers.  AMD has to update fglrx to work with intrepid
<milli> however, I have to keep flashplugin-nonfree at 9.0.124.xxx as the 10.0.1.218.xxx driver sucks all (of one) CPU when flash is active...
<milli> superm1: nod
<kirkland> superm1: http://pastebin.ubuntu.com/53366/
<kirkland> superm1: that's running the python script to create the serial device
<ScottK> milli: There are issues with getting flash updated that are being worked.
<superm1> kirkland, hum interesting.  it looks like even that document is outdated now
<milli> just thought I'd mention it, even though flashplugin-nonfree is, well, not in main
<superm1> i looked at doc/manager-api.txt and it' doesn't mention ActivateService
<kirkland> superm1: yeah, i'm desperately trying to find the 'right' way to do this
<kirkland> superm1: i'd hate to fall back on dun, if there's a more modern way
<superm1> kirkland, and then "document" said right way :)
<superm1> yeah
<kirkland> superm1: the docs are just lacking
<superm1> kirkland, so open up doc/
<superm1> look at serial-api.txt
<kirkland> superm1: where is this doc?
<superm1> kirkland, ah it's not installed in the right binary package
<superm1> i'm looking in the source
<kirkland> oh, okay
<superm1> i'll fix that to be installed as part of libbluetooth-dev
<kirkland> superm1: which source?
<superm1> but for now apt-get source bluez
<superm1> kirkland, although i'm betting you might be able to just use the same rfcomm stuff that you normally use for the DUN service itself
<superm1> like i showed you before
<kirkland> superm1: i've been trying /dev/rfcomm0
<kirkland> superm1: that dev exists
<kirkland> superm1: perhaps i need to setup that device
<superm1> kirkland, /etc/bluetooth/rfcomm.conf
<kirkland> superm1: yup, that's set up correctly
<sbeattie> TheMuso: you probably ought to look at bug 275233
<ubottu> Launchpad bug 275233 in libcanberra "canberra-gtk-play crashed with SIGSEGV in pa_operation_unref()" [Medium,Confirmed] https://launchpad.net/bugs/275233
<Burgundavia> asac: you should post to upstream projects using your canonical or ubuntu addy
<Burgundavia> http://mail.gnome.org/archives/networkmanager-list/2008-October/msg00006.html
<Burgundavia> in case somebody decides to parse mailing lists to attack us (ugh)
<persia> Why?  If someone has an established identity within a community, is it worth changing that for mail archive scanning trolls?
<persia> Is it not enough that we have an average of about 2 patched packages per active uploader, and try to keep that even lower: that statistic ought speak for itself in terms of pushing upstream.
<liw> persia, er, that we have few packages with changes from upstream does not necessarily sound to me like we're pushing stuff upstream, it might also be that we don't change anything
<persia> liw: Sure, in that case, why complain that we don't push anything.
<liw> persia, since part of the complaint is that Ubuntu doesn't help upstream, saying that we don't have anything to give them isn't really a good defense :)
<persia> liw: It's about positioning.  Saying "We're just users: we don't have code.  Our role is to provide you with millions of users, and try to filter the bug reports into something you can handle" is a positive statement.  Saying "This 500 people wrote these 25,000 lines of code, and these 15,000 were pushed to upstream projects" is a reactive defence.
<persia> Asking other people why they don't have more effective measures in place to coordinate user input might be an interesting counterpoint question.
<persia> Remember, the winner in any debate is usually the speaker who can establish the terms of the debate, rather than the speaker with the strongest arguments or the strongest evidence.
<persia> (also known as the reason no diplomat will either answer a simple question simply, or provide a definitive positive statement about anything : it's just safer that way)
<liw> persia, skipping the meta discussion... I'll just say that I don't think the "We're just users..." thing is a positive statement
<persia> liw: Fair enough.  Perhaps this is why I'm not part of the marketing team :)
<liw> :)
<liw> I do agree that anyone relying on e-mail addresses to assign credit to employers is a) [deleted by CoC filter] and b) in need of some statistics tutoring
<wgrant> But all the cool people are doing it.
<persia> Yeah, but it's durned difficult to find any reliable tool to match employers and email addresses.
<persia> Plus, any claims related to specific employers ignore the fact that the majority of Ubuntu developers aren't employed by the primary sponsor.
<wgrant> But then how are they going to attack Canonical?
<liw> hmm. upgrading my desktop machine to intrepid just ended in a crash, doesn't even react to ping. the gdm screen is all garbled (I was doing the upgrade via ssh)
<wgrant> liw: Lovely. What kind of video card?
<liw> something by ATI, iirc
<wgrant> Ah. Them.
<sifunk> mine went all screwy with the nvidia drivers for a bit, but i've got it back now with glx enabled
<liw> I doubt it was related to graphics hardware, though, it wasn't updating anything graphics related recently
<liw> also, when I reboot, the kernel can't mount the root fs
<persia> This doesn't exactly sound promising.
 * wgrant has to agree with persia.
<persia> I have an intrepid box, and it runs great.  I have a box I reinstall every couple days, and it works pretty good, except that there's no support for the video hardware except with vesa.
<persia> I have a hardy box with LVM and encryption and stuff, and now I'm all worried.
<liw> moving the root disk to another computer (it's a usb stick just for this reason), ext3 finds rahter a large number of unreferenced inodes, hmm
<sbeattie> bah, I just did an install, and stuff's failing because /dev/null is mode 600.
<sbeattie> gdm won't run because of it.
<liw> sbeattie, what, again? how on earth does that bug recur so often
 * persia is surprised that none of these issues were encountered *yesterday*
<sbeattie> persia: no kidding.
<liw> persia, I did upgrade tests yesterday, no problems found...
<persia> Yeah.  I know.  That's the odd bit.
<sbeattie> liw: know how to solve it? it looks like it's supposed to be set up properly based on /etc/udev/rules.d/40-permissions.rules
<liw> sbeattie, it's a symptom of a number of different problems, historically; there was at least one bug where some postinst script accidentally deleted /dev/null and then the first script to redirect things to /dev/null created a file
<sbeattie> mmm, that's not this situation, it's a character device.
<liw> sbeattie, can you verify that your /dev is really managed by udev?
<liw> hmph, it would have been such a nice solution to my problem if the usb stick was broken, but no, it's good
<liw> and GiBs of disk space
<liw> sbeattie, with "that bug" I actually meant all the bugs that wreck up /dev/null
<liw> oh, the syslog from the crashed machine has fglrx entries as the last thing
<liw> why does it have that? I wasn't using fglrx earlier
<sbeattie> liw: umm, probably not. I somehow have a fake /sbin/start-stop-daemon
<liw> sbeattie, that is very... interesting
<wgrant> sbeattie: How fake is it?
<sbeattie> wgrant: it's a 3 line shell script that echos that it's a fake script and does nothing.
<wgrant> sbeattie: Uh... nice.
<liw> sbeattie, that makes me think of something related to automated testing
<liw> or something that builds chroots
<liw> since it can be necessary for those to prevent daemons from being started
<wgrant> Is there a diversion?
<wgrant> It should be owned by dpkg.
<sbeattie> that's what dpkg -S claimed, that it was owned by dpkg
<C0p3rn1c> Suggestion: Maybe it's possible to incorperate PowerTOP, LatencyTOP to boost ubuntu's performance
<siretart> C0p3rn1c: patches welcome. try elaborating your ideas at http://brainstorm.ubuntu.com
<C0p3rn1c> siretart, I'm really no expert, I was just reading about this amaizing article on slashdot that apparently makes it possible to boot linux in 5 seconds http://linux.slashdot.org/article.pl?sid=08/10/02/1933206
<persia> C0p3rn1c: powertop is in Ubuntu: you can use it on your own system.  That particular machine was hacked in a number of ways, and while the result was linux, it wasn't a full Ubuntu Desktop.
<Ng> (and latencytop is in the upcoming Intrepid release)
<C0p3rn1c> ok thats great, thx guys
<C0p3rn1c> Also, I know it's not really your distro but maybe it would be good idea to promote ubuntu ultimate edition a bit more, I imagen this could boost the populairity of linux in general because it's pretty impressive and or "cool" for the recreational linux user
<cjwatson> sbeattie: that sounds like the installer broke halfway through - the installer does that temporarily
<cjwatson> C0p3rn1c: we'd rather improve Ubuntu! :-)
<C0p3rn1c> cjwatson: ubuntu ultimate edition is still ubuntu, they just copy your distro and add popular software in the default install :)
<cjwatson> I know, but we control our default install and should be improving it whenever possible
<cjwatson> and when we think it makes sense
<wgrant> UUE is pure evil.
<wgrant> It comes from the creator of Ultamatix, doesn't it?
<cjwatson> also I'm not terribly happy with the implication of the "Ubuntu Ultimate Edition" name
<siretart> what is "Ubuntu Ultimate Edition"?
<wgrant> cjwatson: Neither.
<C0p3rn1c> siretart: http://ultimateedition.info/
<cjwatson> anyhow, much rather advertise our own product than somebody else's
<wgrant> siretart: A misleadingly named Ubuntu derivative created by the creator of an Automatix derivative. You can work out the rest.
<siretart> wgrant: OMG!
 * siretart runs away. screeming
<norsetto> ultimate, hmmm, that also mean final ...
<mpt> Gutsy Gibson? Is that a guitar?
<C0p3rn1c> hehe
<wgrant> It also seems that none of UUE's subpage links work.
<wgrant> I want them powering my distro.
<C0p3rn1c> Maybe UUE is evil, but so is the recreational user, we are all downloading mp3's , illegal movies, etc...
<wgrant> What does UUE actually do?
<wgrant> Other than break?
<wgrant> And mislead?
<wgrant> Their website isn't too informative.
 * norsetto sits down and opens the chips bag
<mpt> That's explained about 1/4 the way down
<C0p3rn1c> like I said, it just adds popular software to the default install
<wgrant> mpt: Ahhh, I tried to avoid looking at the page too much.
<siretart> C0p3rn1c: I can play them with stock ubuntu, FWIW. no need for automatic or other 'ultimate' add-ons
<C0p3rn1c> I havent installed it yet
<wgrant> ... it also has Beryl.
<C0p3rn1c> siretart: sorry I can't really follow, stock ubuntu?
<cjwatson> C0p3rn1c: as siretart alludes to, we've put quite a bit of effort into ensuring that standard Ubuntu can meet those needs, and will continue to do so
<wgrant> siretart: It's too difficult to click "Search", I'm afraid.
<cjwatson> in ways that don't risk our ability to distribute Ubuntu legally
<norsetto> thats cool, its got hardinfo too
<wgrant> And iPod support.
<cjwatson> UUE can probably get away with more since it doesn't have major commercial backing, but we can't necessarily take the same risks
<wgrant> Doesn't Rhythmbox do that?
<persia> Yes.
<cjwatson> however, the standard movie player in Ubuntu can prompt you to download additional codecs as needed (provided they're legal in your jurisdiction)
 * wgrant wonders why these people don't just help us.
<C0p3rn1c> cjwatson: I'm not asking to become them, I just would like to see it grow more popular, to boost the growth of the ubuntu community
<norsetto> wgrant: neah, too much work
<wgrant> I don't see how that would help grow the Ubuntu community.
<C0p3rn1c> cjwatson: it would put more pressure on the hardware vendors to support linux
<cjwatson> C0p3rn1c: we'd rather do that with Ubuntu
<cjwatson> and we will continue to do that, including learning from Ubuntu derivatives
<cjwatson> there are certainly plenty of cases where we can and do work directly with Ubuntu derivatives, but that requires them coming and working with us
<C0p3rn1c> cjwatson: like you said you are restricted with your commercial backing responsibilities
<cjwatson> gotta be a two-way street
<cjwatson> to my knowledge UUE hasn't come to us
<cjwatson> C0p3rn1c: which is one good reason we can't reasonably be expected to support UUE
<C0p3rn1c> cjwatson: I'm sure they would like this, it's in there best intrest
<lool> "we are all downloading mp3's , illegal movies, etc..." err
<liw> C0p3rn1c, it's not because Ubuntu has commercial backing, it's because Ubuntu is a target with enough money that it's worthwhile to sue us that we need to be careful not to do legally controversial things
<cjwatson> C0p3rn1c: then they're entirely welcome to come and talk with us about what we can do to help
<cjwatson> but we aren't going to advertise something we didn't build; it's just not in our interests
<cjwatson> certainly not in preference to Ubuntu itself
 * Hobbsee is surprised the trademark people haven't hit it yet
<C0p3rn1c> cjwatson: I just thought it would be in your intrest to gain a linux user boost
<norsetto> is negerpunk really a music genre (at least in Germany)?
<Hobbsee> C0p3rn1c: as would it be for them.  Let the smaller distro go to the bigger distro, no?
<Hobbsee> C0p3rn1c: besides, there's a release on here at the moment.
<lool> norsetto: http://en.wikipedia.org/wiki/Negerpunk
<lool> norsetto: a joke it seems
<norsetto> lool: ah ok, somebody seems to be taking it seriously though
<cjwatson> C0p3rn1c: it's our opinion that our efforts are best placed doing that with Ubuntu
<C0p3rn1c> I really like ubuntu or linux in general, it's clearly the most advanced OS out there, it just hasnt got a big enough public to force the hardware vendors to support linux
<C0p3rn1c> I recently switched to ubuntu but I'm experiancing really alot of problems because of the lack of support from these hardware vendors like DELL, Nvidia ,...
<cjwatson> yes, we're working directly with hardware vendors on that
<cjwatson> which I think is a more appropriate use of energy :-)
<C0p3rn1c> to support UUE doesnt take any energy it's just a moral issue it seems
<C0p3rn1c> what was the evil part again, I mean that really violates your beliefs ?
<Hobbsee> C0p3rn1c: define support, then, if it takes no energy?
<persia> C0p3rn1c: Well, "evil" is perhaps the wrong word.  The way that things are done breaks several things, and can cause a number of awkward situations for end users.
<persia> For most of the predecessors (Easy Ubuntu, Automatix, etc.), there has been dialog with the creators, and the features requested have been added to Ubuntu.
<wgrant> Its legality is somewhat questionable, it has a misleading name, significant ties with Ultamatix, an Automatix derivative, etc., etc.
<C0p3rn1c> Hobbsee: well you can decide yourself how far you will go with this support, publicity is also a way to support some distro
<liw> debugging my intrepid upgrade crash... fglrx is a kernel module, right? if I'm using it, lsmod should tell me, right?
<persia> As has been said previously, if the UUE people wish to be involved, they are welcome, and it's likely there is a policy-compliant way to address the use cases they are solving.
<wgrant> C0p3rn1c: Why would Ubuntu be likely to publicise a competing, misleading and likely illegal in many jurisdictions distribution?
<liw> competing is not so bad, but unco-operating is
<wgrant> liw: Right.
<cjwatson> C0p3rn1c: I certainly never said evil (that's a strong word), simply that we'd rather improve Ubuntu than advertise something that will take testing resources away from Ubuntu itself and divert them where it's harder for us to respond to them
 * wgrant admits to calling it evil initially.
<cjwatson> if UUE were actively cooperating with Ubuntu, that probably wouldn't be an issue since we'd get testers coming straight through (as we do with Kubuntu etc.)
<wgrant> Some derivatives end up integrating rather well with Ubuntu, but they really need to start the integration.
<cjwatson> C0p3rn1c: but, for the time being, the answer is that we are happy to advertise derivatives that work with us directly, but ones that don't can fend for themselves. I think that's fair
<C0p3rn1c> don't can fend?
 * liw notes that this UUE discussion is already diverting energy _away_ from solving an Ubuntu upgrade problem ;-)
<C0p3rn1c> Excuse me but I don't understand what you mean with that
<cjwatson> you misparsed my sentence
<cjwatson> "but the ones that don't - those derivatives can fend for themselves"
<cjwatson> that's awkward phrasing but perhaps it helps
 * C0p3rn1c speaks dutch natively
<broonie> "fend for" ~= "look after"
<C0p3rn1c> ic
<C0p3rn1c> well I'll email this discussion to them, and see if it can start a dialog
<C0p3rn1c> I'm also of the opinion that there should be more unity in the linux community instead of going our seperate ways by splitting up in so many distro's
<cjwatson> I used to think that, but actually I don't think there's any harm at all in small groups experimenting with different ideas, as long as the results ultimately get fed back into the mainstream if they're good
<davmor2> Guys when you click on n-m applet you get current connections.  Also you get VPN Connections.  If you click on that then click on Configure VPN it opens up Network Connections with the VPN tag at the top.  However the all the buttons are greyed out how do you add one?
<wgrant> davmor2: Install network-manager-<sometypeofvpn>
<wgrant> Where <sometypeofvpn> is vpnc, pptp or openvpn.
<wgrant> This should probably be explained somewhere, as a lot of people are confused by it.
<liw> I think I am seeing what happened with my upgrade crash: I have linux-restricted-modules-*-generic installed, but fglrx not loaded; when upgrading, the modules package gets uploaded, and this triggers fglrx to be loaded into the kernel, killing it
<C0p3rn1c> ok thanks for your time so far,I'm sorry for distracting you guys from your work :)
<davmor2> wgrant: I agree
<wgrant> liw: Hmm, there aren't fglrx modules any more, are there?
<wgrant> There is a DKMSified version, but I don't think that builds with 2.6.27.
<liw> wgrant, well, syslog shows it to be loaded just before the system crashes hard
<liw> Oct  3 10:42:54 gytha kernel: [44538.401449] fglrx: module license 'Proprietary. (C) 2002 - ATI Technologies, Starnberg, GERMANY' taints kernel.
<wgrant> liw: I guess it could have been from the old l-r-m.
<liw> hmm, but those files should have been removed already, surely?
<wgrant> liw: No. Different package names.
<liw> oh, right
<wgrant> l-r-m is named (not just versioned) by kernel version, ABI and flavour.
<wgrant> So it looks like l-r-m triggers a reload of kernel modules even if it's not installing modules for the running kernel?
<liw> it's not a reload, since the fglrx module was not in the kernel; it loads a completely new module
<liw> which is suspicous, to say the least
<wgrant> Hmmm.
<wgrant> Why wasn't fglrx loaded?
<liw> because I don't use it?
<wgrant> I know why you don't want it loaded, but what was stopping it from being loaded?
<liw> more importantly, what triggered it to be loaded?
<wgrant> Working out why it wasn't loaded before might help.
<liw> I'm not sure if I did anything special to prevent it; I can't remember it happening, I remember just being happy that the "radeon" driver was being used by X
<liw> liw@gytha$ sudo modprobe fglrx
<liw> Not loading fglrx module; not used in /etc/X11/xorg.conf
<wgrant> Aha.
<liw> that's with the same system, rolled back to hardy (that's why it's running off a USB stick: easy to roll back :)
 * wgrant has no idea now.
<liw> in the xorg.conf from the crashed system, there is still no fglrx mentioned
<liw> indeed, the files are identical
<tseliot> liw: can you upload your /var/log/Xorg.0.log and your /var/log/Xorg.0.log.old somewhere?
<liw> hmm, kvm-source was installed a second before the fglrx module was loaded
<liw> tseliot, from the hardy version or the crashed, half-upgraded-to-intrepid version?
<tseliot> liw: the latter should be enough
<liw> tseliot, http://files.liw.fi/temp/
<tseliot> liw: hmm... there's no trace of fglrx in either log
<liw> tseliot, yeah, but for whatever reason, there is in syslog
<tseliot> liw: can I see it?
<liw> sure, just a moment
<liw> tseliot, same location; I put dpkg.log there, too
<davmor2> wgrant: I documented it in https://bugs.launchpad.net/ubuntu/+source/network-manager-applet/+bug/277496
<ubottu> Launchpad bug 277496 in network-manager-applet "Intrepid: Network-Manager should document additional packages are required to enable VPN" [Undecided,New]
<tseliot> liw: What does this say? sudo updatedb && locate fglrx.ko
<liw> tseliot, on the hardy or intrepid version?
<tseliot> liw: on the version the syslog you posted belongs to
<liw> I can't run the intrepid version right now, so I'm doing a "sudo find /mnt -name '*fglrx.ko*'" instead (the intrepid filesystem being mounted on /mnt)
<liw> and that returned nothing
<davmor2> query on tracker why is the tracker applet enabled in sessions?
<persia> liw: Can you chroot into it to access local binaries?
<liw> persia, sure
 * liw moves stick to desktop from laptpo
 * persia doesn't think locate is better than find, but does think this may be a sensible proxy for booting the system when debugging
<tseliot> liw: if fglrx were the cause of the problem it would have been mentioned in one of the Xorg logs. What happens on Intrepid, exactly? What are the symptoms of the problem?
<liw> tseliot, gdm's screen gets garbled, no response to keyboard, mouse, network, power button (unless I keep it pressed for five seconds to force a poweroff)
<liw> tseliot, if X was not restarted after the fglrx module was loaded into the kernel, why would it be in the X logs?
<liw> persia, is there something in particular you wanted me to run?
<persia> liw: No, just trying to solve your " I can't run the intrepid version right now, so I'm doing a "sudo find /mnt -name '*fglrx.ko*'" instead" issue so you can get to the meat of it.
<liw> also, I have backups of the desktop, and I can easily get back to the working hardy system, so I can do any debugging that is necessary
<liw> I'm just too ignorant about kernel modules and proprietary drivers to be good at debuggning this
<tseliot> liw: can I see your xorg.conf? And BTW the fglrx module can't be loaded as it's incompatible with the Xorg ABI
<liw> tseliot, http://files.liw.fi/temp/xorg.conf
<tseliot> liw: try leaving only the Device section in your xorg.conf and get rid of the rest
<liw> tseliot, I will do that when I next try the upgrade (it takes several hours, so I'd rather look at other things first)
<wgrant> tseliot: How can Xorg stop the kernel module from loading?
<liw> hm, I can't find any trace of fglrx on the intrepid version
<tseliot> wgrant: I said that Xorg won't use something which is not compatible with its ABI
<tseliot> wgrant: it can try to use it anyway if you pass it IgnoreABI (but that won't still work)
<tseliot> wgrant: a more interesting question is how can you load a module that doesn't exist? ;)
<wgrant> tseliot: Indeed, that is probably a better question.
<liw> hmm. the hardy version of fglrx has the date that is in syslog
<liw> (Feb 25 2008)
<wgrant> Could it have crashed before it synced the newly-installed module to disk? Not likely, I guess.
<liw> wgrant, quite possible, though
<liw> where is fglrx in intrepid? i.e., which package?
<wgrant> It doesn't actually build in Intrepid, does it, tseliot?
<tseliot> liw: xorg-driver-fglrx
<liw> tseliot, even the kernel module?
<tseliot> wgrant: it builds but can't be installed
<wgrant> tseliot: I speak of the kernel module, which seems to be the issue here.
<tseliot> wgrant: because of the video abi specified in the package
<tseliot> wgrant: fglrx-kernel-source then
<tseliot> liw: fglrx-kernel-source contains the source and the DKMS stuff
<tseliot> there's no precompiled module though
<liw> what's the source package for that? I can't find it in my mirror
<liw> aha, fglrx-installer
<tseliot> yep
<liw> ok, as far as I can determine, the intrepid version of fglrx is from Sep 8 2008, and if that's true, the kernel module that was loaded was the hardy one
<persia> Shouldn't that fail to load because of the significant ABI skew?
<liw> persia, version skew compared to what?
<persia> kernels.  2.6.24 vs. 2.6.27
<persia> Or did it blow up pre-reboot?
<liw> the crash happened during the upgrade, so the old kernel was still running
<tseliot> liw: aah, so the crash happened during the upgrade. Was the screen saver disabled? If some 3D screen saver was activated that might have caused problems
<liw> tseliot, the screen was showing gdm, which doesn't have screen savers apart from blanking or dpms off, as far as I know
<liw> but what do I know :)
<liw> I was doing the upgrade over ssh, that is
 * tseliot scratches head
<liw> can upgrading of gtk theme engines cause something like this?
<tseliot> hmm... I wouldn't know
<tseliot> Riddell: is there a KDE equivalent for yelp?
<IntuitiveNipple> Has anyone had success with the desktop amd64 daily installing in a kvm guest (I'm seeing a busybox prompt) ?
<liw> hmm, my dpkg.log shows 19 lines showing dkms being unpacked, same version... why so many?
<Mithrandir> because dpkg is an interesting beast.
<persia> IntuitiveNipple: Which daily?  The beta worked for me.
<IntuitiveNipple> " uvesafb: failed to execute /sbin/v86d" - does this make sense running the amd64 desktop CD (the file isn't there) ?
<IntuitiveNipple> persia: 2008-10-01 (downloaded this morning)
<persia> I downloaded and tested and deleted mine yesterday, but intrepid-desktop-amd64.iso ?
<IntuitiveNipple> yes
<cjwatson> v86d> known
<IntuitiveNipple> cjwatson: thanks :) That'll save me thinking I've messed it up
<Riddell> tseliot: khelpcentre
<tseliot> Riddell: thanks a lot
<IntuitiveNipple> cjwatson: Are there other problems with that? I exit-ed busybox and the got stuff like "Target filesystem doesn't have /sbin/init." and missing directories? I'm wondering if those errors are a by-product of the original issue, or are part of the main problem
<cjwatson> IntuitiveNipple: the v86d error is essentially harmless (unless you end up with a corrupted framebuffer). You have some other problem
<IntuitiveNipple> cjwatson: Hmmm
<cjwatson> IntuitiveNipple: /casper.log and dmesg might have more information for a bug report
<cjwatson> IntuitiveNipple: your problem is indicative of failing to mount the CD
<IntuitiveNipple> cjwatson: "Unable to find a medium containing a live file system"
<cjwatson> yes, as I said
<cjwatson> if the kernel fails to detect your CD drive then you'll get that symptoms
<cjwatson> s/s$//
<IntuitiveNipple> cjwatson: this *should* be it, I think (it has already booted the ISO image) "scsi 1:0:0:0: CD-ROM            QEMU     QEMU DVD-ROM     0.9. PQ: 0 ANSI: 5"
<cjwatson> IntuitiveNipple: I'd rather not be the guy who debugs this with you - was just giving you a pointer
<cjwatson> IntuitiveNipple: #ubuntu-kernel is a better place to follow up if you don't want to file a bug right away
<liw> anyone here know how dkms works?
<cjwatson> (you've run off the end of my expertise)
<IntuitiveNipple> cjwatson: I wasn't suggesting you do, but that would be an expected report wouldn't it? The only thing I can see is that "mounting root file system..." occurs about 3/4 second *before* the kernel logs finding the CD drive
<IntuitiveNipple> liw: Yes, I di
<IntuitiveNipple> s/di/do/
<liw> IntuitiveNipple, would you happen to be able to understand what the packages when upgrading from hardy (where fglrx was not under dkms) to intrepid (where it is)? is there a chance that, say, /etc/init.d/dkms_autoinstall has a bug that triggers the fglrx module in hardy to be loaded into the hardy kernel during an upgrade?
<IntuitiveNipple> liw: I can imagine that happening, yes, since dkms is linked in via "/etc/kernel/postinst.d/dkms"
<liw> IntuitiveNipple, yeah, I got that far, but reading the init.d script made me want to take a break :) my problem is that it seems that loading the old fglrx module into the kernel crashes it
<liw> hm, perhaps I can test this by upgrading only dkms
<IntuitiveNipple> dkms should check at boot-time if the module is available, and build a new one for the running kernel if it isn't there already
<IntuitiveNipple> Don't forget, "dkms status" will show you which modules are built and installed for each kernel version
<liw> hm, merely upgrading dkms did not reproduce the problem
<IntuitiveNipple> liw: Mario has made some significant improvements to DKMS since the hardy version; maybe the cause is the timing of the dkms update - if it is after other dkms modules it has a problem, but if before, it might be okay?
<liw> IntuitiveNipple, see logs at http://files.liw.fi/temp/
<jdong> slangasek: I'm gonna rebase the gutsy backport of firefox/xulrunner against the hardy-updates release today...
<elmo> Ubuntu ftpmaster (drescher) is being migrated to a new (faster) box with more disk; publishing won't be happening, and uploads won't be accepted till DNS propagates
<elmo> (PPAs are unaffected)
<Hobbsee> sweet!
<Hobbsee> pitti: oh dear.  Have you seen https://bugs.edge.launchpad.net/ubuntu/+source/jockey/+bug/277419 yet?
<ubottu> Launchpad bug 277419 in jockey "[intrepid beta] Jockey-gtk doesn't install drivers, it does nothing" [Undecided,New]
<Hobbsee> or is that a tseliot bug?
<tseliot> Hobbsee: I work on both the Nvidia packages and Jockey, therefore either way you're right
<Hobbsee> tseliot: cool.  Get fixing :)
<tseliot> yes, I'm reading the report
<kirkland> persia: regarding bug #277517, are you wanting this for intrepid, or is that just a placeholder for Jaunty?
<ubottu> Launchpad bug 277517 in kvm "Please enable lpia and ia64 builds" [Undecided,Confirmed] https://launchpad.net/bugs/277517
<persia> kirkland: Well, I'd like it for intrepid, and it fixes two FTBFS issues, but I'm not sure how many users with that HW have vmx support.
<persia> works for me on some lpia HW, but other lpia HW doesn't have vmx.
<persia> I don't have ia64, so I'm just trusting IntuitiveNipple
<persia> kirkland: Do you have concerns about the patch, or a preference for intrepid/jaunty?
<superm1> tseliot, I had thought -96 and -71's modaliases were going to be removed as depends from jockey
<superm1> and nvidia common
<superm1> since they are not functional ?
<tseliot> superm1: removing them from nvidia-common will be enough
<tseliot> superm1: I'll talk to pitti about this next week
<superm1> tseliot, and of course if ever they are made functional by another release from nvidia, it's an SRU away
<kirkland> persia: no direct concerns, just a lack of testing on those platforms over the rest of the dev cycle
<ScottK> At least the chances of regression are low.
<kirkland> persia: i was hoping for soren's take on it
<kirkland> ScottK: :-P
<tseliot> superm1: yes, right
<persia> kirkland: Makes sense.  As much as anything, it's an archive-consistency concern for me.  To be honest, I don't ever expect to use KVM on the lpia device I have that supports it (it has a 5" screen)
<kirkland> persia: ;-)
<soren> kirkland: I don't mind an lpia build of kvm. I just didn't think the lpia kernels had kvm support.
<kirkland> soren: ia64?
<RainCT> mdz: Hey. Note that you've added genisoimage as a Depends instead of a Recommends to ubuntu-dev-tools (and I'd prefer if it was a Suggests, anyway :P). I also wanted to ask you to add copyright information for it to the script's header and debian/copyright
<soren> kirkland: I'm not sure it builds on IA64? I know KVM has support for it in git, but I wans't sure about the release tarballs.
<persia> IntuitiveNipple: Can you share your experience with ia64?
<RainCT> mdz: (well, thinking about it again, nevermind about it being a Suggests -as other similarly important dependencies are also Recommends and not Suggests-, but it's still in the wrong line)
<kirkland> soren: this discussion hinges on persia's comments in that bug
<mdz> RainCT: why suggests?  all of the other optional dependencies are recommends
<mdz> RainCT: GMTA :-)
<mdz> RainCT: my mistake of course; it doesn't even match the changelog.  I've fixed it now
<RainCT> mdz: OK, thanks :)
<mdz> RainCT: I've also added the copyright info now
<soren> kirkland: Ah, I suppose I should actually read the bug.. :)
<soren> kirkland: I'm not convinved ia64 is present in the kvm-72 tarballs. I think it popped up later than that.
<kirkland> soren: right, persia says he backported it from 74 to 72
<persia> Yeah.  I don't understand why the patch works even, to tell the truth, but it builds and installs and runs, which made me think it was probably worth it.
<kirkland> I have neither ia64 nor lpia hardware
<soren> persia: You have IA64 hardware?
<persia> No.
<soren> How do you know that it runs, then?
<persia> I have lpia, including lpia with vmx, but no ia64.
<persia> I don't, as I said in the bug.
<soren> But you just said now?
<persia> That's also why I asked for IntuitiveNipple's input.
 * soren goes to look at the bug again..
<persia> Oh, right.  insert a "on lpia" in my previous statement.
<soren> Ah.
<soren> IntuitiveNipple has IA64 hardware?
<persia> Dunno.  IntuitiveNipple wrote the patch.
<soren> IntuitiveNipple: ping
<Riddell> mdz, Keybuk: motu council are blocking on a core-dev application, can the relevant person just turn up at the next tech board meeting?
<mdz> Riddell: I don't see why not, but I'd like to know why the council is blocked on it
<mdz> Riddell:  have you asked them? (half of them are here right now)
<Riddell> mdz: I have, a couple have answered and don't know why it hasn't been processed
<soren> Riddell: I have a few outstanding applications that I intend to look at before I punch out today.
<soren> Riddell: apachelogger's being one of them, apparantly.
<apachelogger> \o/
<Riddell> soren: a month is far too long for this to take
<soren> Riddell: I agree.
<soren> Riddell: We've been discussing ways to improve this process extensively over the last couple for weeks.
<Riddell> mdz: when is the next tech board meeting?  I can't see it on fridge
<mdz> Riddell: we've asked again and again for that to be fixed :-(
<mdz> Riddell: it's next Tuesday at 14h UTC
<Riddell> nixternal: can you add that to fridge ^^
<siretart> mdz: will ffmpeg be on the agenda? or do you prefer to discuss this after release?
<mdz> siretart: apologies for not getting back to you sooner on that; I read the email but didn't have a ready answer and have neglected it
<mdz> siretart: assuming we have a quorum, we can certainly talk about it at the meeting
<mdz> siretart: could you add it to TechnicalBoardAgenda?
<siretart> mdz: I'm not sure if I'll be able to make it to the meeting, but sure!
<siretart> mdz: but perhaps you could answer me in advance a short question: I now have a unstripped replacement package ready in ~motumedia that works on at least one tester system. I'd like to upload it to multiverse now
<siretart> mdz: since we have stuff in multiverse like x264 and similar, I wouldn't expect patent problems here, but I wanted to check in advance to avoid further confusion here
<mdz> siretart: isn't that the same question?
<siretart> mdz: not necessarily. I'd consider having a seperate source package with the encoders as a bad workaround I'd rather avoid
<mdz> siretart: you're asking whether it's OK to have the codecs in Ubuntu, right?  It doesn't matter much which package they're in
<siretart> mdz: we already have these codecs in ubuntu. this question is if there are other than patent concerns in ffmpeg that you were aware of
<nixternal> mdz: tech board is the 7th or 14th?
<mdz> nixternal: 7th, 21st, ...
<mdz> siretart: assuming the copyright file is correct, I don't see anything to worry about
<mdz> siretart: I'm preparing a response to your email though
<nixternal> mdz: roger that...adding it to the fridge
<siretart> mdz: thanks!
<mdz> nixternal: thanks very much
<nixternal> mdz: do you all have an agenda on the wiki or no?
<mdz> nixternal: TechnicalBoardAgenda
<nixternal> groovy
* Riddell changed the topic of #ubuntu-devel to: upload.ubuntu.com moving | Intrepid beta released | archive: Feature Freeze | Development of Ubuntu (not support, not application development on Ubuntu) | #ubuntu for support and generaldiscussion for dapper/feisty/gutsy/hardy, #ubuntu+1 for intrepid | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<nixternal> added the 7th and 14th, 14:00 to 16:00 UTC...before I add a few more every 2nd week thereafter, those time frames are correct?
<nixternal> mdz: ^^
<mdz> nixternal: it is every two weeks from the 7th
<mdz> nixternal: ie. no meeting on the 14th
<nixternal> err, gotcha
<duskyink> hi all, I am new to Open source and have made a small change to gedit and compiled. Where does my output program get saved?
<siretart> duskyink: file a bug in the gnome bugzilla and describe your modifications there
<cjwatson> duskyink: you mean where did the compiler put it?
<Adri2000> cjwatson: time to take a look at an sru?
<munckfish> cjwatson: got a sec re #274854?
<munckfish> LP: #274854
<munckfish> https://bugs.launchpad.net/ubuntu-ps3-port/+bug/274854
<ubottu> Launchpad bug 274854 in ubuntu-ps3-port "spufs filesystem not mounted on boot" [Medium,In progress]
<munckfish> I think it uncovers a more general issue - domount in /lib/init/mount-functions.sh check /proc/filesystem to see if the requested filesystem type is supported
<munckfish> however for filesystems compiled into the kernel as modules
<munckfish> they won't be listed
<munckfish> e.g. take ext2
<munckfish> that doesn't get used on boot on my desktop system
<munckfish> consequently it isn't listed
<munckfish> I think it's being too careful - running mount will cause the kernel to search for a matching module if one isn't loaded
<munckfish> So I think this check isn't helpful
<cjwatson> Adri2000: not at the moment, sorry
<cjwatson> munckfish: hmm, I'd sort of like to know why it was added in the first place
<cjwatson> munckfish: I agree it looks unnecessary but I usually like to find out the reasoning before deleting code
<munckfish> cjwatson: ok I'll go hunt
<cjwatson> munckfish: it's worth noting that domount will exit zero if the filesystem is entirely unavailable, while mount will exit non-zero
<cjwatson> which might be the distinction it's trying to achieve (speculating)
<munckfish> well surely just interpreting mount's exit codes would do the trick?
<munckfish> as long as we're careful not to upset set -e
<cjwatson> does it have a reliably distinct exit code for "filesystem not supported"? the manual page doesn't document that
<munckfish> cjwatson: seems to be returned 32 for various errors
<munckfish> I'll check the source
<soren> "mount -t thisisnotavalidfilesystem /dev/null /mnt" returns 32.
<cjwatson> ok, but what else returns 32?
<cjwatson> 'sides, that's only a hypothesis, might not have been the original reason
<soren> ./sundries.h:#define EX_FAIL	       32	/* mount failure */
<soren> Anything.
<munckfish> The 32 is the default fail
<munckfish> oh you got there first
<munckfish> So if we let the kernel do the searching and loading
<munckfish> then we can only report if the mount failed or not
<munckfish> or
<munckfish> let mount's own message echo out
<munckfish> which wouldn't be so neat
<munckfish> cjwatson: ok I'll spend some time on this later see if I can find out who wrote the code and why it needed to be that way
<munckfish> and I'll see if I can propose and alternative
<cjwatson> ok
<cjwatson> thanks
<cjwatson> an obvious workaround would be to special-case spufs
<munckfish> yeah I already have a patch waiting like that
<munckfish> but then I realised this more general issue
<cjwatson> (crappy, but it would work)
<munckfish> exactly
<munckfish> actually the patch was to call modprobe spufs in mountkernfs.sh if the module isn't listed in the output of lsmod
<munckfish> actually there's a thought (ding!)
<munckfish> cjwatson: the kernel code which loads the filesystem modules if they aren't already loaded
<munckfish> uses the filesystem name as the module name
<munckfish> maybe we should be checking lsmod instead of /proc/filesystems ?
<cjwatson> certainly wouldn't work for everything
<cjwatson> <cjwatson@sarantium ~>$ lsmod | grep tmpfs
<cjwatson> <cjwatson@sarantium ~>$ grep tmpfs /proc/filesystems
<cjwatson> nodev   tmpfs
<cjwatson> well, tmpfs is special-cased, but try sysfs
<cjwatson> the sorts of filesystems mounted using domount are predominantly special ones like that
<munckfish> see get_fs_type(...) in fs/filesystems.c
<munckfish> oh darn of course this is the opposite of the first problem
<cjwatson> sure, doesn't change the fact that sysfs isn't a module
<munckfish> if a filesystem isn't compiled as a module it won't be listed
<cjwatson> oh, also, domount supports trying one filesystem and falling back to the next
<cjwatson> honestly I'm beginning to think special-casing spufs is actually sane
<munckfish> that's ok though
<munckfish> You try one filesystem type (check /proc/modules || check lsmod)
<cjwatson> more expensive to call mount than to grep /proc/filesystems, and speed matters in the boot process
<munckfish> if that fails both those checks you do the same checks for the second type
<cjwatson> dude, basically none of the filesystems on which domount is typically called are modules
<cjwatson> /proc/modules is not going to make things better
<cjwatson> you'll end up having to call mount anyway and suffer the speed penalty for things that fall back from one filesystem to another
<munckfish> Actually I was starting to think checking both /proc/filesystem and lsmod that way we don't call mount
<munckfish> anyway
<cjwatson> but in your case /proc/modules won't help
<munckfish> for spufs it will
<cjwatson> because if the module isn't loaded, it's not in /proc/filesystems
<cjwatson> only if spufs is already loaded :)
<munckfish> groan :( - doh doh doh doh
 * munckfish slaps himself on the forehead
<munckfish> Ok
<cjwatson> you'd have to try modinfo or something, which walks the filesystem
<munckfish> So you'd rather see a special case for spufs in domount
<cjwatson> I don't like it, but I don't see a much better alternative
<cjwatson> it's not like this stuff is used for general filesystem mounting, it's all special cases anyway
<cjwatson> maybe we could move the [ -d /spu ] && grep -qs '^cpu.*Cell' /proc/cpuinfo check into mount-functions and simplify mountkernfs
<cjwatson> dunno
<munckfish> cjwatson: interesting idea
<munckfish> cjwatson: ok let me think thru all of this and get back to you
<mib_rjshf4> hi, anyone here more or less familiar with the e1000e bug? and updated about the situation?
<munckfish> mib_rjshf4: I think I saw something about it in one of the mailing lists today
<munckfish> 1 sec
<cjwatson> mib_rjshf4: https://lists.ubuntu.com/archives/intrepid-changes/2008-October/007851.html and https://lists.ubuntu.com/archives/intrepid-changes/2008-October/007852.html (i.e. fix on its way)
<munckfish> mib_rjshf4: there's some discussion of it here https://lists.ubuntu.com/archives/kernel-team/2008-October/003219.html
<mib_rjshf4> cjwatson, munckfish, thanks, I'll read the pages :)
<munckfish> cjwatson: one other avenue I can explore is whether the kernel team would mind spufs being a builtin
<munckfish> in the powerpc64-smp kernel
<munckfish> that would be a single character fix in one file
<cjwatson> mib_rjshf4: the binaries are on their way into the archive now
<cjwatson> munckfish: sure, that sounds possible too
<munckfish> I've just asked Ben now waiting to see what he says
<mib_rjshf4> Read the pages, nothing new about the true cause of the problem. I have an Ethernet Adapter RTL8101E on an ICH8 platform. Supposedly I'm safe, I'm just uncomfortable because of that guy with a non-ICH8 but with a RTL8101E who also got it's firmware with all 0xFF -- http://lkml.org/lkml/2008/9/24/133 . On the other hand, I can't dump my Ethernet's card EEPROM because the "Opperation is not supported", so writing to
<cjwatson> you asked about the situation, I thought "fix on its way" was kind of what you were looking for
 * cjwatson <- just an archive administrator not a kernel hacker
<mib_rjshf4> cjwatson: yes, and thanks for the info :)
<mib_rjshf4> cjwatson: I'm not complaining, just explaining the full situation
* Riddell changed the topic of #ubuntu-devel to: Intrepid beta released | archive: Feature Freeze | Development of Ubuntu (not support, not application development on Ubuntu) | #ubuntu for support and generaldiscussion for dapper/feisty/gutsy/hardy, #ubuntu+1 for intrepid | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
 * cjwatson nods
<mib_rjshf4> cjwatson: I thought it could be avoided me having to dump all the details if someone had found the real issue, which didn't happen, and as such, I had to expose my rationale :)
<mib_rjshf4> anyway, upgrading now lol, if my Ethernet dies I'll come here and cry
<munckfish> cjwatson: do you happen to know when the next daily live build will be? I'm waiting for that as the beta for PS3
<munckfish> and I note the last one for ports was 30 Sep
<cjwatson> munckfish: slangasek turned the cron jobs off for beta, I assume he'll turn them back on soon
<cjwatson> mib_rjshf4: err, if you're concerned, you should WAIT until the fixed binaries hit the archive
<cjwatson> mib_rjshf4: wait a day
<munckfish> cjwatson: ok thx. Logging off now speak later
<slangasek> yes, CD cronjobs re-enabled now
<asomething> Could a core-dev/main-sponsor please take a quick look at Bug #209173 and tell me if my proposed course of action is acceptable?
<ubottu> Launchpad bug 209173 in gpaint "Changing line width in gpaint freezes X" [High,Fix released] https://launchpad.net/bugs/209173
 * iulian is looking for an archive admin to sync a package - bug 274276
<ubottu> Launchpad bug 274276 in salasaga "Please sync salasaga 0.8.0~alpha4-1 (universe) from Debian unstable (main)." [Wishlist,Confirmed] https://launchpad.net/bugs/274276
<asomething> or i suppose anyone that could give me some direction
<sbeattie> slangasek: FYI, bug 258985 looks to be a regression (specific to some hardware) introduced by the hardy-proposed kernel.
<ubottu> Launchpad bug 258985 in linux "Ralink rt73 hangs with 2.6.24-21 and requires reboot" [Undecided,Confirmed] https://launchpad.net/bugs/258985
<james_w> asomething: makes sense to me
<asomething> james_w: thanks. the debian maintainer said the new rev would be uploaded when the old one hits testing, and that happened today, so i think it should work out
<slangasek> bryce: is bug #272157 on your radar?  someone sent a comment to the release team blog about it; it appears to be fixed upstream
<ubottu> Launchpad bug 272157 in xserver-xorg-video-intel "Intrepid Alpha 6 desktop freeze with Gigabyte G45" [Unknown,Confirmed] https://launchpad.net/bugs/272157
<bryce> slangasek: thanks I'll take a look
<bdmurray> Is there any easy way to switch back from using a ppa version of a package?
<bdmurray> Or packages rather
<slangasek> with a manageable list of affected packages?
<Riddell> hmm, my uploads don't seem to be being accepted
<bdmurray> slangasek: maybe
<slangasek> bdmurray: disable the ppa in your sources.list, run apt-get update, then apt-get install $p1/intrepid $p2/intrepid [...]
<slangasek> alternatively, if you do the first two steps, update-manager may offer to downgrade them for you, I don't remember
<slangasek> (and assuming these are downgrades, it's not guaranteed that this will work - packages don't always support downgrading)
<superm1> bdmurray, the other GUIish way is to open synaptic, find your package and hit "ctrl-e"
<superm1> lets you pick the version you want to install from those in the repositories you have in sources.list
<ion_> One can do an aptitude search for non-Ubuntu packages.
<IntuitiveNipple> bdmurray: I'm pretty sure I've done that using apt-get --reinstall install <pkg> -t <release>
<ion_> installed ones, that is.
<bdmurray> thanks everyone!
<IntuitiveNipple> bdmurray: or, maybe it was apt-get --reinstall install <pkg>=version-string
<bdmurray> I went the synaptic way, but downgrading isn't nearly as easy as testing a ppa
<emgent> heya
<Adri2000> Keybuk: is there a chance we get MoM patches merged for the beginning of the jaunty dev cycle?
<bryce> slangasek: where's the release team blog btw?
<slangasek> release-blog.ubuntu.com, syndicated on planet
<slangasek> (I didn't approve the comment, if that's what you're looking for)
<bryce> ah ok
<slangasek> it's the first legitimate comment there's been, and I haven't decided whether we really want to take comments there
<superm1> slangasek, at what point do you want to make a call on the bluez 4.x stuff?  A majority of the issues being reported have been broken for the earlier release too.
<slangasek> superm1: I was going to install it myself and get a first-hand impression this weekend :)
<superm1> slangasek, OK :)
<psusi> Keybuk: was wondering if you have a moment to help me understand the revision history of upstart... I'm trying to learn bzr and am a bit confused trying to follow the branch/merge paths in upstart
<nxvl> slangasek: is the new kernel waiting in some kind of queue?
<slangasek> no
<slangasek> linux-restricted-modules is; I'll push that through
<nxvl> mm
<nxvl> odd
<nxvl> for some reason my kernel wasn't updating
<nxvl> i was still having linux-image-4
<nxvl> linux-image-2.6.27-4*
<slangasek> the metapackage isn't uploaded yet; you won't get an automatic update
<slangasek> (the metapackage gets uploaded after lrm)
<nxvl> oh
<nxvl> that's the why
<nxvl> i will wait then
<cody-somerville> bug #262156
<ubottu> Launchpad bug 262156 in envyng-gtk "envynggtk.py crashed with ImportError in <module>()" [Critical,In progress] https://launchpad.net/bugs/262156
<kirkland> slangasek: am I correct in assuming it's too late for musica to be added to the intrepid archive?  https://launchpad.net/ubuntu/intrepid/+queue
<turtle_> whats musica?
<slangasek> kirkland: it's possible one of the archive admins will process it; I've been jumping over the sourcefully new stuff myself
<kirkland> slangasek: is there anything i could do to help it along?
<superm1> tseliot, for intrepid, are you still going to be supporting envy-ng and the appropriate binary packages that go with it?
<slangasek> kirkland: um... find an archive admin who's not me that might process it :)
<kirkland> slangasek: ;-)
<kirkland> infinity: any desire to wield archive-admin powers and add a package to the universe archive for me?  :-)
<tseliot> superm1: only envyng-core and envyng-qt
<superm1> tseliot, may i make a suggestion then for it?
<tseliot> superm1: shoot
<nxvl> kirkland: btw, why you didn'y give it the 2nd ACK after getting motuship?
<superm1> tseliot, perhaps don't use the exact same package names that already provide nvidia and fglrx, but for new versions just expect them to come through the backports pocket
<superm1> tseliot, so envy would instead just grab stuff from backports to add on
<kirkland> nxvl: b/c i didn't want to ack myself :-)
<kirkland> nxvl: thought it would look better to have 2 other MOTU ack it
<kirkland> nxvl: is self ack'ing even legal on REVU?
<tseliot> superm1: yes, I guess it's doable. I have to think about the package names though
<nxvl> kirkland: yes it is
<superm1> tseliot, it would cause less churn I think, and then people who don't use envy will still be able to benefit from it being in the backports pocket
<kirkland> nxvl: that's dirty!
<nxvl> kirkland: since you are a motu, you are supposed to package your stuff in a good way
<nxvl> kirkland: no, you need ack from 2 MOTU's and you are one, so why not?
<sourcemaker> Are you having problems on your webpage (http://www.kubuntu.org)?
<tseliot> superm1: yes, I see your point, I don't know if we really want to use different package names, that's all
<nxvl> kirkland: the idea es that any motu should be technically enough to decide that, so it's assumed that if a MOTU packages something it is in a good shape
<kirkland> nxvl: okay, that sounds reasonable
<tseliot> superm1: it's something we should plan carefully
<superm1> tseliot, well what argument is there toward using different package names for envy stuff?
<tseliot> superm1: I don't do that any more in Intrepid
<sourcemaker> I am able to download php files... I am not just but that sound's not good for me... http://www.kubuntu.org/doc/index.php... just for you information...
<superm1> tseliot, oh what do you currently do in intrepid then?  I haven't actually looked at the implementation yet?
<superm1> tseliot, perhaps you already have done what i'm proposing then
<tseliot> superm1: I simply install the packages in main, as Jockey does. Actually I'm working on Jockey too
<superm1> tseliot, oh then there isn't much of a point to envy being around at all then is there?
<tseliot> superm1: there's still some use-case but we'll discuss this with pitti at the next UDS (if I'm invited...)
<superm1> tseliot, right the use case i see is just the newer versions (ala my backports suggestion)
<tseliot> superm1: and the textual interface and the level to which we can customise installations for different cards
<tseliot> and so on
<superm1> tseliot, ah didn't realize there was a text interface
<superm1> cool
<tseliot> superm1: yes, envyng-core
<superm1> but yeah this will be a good discussion for UDS
<tseliot> superm1: envyng -t
<tseliot> superm1: right
<norsetto> tseliot: btw, are the new packages ready?
<tseliot> norsetto: you can apply the debdiffs which I attached for envyng-core and envyng-qt and ignore the gtk one
<norsetto> tseliot: we are not sponsoring, we only have to assess if you can get an exception
<tseliot> norsetto: is there anything else I can do? Maybe add the output of diffstat?
<tseliot> norsetto: or am I missing the point?
<norsetto> tseliot: you just have to confirm that your package will only ship a transitional -gtk binary (which will not depend on the -qt one) so that you get your exception and then you may proceed with sponsoring
<tseliot> norsetto: ok, so would something like a transitional package with "Depends: envyng-core" be ok?
<tseliot> norsetto: envyng-core contains the main libraries and the textual interface
<norsetto> tseliot: yes, but make sure also that the description is updated
<tseliot> norsetto: yes, sure. I'll fix it tomorrow and attach the new debdiff to the bug report
<norsetto> tseliot: perfect, thanks
<tseliot> norsetto: thank you ;)
<norsetto> tseliot: or rather, thanksissimo
<tseliot> hehe
<turtle_> if I installed snes9x-x, where should it be located
<turtle_> ?
<cjwatson> dpkg -L snes9x-x
<cjwatson> also, #ubuntu ;-)
<turtle_> that opens it from the terminal?
<mneptok> turtle_: support questions in #ubuntu, if you please. :)
<turtle_> sorry, forgot i was in here
<mneptok> i feel that way every day when i wake up.
<bryce> hey slangasek, with -ati I'm finding that I'm needing to pull in most of the recent changes to the git driver to solve various bugs in launchpad.  I'm wondering about just putting in a newer git snapshot that has all the changes.  Do you have an opinion?
<slangasek> bryce: are the changes all bugfixes, or are there a lot of structural changes or features?
<bryce> pretty much all bug fixes
<bryce> no structural changes or features
<slangasek> then I'm happy for you to upload, if you think the risk of regression is reasonable
<cody-somerville> slangasek, do you run an ATI card?
<slangasek> no
<slangasek> am I required to commiserate before suggesting bryce upload? :)
 * cody-somerville shrugs.
<cody-somerville> I run nvidia
<cody-somerville> bryce, regress as you see fit
<slangasek> er, what
<cody-somerville> slangasek, as long as we good nvidia goodness, ati doesn't matter much :P
<cody-somerville> bryce, Is the failsafex stuff not finished? When I click ok with almost any of the different options, the screen just goes away and comes back.
<bryce> cody-somerville: no all that should work
<cody-somerville> bryce, its all broken for me :(
<bryce> cody-somerville: it's pretty simple bash stuff so if you want to poke into it you might be able to figure out what's going wrong
<cody-somerville> bryce, Also, I noticed installing the nvidia restricted drivers installs nvidia-settings
<cody-somerville> bryce, although it provides a lot of nice functionality, it never writes an xorg.conf file that whatever version of X we have in Intreprid understands.
<superm1> cody-somerville, it's open source..... ;)
<cody-somerville> superm1, nvdia-settings?
<superm1> yup
<PovAddict> I think I found a package dependency problem... I installed libasio-dev, included one of its headers from my program, and I get this compiler error:
<PovAddict> /usr/include/asio/detail/epoll_reactor.hpp:29:59: error: boost/date_time/posix_time/posix_time_types.hpp: No such file or directory
<PovAddict> which would probably be solved if I install libboost-date-time-dev
<PovAddict> shouldn't libasio-dev depend on it?
<slangasek> PovAddict: yes, it should; please file a bug
<PovAddict> ah looks like it depends on libboost-dev
<PovAddict> and libboost-dev recommends libboost-date-time-dev
<PovAddict> so if the maintainer has his package manager set to auto-install recommended packages, he wouldn't notice the problem :)
 * PovAddict makes a launchpad account
<LaserJock> bryce: around?
<bryce> yep
<LaserJock> bryce: I put in a new .fdi file in /etc/hal/fdi/policy and restarted hal but to no effect
<LaserJock> bryce: has something changed?
<bryce> not afaik
<LaserJock> hmm
<LaserJock> well that .fdi used to work (it's the one I put on the wiki page)
<wtgee> Howdy all....my /etc/hosts file keeps getting overwritten as of todays updates.  Am I supposed to enter a host alias somewhere else now?
<wtgee> Overwritten after each reboot I should say
<slangasek> wtgee: this is a network-manager bug
<slangasek> it's been discussed over the past few days; I'm not sure if there's an open bug report
<wtgee> slangasek: I thought I read something about it somewhere but of course didn't think it applied to me so I didn't pay attention.
<wtgee> slangasek: But I thought I had read that they would be handled via the network manager but I don't see anywhere to do that.   thanks for the info though.
<LaserJock> bryce: ok, well, I restarted X and it still doesn't take it
<slangasek> wtgee: the bug is that there's no reason at all for n-m to manage /etc/hosts by default
<LaserJock> bryce: looking in the X log it looks like *again* there are two devices set up and my configuration is getting overriden
<LaserJock> so how exactly is a person supposed to configure their devices? :-)
<LaserJock> oh wait
<LaserJock> the touchpad tab is back in the mouse configuration tool, sweet
<wtgee> slangasek: That's sort of what I was confused about.  Upon further reflection I think what I read was the the network manager was clobbering /etc/network/interfaces and that one shouldn't manually edit that file.  That is fine with me as I would expect that, but not /etc/hsots
<wtgee> or /etc/hosts
<slangasek> right
<slangasek> the /etc/network/interfaces incompatibility was present in beta, and fixed in the same upload that started fiddling with /etc/hosts
<wtgee> I'm looking through the tracker now to see if it is reported yet and will report if not
<LaserJock> bryce: btw, is there any transition possibility for all the people who used xorg.conf to set up their touchpads?
<LaserJock> it seems like it'd be a fairly big "OMG, Ubuntu killed my devices" moment :-)
<wtgee> slangasek: Should I file it as a network-manager bug or unknown?
<slangasek> network-manager, there's nothing unknown :)
<wtgee> slangasek: My first bug report! Woohoo! Thanks for the info.
#ubuntu-devel 2008-10-04
<bryce> LaserJock: not that I know of
<bryce> LaserJock: patches welcomed tho
<wgrant> Shouldn't xorg.conf be replaced if it hasn't been modified?
<bryce> wgrant: well LaserJock's talking about people who've customized their xorg.conf's to set up input devices
<wgrant> bryce: Ah. Maybe we need some XKit magic to remove the default device entries?
<wgrant> Actually, why doesn't it work?
<bryce> wgrant: i-h/-evdev steals all the devices and ignores xorg.conf settings
<wgrant> Exactly.
<wgrant> But having an entry for the touchpad breaks things.
<bryce> https://wiki.ubuntu.com/IntrepidReleaseNotes - see X.org Input Devices
<wgrant> So it's obviously not entirely ignored.
<jcristau> the synaptics from xorg.conf should steal the device before the hotplugged one
<tseliot> bryce, wgrant: maybe we could make a backup of xorg.conf files and remove inputdevice sections and serverlayout sections with XKit.
<wgrant> tseliot: That's what I was thinking.
<wgrant> Hmmm.
<wgrant> Shouldn't we just remove the default inputdevices and remove their references from serverlayout?
<wgrant> Removing custom inputdevices and custom serverlayouts sounds like a recipe for irate users.
<bryce> commenting them out would be preferable to removing them
<wgrant> jcristau: If it's stealing the device first, why doesn't the entry in https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+bug/214252/comments/16 work?
<ubottu> Launchpad bug 214252 in xserver-xorg-input-synaptics "[Hardy] Synaptics touchpad vertical scroll (middle button) not working as expected" [Undecided,Fix released]
<tseliot> wgrant: yes, I agree with you. We'll need to plan (and then test) this carefully
<wgrant> We haven't got long, though...
<tseliot> bryce: currently XKit doesn't allow to do comment things out but having a backup file, say, xorg.conf_dist-upgrade, should be enough
<bryce> hmm
<tseliot> wgrant: it's 01:47 AM here and by carefully I mean when I'm not half asleep ;)
 * wgrant is glad this can be done in the dist-upgrader, and doesn't have to be a postinst somewhere.
<nxvl> slangasek: did you accepted lrm alreadu?
<nxvl> already*
<wgrant> tseliot: Heh.
<tseliot> bryce, wgrant: ok, we can talk about this maybe via email, and notify mvo
<bryce> sounds good
<slangasek> nxvl: yes
<jcristau> wgrant: that bug doesn't have a recent log, so, dunno.
<tseliot> ok then, good night
<nxvl> slangasek: \o/
<nxvl> slangasek: then i can update in the morning?
<slangasek> nxvl: that depends on when linux-meta is uploaded, you'd have to ask the kernel team on that
<wgrant> jcristau: The recent comments at the end seem to be unrelated to the rest of the bug.
<slangasek> nxvl: well, or you can upgrade by hand, yes
<nxvl> slangasek: yes, but there is still no linux-restricted-modules-2.6.27-5
<slangasek> nxvl: there is; though it may not be on your mirror yet
<nxvl> right, i'm using pe.archive
<nxvl> that might be
<nxvl> slangasek: Bug #256459
<ubottu> Launchpad bug 256459 in debian-installer "ubuntu-server installation, error messange in partitions correction" [High,Triaged] https://launchpad.net/bugs/256459
<nxvl> slangasek: can you confirm that it is on debian-installer actually?
<slangasek> nxvl: 'partman' is a more exact starting point, but 'debian-installer' is also ok
<nxvl> slangasek: ok, i will look at partman, thank you
<LaserJock> wgrant: sorry, was afk
<LaserJock> wgrant: my problem is that I had my touchpad set up in xorg.conf and that got overridden by HAL so I wrote an fdi file
<LaserJock> *now* xinput overrides HAL so my fdi file doesn't work
<LaserJock> so in the end I've moved through 3 different configuration mechanism to configure my touchpad
<wgrant> LaserJock: What do you mean "xinput overrides HAL"?
<LaserJock> wgrant: meaning, xinput settings override my HAL settings
<LaserJock> so I had my fdi file all set up but it didn't have any effect
<LaserJock> so their seems to be a hierarchy, xinput > HAL > xorg.conf
<wgrant> LaserJock: You mean you were trying to override some of the ~4 XI properties that gnome-settings-daemon now sets?
<wgrant> Right.
<LaserJock> wgrant: I'm not sure what's responsible
<wgrant> Which were you trying to set?
<LaserJock> I just know what works and then it stops working
<LaserJock> turn off the tap-to-click and vertical scrolling
<wgrant> Right, gnome-settings-daemon overrides those.
<wgrant> You want System->Preferences->Mouse->Touchpad.
<LaserJock> sure, I figured that out eventually
<LaserJock> but I had a fdi file that worked, and previously I had an xorg.conf that worked
<LaserJock> I think users are gonna have a bit of a shock if they've, like me, done any configuration of their touchpad
<wgrant> If people are delving into their xorg.confs and fdi files, I think we can probably expect them to be able to work this out...
<LaserJock> why?
<wgrant> fdi files only just started existing, so this doesn't affect upgrades.
<LaserJock> no, but it's in the wiki
<LaserJock> people are going to find it and file bugs as to why it doesn't work right
<wgrant> LaserJock: Where in the wiki?
<LaserJock> and existing xorg.conf files not working is a bigger concern
<LaserJock> X/Config
<wgrant> Right, the xorg.conf issue needs to be worked out.
<wgrant> But I don't see fdi files as a particularly significant issue.
 * wgrant fixes the wiki page to mention that gnome-settings-daemon overrides a few things.l
<LaserJock> well, I'm glad to not need the fdi file anyway :-)
<LaserJock> but there are a lot of good documentation on help.ubuntu.com that will need updating
<wgrant> We certainly do need better docs.
<LaserJock> has anybody talked to the Doc Team about this change?
<mrooney> TheMuso: ping?
<slangasek> superm1: ping
<mrooney> wgrant: well, I'll boot back in Hardy so I can get some things done, and try later, thanks for your help!
<wgrant> mrooney: np
<slangasek> superm1: contentful ping: if you have a chance, I'd appreciate a review of https://wiki.ubuntu.com/IntrepidReleaseNotes#nVidia%20%22legacy%22%20video%20support for accuracy
<wgrant> slangasek: Who grants UI freeze exceptions?
<slangasek> wgrant: the release team who grants other freeze exceptions for the component in question
<wgrant> slangasek: OK, so you count for main?
<slangasek> yes :)
<wgrant> slangasek: Given that we're breaking everybody's custom Synaptics touchpad configuration, I'd like to ensure that the most customised options are exposed through the GUI - the two I'd like to add are horizontal and vertical two-finger scrolling. That'd just mean two extra checkboxes in the Touchpad tab of gnome-mouse-properties, and a few extra lines of code there and in g-s-d... what are my chances?
<slangasek> wgrant: chances are excellent; the UI freeze is mostly to prevent gratuitous changes that piss off the doc folks, not to get in the way of fixing major UI blunders
<wgrant> slangasek: Not really a UI blunder, but sounds good...
<wgrant> Well, I guess forcing people to config things through xorg.conf is a UI blunder.
<slangasek> that's my view :-)
<wgrant> slangasek: What's the process for officially getting an exception?
<wgrant> Oh. I didn't see that it was on FreezeExceptionProcess. Sorry.
<bryce> slangasek: ok, -ati git snapshot packaged, tested locally, and uploaded.
<superm1> slangasek, Isn't the migration to "nv" going to be automatic for those users too though?
<superm1> like how you mentioned in the -ati one
<superm1> wgrant, is it possible too for a checkbox for circular scrolling for touchpads that support it?
<superm1> i'm not sure how much is in the synaptics driver - but i know i've got some hardware that supports it at least
<wgrant> superm1: It's entirely in the driver.
<wgrant> superm1: I'd like to add it, and I'm working on that code now, but the hard bit is taking input for the start position.
<wgrant> A guess a set of radio buttons would work.
<wgrant> The touchpad device is really pretty stupid - it just reports touch position, pressure, sometimes number of fingers, and sometimes width.
<superm1> wgrant, ah i wasn't aware it was all software supported
<wgrant> superm1: Any other options that you'd like exposed?
<superm1> wgrant, what else is there?  I just knew about circular scrolling, horiz and vert scrolling
<wgrant> superm1: xinput list-props "SynPS/2 Synaptics TouchPad"
<wgrant> There's a lot.
<wgrant> Much of it probably shouldn't be exposed, but more of it should be eventually.
<superm1> hum, for me unable to find device SynPS/2 Synaptics TouchPad
<wgrant> xinput list
<superm1> oh on this machine it's ALPS
<wgrant> Some types have different names.
<wgrant> Ah.
<superm1> wgrant, two finger scrolling would be nice
<superm1> i've seen some mac folks who have had that
<wgrant> superm1: That's what I'm implementing now.
<wgrant> A lot of people request it.
<superm1> wgrant, cool :)
<bcurtiswx> anyone here understand Oct  3 15:03:52 weather kernel: Inspecting /boot/System.map-2.6.27-4-generic
<bcurtiswx> Oct  3 15:03:52 weather kernel: Cannot find map file.
<bcurtiswx> is that a bad thing?
<slangasek> superm1: I don't know yet; I've asked that question in the bug, but I'm not writing that in the release notes until it's implemented
<slangasek> superm1: did it look accurate, otherwise, in terms of the chipsets claimed to be affected?
<saurabh> i think the global menu patch is a bad idea, normally we access the menu using the ALT key, so why not just hide the menu and then show it after the user presses the ALT key?, this saves vertical screen space as well
<ion_> What patch?
<Hobbsee> i expect you end up with teh ie7 situation then
<Hobbsee> a whole bunch of users going "what the hell have you done with my menu?!?!?!"
<saurabh> Hobbsee: we can make it optional then
<Hobbsee> saurabh: even so.
<wgrant> "global menu patch"?
<saurabh> wgrant: yes
<wgrant> Not quite the response I was wanting.
<ion_> Ditto
<saurabh> i just need the ability to hide the menu for every application
<wgrant> What is the global menu patch, and why is it a bad idea?
<saurabh> wgrant: you get mac like global menu functionality
<wgrant> saurabh: Ah.
<digistyl3> hi TheMuso, are you online?
 * wgrant doesn't normally access menus using Alt.
<digistyl3> hey everyone, i seem to have a strange problem, and i think it's related to the intel driver (i use an intel x3100)
<digistyl3> when i use virtualbox
<digistyl3> the screen contents sometimes freeze
<digistyl3> they only refresh when i move the window
<digistyl3> it happens with me in dosbox too
<digistyl3> i don't have the fancy desktop effects enabled
<digistyl3> how can i debug this?
<digistyl3> it also happens with flash
<digistyl3> if i watch youtube videos
<digistyl3> the image in the video freezes, i have to scroll for it to continue updating the contents
<digistyl3> oh well, i just found two bugs about this and joined them, people thought it was a flashplugin-nonfree bug https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/275285
<ubottu> Launchpad bug 275285 in xorg-server "[intrepid] Flash, VirtuabBox, Dosbox etc. video freezes after few seconds" [Undecided,Confirmed]
<ogra> thats more likely a driver prob
<ogra> digistyl3, you should ask for X driver info
<digistyl3> ogra: someone said that he's using nvidia graphics
<ogra> yeah, i see two people mentionint intel though
<ogra> *mentioning
<digistyl3> ogra: i posted my xserver-xorg and xserver-xorg-video-intel version numbers
<ogra> good
<digistyl3> you don't think the bug is in the kernel, do you?
<ogra> no idea, but it sounds like an xorg driver or compiz bug
<digistyl3> ogra: i have visual effects set to "None", so i think compiz is out of the picture here
 * mcasadevall pokes ScottK 
<siretart> what does 'å¤ èå' mean? (keybuk's quit message)
<Spads> siretart: it's a chinese phrase allegedly meaning "to hell with it" (or equivalent) that was used in the dialogue in Firefly
<realist> I'm not sure, my terminal only displayed one of those glyphs
 * realist wonders how to fix that
<Spads> realist: I installed ttf fonts until everything appeared: http://pastebin.ubuntu.com/23131/ (as of July)
<Spads> \ã / <-- eventually you'll be able to see the postman there
<realist> I'm laking some fonts, it appears
<Spads> realist: well to be fair, I doubt most of those fonts are relevant to your locale, so it makes sense that they aren't installed by default.  Still, I'd love a ttf-lots-and-lots-please metapackage of some sort
<StevenK> ttf-every-font-and-then-some
<Spads> yeah precisely
<realist> I'm about to try something like; apt-get install `apt-search ttf |awk '/^ttf/{print $1}'`
<Spads> yeah I've done something similar
<realist> ^search^cache search^
<Spads> you have to grep out conflicting ones
 * realist nods
<realist> 359MB, maybe not
<lfaraone> How would I go forward with a bug like bug 277302 that has a bzr branch attached and works (IMHO), where ubuntu is upstream?
<ubottu> Launchpad bug 277302 in ubiquity "NetworkManager is starting up "after" ubiquity in only-ubiquity mode" [Undecided,Invalid] https://launchpad.net/bugs/277302
<lfaraone> (correction, it's filed against networkmanager and is triaged as medium)
<siretart> Spads: ah, thanks
<exco> to chroot into a broken 8.10 - do I need an 8.10 live cd or should it also work with an 8.04 one?
<siretart> exco: please use #ubuntu for end-user support
<exco> ok thanks, siretart
<hspaans> g'day all
<hspaans> now Ubuntu 8.10 is in beta, all packages have been landed? this because X sometimes freezes up
<EvanCarroll> Is there a unannounced plan for regression in Xorg to 7.3 in the event ATI doesn't update fglrx in time for release?
<EvanCarroll> or is 8.10 really at risk for being pushed onto the shelf without fglrx?
<cjwatson> the latter; reverting X is pretty much off the table at this point
<EvanCarroll> wow, that amazing.
<cjwatson> we may be forced to do a post-release update of fglrx, although I don't like that option
<tseliot> currently we are migrating installations to the open source driver with Update Manager + X-Kit
<EvanCarroll> the failure of ATI to get fglrx out is going to have massive blowback for the adoption of the distro if it goes out like this.
<Mirv> EvanCarroll: the open source driver should nowadays support good 2D resolutions out of the box on even the X3000/X4000 series, so ordinary people don't notice until they start to want some fancy 3D (at which point there might be an update available already)
<Mirv> the main problem before was that they couldn't even start Ubuntu without fglrx, nowadays luckily that's not a problem
<EvanCarroll> even the opensource driver (radeonhd i presume) don't support HDMI, and the ATI driver doesn't support sound on HDMI, and the conversion from fglrx to ati is actually apearing to draw outside of the size on my screen.. But I could be wrong - I'm looking into that now to file a bug
<Mirv> (since ATI has failed to release drivers supporting latest X.org before, too)
<EvanCarroll> yea, I'll definitly speak with my money on my future purchases I'm afraid new people aren't smart enough to point a blame finger and the buck will stop at the distro
<tseliot> EvanCarroll: we use the "ati" driver (not "radeonhd"). Please file a bug report
<Mirv> EvanCarroll: well NVIDIA has equally lacked support for latest X.org releases, so currently with external gfx cards you choose wrong anyway :) ATI's going to better though, while NVIDIA probably won't.
<Mirv> EvanCarroll: anyway, the point is that if users install intrepid in eg. November, they might have fglrx install option as soon as they boot the installed system
<EvanCarroll> oh well, at least we can see the bumps in the road up ahead. I just wonder if a system that warns early adopters that this will probably not live up their expecatations is called for prior to the update and download of packages. IE some sort of outstanding "critical" issues syndication that integrates with the libapt in a post-calculating-ugrade process
<EvanCarroll> since this will certaintly at the very least break all of the new HTPCs running on the ati chipset
<slangasek> EvanCarroll: the issue will be documented in the release notes, which will be displayed in update-manager when you click 'upgrade'; except that it looks like we're currently showing the wrong document, so I'll dig into that
<EvanCarroll> Is that a feature of update-manager of an extention to libapt?
<slangasek> update-manager, which is the supported upgrade path between Ubuntu releases
<EvanCarroll> interesting, I've always just used apt-get dist-upgrade and figured they had the same functionality
<Mirv> EvanCarroll: read the documentation ;)
<slangasek> they don't; in addition to displaying the release notes, update-manager implements a number of quirks that can't be implemented sanely within apt, to handle specific upgrade issues between releases
<sebner> slangasek: aloha. did you notice my nfdump debdiff (since you are subscribed)?
<slangasek> sebner: hmm, apparently not; sorry, it may have been lost in the wash of beta-related mail
<sebner> slangasek: nvm :) Still interested or should I subscribe u-u-s?
<EvanCarroll> slangasek: thanks for the info, Mirv not mentioned in man pages of update-manager, in fact it is called a "front-end into the apt package management system" -- which almost explicitly says, "I do nothing special"
<sebner> sladen: debdiff is reallllllllllllllllly small though  ^^âº
<EvanCarroll> my mental model just lead me to believe update-manager was aptitude or dselect or somtehing ported to GTK
<EvanCarroll> and that they were all front-ends to libapt
 * EvanCarroll reads the code to update-manager
<slangasek> cjwatson: seems to be some memory fuzziness on my part; I thought update-manager would link directly to the release notes, but it seems to only link to dists/$distseries/main/dist-upgrader-all/current/ReleaseAnnouncement - am I thinking of ubiquity?
<IntuitiveNipple> What's the policy when an existing patch is incomplete? correct the patch, remove it and add a full patch, or add a patch that does the 'diff' between existing and 'full' ?
<slangasek> sebner: uploaded, thanks
<sebner> slangasek: np, thx to you :)
<EvanCarroll> Mirv: yea, there are some things it does, like checks symlinks to /usr/bin/python
<EvanCarroll> and that you don't upgrade more than one leap at a time
<geser> IntuitiveNipple: I guess there is no policy but commonly the patch gets fixed (e.g. a new version gets attached to the bug)
<EvanCarroll> it seems to be like it would be advantagous to move this stuff into a libapt extention
<IntuitiveNipple> geser: I'm repackaging it so I'll just regen the patch then
<EvanCarroll> Mirv: what is the supported upgrade method if you don't have X? like with ubuntu-server?
<ion_> do-dist-upgrade
<ion_> do-release-upgrade, that is.
<EvanCarroll> interesting. =)
<Mirv> EvanCarroll: the documentation is http://www.ubuntu.com/getubuntu/upgrading - of course man pages could be good too, but if one knows man pages etc. one should possibly be able to fix any small breakages apg-get dist-upgrade might cause
<EvanCarroll> I tend to agree, the stuff it does is fairly minor but it does a lot of fairly minor stuff, even reseting themes if they are being used and known to cause problems
<EvanCarroll> some of the stuff it does seems kind of fishy: like executing random scripts in the local directory, and making the assumption that it is being run under sudo
<slangasek> pitti, tjaalton, bryce: in https://wiki.ubuntu.com/IntrepidReleaseNotes we say that some keys may misbehave in X if you have the wrong keyboard model set.  Is this really going to be a problem on upgrade?  If it is, shouldn't we be doing something better to detect the keyboard model on upgrade?
<cjwatson> slangasek: ubiquity links to the online one; I've never looked at what update-manager does
<slangasek> ok
<cjwatson> EvanCarroll: update-manager was conceived as executable release notes
<cjwatson> at least that was how I put it and I liked the phrase, I don't know if it caught on :)
<cjwatson> EvanCarroll: release notes often include all sorts of random little stuff, and update-manager is no different really
<tseliot> slangasek: as regards the problems caused by InputDevice entries for the mouse and keyboard in the xorg.conf, we were discussing with bryce and wgrant about letting Update Manager remove these entries with X-Kit
<tseliot> slangasek: if you were referring to this problem in your last question.
<slangasek> tseliot: I don't know that this has any relation to what is shown as the keyboard type in the GNOME interface
<slangasek> tseliot: btw, I had questions regarding your follow-up to bug #251107
<ubottu> Launchpad bug 251107 in ubuntu-release-notes "[Intrepid] nvidia_drv.so: undefined symbol: AllocateScreenPrivateIndex" [High,In progress] https://launchpad.net/bugs/251107
<tseliot> slangasek: ok, I guess I misunderstood your question then ;)
<slangasek> tseliot: aren't these nvidia drivers shipped in binary-only form?  If so, isn't it a *bug* if the ABI declaration is not hard-coded?
<NCommander> slangasek, no, the NVIDIA drivers have a small LGPL glue code and then the blob
<tseliot> slangasek: only a part is a binary
<NCommander> (its how they run around releasing closed blob drivers)
<tseliot> slangasek: and of course the part which is affected by the problem described in the bug report is the binary one
<slangasek> hum - so the X driver includes an LGPL shim?
<slangasek> still seems buggy to me to auto-increment the ABI, since clearly the binary bit can also break it
<NCommander> Anyone here a firefox guru?
<IntuitiveNipple> NCommander: I became a bit of one recently, fixing up xulrunner1.9, but I don't guarantee anything :)
<NCommander> IntuitiveNipple, I think I found a problem with the firefox alternatives file
<IntuitiveNipple> NCommander: ah ok. I was more focused on internal xulrunner core code, although I did do some stuff with incorrect flashplugin paths a while back.
<NCommander> IntuitiveNipple, can you tell me if firefox-3.0 works for you
<NCommander> (specifically that command)
<IntuitiveNipple> Not for intrepid, no. I'd have to run up a VM and since the daily on Friday it fails to run the CD installer for me
<tseliot> slangasek: I see your point however, if that kind of breakage happens, I assure you that I will notice it (as Xorg won't start). It is more likely that I forget to bump the ABI.
<slangasek> tseliot: well, that seems to assume no one else ever does a package rebuild for other reasons without having the hardware to test with
<slangasek> NCommander: er, check the bug list?
<slangasek> bug #275410
<ubottu> Launchpad bug 275410 in firefox-3.0 "sensible-browser not working" [High,Triaged] https://launchpad.net/bugs/275410
<tseliot> slangasek: well, in my opinion you shouldn't package new upstream versions which you can't test
<tseliot> it's a bit risky
<NCommander> Hrm, this was a bug with x-www-browser
<slangasek> tseliot: I'm not talking about packaging new upstream versions
<tseliot> slangasek: what's the use case then?
<NCommander> slangasek, should a release-blocker bug be considered critical or high
<slangasek> tseliot: anyone doing archive-wide fixing of packaging bugs
 * NCommander can't remember :-/
<slangasek> NCommander: release-blocker status is unrelated to the distinction between critical and high
<NCommander> ok
<slangasek> https://wiki.ubuntu.com/RCBugTargetting
<NCommander> slangasek, this bug completely breaks the Xubuntu Xfce help system
<NCommander> Thank you
<slangasek> well, and?  I've already marked the bug as release-critical...
<tseliot> slangasek: I hope that such a thing doesn't happen without talking to the X-team first
<slangasek> Maintainer: Ubuntu Core Developers <ubuntu-devel-discuss@lists.ubuntu.com>
<slangasek> tseliot: ^^ that's the maintainer field on nvidia-graphics-drivers-71, which implies any core-dev can expect to reasonably upload
<slangasek> NCommander: you're right that the bug title is incomplete; fixing, thanks
<NCommander> I'm adding my two cents
<NCommander> (a second script /usr/bin/firefox-3.0 is also broken)
<slangasek> that's not a second script
<tseliot> slangasek: that doesn't look good to me. Just my 2 cents
<perlsyntax> Does anyone know how to do raw socket in unbuntu?
<slangasek> tseliot: then apparently someone should change it? :)
<perlsyntax> how do i programming in main root?
<slangasek> tseliot: my understanding of current practice is: if the maintainer field points to a specific person or team, talk to them first before uploading.  If not, you can upload without coordination.
<slangasek> perlsyntax: this is not a help channel
<perlsyntax> do i sudo bash to do that?
<perlsyntax> ?
<tseliot> slangasek: good point. Maybe we could use something like this team: https://launchpad.net/~ubuntu-x-swat
<perlsyntax> hello?
<trenton_> Hello all, trying to build Amarok2 from trunk but getting mysql error on kubuntu hardy. needs libmysqld.a which package do I need please?
<tseliot> slangasek: suggestions are always welcome ;)
<perlsyntax> slangasek, any ideas?
<slangasek> perlsyntax: I said, this is not a help channel.  Try #ubuntu, or a help channel specific to your programming language.
<perlsyntax> i did they told me to come here
<slangasek> they told you wrong
<NCommander> slangasek, have you done any work as cooking a patch for this bug, or shall I try to do one myself
<tjaalton> slangasek: it shouldn't matter anymore, so that part can be dropped from the release notes
<slangasek> tjaalton: great, thanks
<slangasek> tseliot: ~ubuntu-x-swat looks like a pretty good fit for that, yeah
<EvanCarroll> I think I was just affected by a keybinding bug my caps lock just randomly got remapped to caps lock
<NCommander> slangasek, I figured out what I need to patch to in the firefox-3.0 source package. I'm going to have it checked for the appname (i.e., if it tries to call gnome-sensible-browser, it will try that first, then fall back to $LIBDIR if not found)
<NCommander> slangasek, any objections?
<tseliot> slangasek: ok, thanks for spotting the problem and for your suggestion
<slangasek> NCommander: yes, I object because I outlined the correct fix in my follow-up to the bug
 * NCommander rereads steve's bug
<NCommander> slangasek, isn't that in effect what I just suggested? Check for the name it was called by, and if it doesn't exist, call the always known to be there firefox binary?
<NCommander> or I said my fix would be
<slangasek> NCommander: no, you said something about "falling back to $LIBDIR"...
<NCommander> In the script, it tries to call $LIBDIR/$APPNAME
<NCommander> Which works out to be /usr/lib/firefox-3.0.3/$APPNAME
<NCommander> So if I call it as x-www-browser, it should try /usr/lib/firefox-3.0.3/x-www-browser before falling back to firefox, unless I misunderstood you
<nxvl> cjwatson: can you please process Bug #274173?
<ubottu> Launchpad bug 274173 in terminator "[FFe] Please sync terminator 0.11-2 from debian sid" [Wishlist,Confirmed] https://launchpad.net/bugs/274173
<hansin> Anyone here heard on any install issues with the beta alternate CD for i386?
<slangasek> it should try /usr/lib/firefox-3.0.3/x-www-browser; then it should do NAME=$(readlink $0); APPNAME=$(basename $NAME); and check for that; and it should iterate until either readlink says it's not a link, or NAME = /usr/lib/firefox-3.0.3/firefox.sh, and /then/ fallback
<slangasek> NCommander: ^^
<NCommander> slangasek, ah. I wasn't quite familar with readlink's behavior, but that makes perfect sense.
 * NCommander attempts to recover the tomes of shell script programming in my head
<NCommander> slangasek, maybe I'm missing something, but is there a reason that you can't simply call the symlink directly?
<NCommander> Since you can do -L $LINK to see if its valid, and if not, drop to firefox
<NCommander> ^^- slangasek?
<NCommander> slangasek, http://pastebin.ca/1219253 - this is what my current tweak to the firefox.sh script looks like
<cjwatson> nxvl: it's a weekend and I have to get up early tomorrow; I'm off to bed
<cjwatson> nxvl: I assume ubuntu-archive is subscribed and thus it is in the queue
<NCommander> nxvl, how's your shell scrpiting?
<nxvl> cjwatson: yes, sleep tight!
<nxvl> NCommander: shoot
<slangasek> NCommander: fails for the case of gnome-www-browser -> abrowser.
<NCommander> nxvl, http://pastebin.ca/1219253
<slangasek> NCommander: I really did have a reason for specifying the fix that I did.
 * NCommander feels lost
<NCommander> Wait
<NCommander> hrm
 * NCommander gets it!
<NCommander> slangasek, one problem with your idea. x-www-browser -> firefox-3.0/abrowser -> /usr/lib/firefox-$VERSION/firefox.sh
<NCommander> (well, x-www-browser -> /etc/alternates/x-www-browser -> *)
<slangasek> I don't think you've understood my idea yet
<NCommander> I think your right
<NCommander> Oh, I see
<NCommander> I missed the "a matching name is found"
<NCommander> Hrm
<NCommander> abrowser still has Mozilla Firefox branding
<slangasek> I have a patch here for it; I'll push it to the bug
<NCommander> Oh, you do?
 * NCommander just finished fixing his patch
<NCommander> oh well, it was a good experience in shell scripting
<slangasek> I do now, yes
<NCommander> Sorry for the duplication of effort, but at least the bug gets resolved, and that's what counts
<slangasek> NCommander: patch posted; please test
<NCommander> slangasek, probably a stupid question, but /usr/lib/firefox-$VER/firefox will exist even if only abrowser is installed, right?
<slangasek> that file appears to belong to the firefox-3.0 package, so probably not?
<NCommander> Your call of last resort should do a sanity check to see that $LIBDIR/firefox exists, and then try $LIBDIR/abrowser before bombing out
<cody-somerville> oh noes
 * NCommander is test building your package as we speak
<cody-somerville> It should try icemonkey or whatever it is called too
<slangasek> it won't fail for the case where the called link is, or points to, abrowser
<slangasek> the last-resort is only ever reached if the caller has done something very wrong
<NCommander> I'm just noting a case that for whatever reason someone links to firefox.sh directly, so ...
<NCommander> Yeah, pretty much
 * NCommander notes that abrowser REALLY needs a better icon
<slangasek> and actually, it appears that abrowser Depends: firefox-3.0, so even that isn't really a concern currently
<wgrant> firefox depends upon firefox-3.0-branding, which is the one with the nasty bits.
 * NCommander nods
<NCommander> Just out of idle curosity, slangasek, do you use abrowser or firefox?
 * ogra sighs ... debian is such a pain if you are used to ubuntu
<slangasek> firefox
<NCommander> slangasek, your fix appears to work fine
<NCommander> (I can use x-www-browser and sensible-browser without any issues and abrowser pops up)
<NCommander> wgrant, what about you?
<NCommander> slangasek, I commented on the bug
 * slangasek nods
<NCommander> slangasek, I envy your shell scrpiting abiltiies; any tips on where I can learn better scripting?
<slangasek> hmm, absorb the entire archive of debian-devel through your skin, perhaps :)
<wgrant> NCommander: I use abrowser
<slangasek> but probably applying a joeyh pattern filter first
<wgrant> Hah.
<NCommander> slangasek, as soon as we get an open source time machine, I shall ;-)
<slangasek> time machine?
<NCommander> wgrant, are you agreed with me that abrowser needs better icons?
<NCommander> slangasek, I'd like to go back intime and sit in on #debian-devel :-)
<wgrant> NCommander: I don't think it's too bad, actually.
<NCommander> I can't believe I'm the one saying this, but its too blue :-P
<slangasek> NCommander: I was referring to the mailing list
<NCommander> slangasek, ah. Maybe I'll sit aside and read the entire archive one day
<slangasek> that's certainly a long way to go about it, though.  Alternatively, if Ian Jackson has ever written a shell scripting guide, that would be a good starting point too.
<slangasek> and probably only a third as long ;-)
<NCommander> lol
<NCommander> Hrm
<NCommander> Things I find frustating
<NCommander> Its impossible to describe a song over the internet if you don't know the name
<NCommander> er
<NCommander> wrong channel
<NCommander> But true
<NCommander> slangasek, the longest thing I ever read was the entire hurd-devel archive
<NCommander> ogra, why is Debian a pain compared to Ubuntu?
<ogra> well, its starts with /sbin not being in any path
 * ogra is playing with a debian port on his n800, where typing is massively painful and they didnt manage to give *any* function to the keypad
<NCommander> ogra, sounds like an Ubuntu port to ARM is in order
<ogra> its only fou silly keycodes to make it work as joystick, sigh
<ogra> *four
<ogra> not yet
<ogra> there is mojo.handelds.rog though
<ogra> *org
<slangasek> ogra: what are you missing being able to run from /sbin?
<slangasek> I think the /sbin in the default path only makes sense because of sudo-by-default
<ogra> well, ifup and ifdown
<slangasek> which you can't run as a non-root user anyway?
<ogra> if you type with a pen giving the full path is just a pain
#ubuntu-devel 2008-10-05
<ogra> su doesnt change my path+
<slangasek> it doesn't?  It certainly does for me
<NCommander> slangasek, if you use sudo, then the lack of sbin paths is somewhat anonying
<NCommander> WHen I run debian, thats the first thing that gets changed
<slangasek> well, presumably the first thing you change is to /configure/ sudo, since it's not configured by default...
<slangasek> this is my point - the lack of /sbin in the default user path is not inconsistent with the rest of the defaults :)
 * NCommander falls over
<ogra> ell, i personally get the network up and install openssh-server :) helps a lot on a tablet :)
<NCommander> Then maybe installed sudo should add the sbin folders to the path ;-)
 * wgrant stabs NCommander with a path segment.
<slangasek> no, because installing sudo is not the same thing as configuring it
 * NCommander dies
 * NCommander runs sudo aptitude install ncommander
 * NCommander is reborn
<NCommander> slangasek, ah, point taken
<stgraber> slangasek: hey, how bad would you feel about getting a new release of ltsp and ldm in Intrepid ? (just to know if it's worth starting to work on packging it)
<slangasek> stgraber: why is it needed?
<stgraber> slangasek: it's mainly bug fixes and clean up but also renames some stuff in the thin client chroot (local apss)
<slangasek> stgraber: sounds like it shouldn't be done for intrepid, no
<slangasek> because "bug fixes and cleanup" << "OMG there's this critical bug that's driving everyone crazy" :)
<stgraber> yeah, it's basically fixing some localapps support as we don't have the ability to play sound with localapps neither can we shutdown the computer (missing sudoers entry in the chroot)
<ogra> slangasek, ltsp is in pretty bad shape due to me being busy in mobile
<ogra> slangasek, stgraber is happy to take over but i wouldnt like to let him start wiht a ton of patches, letting a stable upstream in would be appreciated (its in lenny as well)
<stgraber> slangasek, ogra: Just had a look at ltsp-trunk. on 24 changes, 19 would affect what's in Ubuntu. 10 are fixing bugs (not all are filed in LP yet), 3 are adding back a pretty old regression (ltsp 4.2 it seems), 2 are cleaning up (bashims and comments), 2 are for renaming xrexec to localapps and 2 adds ltsp-cluster support (it's an option, not a default)
<ogra> all 19 sound valid to me
<stgraber> so if I were to add a patch system to keep the same upstream release, 10 out of 19 changes would have to go as patches (taking only bug fixes)
<stgraber> yeah and using them for 2 weeks or so in my test lab at work, I didn't see any regression
<ogra> i'd like ot get an opinion from Keybuk for the ltspfs changes though
<stgraber> yeah, I didn't count this one as it's in ltspfs and won't need a new upstream, only a minor change to debian/ as soon as we know what to change
<stgraber> (or if we don't, just to use my workaround so we at least have localdevs working for Intrepid)
<stgraber> slangasek: http://paste.ubuntu.com/54052/ that's for the ltsp source package, all changes from what we currently have to what I'd like to upload. Numbers are the revision of upstream's branch.
<stgraber> slangasek: for ldm, it's 7 revision, 5 affecting Ubuntu, 3 of them fixing bugs and 2 of them adding features whose default behavior is to be exactly the same as what we currently have in Ubuntu
<stgraber> http://paste.ubuntu.com/54054/ for details
<slangasek> stgraber: "adding back a pretty old regression" - I'm not sure whether I'm parsing that the way you meant it?
<stgraber> oh, where did I say that ? :)
<stgraber> it's adding back a feature that was there long ago
<stgraber> oh, found it, that was on IRC.
<stgraber> I have opened: bug 278399
<ubottu> Launchpad bug 278399 in ldm "[UVFe] ldm (2.0.12 -> 2.0.13)" [Undecided,New] https://launchpad.net/bugs/278399
<stgraber> with all kinds of diff you may want to look for it
<stgraber> and I'm working on the LTSP one now
<Phrozen_One> Has anyone thought of consolidating the setup screens by adding several settings in one window? Such as having a button to change the default settings for partitioning, keyboard, etc. in one window?
<ScottK> slangasek: If you have a moment, would you mind accepting subversion into hardy-backports?
<stgraber> slangasek: ok, I have done the packaging work on LTSP, that's a lot of revision but in the end very few real changes on Ubuntu (there is a lot of changes for gentoo-specific files).
<stgraber> slangasek: I'll test the packages tomorrow and open a bug similar to the one I opened for LDM
<stgraber> I also need to write a good changelog linking to all the bugs (and open some more)
<niccholaspage> E: Couldn't find package linux-ubuntu-modules-2.6.27-4-generic
<niccholaspage> Can someone help me with this? I am running Intrepid
<RAOF> niccholaspage: That would be because there _isn't_ a linux-ubuntu-modules package anymore.
<niccholaspage> RAOF:There is a thread that shows how to make a remix of Ubuntu. I need this package... Is there any other package that has the files?
<wgrant> niccholaspage: Which files?
<niccholaspage> linux-ubuntu-modules fil;es
<niccholaspage> *files
<wgrant> They're integrated into linux-image-*
<niccholaspage> Ah
<RAOF> The script that you're using is broken, or at least hasn't been updated to important Intrepid changes.  You'd be better served by either fixing the script or working out what to do yourself, I think.
<wgrant> I suspect so.
<slytherin> I need some help. I am trying to update alternate CD image (with corrupt Release file) using jigdo yo latest CD image. But the release file is not getting updated.
<james_w> pm-utils release announcement:
<james_w>       * Sleep modules are stackable and have finegrained method
<james_w>         detection. For instance, if you like s2disk but not s2ram, you
<james_w>         can remove the s2ram binary and pm-utils will automatically fall
<james_w>         back to using kernel methods for suspend/resume.
<james_w> might be worth investigating pulling that in. I'll look at it tomorrow
<slytherin> can anyone please help with jigdo problem.
<freshmeen> new
<RainCT> bona nit
<rom1v> hi
<rom1v> In ubuntu, "nvidia-settings -l" need to be executed before launching compiz. Do you know what is the right place to add this at boot time?
<rom1v> ?
<wtgee> Hello...where did the 'disable trackpad' go to in Ibex?
<NCommander> Can someone confirm nominations on this bug for me: https://bugs.edge.launchpad.net/ubuntu/+source/xfprint4/+bug/211335
<ubottu> Launchpad bug 211335 in xfprint4 "Mousepad -> xfprint4 Crashes" [Medium,Confirmed]
#ubuntu-devel 2009-09-28
<soreau> Hello.
<soreau> I am trying to detect whether or not a certain package is installed via bash script. Right now I have pkg --get-selections|grep <pkg-name>| grep -v "deinstall" which works to a certain extent but it also is true if packages with <pkg-name> is in another package name is installed. For instance if compiz is not installed and compiz-core is, it will still detect compiz is installed. How should I do this to get an exact match?
<soreau> In short, I want a reliable way to tell if package X is installed from a bash script
<TheMuso> soreau: dpkg -l could be what you are looking after.
<TheMuso> looking for even
<ion> dpkg --get-selections rather
<ion> That is better for a machine to parse.
<TheMuso> ion: right
<soreau> ion: If you see in my first post, that's what I am currently using and it almost works.. just matches any package containing the string
<soreau> TheMuso: As does grepping dpkg -l
<ion> dpkg --get-selections compiz
<soreau> huh
<soreau> ion: That may be exactly what I need
<soreau> ion: What are all the values that the 'other' field can be? purge, install, deinstall etc
<soreau> If I grep for 'install' it will also match deinstall for instance
<soreau> Is there anywhere I can see all the possible values for that column?
<ion> if dpkg --get-selections compiz 2>/dev/null | grep -qE '\<install$'; then ...
<soreau> ion: I'll bet that's exactly what I wanted. Thanks a lot!
<soreau> ion: Thanks for your help. Still trying to figure out what that grep magic does but whatever it is, it is working :)
<ion> \< stands for word boundary and $ stands for the end of a line.
<lifeless> lambda!
<ion> Î»
<lifeless> \ is haskell declares an anonymous function ;)
<ion> Indeed.
<ion> Unfortunately, one canât use Î» in its place even with Haskellâs Unicode support (the last time i checked).
<soreau> thanks again
<jdong> who can I thank for the policykit-ification of update-manager?
<ScottK> Depends on if you like it or not.
<pwnguin> who wouldn't like an upgrade button that asks for your password then looks at you confused
<ScottK> In that case, it was definitely not me.
 * cwillu_at_work pokes doko__ 
<cwillu_at_work> doko__, bug #418962 is apparently fixed in bash-4.1; is there any chance of getting a patch into karmic, or updating to that version?
<ubottu> Launchpad bug 418962 in bash "[karmic] [regression] menu-complete in bash no longer completes filenames." [Undecided,Confirmed] https://launchpad.net/bugs/418962
<Hellow> Well, I'm glad that got fixed.
<cwillu_at_work> s/got/may get/ :p
<Hellow> :P
<cwillu_at_work> looks like debian doesn't have 4.1 packaged yet
<cwillu_at_work> hell, 4.1 hasn't been released at all yet :(
<cwillu_at_work> hmm; 33 patches to 4.0 are on the maintainers site, none of which are obviously the fix to my eyes
<dholbach> good morning
<manitoba98> Excuse me; can anyone explain why it's necessary to send kernel log messages through dd, rather than letting klogd pick them up directly? Debian doesn't do it that way.
<manitoba98> Other than "it lets us run it as user klogd", which isn't a reason in and of itself.
<pitti> Good morning
<pitti> pochu: oh, great!
<dholbach> pitti: I uploaded didrocks' new gdl - it will need binary NEWing
<dholbach> didrocks: will you taking care of uploading the 4-5 rdepends?
<didrocks> hey pitti, hi dholbach
<dholbach> didrocks: uploaded sabayon too
<didrocks> dholbach: thanks. You want to handle the transition now and not dep on the old (with previous soname) bin library?
<didrocks> I can do it, if you think it worthes before beta :)
<dholbach> didrocks: it's sitting in the queue now - I'll defer that to the release team / archive admins
<dholbach> I think it'd be a quick job and build times shouldn't be long either
<dholbach> didrocks: just let me know what they think and I can help out if necessary
<didrocks> dholbach: no pb, I'll ping them later today and handle it :)
<pitti> hey dholbach; ok, thanks
<dholbach> super
<didrocks> pitti: so, what do you think about handling those rebuilds before beta?
<pitti> dholbach: should be fine, better for testing
<pitti> pochu: uploaded
<didrocks> dholbach: ok, I put that on my schedule, so :)
<pitti> dholbach, didrocks: please upload them ASAP with proper versioned build-depends, then we can already accept them and let the buildds figure it out
<manitoba98> Excuse me; can anyone explain why it's necessary to send kernel log messages through dd, rather than letting klogd pick them up directly? Debian doesn't do it that way.
<dholbach> didrocks: can you just put the debdiffs somewhere and I have a look at them?
<dholbach> manitoba98: maybe the people who can answer the question are not around yet... why don
<dholbach> 't you mail ubuntu-devel@lists.u.c?
<manitoba98> OK, thanks.
<didrocks> dholbach: ok. I'm working on that this evening as soon as I get back home
<pitti> didrocks, dholbach: gdl NEWed
<dholbach> pitti: I'll take the dog for a walk and take care of the rdepends afterwards
 * pitti hugs dholbach
<didrocks> pitti: Thanks :)
<pitti> ArneGoetje: argh
<pitti> ArneGoetje: may it be that you forgot to remove the langpacks before the rebuild? The delta langpacks are very big
<pitti> they should be empty..
<pitti> well, a bit too late now, so we just have to cope and kick out some of them
<ArneGoetje> pitti: no. LP 'forgot' my full-request... :(
<pitti> ah, too bad
<pitti> ArneGoetje: did that happen before?
<pitti> we have to get it right for the final
<ArneGoetje> pitti: I have done a merge with the last full-export and int import in lp-o-matic is currently running... do you still want to have it?
<ArneGoetje> pitti: first time it happened... maybe LP had some hickup
<pitti> ArneGoetje: there were some LP rollouts on Friday and apparently over the weekend, too
<pitti> perhaps it forgot that state when it was restarted
<ArneGoetje> pitti: that might be an explanation
<pitti> ArneGoetje: it gets too late, I'm afraid; we need to have CDs tomorrow around European noon
<ArneGoetje> pitti: hum... ok
<ArneGoetje> pitti: the next export will be a full one again... (if LP doesn't forget it again), so users will need to upgrade
<happyaron> mvo: ping
<mvo> hey happyaron
<happyaron> mvo: I have some question on software-center's pot
<mvo> happyaron: sure
<pitti> ArneGoetje: we don't really need a full export after beta, but I guess we should still do it to test that it still works
<ArneGoetje> pitti: yep
<pitti> hey mvo
<happyaron> mvo: there is a po/software-store.pot, po/po/software-store.pot in your 0.4 version tarball
<happyaron> mvo: and now you've uploaded a po/software-center.pot, which template should be in launchpad, and how to name it?
<mvo> happyaron: software-center should be the one, let me fix that in my source. sorry for the confusion
<happyaron> mvo: only po/software-center.pot should be imported, is that right? I have renamed the original template in lp to software-center, and is that po/po/software-store.pot not needed?
<mvo> happyaron: correct
<happyaron> ok
<mvo> happyaron: the old name should go away everywhere
<happyaron> only one template should be fine
<krabador> NetworkManager Applet 0.7.996 is a massacre
<krabador> all right with dhcp, but totally don't works form manual settings
<cjwatson> krabador: please file bugs in Launchpad rather than on IRC; it'll usually get a better result that way
<ArneGoetje> pitti: I could selectively upload a few language-packs it that helps... which languages are we going to ship on the CD?
<pitti> ArneGoetje: that would help indeed
<pitti> ArneGoetje: en es xh pt de fr bn
<ArneGoetje> pitti: which languages do you want?
<ArneGoetje> pitti: ok
<pitti> ArneGoetje: that won't help the DVD, but at least we can have good CDs
<pitti> ArneGoetje: thanks!
<ion> What, not fi? Iâm appalled.
 * pitti hugs ion
<ion> :-)
<didrocks> pitti, dholbach: all libgdl universe rdeps are uploaded. Do you want that I give a hand on main ones?
<pitti> didrocks: that would be nice, if you have some time to test them?
<pitti> I hope most will "just build"?
<didrocks> pitti: universe ones have built like a charm :) I do some minimal test (at work, it's more difficult, spawing a slow VM on my windows machine :/)
<dholbach> uploaded
<dholbach> gnome-python-extras
<dholbach> and committed to the brancht oo
<dholbach> too
<dholbach> should be all set now
<didrocks> great :)
<pitti> mbiebl: any particular reason why you made libpolkit-gtk-1-dev arch: any? (it's arch: all in Ubuntu)
<\sh> moins
<tgpraveen> any chance we will get theora 1.1 in karmic?
<seb128> tgpraveen, any chance you will stop asking every day if we will get new major version of software or features weeks after feature freeze now? ;-)
<tgpraveen> seb128: i just wanted a yes/no answer :)
<seb128> tgpraveen, which is try for my question too ;-)
<seb128> tgpraveen, dunno, we didn't consider it it's way after feature freeze, if you have excellent recent open a bug asking for an exception
<seb128> recent -> reason
<asd123123> http://17fc5c36.linkbucks.com
<pitti> tseliot: does nvidia 96 actually work on karmic?
<tseliot> pitti: yes, it should. Why?
<pitti> tseliot: ok, thanks
<pitti> just cleaning the DVD seeds, and they had some nonexisting versions any more
<tseliot> pitti: aah, ok
 * directhex has downgraded his nvidia - 185 is crashy crashy crashy
<dholbach> is there a bug open for "gdm only comes up after pressing alt-f7"?
<pitti> dholbach: I don't see one
<dholbach> ok
<dholbach> I just have this on one machine
<dholbach> booting will only show me a black screen until I press alt-f7
<cjwatson> it happens on the live CD for me
<seb128> dholbach, there is one
<seb128> dholbach, bug #434361
<ubottu> Launchpad bug 434361 in gdm "gdm sometimes fails to start after new upstart merge" [Medium,Incomplete] https://launchpad.net/bugs/434361
<dholbach> thanks seb128
<seb128> it doesn't seem a gdm bug
<pitti> seb128: I retitled the bug, so that it's a bit easier to find
<dholbach> hum - I don't need to log in and restart gdm for gdm to work
<cjwatson> seb128: certainly in my case, gdm starts fine, it just doesn't switch vt
<dholbach> ah ok, comment 7 says the same on amd64
<seb128> dholbach, right, read comments on the bugs, just people got confused before finding that ctrl-atl-f7 was working
<cjwatson> ah
<seb128> cjwatson, well some people have the issue with kdm too
<seb128> and workaround are weird there
<seb128> ie booting with splash workaround the bug
<seb128> or reinstalling linux for some users
<seb128> if somebody has a clue how to debug that help is welcome there
<seb128> it's probably a beta blocker too
<cjwatson> yeah
<cjwatson> I wonder if the usplash init script needs to be migrated
<cjwatson> we used to shut down usplash before starting gdm; now we don't
<cjwatson> that seems very likely to be the cause
<seb128> "without splash" before
<seb128> but right, that makes sense
<joaopinto> mvo, sorry for the duplicate bug repos on software-center I didn't noticed they were reported on the previous project name :\
<joaopinto> reports
<mvo> joaopinto: no problem, thanks for reporting the stuff, the rename caused some confusion unfortuatnely
<cjwatson> hmm, this is slightly tricky, I *really* don't want to reproduce the busy-wait in the usplash init script in upstart-wordl
<cjwatson> world
<pitti> does upstart send a signal after a process has terminated?
<cjwatson> well, even that wouldn't be sufficient, since the init script waits for a while and kills it if it doesn't die by itself
<cjwatson> really, I think we want to have upstart take over supervision of the running usplash process when it starts, and pretend that it's a job, so that we can use the 'kill timeout' stuff
<dholbach> seb128: do you know why bug 424311 is set to "low"? :)
<ubottu> Launchpad bug 424311 in gnome-screensaver "gnome-screensaver does not put display to sleep" [Low,New] https://launchpad.net/bugs/424311
<seb128> dholbach, why not?
<dholbach> I find it a bit annoying that the screen does not go to black
<dholbach> it just flickers every few minutes
<seb128> dholbach, because it has not been confirmed and happens to one user only
<dholbach> ok
 * dholbach can confirm
<Laney> and me
<dholbach> Laney: can you add your details to the bug too?
<seb128> dholbach, did it start recently?
<dholbach> seb128: no, a week I'd say
<seb128> dholbach, it's probably not the same bug then
<Laney> done
<seb128> dholbach, yours probably started with the 2.28 update
<dholbach> seb128: you think?
<seb128> well that one has been opened 3 weeks ago
<dholbach> maybe a bit longer already - I really dunno
<seb128> well, you are the third one to mention screensaver today
<seb128> I really think it's new since 2.28
<seb128> I would prefer a new bug if that's the case rather than abusing an old bug about something different
<Laney> no I had it before then
<seb128> ok, cool, let's see if somebody is interested to work on that
<seb128> we don't have anybody working on screensavers that I know
<seb128> but maybe somebody will be annoyed enough to look at it ;-)
<seb128> I put it on my list but I've like one hundred bugs already on my karmic list so low chance I look at that
<Laney> can you view the sleep/wake events?
<seb128> Laney, gnome-screensaver --no-daemon --debug
<Laney> cool
<Laney> i'll do it when i get home
<seb128> but the power management tab is a gnome-power-manager thing
<seb128> not a gnome-screensaver one
<Laney> yeah
<TomaszD> hey asac, would you care to upload a translation update for ubufox? https://bugs.launchpad.net/ubuntu/+source/ubufox/+bug/437604
<ubottu> Launchpad bug 437604 in ubufox "[pl-PL] Polish translation update for ubufox [attached]" [Undecided,New]
<asac> assigned myself now. thx. TomaszD
<TomaszD> asac, cool, thanks!
<asac> TomaszD: if you request a merge into lp:ubufox it would be even quicker ;)
<asac> but not needed
<TomaszD> asac, I know, but I don't have time to learn another DVCS just to upload a few files :P
<asac> ll
<asac> kk
<cjwatson> seb128,pitti: FYI I'm experimenting with http://paste.ubuntu.com/280312/ - feel free to comment while I break my system with it :)
<pitti> cjwatson: "start on stopped gdm" sounds a bit overzealous; shouldn't this rather mean "start on (rc0 or rc6)" or so?
<pitti> nice, this looks so much cleaner than the current init script with its looping
<amitk_> is it a bad time to upgrade (dist-upgrade fails with lots of python errors)
<AnAnt> can someone review LP 438092 ?
<ubottu> Launchpad bug 438092 in texlive-bin "Candidate revision texlive-bin_2007.dfsg.2-7ubuntu1" [Undecided,Confirmed] https://launchpad.net/bugs/438092
<sistpoty|work> james_w: bug #404003: source package is actually opencore-amr, sorry for the inconvenience
<ubottu> Launchpad bug 404003 in ubuntu "please sync libopencore-amr for karmic from unstable" [Wishlist,Confirmed] https://launchpad.net/bugs/404003
<AnAnt> I dropped this Ubuntu change: build with g++ -fno-tree-ter on armel, since debian now uses g++-4.4
<james_w> thanks
<AnAnt> james_w: btw, I've done devscripts merge
<james_w> thanks AnAnt
<AnAnt> james_w: LP 414298
<ubottu> Launchpad bug 414298 in devscripts "Please merge devscripts_2.10.53 from Debian unstable" [Undecided,Confirmed] https://launchpad.net/bugs/414298
<AnAnt> james_w: that's actually devscripts_2.10.55
<cjwatson> pitti: I believe it has to start after gdm, or the chvt ordering goes wrong
<cjwatson> pitti: at least it certainly used to fail if you tried to start usplash_down before gdm
<cjwatson> it does mean that it won't run if you don't have a *dm, I concede
<kalla> some audio sync problem with videoplayer in ubuntu... :(
<Laney> http://launchpadlibrarian.net/32596463/buildlog_ubuntu-karmic-armel.sound-juicer_2.28.0-1_FAILEDTOBUILD.txt.gz - check out the UCF installation. Does that look transient?
<pitti> re
<pitti> cjwatson: ah, perhaps it'd need to be (stop gdm && (rc0 || rc6))?
<cjwatson> pitti: mm, maybe
 * cjwatson is wrestling with getting the initramfs->upstart import stuff Keybuk hacked in to work properly
<pitti> ogra, lool: so bug 417009 is believed to be fixed now, right? You just keep it open until it's verified, or does it need more work?
<ubottu> Launchpad bug 417009 in openoffice "all openoffice apps die in 'com::sun::star::ucb::InteractiveAugmentedIOException' on armel in karmic" [Unknown,Confirmed] https://launchpad.net/bugs/417009
<amitk_> mvo, doko: do you deal with python/apt? I have a failed dist-upgrade and here is the result of trying to fix it. http://pastebin.ubuntu.com/280364/
<mvo> amitk_: hm, that smeels like disk corruption "EOFError: EOF read where object expected
<mvo> "
<lool> pitti: Not sure why it isn't closed; I know we're actualy hiding an issue in some binaries instead of fixing it
<lool> doko: Did you intend to keep it open?
<amitk_> mvo: should I force reinstall some packages?
<asac> ogasawara: plz check the patch in 334413 ... thx
<ogasawara> asac: will do
<mvo> amitk_: try reinstalling python2.6
<doko> lool: yes, we have a work around, not a fix. just take it off the release radar once the build is in the archive
<lool> doko: Ok thanks
<lool> pitti: ^
<amitk_> mvo: 'sudo dpkg-reconfigure python2.6' seems to have done the trick
<AnAnt> can someone look at LP 416949
<ubottu> Launchpad bug 416949 in console-setup "Keyboard layout toggle does not work anymore in karmic" [Undecided,New] https://launchpad.net/bugs/416949
<doko> amitk: bad files, zero lenght?
<mvo> amitk_: hm, that is a bit scary
<amitk_> doko: no, I checked that the files existed
<amitk_> liw: moi! does Computer Janitor track how often a package is used? I am wondering why it is trying to remove deboostrap, kvm, qemu, etc.
<cjwatson> oh usplash, why do you mock me
<directhex> you were naughty in a previous life?
<zul> archive-admins: i think linux-ec2 is sitting in binary-new can we get that in the archive? please k thx bye
<pitti> zul: nothing like *ec2* in the NEW queue
<zul> pitti: hmm..
<pitti> zul: see https://edge.launchpad.net/ubuntu/+source/linux-ec2/2.6.31-300.3, nothing NEW there
<zul> pitti: but it said it built?
<pitti> right
<fbond> mvo: Have a second to discuss possible bugs in python-apt?
<fbond> Just want to confirm that the bugs exist as I see them before filing a report.
<liw> amitk, computer janitor does not track how much packages are used; if you click on the package in the UI what does it tell you as the reason for the removal?
<fbond> mvo: Nevermind, just confused by the various semi-dict-like interfaces.
<mdz> ttx, good afternoon, how is the test going?
<ttx> mdz: there is an issue with eucalyptus-cc upstartification. httpd child processes are crashing. That prevent sthe node from being correctly polled
<ttx> (I'm testing your branch)
<ttx> I'm slowly closing in on the issue, but axis2c is not easy to debug
<mdz> ttx, the command line and config file used to start apache2 are identical.  I did drop the LD_LIBRARY_PATH change because it seemed superfluous, but we can put it back in if needed. did you test if that is the problem?
<mdz> (command line -> except for "-D foreground")
<ttx> mdz: I just managed to get a /etc/init/eucalyptus-cc.conf that doesn't crash. Now I need to find what in the combo of things I added fixed it.
<mdz> ttx, send me the diff?
<mdz> pitti, zul, I believe slangasek took care of it already:
<mdz>  linux-ec2 | 2.6.31.300.0 | http://archive.ubuntu.com karmic/main Packages
<mdz> pitti, zul was talking about the linux-ec2 binary package from linux-meta
<zul> mdz: thanks
<pitti> mdz: ah; well, I didn't see that in NEW either;
<pitti> if it's done now, fine
<mdz> pitti, zul, I can confirm that it's installed in the images at http://uec-images.ubuntu.com/karmic/current/ubuntu-uec-karmic-i386.manifest
<ttx> mdz: http://pastebin.ubuntu.com/280428/
<ttx> mdz: I'll reduce the patch to see what actually fixed the problem
<ttx> mdz: http://pastebin.ubuntu.com/280430/ is better
<mdz> ttx, /etc/eucalyptus/axis2/lib is a symlink to /usr/lib/axis2/lib
<giskard> dude how you write stats (cpu , load) in the motd (before call pam_lastlog i mean)
<mdz> ttx, it still segfaults when I use your LD_LIBRARY_PATH change
<giskard> btw, hi all
<ttx> mdz: yes, EUCALYPTUS=/ and LD_LIBRARY_PATH do not help...
<mdz> ttx, have you debugged the segfault?
<ttx> mdz: no
<mdz> I have a stack trace
<ttx> ah
<ttx> env AXIS2C_HOME=/etc/eucalyptus/axis2
<mdz> ttx, http://people.canonical.com/~mdz/temp/eucalyptus-cc-apache2-crash.png
<ttx> seems to be the critical one. Let me doublecheck that.
<AnAnt> fabrice_sp__: thanks
<fabrice_sp__> AnAnt, for?
<AnAnt> fabrice_sp: the tablelist bug
<AnAnt> bugs
<mdz> it's doing this:
<mdz>   service = adb_getKeysType_get_serviceTag(request, env);
<mdz>   
<mdz>   response = adb_getKeysResponseType_create(env);
<mdz>   status = AXIS2_TRUE;
<mdz>   rc = doGetKeys(service, &outCCCert, &outNCCert);
<mdz> and crashing in DoGetKeys
<fabrice_sp> AnAnt, ahhh, you're aelmahmoudy. You're welcome :-)
<mdz> ttx, I still get the segfaults after setting AXIS2C_HOME
<ttx> grmbl
<AnAnt> fabrice_sp: yup
<ttx> mdz: there is a combination of factors, probably two bugs.
<TomaszD> mvo, hi, have you perhaps noticed that there is something wrong again with update-manager's template? Even the one waiting in the queue is not up-to-date, and the strings that have not been changed are now displayed in English
<TomaszD> mvo, could you take a look at this issue?
<cjwatson> pitti: I think this usplash upstartification is now working - I just needed to crank the initial timeout up a little bit
<cjwatson> pitti: since native upstart jobs don't talk to usplash (at the moment?), so the timeout has a habit of expiring
<ttx> oooooh
<pitti> you rock!
<mvo> TomaszD: I have a look
<mvo> TomaszD: is ths about bug #438077 ?
<ubottu> Launchpad bug 438077 in update-manager "update-manager's translation template is very likely not up to date again" [Undecided,New] https://launchpad.net/bugs/438077
<cjwatson> hmm, it's not quite stopping properly if gdm isn't in use though
<TomaszD> mvo, indeed it is
<TomaszD> mvo, I'm especially worried about the policykit dialog window, where there's a new string about the system policy preventing updates or something close to that
<ttx> mdz: can you crash it with the full patch ?
<mdz> ttx, segfault is at:     home = strdup(getenv("EUCALYPTUS"));
<mvo> TomaszD: that is comes from aptdaemon
<ttx> mdz: yes... but if you set that alone, the polling to the node doesn't really occur.
 * ttx rechecks
<TomaszD> mvo, ok, but the rest is still worrying
<cjwatson> pitti: actually - I wonder if the right answer would be for the gdm job to emit a stop-splash event
<cjwatson> or even a dm-starting event
<mvo> TomaszD: it is, I targeted it
<mdz> ttx, adding export EUCALYPTUS=/ to the upstart job doesn't seem to get it into the apache2 enivronment for some reason
<mdz> or env
<cjwatson> pitti: that would save having to keep track of whether gdm actually gets started (e.g. 'text' on command line)
<TomaszD> mvo, thanks
<ttx> mdz: you need AXIS2C_HOME
<ttx> with env EUCLYPTUS and AXIS2C_HOME set it works
<cjwatson> mdz: the init(5) manual page documents env KEY=VALUE and export KEY, but not export KEY=VALUE
<ttx> all the other changes in the patch are superfluous.
<mdz> cjwatson, env KEY=VALUE is what I'm using
<ttx> mdz: http://pastebin.ubuntu.com/280457/ works for me
<mdz> it works for HTTPD_CONF=/var/run/eucalyptus/httpd-cc.conf
<mdz> but not for EUCALYPTUS=/
<apachelogger> asac: ping
<mdz> ttx, if you look at /proc/xxx/environ do you see EUCALYPTUS=/ there?
<ttx> mdz: yes
<mdz> ttx, I can't get that to work for some reason
<mdz> ttx, ararrggghh
<mdz> using "restart" doesn't seem to process the new env stanzas
<mdz> but 'stop' and 'start' did
<mdz> keeeeyyyybbuuuuuuukkk....
<ttx> mdz: uh :)
 * dholbach hugs mdz
<ttx> there were two bugs, the segfault was masking the other.
 * ttx has been banging his head against that one for a few hours :)
<cjwatson> hmm, now I have usplash stuck on
<cjwatson> whoopsie
<highvoltage> heh, so now you have to press alt+F1 AND alt+7?
<mdz> ttx, gdb made quick work of the segfault, it was clear that it was missing $EUCALYPTUS
<mdz> if my changes to the upstart job had actually worked, the second one would have been quick too ;-)
<mdz> ttx, is the cc registration working?
<ttx> mdz: yes.
<cjwatson> highvoltage: no, it's just hosed. undoubtedly my fault
<ttx> mdz: I tested from a daily + upgrade though, which is a slightly different test path
<mdz> ttx, it doesn't seem to re-run the registration when I restart the cc, though I thought it would
<mdz> ttx, I've pushed a new auto-registration branch
<mdz> with the env fixes
<mdz> ttx, are we ready to merge it into ubuntu and upload?
<ttx> mdz: I think so. I was planning to rebuild and test, but the sooner it lands on the daily, the better
<asac> apachelogger: ?
<apachelogger> asac: any news on trademark in kubuntu-firefox-installer? also, I really really think that making the firefox packages conflict and replace kubuntu-firefox-installer is the best option at hand :)
<apachelogger> asac: btw, is firefox-gnome-support a recommends?
<mdz> ttx, yes, dialing
<ogra> could $archive_admin_of_the_day get linux-fsl-imx51 and linux-mvl-dove out of NEW for me ?
<mdz> ttx, uploaded
<mdz> cjwatson, can you review and approve?
<ogra> james_w, ^^^ ?
<mdz> and spin new server ISOs?
<asac> apachelogger: can you get me a mail with screenshots etc. ... would be easier for me to check with mozilla if i had something like that.
<ttx> mdz: I'll spend some cycles this evening validating that iso
<apachelogger> asac: sure
<mdz> ttx, what about the public IPs issue?
<james_w> ogra: already in the middle of the queue
<ogra> merci :)
<mok0> Any hints on how to easiest solve the getline() problem with karmic's libc=
<mok0> ?
<cjwatson> mok0: rename the local function
<mok0> cjwatson: I've been doing that but in this particular instance I don't want to
<mok0> cjwatson: not if I can avoid it.
<mok0> cjwatson: The error comes from a 4-line change in stdio.h
<cjwatson> that's correct, but it was an addition to POSIX
<mok0> cjwatson: the addition is to include getline as a std. function?
<ttx> mdz: did you commit the -0ubuntu9 changes to lp:~ubuntu-core-dev/eucalyptus/ubuntu ?
<ttx> mdz: about the public IP issue, maybe we can discuss it on the call.
<mok0> cjwatson: earlier you had to define __GNU to get it
<mok0> cjwatson: now it's controlled by __USE_XOPEN2K8 which is apparently defined somewhere.
<cjwatson> it used to be a glibc extension, but POSIX incorporated it
<cjwatson> I'm sure you can use feature test macros to declare that you want an older version of POSIX
<cjwatson> info libc, search for feature test
<mok0> cjwatson: I'll look into it, thanks
<cjwatson> that sort of declaration might be a stopgap; I wouldn't recommend it long-term
<mok0> cjwatson: Well, we have an FTBFS list a mile long, ultimately upstream should fix it
<sistpoty|work> mok0: if it uses autotools, you could also add a configure check for it
<cjwatson> sistpoty|work: shouldn't need that ...
<mok0> sistpoty|work: it's not a missing function, it's a dual declaration
<mdz> ttx, yes I did
<sistpoty|work> mok0: yep, in the sense of #ifndef HAVE_GETLINE local definition #endif, and let HAVE_GETLINE set by autotools, but you could also just remove the local definition though ;)
<mok0> sistpoty|work: AFAICT it's not a standard getline()
<sistpoty|work> mok0: then you'll need to rename it, like cjwatson first wrote
<mok0> sistpoty|work: I have to edit a dozen files then
<mok0> sistpoty|work: which is why I'd rather unset __USE_XOPEN2K8
<ttx> mdz: ok, got it. launchpad is late.
<cjwatson> do not touch that macro directly
<cjwatson> it is internal
<cjwatson> there are public macros available for your use
<mok0> cjwatson: I am looking at features.h to find it
<cjwatson> specifically, I should think, #define _POSIX_C_SOURCE 200112L
<mok0> cjwatson: that doesn't sound like a public macro either
<cjwatson> well, it is.
<cjwatson> it's in info libc.
<mok0> cjwatson: ah, thanks.
<lolufail> hi
<lolufail> I'm experiencing kernel oops in with my fresh raid5->dmcrylt->lvm2->ext4 configuration
<lolufail> I cannot mkfs.ext4
<lolufail> http://pastebin.com/m56628b69
<lolufail> should I file a bugreport?
<sistpoty|work> mok0: or you could use seddery: for i in *c; do sed -e 's/getline(/getline_local(/' $i | sponge $i; done
<mok0> sistpoty|work: I could, yeah
<sistpoty|work> (and review the debdiff, that only good things matched)
<mok0> sistpoty|work: or an appropriate #define getline anothergetline
<nh2> does it make any difference if I autoreconf before PPA upload?
<mok0> Gotta go see you later
<slangasek> ttx: question regarding the instructions in http://testcases.qa.ubuntu.com/Install/ServerEConfig
<slangasek> ttx: will euca-bundle-image do the right thing if you pass it /boot/vmlinuz instead of /boot/vmlinuz-2.6.31-11-generic?  (I.e., will it follow symlinks?)
<slangasek> davmor2: ^^
<ttx> slangasek: no clue. I'd need to try
<slangasek> ttx: low priority, but if it doesn't work I think we need to fix it so it does; otherwise we have to embed kernel ABI versions in our test case
<ttx> would work with /boot/vmlinuz-$(uname -r) though
<slangasek> true
<slangasek> davmor2: can you switch the testcase to use the above rune?
<davmor2> slangasek: np's
<ttx> slangasek: in the end we would rather test the UEC kernel and ramdisk provided with the images
<ttx> slangasek: see http://uec-images.ubuntu.com/karmic/current/
<ttx> though I'd like to retest those on my now-working UEC
 * ttx disappears again
<slangasek> ttx: oh?  so we're now publishing kernels / initrds alongside the images?
<slangasek> that's a rather late change to the release publishing
<ttx> slangasek: bug 429106, see smoser
<ubottu> Launchpad bug 429106 in vm-builder "kernel and initramfs should be available for uec" [Medium,Fix committed] https://launchpad.net/bugs/429106
<slangasek> ok
<ttx> slangasek: this can be reverted easily.
<ttx> :)
<slangasek> well, one of the consequences of distributing kernels in this fashion is that they aren't accompanied by source code... or even a clear indicator of what version of the source they are
<slangasek> (s/clear/unambiguous/; obviously the ABI version narrows it down, but it's not unique)
<slangasek> smoser: see above; I don't think we should be publishing kernels / initramfs in this fashion, this has GPL compliance implications
<smoser> slangasek, i'm not 100% bent on publishing kernels in that fashion
<smoser> i have 2 thoughts though:
<smoser> 1. we're essentially doing this with ec2 kernels on ec2 (we make them available to run, but similarly to above, there is no absolute link of source -> binary)
<smoser> 2. if a user of UEC wants to create a kernel/initrd/guest image and they're running on their local system anything other than the release for which they want to create the guest, they're kind of SOL
<smoser> we need to provide them with a kernel and initrd that they can easily pair with a.) our uec images b.) ones they make themselves
<slangasek> smoser: 1) is also a bug we need to solve, then; it just wasn't as obvious to me in that case as it is when I'm being pointed at the uec-images directory listing :)
<slangasek> smoser: 2) I guess that's fair - we should still get the GPL reqs addressed before we start publishing in this fashion, though
<smoser> i agree that that directory listing is far from perfect . and in that bug, i mentioned that..
<mvo> TomaszD: I think the u-m problem is fixed, it turns out something is meddling with gettext
<smoser> slangasek, i really would like your insight on how to make that directory output easily usable and "correct" in other ways also.
<smoser> the other thing that has come to my mind is the deletion of non-current kernel images (as i belive is done in the archives). that should then apply here too i think
<TomaszD> mvo, great :)
<slangasek> smoser: generally, by integrating anything you need into the scripts from the 'cdimage' branch that I copied to nectarine, and reusing those
<smoser> slangasek, i guess i dont follow that. but i'll look more into it.
 * hyperair wonders if anyone's looking at sreadahead
<slangasek> smoser: cf. http://cdimage.ubuntu.com/daily/current/, which always includes an autogenerated header... we should be reusing the existing toolset for UEC publishing
<slangasek> smoser: e.g., fixing the daily builds to call the checksum-directory tool as I had pointed out
<davmor2> slangasek: what do you want me to do then leave the docs for now and wait till after beta to alter them?  So we at least have a working testcase for beta?
<slangasek> davmor2: no, change them to use the $(uname -r) rune
<cjwatson> hyperair: an upload went in last night to speed it up a lot
<cjwatson> hyperair: if that's not what you mean, be more specific ...
<smoser> slangasek, i can/will get the directory checksumming in.  i was asking more about the naming of files and such.  I'd like to name the kernels such that they can easily be referred to with, as you suggested, a static identifier (ie, like /vmlinuz). so that any scripts based on directory output wouldn't have to fish around for versions
<davmor2> slangasek: how's that now?  http://testcases.qa.ubuntu.com/Install/ServerEConfig
<slangasek> smoser: server-side scripts, or some sort of user-side scripts?
<slangasek> smoser: for server-side, I don't think it should be much of a problem, since we *have* to publish information about what source package this came from
<smoser> slangasek, i was meaning client side.
<slangasek> davmor2: looks good to me, thanks
<smoser> ie, when you document "heres how to install our UEC image on your cloud"
<davmor2> np's
<smoser> best if you don't have to say: download http://uec-images.u.c/releases/<release>/fish-for-kernel-name.img.gz
<smoser> or what nt
<smoser> not
<slangasek> smoser: ok.  can be done; shouldn't be done until we first have the GPL issue addressed prominently
<smoser> but rather http://uec-images.u.c/releases/i386/kernel.gz
<smoser> slangasek, ok. so what do i need to do on the gpl issue.
<slangasek> well, I would prefer ubuntu-uec-karmic-i386-vmlinuz-generic-pae
<smoser> slangasek, thats fine
<smoser> but a static name. rather than with a version in it
<slangasek> smoser: we need a header that gives the user a link to the corresponding source code
<smoser> but ew dont want to lose the source of that, and ideally would like to make the version info available
<slangasek> that can be included in the header
<hyperair> cjwatson: hmm that's what i meant. (it was no-op-ing)
<hyperair> but i still don't see a pack file anywhere =\
<hyperair> i guess i'll have to reboot twice to see
<slangasek> we can't just point at the archive, because the matching kernel version isn't guaranteed to be there - so we'll want to link to the launchpad UI, specifying an exact version number
<slangasek> smoser: and the kernel / initrd are being extracted from vm-builder, right?  So the information in the manifest is guaranteed to always be correct?
<smoser> slangasek, right. they pull from vmbuilder image
<slangasek> ok
<slangasek> in that case, perhaps we don't have any more GPL problem here than for anything else in the image, it just wasn't obvious that this is the case
<slangasek> (on EC2, OTOH, we may still have a GPL issue)
<mdz> slangasek, can you notify me, kirkland, ttx and mathiaz when there is a server build with eucalyptus -0ubuntu9 available?
<mdz> kirkland, and will you take responsibility for notifying eucalyptus and giving them a download URL?
<emgent> k
<davmor2> mdz: most of the testcase is written now I'm just finishing off a couple of bit then I'm going to do a fresh install follow the testcase to make sue I didn't miss any steps but if there is going to be a respin I might wait till after that in case anything changes.
<mdz> davmor2, the main change in the next build is that the registration happens automatically, so that it actually works when it comes up
<mdz> davmor2, there will be at least one more respin after that, where there will be one additional question asked during installation
<davmor2> mdz: I'll wait then and make the mods once everything is in place.
<mdz> davmor2, it's definitely worth trying with the next build (with eucalyptus -0ubuntu9)
<davmor2> mdz: I've taken the steps to split out the current post install config to minimise damage to the cluster and node install pages so there are 3 pages currently.  So the changes shouldn't cause too much interruption.  I did actually mean I would wait for the updated version before I removed and text, I just didn't say it very well :)
<davmor2> s/and/any text
<slangasek> mdz: ack
<pitti> james_w: still here by chance?
<pitti> james_w: just going through couchdb update with kenvandine
<james_w> I am
<pitti> james_w: I'm curious why you recommended using Breaks: for a package split with moving files, instead of hte standard Conflicts:?
<mdz> davmor2, if you send me a link, I can give you a heads up as to the expected changes
<james_w> pitti: that was Colin's advice
<davmor2> mdz: http://testcases.qa.ubuntu.com/Install/ServerEConfig
<pitti> james_w: because it's confiles?
<pitti> conffiles
<pitti> since for non-conffiles, breaks: isn't strong enough
<james_w> I'm not sure
<davmor2> mdz: I'm assuming steps 1-7 can be dropped
<slangasek> pitti: because the Conflicts: part of Conflicts/Replaces was never strictly necessary when one package takes over files from another
<mdz> davmor2, exactly
<pitti> slangasek: so using Breaks:/Replaces: sometimes makes apt's job easier?
<slangasek> yep
<pitti> ah, ok; thank you
<mdz> davmor2, I think the euca-bundle-image call should use the kernel from the downloaded image, not the kernel from the local system (in /boot)
<mdz> davmor2, http://uec-images.ubuntu.com/karmic/current/ provides the kernel and ramdisk which should be used
<slangasek> pitti: in fact, Conflicts+Replaces has a special meaning that people usually forget about:  it means "this package should be preferred as a replacement for the other package on upgrade"
<slangasek> mdz: though not under names that are going to stay as they are currently
<davmor2> mdz: slangasek thought that would be a cleaner way around kernel updates.  I just bowed to the greater knowledge
<cjwatson> once upon a time, people used to use Conflicts in addition to Replaces because Replaces didn't work when the packages were installed the wrong way round
<cjwatson> that was fixed ages ago, but old habits die hard
<slangasek> davmor2: no, I only said we shouldn't have hard-coded version numbers in the test case; mdz is talking about grabbing the kernel from somewhere else entirely
<cjwatson> but if there really is a reason to avoid installing the old package simultaneously, then Breaks is independently a reasonable thing to do; it isn't really Breaks+Replaces
<mdz> slangasek, davmor2, those two kernels are not the same
<mdz> the one installed on the cluster controller is a -server kernel
<mdz> the downloadable one should be the -virtual kernel
<mdz> smoser, confirm?
<cjwatson> the -virtual vmlinuz is the same as the -server one, no?
<smoser> -virtual vmlinuz is subset of modules of -server
<cjwatson> last I looked, -virtual was constructed by stripping down -server at the file level
<slangasek> mdz: well, previously the instructions said 'generic', and the kernel available for download on uec-images is -generic-pae
<davmor2> mdz: on my cluster install it reads 2.6.31-11-generic
<smoser> for i386, the -virtual is subset of -generic-pae
<smoser> for x86_64, subset of -server
<cjwatson> huh, interesting
<slangasek> ah
<mdz> cjwatson, it is
<mdz> more or less
<mdz> the point being that we want to install a lighter kernel on virtual machines
<slangasek> it's not lighter
<slangasek> the vmlinuz is supposed to be the same
<mdz> slangasek, lighter as in fewer modules
<slangasek> ah - the initrd will be lighter, sure
<mdz> and a smaller disk footprint
<mdz> which matters when it will be used as the basis for hundreds of variations
<davmor2> mdz: so should the lines relating to kernels/initrd's be specific to the download then?
<smoser> lines related to ?...
<smoser> one thing you *could* do is something like what pygrub does (or at least what i thought it does). mount the image, poke around for kernels
<davmor2> smoser: http://testcases.qa.ubuntu.com/Install/ServerEConfig
<smoser> ah
<smoser> i think we want to have the test download the correct paired kernel.
<jdstrand> kees, mdeslaur: can you look at a potential fix for bug #437854: http://paste.ubuntu.com/280574/
<ubottu> Launchpad bug 437854 in libvirt "apparmor profile denies access to alsa" [Medium,In progress] https://launchpad.net/bugs/437854
 * kees looks
<kees> jdstrand: erm, fix is where?
<jdstrand> actually, /tmp/pulse-*/ should be /tmp/pulse-*/*
<jdstrand> I'm not completely keen on it, cause abstractions/audio pulls in quite a bit
<jdstrand> I'm not sure how to get away without it though
<kees> I didn't see a patch on that bug -- you were thinking of just adding the audio abstraction plus the /tmp/* paths?
<jdstrand> kees: that whole stanza (no, I don't have a patch)
<jdstrand> kees: I need to add ipc_lock, deny kill, add /dev/shm/pulse-shm*, all of it
<kees> oh! I totally missed the pastebin URL, reading
<kees> jdstrand: I use this for pulse: http://paste.ubuntu.com/280576/
<mdeslaur> jdstrand: why does it need /tmp/pulse-*/ w,?
<jdstrand> mdeslaur: it needs to create that dir
<jdstrand> kees: I can play with it more, but it didn't like when I used 'owner'
<kees> hrm, weord
<kees> weird too
<jdstrand> kees: I think because kvm is running as root, but it is trying to access my uid's pulse stuff
<kees> aah, yeah, good point
<mdeslaur> jdstrand: hmm...why is it trying to access _your_ pulse?
<mdeslaur> also, why isn't /tmp/pulse-* in abstractions?
<kees> mdeslaur: that's a separate bug that needs to be fixed
<jdstrand> mdeslaur: pulse has been a moving targer
<jdstrand> target
<jdstrand> we add stuff as it comes up
<jdstrand> mdeslaur: I think you are right regarding root and my pulse
<jdstrand> it may have failed cause of the /tmp stuff
<jdstrand> kees, mdeslaur: anyhoo, pulse abstraction tinkering aside, I wasn't totally pleased with the access to the files in /dev or ipc_lock
<jdstrand> it did flat refuse to allow 'kill' atm
<jdstrand> also, if I use @{HOME} as is, that expands to all in /home/*/...
<jdstrand> as this process is root, DAC won't do anything, so I want to be extra careful with the access
 * jdstrand -> afk
<davmor2> mdz: How is that I've added the 64 version after the /!\ hopefully it's right now.
<mdz> davmor2, I don't see a step where you actually download the kernel and initrd from uec-images
<mdeslaur> jdong: I probably wouldn't use the abstraction in order to not have the @{HOME}
<mdeslaur> jdong: sorry, wrong auto-completion
<mdeslaur> jdstrand: ^
<mdeslaur> jdstrand: it shouldn't need anything besides the root-owned pulse files...nothing in /dev should be needed I think, and the esd stuff shouldn't be used anymore
<davmor2> mdz: is that not what the wget and gunzip lines do?  It's still set for release beta but that's because that's what these notes are specific for?
<mdeslaur> uhmm...that, of course, assumes libvirt is compiled with pulse support
<ttx> mdz: nurmi just confirmed the mailhost patch, I can commit it, do a quick build/run test and release
<ttx> mdz: just checking you aren't already committing that.
<jdstrand> mdeslaur: ok, those are excellent points. I'll play with it. thanks!
<jdstrand> mdeslaur: it does need access to /dev/snd/*
<mdeslaur> huh
<jdstrand> mdeslaur: it is kvm confinement that I'm adjusting
<jdstrand> mdeslaur: it uses alsa
<mdeslaur> oh :(
<jono> folks, I am still getting a stack of boot messages before xsplash, should I file bugs against them
<robbiew> jono: what are they?
<robbiew> jono: if they start with some decimal number in brackets: [ 1198.829291]  foo: blah blah...then file against kernel
<jono> robbiew, I get that, but also some kind of pci message, an apparmour message about firefox
<jono> and I also see some services starting, like couchdb
<jono> are these messages logged? dmesg and messages doesnt show them
<doko> hmm, firewire disks are not mounted when they are already connected on start
<robbiew> jono: I know Keybuk is aware of the firefox/apparmour stuff...I think that's handled by kees and the gang
<jono> also, it seems KMS starts a little while into the boot
<robbiew> jono: /var/log/syslog
<jono> as opposed to right away
<mathiaz> doko: right - I've seen the same behavior with usb disks
<cjwatson> jono: apparently starting KMS early loses us 2-3 seconds, so Keybuk is trying to avoid it
<cjwatson> which is why it was taken out of the initramfs
<jono> syslog doesnt show anything
<jono> cjwatson, ahh
<kees> jono: if you have firefox/apparmor issues, please open a bug for it.  jdstrand has been doing that profile's development.
<doko> mathiaz: hmm, the connected usb disk is always mounted on boot
<jono> is there a way I can pause the boot to note down these messages?
<jono> I don't seem to have them logged anywhere
<mathiaz> doko: well - I connected my encrypted usb disk before booting my karmic laptop and I wasn't prompted for the usualy password
<cjwatson> ctrl-s might do it
<cjwatson> (ctrl-q to unpause)
<kees> jono: oh, do you mean "Skipped: ...firefox?"  that's known and will be uploaded shortly.
<robbiew> jono: you can also check if they are still on vt1
<jono> kees, thats the one, it skips the profile
<doko> mathiaz: is there already a bug report?
<mathiaz> doko: hm - I don't know - I haven't had time to investigate that yet
<jono> robbiew, they are on vt1
<jdong> kees: a higher-level AA question; does the apparmor/lsm framework provide a feasible way to do some Windows-UAC-like interactive denials?
<jono> I wonder if I can pipe them into a file somehow
<kees> jono: if you want to subscribe: bug 435285
<ubottu> Launchpad bug 435285 in apparmor "apparmor log message on booting" [Low,Fix committed] https://launchpad.net/bugs/435285
<jono> thanks kees
<cjwatson> jono: doubt it
<jdong> kees: in some cases it'd be a cool feature to have for things like Firefox and an occasional, say, thumbdrive access
<jono> ok, I will copy it into a file by hand in vt
<jono> 2
<jono> brb
 * cjwatson admires jono's optimism in believing that there's a shell on vt2 at that point
<kees> jdong: not presently (it would require user-space call-back and blocking the syscalls, etc)
 * robbiew admires jono's optimism that we will fix his bugs
<robbiew> lol
<jdong> kees: *nods* would be pretty neat if implemented though, but yeah I was afraid it'd be nontrivial in how the userspace<->syscall interaction would be
<mdz> ttx, see mail, I don't think we need it
<jdstrand> kees, mdeslaur: I think this is as good as it gets: http://paste.ubuntu.com/280609/
<mdz> ttx, so the only further change needed at this point is to fix up the question text to explain the allowed format
<ttx> mdz: that was my guess as well.
<jono> cjwatson, I am flicking into vt2 right now and copying over content from vt1 by hand into a text editior
<mdz> ttx, I'm working on that now
<jono> so I can get the boot messages
<cjwatson> I'd use a digicam myself ...
<kees> jdstrand: how about making that a "pulse" abstraction, and then adding that to the "audio" abstraction?
<jono> cjwatson, I am most of the way through it now
<ttx> mdz: ok. If you don't need me I'll call it a day. I'll test ISOs first thing tomorrow morning, and do some UEC image validation as well.
<jdstrand> kees: well, I mentioned the @{HOME} issue with mdeslaur
<kees> jdstrand: hrm, yeah, good point.
<jdstrand> kees: @{HOME} will expand to /root and /home
<cjwatson> sigh, this is confusing. is it really taking 30 seconds to get out of the initramfs, or am I doing something to block it by mistake?
<jono> brb rebooting
<jdstrand> kees: I am adding /tmp/pulse-*/ stuff to the audio abstractino though
<cjwatson> oh, hah - & on that strace might be an idea
<jdstrand> we never saw it cause our gui apps use user-tmp
<kees> jdstrand: aaah, yeah
<jdstrand> I'm really not keen on the /dev access, but there isn't anything I can do but add it and comment on it
<jdstrand> people can fine-tune it if needed
<mdz> ttx, I've pushed new question text to the Ubuntu branch
<mdz> ttx, it should be ready to test and upload now
<ttx> mdz: ok, building and quicktesting now.
<jono> ok
<jono> the error I get on boot shortly after it says grub is loading is:
<jono> e1000e 0000:00:19.0: pci_enable_pcie_error_reporting failed 0xfffffffb
<jono> this is just before the AppArmour profile
<jono> I assume this is a kernel bug
<jono> pgraner, ^
<robbiew> I get a similar message
<robbiew> so it may be a thinkpad thing
<jdstrand> oh, I do too
<robbiew> worth reporting...could simply be a nag message
<robbiew> for apw to help clean up
<jdstrand> I do not have a thinkpad, but an intel mobo
<jono> ok, I will file it
<pgraner> jono, robbiew: I'm not seeing it on my non-stinkpad
<robbiew> driver related then?
<jono> pgraner, should I file against the kernel?
<pgraner> robbiew: most likely we updated to .31.1 in the last upload
<jono> I also have the messages I see before xsplash, will file a bug against those too
<pgraner> jono: yea and assign it to rtg and make it high
<jono> pgraner, will do
<robbiew> jono: that pci_enable message should be in your dmesg output as well
<jono> pgraner, what package name do I pass to ubuntu-bug?
<jono> robbiew, thats where I dug it out from
<mdeslaur> jderose: looks good to me
<robbiew> linux
<mdeslaur> jderose: sorry, not you
<pgraner> jono: -p linux
<mdeslaur> jdstrand: looks good to me
<jono> pgraner, ta
<jono> pgraner, might be sensible to have an alias for 'kernel' that points to 'linux'
<pgraner> jono: give me the bug number when your done
<jono> pgraner, will do
<pgraner> jono: there you go thinking like a normal person...
<robbiew> lol
<robbiew> pgraner: I'm now deeply offended
<robbiew> lol
<maco> -p sound aliasing to linux but doing the "apport-collect -p alsa-base" thing might be nice too
<maco> since right now thats two steps
<jono> pgraner, it was already reported:
<jono> https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/436370
<ubottu> Launchpad bug 436370 in linux ""pci_enable_pcie_error_reporting failed" error when booting" [Undecided,New]
<pgraner> jono: ack, I'll get rtg on it
<jono> pgraner, I haven't changed the priority on this yet - you may want to do this
<ttx> mdz: just updated the branch (got rev631), it's not the text with the "delimited by spaces" example.
<jono> robbiew, where do you think I should file these boot messages before xsplash? is that an upstart thing?
<pgraner> jono: ack
<jono> pgraner, cheers buddy
 * ttx pushes the revised version.
<robbiew> jono: just add ubuntu-boot in the tag and subscribe me
<jono> robbiew, will do
<robbiew> then I can triage
<jono> thanks pal
<jono> robbiew, done: https://bugs.edge.launchpad.net/ubuntu/+source/upstart/+bug/438335
<ubottu> Launchpad bug 438335 in upstart "Boot messages show before xsplash kicks in" [Undecided,New]
<robbiew> ack
<slangasek> mdz, kirkland, ttx, mathiaz: server ISO build is up
 * mathiaz syncs
<ttx> slangasek: ok
<jono> kirkland, do you still need some community testing?
<jono> or are you doing fine with the level of testing going on now?
<davmor2> slangasek: is this the uec image with update?
<slangasek> davmor2: no, this is a server ISO with updated eucalyptus packages
<davmor2> slangasek: :) thanks
<mdz> slangasek, thanks
<mdz> mathiaz, davmor2's work in progress test plan is at http://testcases.qa.ubuntu.com/Install/ServerEConfig
<mdz> kirkland, ttx, ^^
<siganderson> a me su karmic Ã¨ sparito sistema->amministrazione->servizi ... Ã¨ normale?
<siganderson> oops... sorry
<pgraner> jono, robbiew: can you try booting with apparmor=0 on your grub line and see if that message goes away
<robbiew> I could...if I cared :P
<robbiew> sure one sec
<pgraner> robbiew: dooh
<jono> siganderson, sorry this is an english speaking channel
<siganderson> I have nomore system->amministration->services is it normal? If i type services-admin in the terminal it says that I must install gnome-system-tools, but I have it already installed
<jono> pgraner, glad Robbie cares :-)
<pgraner> jono: yea tell me about it
<jono> haha
<slangasek> doko: is this openjdk nss build-dep going to change the package size and impact CD sizes?
<doko> slangasek: no, libnss3 is already on the CD, but it's only useful if ca-certificates-java is accepted as well, and ca-certificates is synced to import the new certificates from the start
<robbiew> pgraner: the message is gone...but I also got "* AppArmor not available as kernel LSM.                       [fail]"
<doko> slangasek: ahh, wait ... please reject it
<slangasek> doko: both? or just openjdk?
<doko> slangasek: no openjdk-6 only, the dependency is libnss3-1d ... damn dlopened code ...
<slangasek> ok, done
<slangasek> (neither appears to be something I'm going to accept during the beta freeze, anyway)
<pgraner> robbiew: ok thanks
<smoser> slangasek, is it allowed to un-mark something for beta ? i think that bug 414997 is functioning as it should, with no chnages needed other than documentation. so i dont think it needs to be beta block, and i'd like to wait on soren before doing anything rash.
<ubottu> Launchpad bug 414997 in ec2-init "ec2-set-defaults should be 'run_once_per_ami'" [Medium,In progress] https://launchpad.net/bugs/414997
<slangasek> smoser: that bug is /not/ marked as a beta blocker
<slangasek> smoser: only bugs that are targeted to the release are blockers
<smoser> oh. i didn't realize that. so that bug is set to 9.10 beta milestone, but it needs a karmic track that is milestoned that in order to be blocker ?
<slangasek> smoser: correct.  so if there are other bugs that you think are marked as beta blockers, you may want to double-check that this is really the case
<smoser> agreed!
<rickspencer3-afk> slangasek, any chance you could do a review of desktopouch and couchdb?
<slangasek> rickspencer3: reviewing of what?
<rickspencer3> the packaging, I suppose
<rickspencer3> before it gets uploaded
<slangasek> rickspencer3: better to have someone else do it today
<rickspencer3> slangasek, ok
<slangasek> rickspencer3: btw, someone needs to attend to erlang's build-dependency on wxwidgets2.8
<ia> hello. could you tell me, please, where (in system) i can find grub boot picture (which can be seen after boot menu, but before gdm appears) - white ubuntu logo on black background.
<slangasek> rickspencer3: wxwidgets2.8 is in universe, either it needs an MIR or erlang needs to not b-d on it (I think the latter is much saner)
<rickspencer3> oops
<kenvandine> it should definately not b-d on wxwidgets
<slangasek> -rw-r--r-- 1 lp_publish lp_publish 36710522 Nov  5  2008 /home/lp_archive/ubuntu/pool/universe/w/wxwidgets2.8/wxwidgets2.8_2.8.9.1.orig.tar.gz
<slangasek> (much, /much/ saner)
<ttx> slangasek: new eucalyptus just uploaded per mdz latest changes, please review and if approved, trigger a CD build with it.
 * ttx is calling it a day
<slangasek> ttx: how urgently is that wanted?  there are several other CD-affecting changes that I need to review and accept for beta
<slangasek> (d-i)
<slangasek> if it affects your testing timeline I'll do eucalyptus first, otherwise I'll process them in order of the number of CDs they affect
<ttx> slangasek: it would be great if I could get the new server ISO toasted for tomorrow's breakfast (European time) :)
<slangasek> ttx: right, that's not a challenge then :)
<slangasek> ogra: redboot-tools> needed for beta?
<ttx> slangasek: others might raise priority, though.
<slangasek> ogra: (not clear from the changelog, no bug references)
<slangasek> kenvandine: well, it builds the erlang-wx binary, which rather distinctly involves wxwidgets.  I'd be fine if we dropped it, but it has reverse-deps...
<slangasek> (erlang-{common-test,debugger,megaco,reltool,x11})
<kenvandine> i know nothing about the erlang package
<slangasek> but you have an opinion on whether it should b-d on wxwidgets? :)
<kenvandine> slangasek, looking
<kenvandine> slangasek, it looks like this was added in debian back in april, have we just not synced with them in a while?
<mathiaz> kirkland: mdz: why is postfix installed with a cluster controller?
<slangasek> kenvandine: the present erlang package in Ubuntu dates to Jun 18, this has probably been an outstanding problem since erlang was promoted
<rickspencer3> slangasek, is that erlang-wx dependency blocking beta?
<mathiaz> kirkland: mdz: well I've found why - eucalyptus-cloud needs it to be able to send email when accounts are created
<slangasek> rickspencer3: no, but we should be making progress on it now so it can be resolved immediately post-beta
<rickspencer3> slangasek, ack
<rickspencer3> is there a bug #?
 * rickspencer3 checks
<slangasek> rickspencer3: no, I haven't filed one yet
<rickspencer3> ok
<rickspencer3> slangasek, I'll take care of logging the bug
<slangasek> rickspencer3: thanks
<rickspencer3> I'll assign to kenvandine, and you should see progress in the next day or so
<slangasek> rickspencer3: best to file the bug w/ tasks against both erlang and wxwidgets2.8
<rickspencer3> k
<rickspencer3> slangasek, I wasn't smart enough to figure out what wxwidgets project to assign it to ... so there's only the one task
<slangasek> rickspencer3: 'also affects distribution' -> wxwidgets2.8 + ubuntu
<slangasek> (bug #?)
<rickspencer3> https://bugs.edge.launchpad.net/ubuntu/+source/erlang/+bug/438365
<ubottu> Launchpad bug 438365 in erlang "erlang should not depend on wxwidgets2.8" [High,New]
<rickspencer3> there's only wxwidgets2.6 (that I could find)
<slangasek> rickspencer3: I think you're probably searching in the wrong place, then; note that you have to use "also affects distribution", not "also affects project"
<rickspencer3> aah
<rickspencer3> d'oh
<slangasek> "project" is for things that aren't packages :)
<jdstrand> soren: hi! I've been meaning to tell you that I have a little bash script you can use/extend/steal/whatever. it's not the prettiest thing you'll ever see, but I found it helpful
<jdstrand> soren: http://bazaar.launchpad.net/~ubuntu-bugcontrol/qa-regression-testing/master/annotate/head%3A/scripts/apparmor/libvirt-apparmor.sh
<slacker_nl> hello
<slacker_nl> how can one change the something on the following page: https://wiki.ubuntu.com/UbuntuDevelopment/UsingDevelopmentReleases
<seb128> slangasek, I've just uploaded a nautilus update which fix a bug in the xsplash code, it's a one word change to use the correct software name
<seb128> slangasek, without that xsplash waits for a "nautilus" which never registers
<slangasek> seb128: ok - does that mean with this fix, we now get proper xsplash -> desktop transitions? (timeout + watch are both correct?)
<seb128> slangasek, yes
<slangasek> rockin'
<seb128> slangasek, oh question for you since you are around
<seb128> slangasek, how would you recommend running a command with an another user in a postinst?
<slangasek> seb128: su -c?
<seb128> slangasek, ok thanks
<slangasek> mathiaz, soren, kirkland, smoser: should linux-headers-ec2 be seeded somewhere? (components-mismatches wants to drop them to universe)
<slangasek> tedg: did I read correctly that you're working on bug #436181 today?
<ubottu> Launchpad bug 436181 in indicator-session "Indicator-applet-session crashed" [Critical,In progress] https://launchpad.net/bugs/436181
<tedg> slangasek: Nah, we decided that it wasn't a bad enough user experience ;)
<tedg> slangasek: Yeah, I'm not sure of the root cause.  But I have a branch that I can't get to crash.  seb128 has volunteered to test on his setup.
<slangasek> ok
<seb128> I'm just doing this gdm change first
<seb128> slangasek, "su -c 'gconftool --get /desktop/gnome/interface/gtk_theme' gdm"
<seb128> slangasek, is there anything stupid in this command?
<slangasek> looks sane to me
<seb128> it's not supposed to write on stdout?
<slangasek> you may or may not need a '-i' as well to specify that it's a login shell
<seb128> because it doesn't
<slangasek> dunno
<slangasek> er, not -i -- -l
<slangasek> but no, that doesn't help either
<slangasek> seb128: oh, -s /bin/sh
<slangasek> instead of trying to execute the command using the /bin/false shell ;)
<seb128> now it makes sense ;-)
<seb128> slangasek, thanks
<slangasek> sure
<mathiaz> slangasek: yes - probably
<mathiaz> slangasek: I'd suggest on the dvd seed
<mathiaz> slangasek: to keep it in main
<slangasek> mathiaz: mumble; nothing else from ec2 is on the dvd seed
<mathiaz> slangasek: right - the rest is in the uec seed
<slangasek> the dvd seed corresponds to an actual image, please don't use it "to keep [things] in main" :)
<mathiaz> slangasek: which is what is installed by default in uec
<mathiaz> slangasek: I don't think we wanna have the headers installed by default the uec image
<mathiaz> slangasek: ok - so where else should it go?
<slangasek> that's fine - in that case, the supported seeds would be the right place for it
<mathiaz> slangasek: ok - supported then
<slangasek> supported-kernel, specifically
<mathiaz> slangasek: should I add to this line (in supported-kernel)? http://paste.ubuntu.com/280726/
<mathiaz> slangasek: I'm not that ec2 should be considered at the same level as -virtual
<slangasek> mathiaz: yep - I see a couple other things to clean up in there though, so I'm happy to take care of it
<slangasek> (e.g., "backports-jaunty" is wrong :)
<mathiaz> slangasek: ok - I'll let you add it during your cleanup
<kirkland> mathiaz: right, email needed to create accounts
<slangasek> siretart: any reason to regard the auctex upload as beta-critical?
<kirkland> slangasek: mdz: i'm syncing the iso's now
<kirkland> jono: some testing would be great, yeah;  what else do you need from us to make that happen?
<kirkland> slangasek: regarding the kernel seed, "yes, probably so..."  but I'm not the expert on that one
<kirkland> slangasek: do we have an ec2-image seed?
<slangasek> kirkland: there's a uec seed; mathiaz said he didn't think it was needed there; I've seeded it in supported-kernel
<kirkland> slangasek: hmm... maybe jjohansen1 knows?
<slangasek> mm?
 * jjohansen1 goes to read scroll back
<slangasek> kirkland: I do agree with mathiaz that I think it's unlikely to be needed by default, so there's no need to include it in our image; so supported-kernel is the sensible place to keep it around
<kirkland> slangasek: coolio
<jono> kirkland, we would still need http://testcases.qa.ubuntu.com/System/Eucalyptus updating will a full set of tests and where to report feedback
<jono> I can push the message if that page is updated, but I would need that first
<kirkland> mdz: i'm just getting the message about notifying eucalyptus about iso's, as I've been flying all day today
<kirkland> mdz: i'll tell them now
<slangasek> smoser: what else is needed to close out bug #431103 for beta?
<ubottu> Launchpad bug 431103 in linux-ec2 "ssh host key fingerprint no longer available in the console log" [High,Fix released] https://launchpad.net/bugs/431103
<siretart> slangasek: no, auctex is not beta-critical. post-beta it is required for emacs23
<slangasek> siretart: ok
<slangasek> siretart: (motu-release has approved emacs23?)
<siretart> slangasek: yes, they did. the bug is referenced in the changelog
<siretart> that's bug #433397, BTW
<ubottu> Launchpad bug 433397 in emacs22 "FFe for emacs23" [Wishlist,Confirmed] https://launchpad.net/bugs/433397
<slangasek> siretart: ok, cool
<siretart> TBH, I even think we should even promote it for main, and demote emacs22 to universe. I've been using pre-release versions of emacs23 for over a year, and I'm totally sold by emacs23
<siretart> but that's a different story
<seb128_> slangasek, I've uploaded a new gdm which set a specific theme for the login screen
<slangasek> seb128_: thanks, will review
<seb128_> thanks
<slangasek> siretart: not something I'm inclined to consider post-beta
<siretart> you aren't an emacs user, are you? ;-)
<siretart> anyway, you're probably right, because a lot of add-on package need to become 'emacs23'-enabled, like I just did for auctex
<slangasek> siretart: heh, my editor usage is secondary to my RM hat. >:)
<siretart> that's rather straight forward for most packages, but it will take some time to get it sorted out, given our bad performance at preparing the emacs23 package :-(
<mathiaz> kirkland: hey - going through http://testcases.qa.ubuntu.com/Install/ServerEConfig
<mathiaz> kirkland: point 3 ran into an error: http://paste.ubuntu.com/280758/
<mathiaz> kirkland: BTW I don't have br0 interface configured on the CC
<mdz> mathiaz, kirkland, how is it going?
<mathiaz> mdz: I've just installed the CC and the NC on two physical systems
<mdz> mathiaz, steps 1-7 are obsolete with the current build
<mdz> everything should be registered automatically
<kirkland> mdz: sync'd ISO's to home; i'm at the airport now, won't be home for a few hours
<mathiaz> mdz: is the bridge interface supposed to be setup automatically on the CC?
<kirkland> mdz: i just reviewed davmor's test instructions; they look good
<mdz> mathiaz, not afaik; I believe only the node controller gets a bridge set up
<kirkland> mathiaz: i don't think the CC needs a bridge
<mdz> kirkland: you mean the steps after #7, right?
<mathiaz> kirkland: mdz: oh right.
<mdz> actually I lie. #2 and #6 are still valid
<mdz> the node won't be registered automatically yet
<kirkland> mdz: minus the manual registration, you mean?
<mdz> I'll just go ahead and edit it
<mdz> kirkland: the SC, walrus and CC will be registered automatically now
<mdz> but the nodes are still manual
<mathiaz> mdz: step 6# gave me an error: http://paste.ubuntu.com/280769/
<mdz> mathiaz, I have never done that bit before; ask #eucalyptus?
<mathiaz> mdz: ok
<NCommander> Can someone confirm a bug for me? Anyone with the en_US lang, and latest karmic, please run apt-get update on the console, and see if you get , vs. .
<NCommander> (separating numbers that is)
<NCommander> er wait, nm
<NCommander> bah, false alarm
<Turl> Hi
<Turl> can you guys tell me why my karmic firefox says "shiretoko" in the title? it has all the firefox branding in the other places
<slangasek> mdz, kirkland, mathiaz: 20090928.2 is now the current server ISO, including eucalyptus ubuntu10
<slangasek> TheMuso: where have things landed wrt alsa and ia32-libs for karmic?  update-manager tells me it doesn't want to upgrade lib32asound2-plugins
 * mathiaz syncs
<mdz> slangasek, thank you
<TheMuso> slangasek: I put libasound2-plugins back into ia32-libs and reverted the changes made to lib32asound2-plugins...
<slangasek> TheMuso: ok, cool - unfortunately, installing lib32asound2-plugins wants to remove ia32-libs, and nothing else wants to kick lib32asound2-plugins out for me... looks like some tweaking may still be needed here?
#ubuntu-devel 2009-09-29
<TheMuso> slangasek: I don't know. I simply put it back to the way things were before. I'll have a look.
<TheMuso> slangasek: afaik originally they conflicted.
<slangasek> TheMuso: ah, indeed they do
<slangasek> TheMuso: perhaps ia32-libs needs to have a Conflicts: added in the other direction?
<cjwatson> they originally conflicted and there was a bug about that
<cjwatson> I think you need to revert slightly less far - I think that was fixed at one point?
<TheMuso> Anyway, I'll have a look today.
<slangasek> cjwatson: I'm not sure that's true; my recommendation (which, er, somehow isn't in the list web archive?) was to put alsa back into ia32-libs
<TheMuso> It will take me several hours to upload ia32-libs as it is.
<slangasek> yeah
<slangasek> ia32-libs is in universe, not blocking anything for beta, so take your time
<cjwatson> slangasek: that may be, I might be misremembering
<slangasek> cjwatson, TheMuso: reviewing the current state: lib32asound2-plugins is built from alsa-plugins, which build-depends on libpulse-dev, which has no biarch equivalent; so we end up with a biarch plugins package without the key default plugin - I think that binary package should be nuked entirely for karmic, and ia32-libs have a conflicts: added only if that conflicts: is needed for upgrades from jaunty
<TheMuso> slangasek: Ok I can take care of both.
<seb128> slangasek, I've uploaded a patched indicator-session with changes from ted to fix the crash at login issue
<seb128> I tried the change there they seem to work correctly, ie I didn't get the crash yet where I was getting it half of the time before
<smoser> slangasek, regarding your question above about bug #431103. we need a kernel build of 2.6.31-300.3. jjohansen was looking to get one, i think.
<ubottu> Launchpad bug 431103 in linux-ec2 "ssh host key fingerprint no longer available in the console log" [High,Fix released] https://launchpad.net/bugs/431103
<Rashko> hi all
<Rashko> how can I enable more than 4 serial ports
<Rashko> I need some help please
<Rashko> 2 pci cards 6 + 4 serial ports but only 4 ports is active
<Rashko> how can I enable more than 4 serial ports
<mathiaz> smoser: slangasek: is uec-images.ubuntu.com rsyncable?
<smoser> according to soren at https://wiki.ubuntu.com/UEC/Images/Testing , yes. and my experience agrees
<slangasek> smoser: the kernel build is already done; I'm asking about the task open on ec2-init
<smoser> as far as I know the kernel build is not done.
<smoser> $ rmadison --suite karmic linux-ec2
<smoser>  linux-ec2 | 2.6.31-300.3 |        karmic | source
<smoser>  linux-ec2 | 2.6.31.300.0 |        karmic | amd64, i386
<smoser> and my feeling about ec2-init is that no changes are needed, but I would like an official kernel build to verify that in.
<smoser> i could be reading that information wrong, or otherwise ignorant
<slangasek> smoser: your rmadison is out-of-date wrt the archive
<smoser> oh?
<cjwatson> our rmadison only updates every six hours
<smoser> this makes me happy
<smoser> slangasek, so, maybe nothing. i'll wait till the build pulls that version, and picks it out with initrd/kernel then will upload those kernels and test them.
<slangasek> smoser: the current build /already/ has that version :)
<slangasek> would be good to have this confirmed, since that's marked as a beta blocker
<mase_wk_> i'm having some problems building a kernel package on 8.04 which will automatically run update-initramfs. I am passing the --initrd flag to make-kpkg however it does not seem to update the initramfs
<smoser> slangasek, i meant http://uec-images.ubuntu.com/karmic/current/ubuntu-uec-karmic-amd64.manifest
<slangasek> smoser: yes, I see -300.3 listed there
<slangasek> smoser: oh, I see; you're looking at the linux-ec2 *binary* package, which is not built from linux-ec2 source - it's built from linux-ec2-meta source and will not have a matching version number
<slangasek> smoser: the actual kernel image is already at version -300.3, so this fix should be present
<slangasek> mase_wk_: this is not a support channel; please see #ubuntu
<mase_wk_> slangasek: np, thanks
<smoser> slangasek, ok. there will be a 0929 build in the next 20 minutes or so. i'll take its output and upload to ec2 later tonight.
<slangasek> smoser: why are you waiting when the existing one already has the relevant kernel?
<smoser> i guess i can upload the kernel from last nights you're correct. i just was being lazy.
<smoser> and i might as well refresh the nightly that i have out there (or at least check whats different in the manifest0
<rgreening> ScottK: ping
<rgreening> Can you look at bug 425751
<ubottu> Launchpad bug 425751 in usb-creator "usb-creator transitional package should be seeded?" [Undecided,New] https://launchpad.net/bugs/425751
<rgreening> ScottK: not sure if you can fix or at least direct to someone who can and set the correct milestone
<ScottK> rgreening: Fixed.
<rgreening> ty ScottK
<rgreening> ScottK: will you be updating the bug to reflect? Thanks
<ScottK> rgreening: Did already.
<rgreening> ah.. I see it has updated.
<rgreening> cool
<rgreening> yay
<rgreening> ScottK: just read the comment... does this mean it is ok for Ubuntu seed as well? Or does it just need to be in 'a' seed?
<ScottK> rgreening: "a seed" is all that was needed.
<rgreening> cool. understood.
<LaserJock> so hmm, I can't seem to get Karmic to play a CD
<LaserJock> seems to be bug 435035 but there's not a lot of info
<ubottu> Launchpad bug 435035 in gstreamer0.10 "rhythymbox doesn't play cds (No URI handler implemented for "cdda")" [Undecided,New] https://launchpad.net/bugs/435035
<LaserJock> darn it, now I can't get the CD to eject :(
 * ScottK hands LaserJock a large hammer and a screwdriver ...
<LaserJock> I got it out eventually
<LaserJock> but still sucks that I can't listen to my brand new CD :(
<ajmitch> Yes, it does seem a bit of a problem if it just doesn't work in karmic
<ajmitch> I'm too used to having all the music on the computer already
<LaserJock> rhythmbox, banshee, totem, nothing works
<ajmitch> they all use the same gstreamer plugins
<LaserJock> yep
<LaserJock> I guess I could try amarok ... but yuck
<ajmitch> or try & use sound-juicer to create .oggs?
<LaserJock> hmm, perhaps. I was assuming if it wouldn't play it wouldn't rip very well
<ajmitch> from what I read in that bug, they still had sound-juicer working, which is odd
<ajmitch> since it also uses gstreamer for ripping & encoding
 * ajmitch doesn't have an up-to-date karmic install booted to check
<Darxus> It's looking like the upcoming ubuntu release will have a default chat client that will not let you use it without saving your passwords.
<Darxus> How do I get the attention of somebody who can prevent that?
<Darxus> https://bugs.launchpad.net/ubuntu/+source/empathy/+bug/118800
<ubottu> Launchpad bug 118800 in empathy "Cannot add account" [Undecided,New]
<ScottK> Darxus: That's a pretty old bug, is it still accurate for the current release?
<jdong> ScottK: yup reproduced here
<jdong> the apply button is greyed out unless you type in a password
 * ScottK looks
<jdong> I see no obvious way from the UI to create an account without saving a password
<Darxus> ScottK: Yup.
<Darxus> Bizarre, huh?
<jdong> well yeah kind of; I can certainly understand the concern
<jdong> though I have to point out 99% of users will want their passwords remembered
<jdong> (not saying we shouldn't cater to the others)
<ScottK> Darxus and jdong: I did the LP magic to get it on the release team's radar.  Not sure what they will do with it.
<jdong> ScottK: *nods* thanks
<jdong> I just admit I haven't touched Empathy much to know if it'd be a big deal (tm) to implement this feature
<Darxus> ScottK: Thank you.
<TheMuso> It would likely break UI freeze
<jdong> we could just... bring back pidgin
<jdong> *puts on flamesuit*
<LaserJock> jdong: +1
<LaserJock> I thought pidgin had a good chance of coming back, but I guess it's a little late now
<Darxus> LaserJock: Why did you think it had a good chance of coming back?
<LaserJock> well, it's hard to put it well
<LaserJock> I just felt like empathy really didn't rise to the occasion
<Darxus> Ah.
<LaserJock> it seems like a basic, minimalistic IM client but not much more
<Darxus> Heh.
<LaserJock> I haven't seen much of an "improvement" in empathy in like a year, I expected more I guess
<Darxus> I'm disappointed it doesn't have the gui and backend separated into client / server pieces like quassel.
<Darxus> Because as long as I can't do a single reattach to get back to my four irc servers, jabber, aim, and yahoo, I'll still primarily be using a console client in screen :/
<jdong> well I'm not impressed with how quassel is separated either
<Darxus> I haven't actually tried it yet.
<jdong> why is there a single system daemon installed by the package to be shared by all users?
<Darxus> Ew.
<Darxus> Well... I don't know....
<jdong> but yeah, the IDEA behind quassel/smuxi is nice
<Darxus> Oh, thanks for mentioning smuxi, wasn't aware of that one.
<jdong> Darxus: it's pretty nice and I found its codebase to be very clean to work with; though in terms of raw features it lags behind quassel, irssi, weechat
<Darxus> But it would be nice to be able to drop bitlbee too (mostly requiring jabber support).
<Darxus> How hard could this stuff really be, I've done irc over telnet?  :P
<jdong> but as far as empathy is concerned, I totally agree with what LaserJock's opinions are on the matter
<jdong> in its current state it still looks and feels like a proof-of-concept/rough-cut basic IM client, not something I feel should've replaced pidgin by default
<ScottK> jdong: I don't think that there is a single system daemon shared by all users with the quassel monlithic client (the one we use as default).
<ScottK> If you use a remote core on a server somewhere, it can support multiple clients.
<Darxus> And you feel that pidgen is more solid?
<jdong> ScottK: the last time I installed it on Jaunty (two weeks ago) it ran a single server via an init job
<ScottK> I'll have a look.
<jdong> Darxus: yes, I do feel it's more solid and featureful though it lacks the AV capabilities
<Darxus> Interesting.
<LaserJock> and it has *gasp* preferences
<jdong> LaserJock: but... we don't need those!
<jdong> LaserJock: the last time *I* made an IM client, it had a big textbox and a little textbox!
<Darxus> Hehe.
<Darxus> I created a bug for quassel/smuxi type functionality in empathy:  https://bugs.launchpad.net/ubuntu/+source/empathy/+bug/438502
<ubottu> Launchpad bug 438502 in empathy "Break UI and backend into client / server." [Undecided,New]
<Darxus> I realize it's not going to happen any time soon.
<Darxus> I can't nominate for Lucid yet?  :P
<ScottK> That's something to file in an upstream bug tracker.  Ubuntu wouldn't do that split without upstream.
<Darxus> Oh, hmm.
<ajmitch> it is a fairly major change for an app
<Darxus> I realize.
<Darxus> I'm filing an upstream bug.
<LaserJock> ajmitch: pfft, I'm sure it'd make the Papercut list ;-)
<Darxus> Doesn't LP have a way to link to a gnome bug?
<ajmitch> LaserJock: I'll let you take on that one :)
<Darxus> Hehe.
<johnp> hello.
<Darxus> Cool, figured out how to link the upstream bug.
<Darxus> ("also affects project")
<YokoZar> package ttf-tahoma-replacement 1.1.30-0ubuntu2 failed to install/upgrade: error writing to '<standard output>': No such file or directory
<YokoZar> ^^ best error report yet :)
<StevenK> Haha
<YokoZar> https://bugs.launchpad.net/bugs/438391
<ubottu> Launchpad bug 438391 in wine1.2 "package ttf-tahoma-replacement 1.1.30-0ubuntu2 failed to install/upgrade: error writing to '<standard output>': No such file or directory" [Undecided,New]
<al-maisan> Good morning!
 * slangasek waves
<slangasek> TheMuso: hmm, your alsa-plugins upload also drops three patches out of debian/patches
<dholbach> good morning
<TheMuso> slangasek: hrm I'll have a look.
<TheMuso> slangasek: hrm screwed up with creating the package. Feel free to reject, and I'll re-upload.
<pitti> Good morning
<al-maisan> Good morning pitti
<slangasek> TheMuso: ack, rejected the first one
<stefanlsd> YokoZar: Just wanted to say thanks so much for the wine1.2 packages and quick updates. Its really awesome :)
<YokoZar> stefanlsd: at some point soon I'm going to have to freeze it for karmic though
<YokoZar> although I still need some manual patches (eg one that lets photoshop install)
<stefanlsd> YokoZar: yeah. will go back to your ppa then i guess once its frozen.
<highvolt1ge> morning YokoZar and stefanlsd
<AnAnt> LP 438092
<ubottu> Launchpad bug 438092 in texlive-bin "Candidate revision texlive-bin_2007.dfsg.2-7ubuntu1" [Undecided,Confirmed] https://launchpad.net/bugs/438092
<dholbach> cjwatson_: AFAICT you fixed the alt-f7 gdm switching thing - good work! :)
<tkamppeter> pitti, hi
<pitti> hey tkamppeter
<tkamppeter> pitti, it is about bug 420015
<ubottu> Launchpad bug 420015 in cups "usblp Kernel module needs to be removed and /dev/bus/usb/*/* made accessible for USB printers to work with CUPS 1.4.x" [High,Confirmed] https://launchpad.net/bugs/420015
<tkamppeter> There are still users who cannot access their USB printers.
<pitti> tkamppeter: Debian users complain _a lot_ about the libusb change as well
<pitti> it breaks tons of stuff and third-party apps which need it
<tkamppeter> pitti, then I have tried the situation of my HP printers and found that the HP DesignJet 130 appears in "ls -l /dev/bus/usb/*/*" but not in "lsusb". Looks like a low-level USB problem.
<pitti> tkamppeter: nope
<pitti> tkamppeter: try "sudo lsusb"
<pitti> tkamppeter: the problem is that these devices aren't world-readable any more with the new udev rule (it makes them 660 root:lp)
<maxb> cjwatson_: It seems that something is causing postinst failure on upgrade - your emit events change seems like a likely candidate
<tkamppeter> Yes, it is exactly only the DesignJet 130 which needs "sudo usblp".
<Whoopie> asac: Hi, I tested the patch for bug 413053 and it's working.
<ubottu> Launchpad bug 413053 in gnome-bluetooth "Bluetooth-applet drops paired phone from list of devices" [Undecided,Fix committed] https://launchpad.net/bugs/413053
<maxb> cjwatson_: err, oops, the word "gdm" was supposed to be in that sentence somewhere :-)
<maxb> lp 438561
<ubottu> Launchpad bug 438561 in gdm "package gdm 2.28.0-0ubuntu8 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Undecided,New] https://launchpad.net/bugs/438561
<tkamppeter> pitti, what I have seen in bug 420015 is that a user uses /dev/usbmon3 as URI for an Epson. Seems that this is a third-party device generated by a daemon of a manufacturer-supplied driver and this daemon passes the data on to something like /dev/usb/lp0 which does not exist any more with CUPS 1.4.x.
<ubottu> Launchpad bug 420015 in cups "usblp Kernel module needs to be removed and /dev/bus/usb/*/* made accessible for USB printers to work with CUPS 1.4.x" [High,Confirmed] https://launchpad.net/bugs/420015
<asac> Whoopie: checking
<Whoopie> asac: just told you as you were asking in the report. ;)
<asac> ok
<asac> we will get it fixed after beta
<Whoopie> asac: ok, a new 2.28.1 was tagged in gnome-bluetooth git which fixes it (and some other issues I debugged with the maintainer)
<asac> Whoopie: ok. thanks. if you know further launchpad bugs fixed, please set to fix committed
<Whoopie> asac: what do you think about bug 436694? Could we ship the same udev rule as fedora does?
<ubottu> Launchpad bug 436694 in gnome-bluetooth "[karmic] gnome-bluetooth applet menu does not have "Turn Off Bluetooth" as described in help and needed." [Undecided,Confirmed] https://launchpad.net/bugs/436694
<cjwatson> dholbach: excellent, glad it works for you
<cjwatson> maxb: hmm
<cjwatson> maxb: I don't think that can possibly be my change, since the gdm postinst doesn't actually restart the job
<cjwatson> maxb: it's more likely the pre-existing 'status gdm' in the postinst
<slangasek> asac: epiphany> if you want it demoted, please go ahead and unseed it
<cjwatson> maxb: I could be wrong of course, but I can't see the mechanism by which my change would have broken this
<Whoopie> asac: btw, why after beta? it's one month since then.
<asac> Whoopie: one month? read /topic ;)
<asac> slangasek: ok. i will double check with seb one last time.
<seb128> asac, go for it
<asac> kk
 * asac updates seeds
<Whoopie> asac: hehe, sorry. on https://wiki.ubuntu.com/KarmicReleaseSchedule, I just read "23" and "october". ;)
<asac> Whoopie: how does that udev rule help?
<mat_t> cjwatson: hi
<YokoZar> seb128: I believe https://bugzilla.gnome.org/show_bug.cgi?id=468445  needs to be reopened now (and you are the reporter upstream)
<ubottu> Gnome bug 468445 in GtkFileChooser "gtkfilechooser save/save as dialog misplaces focus" [Normal,Resolved: fixed]
<cjwatson> mat_t: hello
<seb128> YokoZar, reopening closed bugs because you have a similar issue in newer versions is usually not the right thing
<YokoZar> I think it's the same issue though
<YokoZar> The save as dialog is still focusing wrong
<seb128> YokoZar, the code could have changed and comments about debugging on the old code will just creating confusion
<YokoZar> Ahh ok
<YokoZar> https://bugs.launchpad.net/ubuntu/+source/gtk+2.0/+bug/130224  <-- launchpad link, should file a new gnome one then
<ubottu> Launchpad bug 130224 in gtk+2.0 "gtkfilechooser save/save as dialog misplaces focus" [Low,Confirmed]
<seb128> open a new bug if you want rather
<seb128> and mention the old one number
<YokoZar> yeah np
<seb128> thanks
<seb128> I'm too busy to work on minor issues like that
<seb128> but opening upstream would be nice
<pitti> tkamppeter: right, what I meant; there are also tools for ink levels etc. which only work with usblp
<ogra> casper on slow media with no progressbar at all in usplash is not a very pleasant experience
<MacSlow> asac, can you quickly look over https://bugs.edge.launchpad.net/notify-osd/+bug/438312
<ubottu> Launchpad bug 438312 in notify-osd "[Karmic]Network manager notification about being connected not shown when connecting with mobile phone(3G)" [Undecided,Incomplete]
<asac> MacSlow: invalidated and moved to applet ... even though i dont think its something we did before
<asac> thx
<MacSlow> asac, ok thanks... I wasn't sure... initially I thought Mio ran into a "suppress display of a notification"-situation, but then I wanted to also get your view on it as I don't know what network-manager does and does not with notifications.
<asac> i might be wrong, but afaik we dont display notifications for that ... but i kept it open for nm-applet to check
<MacSlow> ok
<joaopinto> mvo_, does it make sense to have a "Price: Free" field on a Get Free Software section :) ?
<mvo_> joaopinto: check bug 419295 for a discussion about this
<ubottu> Launchpad bug 419295 in software-store ""Price: Free" is redundant when user is navigating in the "Get Free Software" section" [Undecided,Invalid] https://launchpad.net/bugs/419295
<joaopinto> ah ops :P
<mvo_> joaopinto: its a valid question, no problem. I think we need a faq or something to link to the discussion
<joaopinto> mvo_, in the long term apturl will be integrated with aptdaemon right ?
<ttx> cjwatson: we'll need at least one more cycle on the eucalyptus package, I'm fixing critical issues revealed in my UEC-install-from-daily testing
<joaopinto> I would like to be able to install apps from a web page using multiple links without entering the password for each click, I am not sure it that will be available keeping a reasonable security
<mvo_> joaopinto: with software-center and aptdaemon, yes
<mvo_> joaopinto: should be done for lucid already
<mvo_> joaopinto: I mean, it will be done for lucid
<joaopinto> that would require some whitelist mechanism, to keep credentials for a specific page
<ttx> cjwatson: the PUBLICIPS postinst fails if you set multiple addresses, see bug 438586
<ubottu> Launchpad bug 438586 in eucalyptus "Public IPs settings are not propagated to configuration" [High,Triaged] https://launchpad.net/bugs/438586
<joaopinto> ok,  apturl will just queue the requests into software-center
<Whoopie> asac: right now, /dev/rfkill has permission 644 so that gnome-bluetooth can enable/disable BT. This rule seems to allow users the access to /dev/rfkill.
<mvo_> joaopinto: right, the current ui will just be integreated with software-center (and made look nicer)
<joaopinto> ok :)
<Whoopie> asac: http://www.spinics.net/lists/hotplug/msg02404.html
<tkamppeter> pitti, should we perhaps return to the usblp-based CUPS backend and tell the manufacturers to stop using usblp, so that in the next release we can switch over to not use usblp.
<pitti> tkamppeter: is that possible with 1.4?
<pitti> tkamppeter: allegedly it is with --enable-libusb=no
<pitti> tkamppeter: but I didn't test it
<tkamppeter> pitti, problem is once that next release is LTS and second, if we stay with usblp manufacturers could stay using it.
<pitti> tkamppeter: but that would again break system-config-printer, I guess?
<pitti> tkamppeter: the advantage would be that people upgrading from jaunty and earlier would actually not end up with a broken printer (since libusb changes the device strings)
<pitti> tkamppeter: or does s-c-p get along with both?
<tkamppeter> pitti, principally, CUPS can be built also with a usblp-based "usb"backend.
<pitti> tkamppeter: for LTS I wouldn't change the backend, we should keep with what we have in karmic
<tkamppeter> s-c-p works with both versions, and CUPS intends that both give the same URLs.
<pitti> tkamppeter: oh, so why didn't we do this from day one then?
<pitti> (build with usblp support)
<pitti> it was a real pain to do the switch to libusb, and it feels wrong, too
<tkamppeter> pitti, the USB backend of CUPS can be built EITHER usblp-based OR libusb-based, not both (with auto-detection of usblp presence) in one backend.
<pitti> tkamppeter: right, I understand
<pitti> tkamppeter: I meant, why didn't we keep usblp in 1.4.0?
<tkamppeter> One could make a workaround building both backend versions and renaming them (usb-usblp and usb-libusb), then add a wrapper script (usb) which checks presence of the usblp module with lsmod and then starts the appropriate real backend.
<pitti> tkamppeter: what's the advantage of using the libusb one?
<pitti> it seems so much easier and backwards compatible to use usblp only
<tkamppeter> pitti, once HPLIP is libusb-based, it grabs the device and takes it away from the usb backend (usblp) of CUPS 1.3.x.
<cjwatson> pitti: as ogra observes, casper on slow media is pretty nasty with no progress bar. Is there any way we could make the progress bar run-time-optional in usplash-theme-ubuntu somehow, rather than just commenting it out entirely?
<pitti> tkamppeter: right (but that's a different backend?)
<ogra> ++
<ogra> the bouncing bar would suffice i think
<pitti> cjwatson: with some small hacks, yes
<ogra> so you see it didnt die at least
<cjwatson> we could have a new command in usplash to turn it on
<tkamppeter> pitti, this causes sonme confusion, especially the UDEV scripts must always check both the low-level signals and the usblp signals coming from the printer to reliably determine when a printer appears and when it disappears.
<pitti> I guess it won't be precise any more with upstart scripts, but it'd at least show something
<ogra> another option would be to drop quiet on slow live media
<pitti> it requires changing the logo position and adding a new command line switch or usplash_write command
<ogra> but i guess that would require additional translations we havent prepared
<pitti> I'll ask the design team
<pitti> oh, mat_t is here ^
<pitti> mat_t: since you asked for dropping the progress bar, any opinion about bringing it back on the live system boot?
<asac> Whoopie: yes. understood that. didtn know how that ACL_MANAGE works ... but now i know ;)
<asac> thx
<mat_t> pitti: in the meeting atm - will get back to you in a bit
<pitti> it also requires new artwork, and moving the icon further up by default (not almost-centered)
<Amaranth> pitti: you could just drop the progress bar down
<cjwatson> pitti: I was actually wondering yesterday if it would be worth adding a way for upstart to prod usplash occasionally, say when events occur
<pitti> Amaranth: then the text area gets pretty small on smaller resolutions (like 400 pixel y)
<ogra> or let the icon pulsate or something
<Amaranth> text area? I thought you just wanted a progress bar
<pitti> the text area is still there, and required
<cjwatson> pitti: if it were built-in, it would be fairly efficient
<ogra> Amaranth, you can still drop quiet
<pitti> (fsck, password entry, etc.)
<tkamppeter> pitti, second, the usblp backend disables bi-di access for several important manufacturers, as usblp does not work with most printers of them
<cjwatson> though at the moment you'd have to reopen the fifo each time, which isn't idedal
<cjwatson> ideal
<pitti> cjwatson: "more" built in than usplash_write?
<cjwatson> something that doesn't involve spawning a process each time, yes
<tkamppeter> pitti, third, the libusb-based backend supports also some more general access, for example to allow printing and non-printing functions on an MF device to be done in parallel.
<Amaranth> so basically usplash_write built into upstart that just keeps the connection open?
<cjwatson> I wouldn't want to hack it in without consulting with Keybuk, obviously, but it was something I was thinking about while upstartifying usplash
<pitti> Amaranth: probably more like usplash listening to upstart events, I think
<ogra> we're pre upstart, arent we ?
<cjwatson> ogra: casper is, yes
<ogra> right
<Amaranth> pitti: ah yeah, then usplash can just listen for starting events and show some text
<cjwatson> ogra: sorry, my question about upstart prodding usplash occasionally was not directly related to your problem
<ogra> yes, i thought so
<cjwatson> usplash listening to upstart events would be a little tricky, since it starts before upstart - doable but tricky
<cjwatson> and the main loop would need to be rewritten, though it needs rewritten anyway!
<ttx> cjwatson/slangasek: new eucalyptus (0ubuntu11) uploaded to fix critical issues uncovered in daily CD testing. Please review/approve/respin if appropriate
<cjwatson> Amaranth: even if it were done in upstart, can't keep the connection open the way usplash is at the moment
<cjwatson> Amaranth: the comms protocol is a fifo not a socket
<Amaranth> ah
<cjwatson> but pitti's probably right, better the other way up
<pitti> cjwatson: I just feel that coding usplash knowledge into upstart seems a bit wrong
<tkamppeter> pitti, what I would like to see as a CUPS USB backend would be one acting similar to the hp backend. Instead of simply giving up silently if a printer is grabbed by the usblp backend it should simply detach the printer and access it through libusb. This way one could leave the usblp kernel module loaded so that third-party backends can still use it.
<pitti> tkamppeter: that would be nice indeed
<tkamppeter> pitti, one would need to have a look into the "hp" backend to see how it works and patch the CUPS USB backend, and also test on printers which are not from HP.
<ogra> asac, what do i have to do to make NM like my NIC on my babbage board ?
<ogra> asac, i can get it to work with ifconfig eth0 up and dhclient, NM doesnt see it at all though
<mat_t> pitti: how long does the live system boot take? Until we can display xsplash that is
<pitti> ogra: ^
<ogra> on armel its 40-50sec
<pitti> mat_t: I guess a magnitude of 30 seconds to a minute?
<ogra> depending on the SD card i use up to 1.5min
<mat_t> pitti: 30 secs until xsplash?
<pitti> I guess so
<mat_t> hmm
<pitti> on a CD it's a similar magnitude, though
<pitti> stuff needs to be loaded from CD, squashfs unpacked, casper configures some things, etc.
<mat_t> sabdfl was very clear on progress bars, since they're not really reliable... For most of the time you see it going from side to side anyway
<mat_t> and then it accelerates, decelerates, etc
<pitti> by and large they will, unless we do some heavy changes (see above)
<pitti> mat_t: could we make the logo pulsate instead?
<pitti> ogra: ^ WDYT?
<pitti> we already have the fading code anyway
<mat_t> pitti: we could (I mean, you probably could) :)
<mat_t> pitti: we could have it going fade in-out slighly
<ogra> ++ on any kind of indication that the system doesnt hand
<ogra> *hang
<mat_t> pitti: but only on live cd/installer, not in the real session
<ogra> i dont care *what* we do but sitting in front of a white logo for a minute doesnt make me feel confident my system still boots
<asac> ogra: what driver is it using?
<ogra> asac, a forwardported version of the FEC driver from 2.6.28
<pitti> mat_t: that can be arranged, yes
<pitti> by calling usplash with --pulsate or so
<ogra> asac, built into the kernel
<mat_t> ogra: 1 minute boot is annoying in any scenario :)
<pitti> I'm fairly sure that casper runs early enough to be able to modify the usplash startup
<cjwatson> it can send a command to usplash, at any rate
<ogra> mat_t, well, its a special case for me, but the CD isnt much faster either
<pitti> cjwatson: right, or that
<lifeless> or change stuff for the initramfs in its hooks?
<cjwatson> mat_t: live CD boot is pretty much always slow no matter how you shake it
<cjwatson> lifeless: bikeshed
<lifeless> cjwatson: uhm sure, was just saying it should clearly be possible
<cjwatson> it can be done, yes :)
<mat_t> cjwatson: pitti: how about displaying some text info for live CD?
<ogra> effectively we should indeed look into cleaning up casper and make it faster :)
<cjwatson> mat_t: beware that we have a long-standing lack of translatability at this stage
<pitti> mat_t: simple matter of sending an usplash command
<pitti> mat_t: but no i18n
<pitti> right
<cjwatson> so while it's certainly possible you should be a bit careful about relying on it for everything
<mat_t> right
<cjwatson> ogra: fundamentally you have to get several hundred megabytes of data off slow media, there's a limit
<cjwatson> well, obviously you don't have to get *all* of it off, but a fair bit
<doko_> fta, asac: what is the name of the ubuntu-chromium-daily PPA? how do I turn on verbose logs?
<ogra> cjwatson, well, there is a lot of old cruft in casper
<mat_t> ok, let's go with pulsation then. I think it will provide a nice experience
<pitti> actually, I was quite surprised about how fast the live system boots from an USB stick nowadays
<cjwatson> sure, but cleaning it up isn't going to solve this problem really
<ogra> cjwatson, only talking about all the hooks and scripts we have
<pitti> heck, it's almost faster than booting my normal system from my slow HD..
<seb128> pitti, you have a fast usb key or something? it takes some minutes there
<ogra> there is stuff we carry along since breezy/dapper that totally isnt needed anymore
 * ogra plans a lucid spec for that
<pitti> ogra: we could perhaps get rid of reconfiguring X; locale configuration is also pretty slow, but still necessary; most of it should be fairly harmless, though, like setting gconf keys and doing small file changes?
<asac> doko_: https://edge.launchpad.net/~chromium-daily/+archive/ppa
<pitti> seb128: it's much faster than jaunty, anyway
<cjwatson> most of the slow stuff is still needed, I think :-/
<asac> doko_: https://wiki.ubuntu.com/Chromium/Debug
<doko_> asac: thanks!
<asac> http://code.google.com/p/chromium/wiki/LinuxDebugging
<asac> http://code.google.com/p/chromium/wiki/LinuxDebugging#Logging
<asac> doko_: ^^
<asac> ogra: udevadm info --query=all --path=/devices/pci0000:00/0000:00:08.0/net/eth2
<asac> something like that
<asac> what do you get?
<asac> (of course find your device)
<joaopinto> mvo_, software-center crashed rebuilding the app info cache during today's update
<ogra_> grrr
<asac> ogra: did you get my last message?
<ogra> nope
<joaopinto> known issue ? should I report it ?
<ogra> nothing since 12:08
<mvo_> joaopinto: hm, bad. could you please submit a bugreport?
<mvo_> joaopinto: I check it after lunch
<joaopinto> ok, done, bug 438639
<ubottu> Bug 438639 on http://launchpad.net/bugs/438639 is private
<joaopinto> Title: software-center crashed with DatabaseError in _database_gen_postlist_iter()
<pitti> ogra: would you mind filing a bug against usplash about the pulsating and assign it to me? (for post-beta tracking)
<ogra> pitti, will do
<ogra> asac, so what was your last message ?
<asac> one sec
<tkamppeter> pitti, I have found the following in io/hpmud/musb.c of the HPLIP source tree: http://pastebin.ubuntu.com/281172/
<tkamppeter> pitti, so it seems that libusb has a function to detach a device from a kernel module.
<pitti> tkamppeter: nice
<pitti> tkamppeter: I guess it unbinds the printer device from the usblp driver
<asac> 2:10 < asac> ogra: udevadm info --query=all --path=/devices/pci0000:00/0000:00:08.0/net/eth2
<asac> 12:10 < asac> something like that
<asac> 12:10 < asac> what do you get?
<asac> 12:10 < asac> (of course find your device)
<asac> ogra: ^^
<ogra> asac, no pci bus on that HW
<tkamppeter> pitti, I think so. And seeing these few lines it will be a rather small patch in the usb backend for CUPS. Once the usb backend patched this way we can stop blacklisting the kernel module.
<ogra> asac, its a virtual device and i think we had solved that in jaunty and it regressed now
<ogra> asac, http://paste.ubuntu.com/281190/
<asac> hmm
<pitti> tkamppeter: that would solve a lot of headaches indeed
<ogra> iirc you had a special patch for virtual devs
<tkamppeter> pitti, we only need to be careful to not detach the module for discovery, as discovery already happens if we do not use the usb backend (and want to use the backend from the manufacturer).
<pitti> tkamppeter: although, I'm not actually sure it would
<pitti> tkamppeter: since unbinding the printer from usblp would again break those ink level tools etc. which rely on usblp
<asac> ogra: sudo killall NetworkManager ... sudo NetworkManager --no-daemon 2>&1 | tee /tmp/nm.log.txt
<asac> wait a bit and post the log
<asac> (we dont have those patches anymore)
<ogra> asac, hmm, NM dies
<tkamppeter> pitti, for which printers are there usblp-based ink level tools?
<ogra> <WARN>  nm_dbus_manager_start_service(): Could not acquire the NetworkManager service as it is already taken
<pitti> tkamppeter: I bounced you the mail from Markus Heinz (was on pkg-cups-devel@)
<ogra> asac, that bug will likely hit us on dove as well btw, no exposed pci bus there either
<tkamppeter> pitti, escputil can send the ink level and maintenance requests into a print queue and then it should work with whatever backend is used for the printer.
<asac> ogra: you didnnt successfully killall NetworkManager if you get that message
<ogra> yeah
<ogra> it doesnt let me
<ogra> fun
<ogra> ogra@babbage2:~$ sudo service network-manager stop
<ogra> network-manager stop/waiting
<ogra> heh
<ogra> looks better now
<asac> ogra: killall usually works for me
<ogra> asac, not if upstart owns it and has respawn set ;)
<asac> hmm
<asac> maybe because i am quick enough ;)
<ogra> new world order
<asac> well. i am doing it everywhere still ;)
<ogra> http://paste.ubuntu.com/281196/
<tkamppeter> pitti, we must check for all these tools whether they are really needed. HP printer maintenance can be done with HPLIP, so no third-party tool is needed, escputil can act through print queues, so that way one can perhaps also work without usblp.
<asac> ogra: ok so its the not detected device driver
<ogra> well, its compiled in
<tkamppeter> I do not know which printers are really supported by libinklevel and which ones have no alternative to libinklevel.
<ogra> asac, what is device_creator() looking for ?
<tkamppeter> pitti, one should perhaps even make the CUPS usb module detach the printer before starting to access and reattach when done. This would be the ideal solution (the hp backend does not reattach).
<asac> ogra: http://paste.ubuntu.com/281198/
<ogra> hrm
<asac> ogra: you could put a udev rule that adds that label?
<asac> i think its safer to do that for your specific device id rather than allowing all that dont have drivers
<ogra> evil, but would work i guess
<ogra> asac, though it will bite us on all other armel systems too i guess
<tkamppeter> pitti, problem is that there is no "attach" function in libusb, and if one detaches more than one device at a time onr could probably no guarantee that they get attached to the same /dev/usb/lp* as before.
<pitti> tkamppeter: hm; seems that this would rip out more race conditions than it solves..
<asac> ogra: the regression we would get when allowing net devices without drivers is that all virtual devices get managed (like vmnet etc.)
<asac> ogra: so i think we need to explicitly whitelist vid/pid in rules somehow
<asac> but i will check with dan
<ogra> i'll ckeck with amitk_ if we can get a fake entry in there kernel side
<tkamppeter> pitti, I discovered the following comment in the HPLIP source:
<asac> ogra: can you install connman please and see if it labels your device properly?
<asac> ogra: like what i have here: http://paste.ubuntu.com/281205/
<tkamppeter> pitti: http://pastebin.ubuntu.com/281206/
<asac> if that works we can check what connman does
<ogra> will do, just rebooting to test a udev hack
<asac> kk
 * ogra just noticed he didnt have a 70-persistent-net.rules entry 
<tkamppeter> pitti, for that HP takes the vendor/product ID and gets the model name from their own database which comes with HPLIP. So the method does not work for non-HP printers.
<tkamppeter> pitti, so to get make/model/device ID of a USB printer one must claim it on one of libusb or usblp.
<mvo_> joaopinto: thanks
<tkamppeter> pitti, to not disturb any other backend (which could use the other method) the universal backend must be ready to discover and access the device with both methods.
<tkamppeter> pitti: It is possible to switch a device from usblp to libusb, but not from libusb to usblp, as the latter would not guarantee that the printer gets the same /dev/usb/lp* as it had in the beginning.
<pitti> tkamppeter: so my gut feeling is that we should only use one; seems that trying to use both dynamically just results in more error situations?
<seb128> ogra, what indicator session version do you use?
<seb128> indicator-session
<ogra> seb128, ogra@babbage2:~$ dpkg -l |grep indicator-session
<ogra> ii  indicator-session                   0.1.5-0ubuntu1                             An indicator showing session management, sta
<seb128> ogra, it's fixed in 0ubuntu2
<ogra> ok, thanks
<tkamppeter> pitti, an ideal CUPS USB backend goes through all printer devices identified as such by interface classes (07/01), then it should try to get the ID with libusb but without trying to detach the device. If the device is not accessible it should try to access via usblp. Same strategy when accessing to print.
<ogra> ubuntu2 wasnt on the image i used for install apparently
<seb128> it was uploaded this night
<pitti> my X.org has used 50% CPU for more than ten minutes now; I already killed firefox, but that wasn't it; is there a way to find out what keeps it busy?
<pitti> xrestop doesn't seem to tell me that
<AnAnt> htop ?
<pitti> AnAnt: the only real busy process is Xorg..
<pitti> oh, found it
<pitti> there was a runaway gdm-simple-greeter
<ogra> asac, meh installing connman via ssh = bad idea :P
<pitti> ArneGoetje: argh; something went wrong with the recent manual langpack upload
<pitti> ArneGoetje: e. g. language-pack-gnome-de-base only has a tiny subset of what it should have
<pitti> and desktop is now mostly in English
<ogra> asac, connman works
<pitti> ArneGoetje: did something go wrong with the tarball merging?
<tkamppeter> pitti, such an ideal USB CUPS backend should not be too difficult to code, all the code is already in the two USB backends of CUPS, one only needs to merge this code in the correct way.
<asac> ogra: yeah. i have to check that. but i assume that connman also would manage vmnet's
<ogra> might be ... its the first time i use it :)
<asac> ogra: connman is supposed to not touch your existing interfaces ;) ... at least according to marcel
<ogra> asac, you mean /e/n/i ?
<ogra> or which ones ?
<ogra> note that i removed NM from upstart and rebooted ... so eth0 is free
<ogra> (and i didnt touch /e/n/i)
<asac> ogra: no . connman claims to not touch anything that is already upped (not related to eni)
<ogra> ah, yes, the interface is definately down when i boot
<ogra> oh, you mean because of the ssh ?
<asac> ogra: my comment was about "ssh = bad idea"
<ogra> i indeed shot down NM and that teared down the interface it seems
<asac> yeah
<asac> ogra: i didnt want you to test connman ... rathher just see if connman adds those udev labels
<asac> you can have both running side by side because connman doesnt touch anything that is already up
<ogra> ah
<asac> (minus issues with wifi because connman fires up its own supplicant)
<ogra> udev output didnt change
<asac> ogra: so your device didnt get any CONNMAN_ labels (like what i posted?)
<ogra> asac, nope, didnt change at all
<ogra> http://paste.ubuntu.com/281226/
<asac> ogra: ok. means that connman wouldnt manage it either
<ogra> ogra@babbage2:~$ ps ax|grep conn
<ogra>  1436 ?        Ss     0:00 /usr/sbin/connmand
<ogra>  1450 ?        S      0:00 /sbin/dhclient -d -q -e BUSNAME=org.moblin.connman -pf /var/run/connman/dhclient.eth0.pid -lf /var/run/connman/dhclient.eth0.leases -cf /usr/lib/connman/scripts/dhclient.conf -sf /usr/lib/connman/scripts/dhclient-script eth0 -n
<ogra> well, it does manage it
<asac> /etc/udev/rules.d/92-connman.rules
<ogra> /etc/udev/rules.d/92-connman.rules: No such file or directory
<asac> http://paste.ubuntu.com/281227/
<asac> ogra: ^^
<asac> hmm. that should be /lib i guess
<ogra> 0.30+git.1.5b69740e1+dfsg-0ubuntu1
<asac> anyway. for me the /etc/ file exists ;)
<ogra> created by postinst ?
<ogra> its definately not in the package here
<asac> most likely not
<ogra> ogra@babbage2:~$ dpkg -L connman|grep rules
<ogra> ogra@babbage2:~$
<ogra> hmm, postinst only adds reboot notification
<ogra> http://paste.ubuntu.com/281228/
<asac> i would think you are struck by conffiles mechanism
<ogra> no udev rule
<ogra> ogra@babbage2:~$ cat /var/lib/dpkg/info/connman.conffiles
<ogra> /etc/dbus-1/system.d/connman.conf
<ogra> /etc/init.d/connman
<asac> yeah strange
<asac> anyway
<asac> so connman isnt a better example ;) ... it just manages all eth devices
<ogra> yeah, apparently
<asac> maybe we should make NM manage all eth devices
<ogra> well, i'll try to get amitk_ to add DRIVER to the actual driver
<asac> and allow packages that come with vmnet etc. to blacklist their individual things in udev rules
<ogra> well, if oyu match on the ethX naming ...
<asac> you can have all kind of names
 * ogra needs to test the next image, can i kill that install (wont be able to test stuff for 1.5h)
<asac> ok
<ArneGoetje> pitti: looking
<pitti> ArneGoetje: don't worry, it's all good
<ArneGoetje> pitti: puh...
<ArneGoetje> pitti: what was the issue?
<pitti> ArneGoetje: apparently they were unpacked in a bad order; but that's not something we changed recently
<pitti> I installed some test packages manually, that might have screwed it up
<ArneGoetje> pitti: right
 * ogra carefully knocks on LP ...
<ogra> is there still life in it ?
<highvoltage> ogra: I can point you to some good LP support?
 * beuno pokes the sysadmins about LP
<highvoltage> ogra: I mean, I could point you to some real good LP assitance
<ogra> seems to work atm
<beuno> *very* slow
<highvoltage> (*sigh* I wish someone would take the bait for once so that I could paste http://photos.jonathancarter.co.za/v/paris2006/800_PICT0125.jpg.html)
<ogra> asac, amitk_ bug 438687 ... feel free to have a foodfight about on which end it needs fixing :)
<ubottu> Launchpad bug 438687 in network-manager "FEC driver does not set "DRIVER" property in udev which makes network-manager fail" [High,New] https://launchpad.net/bugs/438687
<asac> imo it needs to be fixed on the vmnet drivers
<ogra> vmnet ?
<ogra> do i need to add another package ? :P
<asac> everything that provides "ethernet" devices that shouldnt be managed should ship their own udev rules somehow
<asac> i dont know
<amitk_> ogra: looks like YOU get to fix it in that case :-p
<ogra> meh
<ogra> amitk_, how would i add such a udev rule to the kernel package ?
<amitk_> though I can look at the DRIVER property and fix it if it isnt too hard. (right after dealing with RTC)
<asac> amitk_: do you know if those DRIVER properties always go away if you link stuff statically?
<asac> would be great if everything had a driver;)
<ogra> amitk_, do we know about a single board in the company where the battery is working for sure ?
<ogra> amitk_, i'm not sure its not caused by my battery
<amitk_> asac: not sure. But it sounds like the driver didn't provide it in the first place.
<ogra> i see it on the dove board btw
<ogra> though the driver sits under platform, not virtual
<amitk_> ogra: see what?
<amitk_> ogra: it does see like a problem with your board.
<ogra> amitk_, DRIVER in udevadm output
<ogra> ??
<ogra> my bopard is running with your kernel .. the driver doesnt export the property
<amitk_> My board survived being powered off for over 3 days (stopped working on it in Portland on Friday). And i see the correct date and time now
<amitk_> ogra: I meant RTC
<ogra> oh, you switched topics :)
<ogra> yeah
<amitk_> sorry
<ogra> thats what i mean, but i dont know the value of the battery to replace it ... and i'm still irritated that i dont see any charge power
<amitk_> ogra: I will measure the charge power. But in this case I suspect your battery is too dead to be charged.
<ogra> there is nothing printed on it ... so i wouldnt even know the voltage/kind of battery i need to buy
<amitk_> ogra: btw, even my ethernet came up automagically
<ogra> with NM ?
<amitk_> nope
<ogra> it surely works with /etc/network/interfaces
<ogra> its just the NM part thats missing
<amitk_> I had the ethernet cable plugged in and it autonegotiated with dhcp (serial console)
<amitk_> 'iface eth0 inet dhcp' in /etc/network/interfaces, that is
<ogra> yeah, that definately works
<ogra> connman works too
<ogra> just NM doesnt because it looks for that property
<amitk_> *sigh*
<amitk_> ok, I'll look at it. But I am tempted to mark the RTC bug invalid
<ogra> lets see if we can get confirmation it works from someone else first
<amitk_> ogra: you did get confirmation! From me :)
<ogra> we have enough boards, if yours works there sdhould be at least one other one
<joaopinto> does it make sense to report such an obvious bug like flash failing to install from firefox plugin finder service ? Does anyone know a bug report about it ?
<doko_> lool, seb128: Is this meant to be applied for armel as well?
<doko_> gst-plugins-base0.10 (0.10.9-2) unstable; urgency=medium
<doko_>   * Don't build the doc on arm and m68k.  It's painfully long, and -- at least
<doko_>     on arm -- it segfaults; this is to lower the impact of #383147.
<doko_>   * Update TODO list.
<doko_>  -- Loic Minier <lool@dooz.org>  Sat, 19 Aug 2006 23:25:01 +0200
<doko_> currently ftbfs on armel, but unsure if that's releated
<seb128> doko_, no idea, I didn't try on armel if the issue shows there
<doko_> dh_installinfo -pgstreamer0.10-plugins-base-apps
<doko_> dh_installinfo: dpkg-architecture failed
<doko_> make: *** [binary-install/gstreamer0.10-plugins-base-apps] Error 1
<doko_> I'll try a rebuild first
<ogra> doko_, gst-...-good currently chokes on the dh-shlibs issue
<ogra> because of graphviz and libshout
<doko_> ogra: which I fixed on Sunday. wake up ;p
<ogra> oh, i thought you only fixed it in debian yet :)
 * ogra wasnt aware it was in ubuntu already
<pitti> stgraber, highvoltage: is edubuntu purely a DVD nowadays? I can't find dailies on http://cdimage.ubuntu.com/edubuntu/
<davmor2> pitti: as I understand it yes.
<highvoltage> hmm, there was dailies recently
 * highvoltage checks
<highvoltage> pitti: http://cdimage.ubuntu.com/edubuntu/dvd/20090929/
<highvoltage> pitti: yes, purely a DVD
<pitti> highvoltage: ok, thanks
<pitti> added to tracker
<highvoltage> thank you pitti
<lool> doko_: What was the buildd with the dpkg-architecture bug?
<lool> doko_: I've seen that segfault on the new arm board
<doko_> lool: sorry, I didn't write this down
<tkamppeter> pitti, I have tried to merge the two USB CUPS backends together, but I have found another problem: The two backends coming from the same version of CUPS produce different URIs for the same printer.
<pitti> tkamppeter: right, that's what I meant with "not break everyone's printers on upgrade"
<pitti> there are several reports about that
<lool> doko_: disabled doc building on armel too; thanks
<tkamppeter> pitti, it looks like a bigger problem: The simplest solution to make everything just work is to keep the usblp version of the CUPS backend, but on the other side there are several advantages in favor of switching to the new technology: The three I mentioned earlier and the possibility to get the serial number from every printer, even if the device ID does not contain it.
<hunger> LP is getting more confusing each time I try to use it:-(
 * hunger wonders why he can no longer report bugs there.
<tkamppeter> pitti, the new backend needs to made tolerant in accepting URIs when printing, especially accepting URIs where serial number and/or interface are missing.
<cjwatson> hunger: while I don't like the current form, the wiki page it redirects you to does have instructions if you read down a bit
<pitti> tkamppeter: serial number is if you have more than one printer of the same vendor/product?
<hunger> cjwatson: Yeah, I tried the first couple of things and they do not work here:-(
<hunger> cjwatson: They seem to be tailored to ubuntu, not kubuntu and particularly not some customized kubuntu like I always end up using:-(
<cjwatson> hunger: read further down :-/
<cjwatson> hunger: it does include a URL hack
<hunger> Yes, I just saw that.
<tkamppeter> pitti, yes, that is the reason why we want to have serial numbers in URIs for USB printers.
<tkamppeter> piit, the number of use cases is small but not zero.
<hunger> cjwatson: I keep up ending on the bug reporting "help" wiki page whatever I try to do. Sorry, I seem to be too stupid to report bugs.
<Riddell> hunger: run   ubuntu-bug <packagename>
<hunger> Ah, I missed the blindingly obvious ?no-redirect.
<hunger> Riddell: krunner does not let me do that.
<Riddell> hunger: what kubuntu version are you running?
<LaserJock> was there any idea of when they were going to change it back so you can file with +filebug as normal?
<LaserJock> it sounded like it was just going to be a temporary thing to gain some stats or something
<jdstrand> ttx: I just saw your comment in bug #438747
<ubottu> Launchpad bug 438747 in eucalyptus "Instances with a public IP do not run" [High,Triaged] https://launchpad.net/bugs/438747
<ogra> pitti, you wanted bug 438762 assigned ?
<ubottu> Launchpad bug 438762 in usplash "should show some kind of indication of system being alive during livesession boot" [Medium,New] https://launchpad.net/bugs/438762
<pitti> ogra: please
<jdstrand> ttx: are you guys using dhcp3-server?
<ogra> done
<ttx> jdstrand: meeting, can't talk right now
<hunger> Riddell: karmic.
<jdstrand> ttx: well, when you get back, feel free to respond. I ask because if you are, you are likely going to need to adjust the dhcpd3 apparmor profile to deal with /var/run/eucalyptus/net/euca-dhcp.conf
<hunger> Riddell: But I do tend to move most of the ubuntu specific recommended stuff.
<jdstrand> ttx: we can easily add that path to the package so it works out of the box
<kees> doko_: what's needed for libelf 0.8.12?
<kees> doko_: (I assume post-beta?)
<doko_> kees: a FFe
<kees> doko_: okay, cool;  -0ubuntu1, or do you think Debian will close their 548865 bug you just opened?
<doko_> kees: I have a -0ubuntu1 which I can upload
<kees> doko_: ok, cool.
<doko_> gah, subscribed the wrong motu team
<alkisg> gnome-power-cmd shutdown is no longer there in Karmic, how would a script poweroff the PC without having sudo rights? (talking about https://bugs.launchpad.net/ubuntu/+source/italc/+bug/367960)
<ubottu> Launchpad bug 367960 in italc ""power down" request fails on 9.04; logout instead" [Undecided,Confirmed]
<smoser> slangasek, http://paste.ubuntu.com/281408/ has the amis for beta candidates
<smoser> am i able to update iso tracker or does someone more worthy have to ?
<beuno> pitti, pin
<beuno> ping even
<beuno> pitti, there's a, what i'd consider a critical issue with gdm that I'd like to discuss
<beuno> we pre-select the user, so it's not clear what they should do
<beuno> that's bad, but what's really bad, is that if you start typing your password (assuming it's selected), it shows what you're typing in clear text
<beuno> I'm guessing it's trying to search or some default gnome behavior
<cjwatson> isn't that username selection?
<cjwatson> i.e. so that I can type 'cjwatson' rather than having to reach for the mouse
<beuno> cjwatson, maybe, but since it shows me the text I'm typing, it feel insecure
<beuno> if we didn't select the user by default, it would be less likely that users assume they should type, although I think we shouldn't show you the search text all together
<beuno> they may be orthogonal issues, but piling them up is a bit concerning  :)
<cjwatson> hmm, I haven't noticed a user being selected by default
<beuno> not sure what the criteria is, maybe the first one on the list
<cjwatson> it doesn't do that at all for me
<beuno> you click on it, and it brings up the password field
<beuno> I just did this on a fresh karmic install
<cjwatson> it shows the username, but it is not selected
<beuno> do you have more than 1 user?
<cjwatson> perhaps the UI is confusing if you only have one user; there are several here
<beuno> right, I think that's the case
<cjwatson> anyway, I would like to request that the fix for this not involve breaking username selection via the keyboard
<beuno> sure, I don't see why we would have to break keyboard navigation at all
<cjwatson> the reason, I think, why keyboard username selection needs to show the text right now is that it lets you select by username not by full name
<cjwatson> i.e. I don't have to type in a prefix of "Colin Watson"
<cjwatson> and so it'd be a bit confusing to jump around in the list depending on username prefix without showing you the text
<beuno> I agree, but I think it's safe to guess the people using the keyboard and with more than one user is a pretty small subset of people
<cjwatson> perhaps if it were more explicit that you *can* type in a username, rather than it being a hidden feature ... but I thought that was removed deliberately
<beuno> maybe it's not one or the other, but I'd rather we drop the text from the screen if we have to pick one
<cjwatson> I don't think either of us have any evidence on which to base a conversation about that assertion
<bgamari> It seems that there is something quite wrong with the firefox-3.5-dbg package
<cjwatson> "more than one user" is common for family computers, so that at least is not in itself a corner case
<bgamari> /usr/lib/debug/usr/lib/firefoxd-3.5.3/firefox has no symbols in it according to nm
<beuno> cjwatson, right, but more than one user *and* keyboard selection?
<cjwatson> but beyond that, we have no data
<cjwatson> (as far as I know)
<beuno> either way, lets discuss that *if* it's one or the other
<cjwatson> beuno: *shrug* all I know is I use it ;-)
<beuno> is pitti the right person to talk to about this?
<beuno> cjwatson, so we'll make sure you can still use it!
<cjwatson> I am happy to be dismissed as a corner case if there is actually evidence that I am
<pitti> beuno: pong
<beuno> cjwatson, you should probably still be able to find-by-typing, but maybe just not display the text on the screen
<beuno> pitti, hi!
 * pitti reads backscroll
<cjwatson> beuno: do you not think that would look pretty bizarre?
<beuno> cjwatson, yes I do
<pitti> beuno: what's the problem, gdm having an username input box? I'm afraid I don't quite understand what the problem is
<beuno> pitti, so, when you only have one user
<beuno> it's selected by default
<pitti> right
<beuno> that's confusing in itself, because it's not clear that you have to click a selected item
<beuno> on top of that, if I assume that since it's selected I should just type my password
<pitti> well, you can also just type your user name, as in the past 50 years of unix history
<beuno> as I type, a search box comes up and shows me what i'm typing in clear text
<pitti> right, I read that
<pitti> the user selector right now is just a way to shortcut the user name entry
<beuno> I understand that
<pitti> I'm indeed not really happy about how it looks nowadays
<pitti> but the face browser didn't land in time
<beuno> ok, good, that's a start
<beuno> can we not select a user by default?
<beuno> that would improve the situation already
<pitti> beuno: we could theoretically
<pitti> but then you'd have to look harder
<pitti> whether it's a password or username prompt
<pitti> so far you'll always have an user name prompt
<pitti> so it's confusing either way, I think
<cjwatson> speaking of keyboard navigation, I wish we hadn't made it completely non-obvious how to restart the computer using the keyboard
<beuno> pitti, can we show the password prompt, with focus, if there's only 1 user?
<cjwatson> apparently nobody designing this stuff is worried about RSI :)
<beuno> that would be the best solution, I think
<pitti> beuno: theoretically yes; it's similar to what should happen if you select another user in the user switcher applet
<pitti> it just doesn't work, you always get the user picker
<beuno> pitti, so what's the best way to make that happen?  bug report?
<beuno> I have the whole design team looking at me waiting for an answer  :)
<pitti> sure, bug reports are always good
<pitti> however, we have tons of release-critical bugs still to fix, so please don't hold your breath
<beuno> and the karma is nice
<pitti> there's a relatively low chance of getting this fixed in karmic
<beuno> hm
<beuno> do we auto-login by default?
<Ng> beuno: can I humbly suggest epic care in this regard, to avoid people typing their username into the password field, getting bounced back to a username field and typign their password in the clear ;)
<Ng> I've seen people get confused by what state the login screen is in and do that sort of thing :/
<beuno> yes, I've done it myself
<beuno> it's a good point
<pitti> beuno: you have to select that in the installer (auto login/manual)
<cjwatson> we do not auto-login by default, although there is an option in the installer to do so
<beuno> pitti, can we "not select by default" for karmic?
<pitti> beuno: that's what I actually meant (what Ng said)
<pitti> beuno: in the past 50 unix years, people have become conditioned to type username/passwordr
<beuno> yeah, Ng has a good point
<pitti> now it's inconsistent
<pitti> I mean, it will be, if we do what you propose
<beuno> agreed, I will take this back to the design team to have a better plan for Lucid
<beuno> but, can we not select it by default?
<beuno> you have to click on the username anyway
<beuno> and clicking on something that is already selected is not an expected pattern
<pitti> no, you can just press enter
<pitti> it is selected by default already; doesn't that work for you?
<beuno> it does
<pitti> I always just press enter, then type my password
<beuno> I *don't* want it selected
<pitti> oh
<beuno> so it's clear I have to click on it
<beuno> if it's selected, you don't feel compelled to click on it
<pitti> well, right now you don't have to click on it..
<beuno> you do if you're the average person who uses a computer
<beuno> who uses the mouse as much as possible
<beuno> we present you with a graphical screen with options, people will interact with it with their mice
<beuno> if we gave them a terminal, sure
<beuno> I understand the history behind this, and we don't want to annoy people who ahve be using unix for 40 years
<beuno> can we come up with something that works for everybody?
<beuno> ...and that can be implemented for karmic
<pitti> well, the current state does work for everybody, it's just that you want it to work differently :)
<pitti> right now, it's either click/type password, or enter/type password
<pitti> or type user/type password
<pitti> so from what I understand, you wnat to eliminate the second option
<sistpoty|work> if you can just press enter, it would make sense to also prefill the username box with the selected username?
<beuno> I don't want to eliminate any behavior
<pitti> sistpoty|work: could do, if the text is selected
<pitti> sistpoty|work: we don't want to break the 3rd option
<cjwatson> sistpoty|work: it's not a box with an allocated location on screen - it's a search box that only comes up while you're typing
<sistpoty|work> pitti: yep
<beuno> I want us to make it clear what the user needs to do on the first screen they will get when they instlal ubuntu
<cjwatson> sistpoty|work: like a GTK list search
<beuno> the current way it works, exposes their password
<pitti> beuno: oh, so you want to add a real input line for the user?
<beuno> that's not a great experience
<sistpoty|work> cjwatson: ah, I see (/me is a xdm user *g*)
<beuno> pitti, I'm trying really hard not to prescribe a solution here
<pitti> beuno: well, I'm still in the "understand the problem" phase TBH
<beuno> just to figure out what would make you everyone happy
<beuno> pitti, the critical issue for me is that the way we're presenting it right now, can lead up to people exposing their password
<beuno> if someone sees it, it's a problem for them, if it's just them, they will feel insecure
<beuno> we look bad either way
<beuno> we can tackle this in different ways
<djsiegel> beuno: the issue is that we show list of users, and a username text entry?
<beuno> one of them is making it so the screen doesn't imply that you're user is selected already
<pitti> djsiegel: we don't have an username text entry
<beuno> djsiegel, no, lets stick with the only-one-user case for simplicity
<beuno> it's that we show the users' name
<beuno> selected
<beuno> in a list
 * pitti -> desktop meeting; following with half an eye
<beuno> and what the user needs to do, is click on an already selected item
<beuno> which is not obvious
<beuno> I've done this test with 4 different people now
<TomaszD> the new gdm UI is not designed very well. Why, if the first user is preselected, doesn't the Password dialog come up anyway without user interaction?
<TomaszD> this is really, really weird to me.
<beuno> present them the gdm, and ask them what they need to do now
<djsiegel> beuno: so, it looks selected but is not?
<beuno> *none* of them could guess without playing
<beuno> djsiegel, it is selected, but only so you can hit enter to get a password field
<beuno> so yes, it's selected but it's not, to the user
<beuno> djsiegel, so, if the user assumes it's selected, and we need their password
<djsiegel> beuno: ah, and we just select the first user in the list?
<beuno> if they type
<pitti> tedg: when you select a user in i-s, gdm comes up with the user picker, instead of the user being preselected; is that a gdm or i-s bug?
<pitti> (it's related to this discussion here)
<beuno> their password appears in clear text on the screen, because we assume he is searching for a username
<TomaszD> beuno, wouldn't it be better to have the Password field displayed for the preselected user, rather than not select any user by default?
<beuno> djsiegel, yes
<beuno> TomaszD, yes, I think that's what I'd prefer at this point, although Ng had a good point about people typing their username into it
<djsiegel> so, what we really need is the user to complete the task of picking a user, then complete the task of entering a password, and make sure they strictly observe that order
<tedg> pitti: I think it's a feature that gdm doesn't have.
<djsiegel> or else they will expose the password
<TomaszD> beuno, but it makes more sense than the current design anyway
<beuno> yes
<pitti> tedg: ok, too bad; the old one had it
<TomaszD> the current design makes no sense at all.
<siganderson> do anybody know why there is nomore serivces-admin (the service manager) in karmic koala?
<djsiegel> beuno: what can we do to make it clear that they must pick a user, and not type a password?
<pitti> siganderson: we killed it because it was already utterly broken before, and now with upstart it doesn't work at all
<beuno> djsiegel, half way there is not selecting the user, and maybe telling them to?   I can't remember if we do, althought I feel that if we're having to explain, "we're doing it wrong"
<siganderson> pitti, will it be restored in the beta version?
<TomaszD> what I find horrifying is how the dialog window elements move around and pop up from nowhere, there should be a law against it. It confuses the hell out of new users. But that's a different story.
<djsiegel> beuno: they will not read any messages
<pitti> siganderson: no plan for this; it needs some heavy upstream work
<djsiegel> beuno: so we could hide or disable the password field
<djsiegel> I prefer hide, because disabled looks strange
<beuno> djsiegel, it is hidden today
<siganderson> pitti, ok thank you
<beuno> and it shows up when you click on the already-selected user
<djsiegel> beuno: and people are typing their password without seeing a field?
<djsiegel> beuno: so what is the problem exactly?
<TomaszD> yeah, I don't understand the argument here really
<beuno> djsiegel, it's 2 problems
<beuno> 1. It's not obvious what the user needs to do, our visual cues tell them that their username is already selected
<TomaszD> true
<beuno> 2. If they decide to assume that that step is done, and they need to type their password, it shows up in clear text
<djsiegel> 1. so we need to make it obvious that nothing is selected yet, right
<djsiegel> ok
<TomaszD> but I can't believe that people click on an already selected username, see the password field... and type in your username
<beuno> I'm not saying that 2. is something that will happen a lot, but when it does, it will be very bad
<djsiegel> make it obvious that no user is selected yet
<beuno> 1. makes 2. worst, but they are orthogonal in a way
<beuno> yes
<djsiegel> it takes an advanced user to hit enter
<beuno> correct
<djsiegel> they may try hitting enter in the absence of a visual cue
<beuno> that was my argument to pitti and cjwatson
<cjwatson> TomaszD: it would be more likely if we displayed the password prompt before giving them the opportunity to select username
<djsiegel> so they don't lose that featyre
<djsiegel> feature*
<cjwatson> djsiegel: err. I think you need some more levels in between novice and advanced, there!
<djsiegel> cjwatson: I have more levels, I am just making a rough decision here
<djsiegel> :)
<djsiegel> rules of thumb
<beuno> I'm certain we can find a solution that makes everyone happy
<TomaszD> I would personally go for either 1) no-one selected, password field visible and disabled, or 2) pre-selected user, password field visible and enabled
<beuno> but we have to figure it out together:  what can be done by karmic, and what addresses both use cases
<TomaszD> it does not make sense to hide the password field, the window needlessly jumps around
<pitti> a complete redesign is too late for karmic, but in the lucid range
<pitti> small tweaks can still be done, but we are in UI and beta freeze, mind you
<beuno> pitti, ok, so let's not do a complete redesign, but we need to do something for karmic
<TomaszD> so make the password field visible and focused by default
<pitti> also, we don't have time for that in the desktop team any more, I'm afraid (external contributions welcome, of course)
<beuno> yes, I am aware of it
<TomaszD> not that big of a change, a lot of help though
<djsiegel> beuno: so, what is the objection to (1) a list of users with uniform visual treatment (none looks selected)
<pitti> beuno: well, we could also just do it properly in lucid..
<djsiegel> 2. show the password field once user has made a selection
<beuno> djsiegel, I have no objections, pitti does
<beuno> that enter will not work then
<djsiegel> how is enter used?
<djsiegel> when there is a single user?
<beuno> boot, enter, password
<djsiegel> make enter still work
<pitti> djsiegel: well, it's not a hard objection, but right now you can just press enter, type password, go
<djsiegel> just don't select a user in the list
<pitti> that would magically select the first one?
<beuno> yes, that would work, if it's possible to do
<djsiegel> pitti, sure
<djsiegel> pitti: or enter could be made only meaningful when one user is available
<djsiegel> that might be smarter
<djsiegel> making it always do the first seems arbitrary
<djsiegel> but on a single user system
<djsiegel> make it choose the only choice available
<ScreamerX> hello
<TomaszD> wait a second... if there is only one user available, why would you not display the password field by default?
<ScreamerX> is there any key combination that puts my fullscreen opengl application into background?
<TomaszD> it seems absolutely unnecessary to either click or hit enter when there is only one choice to be made
<djsiegel> TomaszD: yes, good question
<beuno> TomaszD, right now, because we need to do something for karmic
<beuno> so lets do what we can, but lets do something
<beuno> and, for lucid, we'll kick ass
<djsiegel> TomaszD: you're right, we should show something different for single-user systems, but that might require some heavy lifting
<beuno> user test it, etc
<TomaszD> djsiegel, not much different, just the password field visible, focused.
<djsiegel> we got a paper cut the other day "typing my password is annoying, I should never have to do it"
<beuno> TomaszD, if we focus it, we may run into what Ng said, which is valid for old-time linux users
<beuno> so we need to back up the change with data
<beuno> that change at least
<djsiegel> beuno: I would not worry about 50-year UNIX veterans being confounded by our GUI...
<TomaszD> beuno, old-time linux users tend to read what's on the screen
<djsiegel> not a significant use case to design for
<TomaszD> I would not really worry about them
<cjwatson> 50-year Unix veterans - how about the last five years of Ubuntu users
<ScreamerX> i am slackware user
<beuno> TomaszD, they read the least
<cjwatson> that is perhaps a slightly better and less hyperbolic example
<beuno> cjwatson, that's kind of what I meant
<beuno> all our current userbase
<TomaszD> I've used Ubuntu for the last 5 years and when I see a new login dialog I read what's on there
<cjwatson> exactly
<djsiegel> cjwatson: don't accuse me of being hyperbolic, i was just quoting what someone said earlier!
<djsiegel> :)
<TomaszD> especially if's just my username and "Password:" field
<cjwatson> djsiegel: I know, but it's still a better example
<beuno> ok, back to the issue
<djsiegel> sure
<djsiegel> what are we talking about anyway?
<djsiegel> people who will type their username into a password field?
<beuno> can we not select it, and enter auto-selects the first user?
<beuno> no change in behavior, and we address the bulk of this issue
<mvo_> Riddell: I see a update-manager commit from 28 sep - I fixed the problem there on 25th, was your tree outdated? or did I miss anything with the fix?
<mvo_> Riddell: nevermind, found it
<TomaszD> anyway, at least now I know what's been freaking me out about the new gdm *and* I know that the enter key works, don't have to reach for the mouse
<TomaszD> :)
<Hatl> is there a way to minimize a fullscreen opengl application?
<beuno> pitti, let me know when you're back so we can make sure this is on someone's plate for karmic
<Amaranth> Hatl: ctrl-alt-d (if you're using compiz)
<pitti> beuno| can we not select it, and enter auto-selects the first user
<pitti> beuno: if you think that helps, it sounds doable for karmic
<Hatl> Amaranth: im using kde. but the kde-shortcuts don't work
<Amaranth> Hatl: Well, this is more of a question for #kubuntu (and I have no idea)
<pitti> beuno: it just doesn't appear to me as making the dialog less confusing (since it's not how gtk lists usually work)
<Hatl> Amaranth: ok :)
<djsiegel> pitti: I thought our goal was not to make the dialog less confusing, but to satisfy the use case of pressing ENTER on single user systems, and to avoid giving users the impression that a default user is selected in the list by not highlighting any without explicit user action.
<pitti> djsiegel: ok; so that's the karmic goal, and for lucid we'll turn it upside down then?
<djsiegel> I guess that does make it less confusing (not highlighting so users don't get the impression that it's time to type the secret code)
<djsiegel> pitti: what are we turning upside down? I am not sure.
<pitti> djsiegel: perhaps in lucid we'll get the real facebrowser, then we can get rid of this user chooser entirely
<pitti> djsiegel: like, redesigning the entire thing
<beuno> pitti, for lucid, we will do research and come back with data so we can find a screen that makes everyone proud
<beuno> pitti, so I'll capture this in a bug and assign to...?   :) :) :)
<pitti> beuno: good question; as I said, we already have more critical bugs in the desktop team than we can possibly handle
<pitti> beuno: not making the first user selected is easy; making enter magically work requires more intrusive code, since it's not how gtk lists are working
<beuno> pitti, so it's a prioritization issue. Who prioritizes?
<pitti> beuno: for desktop, basically rickspencer3 and me
<seb128> I guess the change you want is not trivial
<seb128> if the first item is not selected it will not react to key events
<rickspencer3> what exactly is going on?
<seb128> needs some tweaking
<Amaranth> hmm, you could look for keypress events on the GtkWindow?
<rickspencer3> I thought we were past beta freeze
<rickspencer3> we should be removing features that don't work well, not adding to them
<pitti> let's remove gdm :)
<djsiegel> pitti: here here
<rickspencer3> hehe
<seb128> rickspencer3, seems they want the list to have an empty selection but act as if there was a selection
<beuno> rickspencer3, hi  :)
<pitti> djsiegel: (this thing gave us nothing but trouble anyway...)
<seb128> which is a non standard widget behaviour...
<djsiegel> seb128: some element has input focus -- the window? It just has to pick the first user in the model and continue.
<cjwatson> just as a point of terminology, beta freeze is the period that runs from the week before the beta release until the beta release
<rickspencer3> uh, can users log in as it is? I mean functionally?
<cjwatson> after the beta release, we go back to feature freeze status
<cjwatson> (and UI freeze etc.)
<pitti> rickspencer3: yes
<djsiegel> no need to hack the list widget
<Amaranth> rickspencer3: yes but they have to know they have to click on the thing that is already selected
<rickspencer3> if we are going to replace GDM with our own UI in Lucid, mucking with it after beta freeze is illogical
<pitti> if we are fine with droppping the "just press enter to select first user" behaviour, it's a simple change
<rickspencer3> that;s unfortunate, but it doesn't crash
<rickspencer3> we need to *prioritize* now
<beuno> rickspencer3, can we have a quick call so i can explain this?
<rickspencer3> beuno, I don't think I have time for that
<rickspencer3> we have four weeks until we *ship*
<beuno> rickspencer3, I understand
<pitti> (more like three)
<rickspencer3> we need to be crystal clear on priorities
<Amaranth> changing it to not select any user is a simple enough change
<beuno> rickspencer3, this is a big problem, with a potentially very simple solution
<rickspencer3> I can't see something that is annoying like this raising to the level of a change that we would introduce
<Amaranth> slows down power users a bit but makes the interaction clearer
<beuno> rickspencer3, this is *not* an annoying issue
<rickspencer3> beuno, how many things are like that on the desktop?
<pitti> Amaranth: right, what I said
<beuno> rickspencer3, this is a situation where we end up showing the users password in creal text
<beuno> rickspencer3, so, I'll start explaining it *again*
<Amaranth> d'oh, the user list has searching
<seb128> beuno, well your suggested change will not fix that password issue
<pitti> I'm fine with just dropping the first selection
<rickspencer3> is this caused by the the default answer is "no"
<beuno> seb128, it will make it less likely. Ideally, we would not show clear text at all
<rickspencer3> at some point we have to stop making changes and start fixing bugs
<rickspencer3> that time is defined to be weeks ago
<pitti> beuno: if you have many users, you certainly want typeahead search; using the mouse with more than 5 users will kill you
<beuno> pitti, I agree, which is why I'm comprising here
<seb128> pitti++
<beuno> comprimising even
<beuno> I don't want to break anyone's use case, and I want this fixed for karmic
<pitti> beuno: so, if we just drop the initial selection?
<djsiegel> pitti beuno seb128, dropping the selection seems important, but ENTER to pick single user is not
<Amaranth> if you drop the selection you lose the typeahead
<seb128> having to use the mouse is annoying
<djsiegel> as seb128 and rick point out
<rickspencer3> this is for machines with how many users?
<pitti> Amaranth: oh?
<djsiegel> Ah, you lose typeahead when you drop selection?
<djsiegel> \
<pitti> rickspencer3: 1
<Amaranth> pitti: the list has to be focused for that to work
<pitti> Amaranth: you can still focus the list, but not select the first entry?
<djsiegel> You can focus a list without selection
<rickspencer3> this only impacts people who have one user on their machine, or one or more?
<djsiegel> At least from code
<djsiegel> maybe not with a mouse
<pitti> rickspencer3: by and large one
<seb128> I fail to see that as an important issue to be honest
<cjwatson> unless this is just me, if you have more than one user then there's no default selection
<rickspencer3> I can't believe we are even discussing mucking with gdm at this point
<seb128> other distro are shipping with that screen for several cycles and nobody really complained during karmic
<cjwatson> yay, I think I just got wubi working
<djsiegel> cjwatson: it's not just you
<pitti> cjwatson: you rock!
<cjwatson> it forgot my real name, but aside from that ...
<beuno> rickspencer3, mt said he reported this ages ago, and it did not bubble up. It's most likely a failure in our team to communicate, I'm sorry about that
<asac> pitti: dont forget nm ride-along :)
<pitti> asac: yep
<asac> (for wubi)
<beuno> rickspencer3, so, not going to happen?
<beuno> I need to report back
<rickspencer3> beuno, right
<beuno> rickspencer3, even with a trivial fix?
<asac> beuno: we first have to see that trivial fix. from the discussion above it felt there is no trivial fix
<seb128> beuno, if somebody add a patch to the bug we will review it
<seb128> beuno, but we are not going to work on it
<beuno> ok, I'll report that back
<seb128> I still fail to see that as an important issue, it seems to confuse no user so far
<seb128> based on feedback we got during the cycle
<beuno> seb128, I've said this 3 times
<beuno> I've done this with 4 users already
<beuno> sat them down on the laptop
<beuno> with GDM
<beuno> and asked them what they had to do now
<beuno> NOBODY KNEW
<beuno> this *is* a problem
<beuno> wether it's critical or not to you, it's different
<beuno> we are olishing ubuntu making it nice to use
<beuno> this is a critical part of that
<beuno> the first screen you run into
<beuno> the fact that everyone is being snarky about it does not help *anyone*
<seb128> nobody is being snarky there
<seb128> but it's amazing that nobody raised that before beta if that's such an issue and so obvious
<beuno> it's a critical bug in Ubuntu
<beuno> seb128, I have raised this multiple times, it just hasn't bubbled up
<beuno> which is why I'm here
<beuno> I will file the bug, as critical, as it's a bug, not a feature
<seb128> there is a bug open
<beuno> #?
<seb128> couldn't you look for the number?
<seb128> it would take you as long to find it as it will take me
 * seb128 searches the number
<beuno> bug #410337
<ubottu> Launchpad bug 410337 in hundredpapercuts "Log in screen is confusing, not clear what to do" [High,Triaged] https://launchpad.net/bugs/410337
<beuno> look at that
<beuno> reported by me, almost 2 months ago
<seb128> yes
<seb128> I know about it, I triaged it and set it upstream
<beuno> ok, so this has been on the plate for a while
<beuno> I stated the user testing in the bug
<seb128> I've added a comment saying that enter works as suggested for me
<seb128> but nobody followed up or commented
<beuno> using the keyboard is *not* the common case
<seb128> right but the description didn't suggest any change
<beuno> there's a wiki, and a suggestion, and a mock up
<beuno> rickspencer3, ^
<beuno> this no longer is "this just popped up"
<beuno> yes it did
<beuno> and comment #1 does it precisely
<Amaranth> So... if I make this patch will it be considered? Should be simple to do the not selected part at least
<mdz> kirkland, I seem to have missed ttx. can you update me on eucalyptus wrt beta?
<beuno> and it's *exactly* what we're asking for now
<seb128> "The user name displayed at the top of the list should not be selected by default. Pressing Enter should result in selecting the user from the top of the list, unless any other menu item or button has been manually highlighted."
<seb128> that?
<Amaranth> Making enter still work is more complicated but not much so
<seb128> beuno, I fail to understand why not selecting an user will solve the fact that it's not obvious what to do
<Amaranth> I've poked into gdm code recently, mostly know my way around
<seb128> beuno, and the "Pressing Enter should result in selecting the user from the top of the list, unless any other menu item or button has been manually highlighted."" already works
<rickspencer3> seb128, beuno I don't see how this could have been in Karmic so long without this coming back as a "Critical" issue from usrs
<pitti> Amaranth: yes, as we already said, patches will be considered, and are appreciated
<rickspencer3> and secondly, we are past beta freeze
<pitti> Amaranth: my main concern is that we don't really have spare time in the desktop team, but contributors are always welcome
<rickspencer3> at this point, every change is considered risky, and must be traded off against fixing crashers
<rickspencer3> pitti, but even a "trivial" change takes some work ...
<pitti> rickspencer3: well, if someone makes a patch who wouldn't otherwise fix bugs, it's not really a tradeoff
<rickspencer3> and risks a regression
<pitti> the regression potential needs to be considered, of course
<rickspencer3> and what if we get user feedback that they don't like what it was changed to
<rickspencer3> I don't understand why we are even discussing it
<seb128> well I don't see a clear suggestion in the bug to make the thing obvious
<rickspencer3> it's functional and it doesn't crash
<beuno> rickspencer3, so you'll go with "users haven't yelled hard enough about this, so lets ignore user testing"
<rickspencer3> beuno, we have to *ship*
<rickspencer3> it is time to *ship*
<beuno> rickspencer3, I don't think "functional and doesn't crash" is the theme here, sorry
<beuno> I understand the stress
<rickspencer3> we must stop making changes and fix our most serious bugs and *ship*
<seb128> beuno, how unselecting will make it obvious what to do?
<seb128> I would understand if you asked to add a button or icon in the list
<beuno> but it's a bad excuse to not spend an hour fixing an experience that will affect every single user that installs ubuntu
<beuno> seb128, because what you need to do is select it
<seb128> but it's not the selection which will make people click on the list if they don't do now
<rickspencer3> beuno, as I said, we need to have crystal clear focus
<beuno> and if it's already selected
<beuno> then it tells you not to click it
<seb128> anyway seems Amaranth is wanting to provide a patch so let's see how that goes
<mat_t> beuno: you said you run some tests on that didn't you?
<Amaranth> oh boy, custom widgets galore :)
<beuno> mat_t, I've tried this with 4 different people now
<kirkland> mdz: sure ... would you like it here or elsewhere?
<beuno> 3 non-techie users, and one techie
<mat_t> beuno: did everyone have the same problem?
<beuno> all of them failed to tell me what they needed to do with that screen when it came up
<seb128> beuno, next time start raising issues before beta
<beuno> seb128, yes, I should of been more vocal before
<mat_t> seb128, that bug was filed 2 months ago!
<rickspencer3> are you saying that users can't figure out how to log in after installing their systems?
<beuno> I filed the bug, did not presure
<rickspencer3> beuno, ^
<seb128> mat_t, like 1 thousand others on my list
<beuno> rickspencer3, not without experimentation, no
<kirkland> mdz: several of us have been testing; i have one minor fix to your upstart script uploaded
<rickspencer3> that sounds like an outlandish claim to me
<beuno> they click around, and eventually figure it out
<seb128> mat_t, that one got almost no comment nor duplicate, it stayed in the noise
<mat_t> yeah, I understands
<rickspencer3> I can't imagine that this would not have been escelated by users immediately
<seb128> mat_t, we get ton of bugs which get duplicates and comments daily
<kirkland> mdz: committed; not yet uploaded
<kirkland> mdz: that needs to be uploaded and cd re-spun
<seb128> mat_t, how do you expect us to pick bugs which have sit there and nobody complained about?
<beuno> rickspencer3, users did not complain about notifications before either
<kirkland> mdz: i'm looking over the bugs right now to see if there's anything beta-critical and/or low-hanging to batch into this upload
<beuno> seb128, I'm sorry about bringing this so late to the table, it was a failure in processes
<mdz> kirkland, does that minor fix have to do with the failed registrations? that seemed to be the biggest issue
<kirkland> mdz: this fix allows images to run; otherwise, you make a reservation, and it terminates immediately because /var/run/eucalyptus/net doesn't exist
<mat_t> seb128: sure, I though since you marked it as triaged it would be on your (meaning desktop team) radar. I may be wrong here, I know you have tons of triaged bugs
<seb128> mat_t, right, we have some thousand triaged bugs, that just means we passed the message to people writting the code
<kirkland> mdz: i'm still looking at registration
<mat_t> sure
<mdz> kirkland, ah, right, the bug that ttx mentioned on IRC earlier
<beuno> rickspencer3, we have a team built specifically to address usability issues. If in the end, it's going to be ignored, and the only valid measure is user complaints, then we have a problem
<kirkland> mdz: that's still not working reliably for ttx or i
<WildBill> Is this page the right one for Eucalyptus testing? http://testcases.qa.ubuntu.com/System/Eucalyptus
<mdz> kirkland, is there anything I can do to help debug registration?
<seb128> mat_t, as said that one has got almost no activity since it has been filed, and activity is the metric to spot common issues
<mathiaz> mdz: how to enable upstart debugging?
<mdz> mathiaz, there's a page in the upstart wiki about it
<kirkland> mdz: yeah, sure; we seem to have a timing issue, that i would have thought upstart should have solved for us
<mdz> I think it involves passing a command line option
<seb128> beuno, nobody is ignoring your team but the beta weeks is not the week to wake up with all the issues
<mathiaz> mdz: I looked at this yesterday and I suspect that the upstart cc-registration job is not run
<rickspencer3> beuno, I am supremely unconvinced that users can't log in
<kirkland> mdz: i'm still digesting your upstart changes now
<mdz> mathiaz, it was definitely run for me
<kirkland> mdz: i've held off on uploading with this one minor change, in the interest of solving registration too
<mdz> though I could not test all possible orderings
<rickspencer3> as seb128 says, if this was an organized design process and I had confidence that it was going to make the project better and not interfere with us shipping, we would be helping you
<mdz> in fact, I didn't test the case where reboot happens before registration, which is what's happening here
<mathiaz> mdz: kirkland: I'm looking into this as well
<beuno> I am not saying they can't, i'm saying it's a clumsy process, which makes them experiment, and one of their experiments makes them expose their password
<rickspencer3> I mean we would actively allocated resources to help with this goal
<rickspencer3> beuno, well, we need to trade off shipping without crashers and hitting our release dates
<mat_t> seb128: usability bugs are very often ignored by current users, who simply get used to them or find a bypass. Users who are most affected by them are often silent, because they would never use launchpad, etc
<kirkland> mdz: i have one comment, though on your upstart scripts, somewhat related to the /var/run change i'm making
<beuno> rickspencer3, you are being overly stubborn, this seems to be a pretty trivial change
<rickspencer3> "shipping is a feature"
<kirkland> mdz: the init scripts previously chowned a bunch of that /var/run/eucalyptus stuff to eucalyptus:eucalyptus
<rickspencer3> beuno, that's my job
<seb128> mat_t, right, but we fail to spot those without our metrics then and it's your role to raise those issues early
<kirkland> mdz: in the upstart implementation, all of that is owned by root:root
<rickspencer3> *it's time to ship*
<seb128> mat_t, the beta week is really late
<kirkland> mdz: i haven't seen a problem with it yet, necessarily
<ogra> thats what the milestonre tag is for btw ...
<kirkland> mdz: just something i've noted
<rickspencer3> I need to make the call about where we allocate our precious resources, and I do this on behalf of our users
<ogra> if the bug would have been milestoned it would have shown up in the weekly release team meeting
<kirkland> mdz: of course, euca_root_wrap might be handling all of that :-)
<mat_t> seb128: you are totally right that we should've raised this earlier
<rickspencer3> our users need us to focus on the highest priority issues in the most organized manner possible now
<mdz> kirkland, iirc the only /var/run stuff I touched were pid files, temporary files and the like.  don't think there was anything there used by eucalyptus itself (which runs as eucalyptus) as opposed to the init script (which runs as root)
<mdz> if I overlooked something, we should check it
<kirkland> mdz: okay, good
<mat_t> seb128: we'll be better in the future :)
<beuno> rickspencer3, and you do it ignoring usability data. This is concerning. I'm not going to continue hammering at this, I've raised it with Ivanka, we will go from there
<seb128> mat_t, right, learning experience ;-)
<rickspencer3> beuno, I have not seen any "data"
<rickspencer3> and in any case, it's too late
<seb128> mat_t, we will probably sort this one since Amaranth seems to be one the case but that's a lesson learnt for next time in any case
<kirkland> mdz: my fix is mkdir -p /var/run/eucalyptus/net (which ensures that both eucalyptus and net get created); and chowning those two directories to eucalyptus:eucalyptus
<mat_t> seb128: totally :)
<mdz> kirkland, I certainly don't mind that change
<beuno> rickspencer3, I've told you, 4 times now, I have done user testing. You continue to ignore that.
<mat_t> seb128: thanks for your help!
<kirkland> mathiaz: let's sync up on the registration thing
<kirkland> mathiaz: where are you with it?
<mathiaz> kirkland: sure
<seb128> mat_t, you're welcome
<beuno> rickspencer3, which is why I'm saying you're being overly stubborn
<kirkland> mathiaz: i'm parsing the upstart scripts now
<seb128> that said, dinner time there and other issues waiting
<kirkland> mathiaz: and mdz is offering to help
<mathiaz> kirkland: I'm reinstalling a test vm for that
<kirkland> mathiaz: let's figure out what we can do in parallel
<rickspencer3> beuno, as a usability engineer, you need to understand that your user testing needs to be done in manner that is both timely and compelling
<mathiaz> kirkland: first step - making sure that the upstart jobs are actually run
<mathiaz> kirkland: using a pre-script to touch a file
<mathiaz> kirkland: I'm also wondering whether the *registration jobs should written as services or tasks
<beuno> rickspencer3, it *was* timely, the bug just fell off the radar. We can do this all day, but it's not getting anywhere. If Amaranth is working on it, awesome. We will bring this up in the Nov sprint, and discuss the failure in the process.
<rickspencer3> beuno, sounds good
<ogra> beuno, using the milestone filed in launchpad was the missing bit
<seb128> we need a better process than having bugs filled in the middle of thousands
<ogra> milestoned bugs are reviewed weekly
<ogra> it would have shown up early if i milestone would have been set
<ogra> s/i/a/
<Amaranth> ugh, so ugly
<seb128> beuno, for the record I think having a "select user" button would work better than no selection
<seb128> and would probably be easier code wise
<Amaranth> gdm created a custom widget for the user switcher then went and used it for the keyboard and session selectors too, apparently
<beuno> seb128, I'm happy to discuss alternatives if it makes it easier. I have to go now, but if you decide to address this, let me know and I'll provide you whatever I can to get it fixed
<beuno> seb128, rickspencer3, pitti, cjwatson, thanks for looking into it
 * beuno -> off
<robbiew> IMHO, we've done enough late changes in this release...I don't like this idea at all
<robbiew> for the record, a bug that stays in "New" and "Undecided" has little chance of being fixed...especially at this stage
<robbiew> when we have more critical issues to address
<kirkland> mdz: https://bugs.edge.launchpad.net/ubuntu/+source/eucalyptus/+bug/438602
<ubottu> Launchpad bug 438602 in eucalyptus "Autoregistration sometimes fails" [High,Triaged]
<kirkland> mdz: that's ttx's writeup on the current issue
<kirkland> mdz: i've confirmed that walrus autoregistration is working; though cc is not
<mathiaz> mdz: so the other part in the upstart jobs I don't understand is that registration should be run once - how is this expressed in upstart?
<mathiaz> mdz: is it the use of a task?
 * robbiew corrects himself:  a bug that stays in "Triaged" and "Low" has little chance of being fixed
<mdz> mathiaz, it isn't.  it's run every time we notice that the components have come up
<mdz> this is by design
<mdz> nurmi says it is idempotent, so it is harmless to register again
<mathiaz> mdz: design in upstart?
<mathiaz> mdz: ah ok.
<mdz> and if our IP address changes or something, we need to re-register anyawy
<mdz> mathiaz, design of the jobs
<mathiaz> ok - so eucalyptus-cc-registration is not run
<mathiaz> I've added a pre-start script to the cc-registration job:http://paste.ubuntu.com/281524/
<mathiaz> IIUC /tmp/cc-registration.started
<mathiaz> should be created if the job is run
<mathiaz> I've rebooted the system - and after 5mn /tmp/cc-registration.started isn't there
 * lamont looks at the current  'hello' source, cries a little.  what's a good _trivial_ source package these days?
<lamont> I suppose I could just build one
<kirkland> mathiaz: note that the author is still set to mdz; you might update that if you wrote that script
<mdz> mathiaz, interesting.  upstart debugging sounds like the next step
<mdz> mathiaz, http://upstart.ubuntu.com/wiki/Debugging
<mdz> kirkland, I did write that, but it's not important anyway
<kirkland> mdz: ah, i misunderstood mathiaz then
<mathiaz> so the other strange thing is this: http://paste.ubuntu.com/281528/
<mdz> mathiaz, your job looks correct; if the file is not being created, then it doesn't seem tob er unning
<mathiaz> note that eucalyptus-walrus-registration stop/waiting
<mdz> mathiaz, check "status eucalyptus-cc"
<mdz> mathiaz, and "status eucalyptus-cloud"
<mdz> eucalyptus-cc-registration is supposed to run when both of those come up and running
<mathiaz> while the walrus registration is actually sucessfull
<mathiaz> eucalyptus-cloud start/running
<mathiaz> ^^ but there isn't any pid there
<mathiaz> and the eucalyptus-cloud job defintion doesn't have any script/exec defition
<mathiaz> it only has a post-script definition
<mathiaz> http://paste.ubuntu.com/281529/
<mdz> mathiaz, the -registration jobs are tasks, which means they don't stay running, they go back to stopped/waiting
<mdz> stop/waiting
<mdz> so that's normal
<mathiaz> ^^ I wonder what eucalyptus-cloud is meant for then
<mdz> mathiaz, eucalyptus-cloud is meant to wait for the cloud service to come up, and emit a signal when it is ready
<mdz> mathiaz, -cloud, -sc and -walrus all run within the same process, but don't all come available at the same time
<mdz> (necessarily)
<cjwatson> is post-start actually run at all if there's no main process?
<mdz> mathiaz, -cc runs as a separate process, so it comes with its own pre-start
<mathiaz> mdz: eucalyptus-sc-registration.conf has a respawn whereas cc-reg and walrus-reg don't
<mdz> cjwatson, it worked for me
<ion> cjwatson: It should.
<mdz> mathiaz, that's an anomaly; I was starting to experiment with respawn but found it wasn't needed
<mdz> it should be harmless
<mathiaz> mdz: ok.
<mdz> respawn means that if it fails to start, it will get retried until it succeeds
<mdz> it wouldn't hurt, but might mask bugs
<mathiaz> mdz: -cc is a different process, while walrus is the same as -cloud?
<mdz> mathiaz, that's correct
<fta> doko_, i guess you have your answers for chromium now, right?
<mdz> mathiaz, -cc is actually an apache2 process using axis2
<mathiaz> eucalyptus-cc-registration.conf: start on (started eucalyptus-cc and started eucalyptus-cloud)
<mdz> -cloud/-sc/-eucalyptus is one JVM process
<cjwatson> IMO, respawn with a limit would be neater than that timeout loop
<mathiaz> eucalyptus-walrus-registration.conf: start on (started eucalyptus-walrus and started eucalyptus-cloud)
<mathiaz> could that be an issue^^?
<mdz> cjwatson, hmm, I think I agree. I didn't know that respawn had a limit
<mdz> mathiaz, could what be an issue?
<cjwatson> you would probably still need the sleep 1 to avoid it respawning too rapidly
<mathiaz> cc-registration depends on two different processes, while walrus-registration depends on the same process?
<mathiaz> eucalyptus-walrus-registration.conf: start on (started eucalyptus-walrus and started eucalyptus-cloud)
<cjwatson> anyway, not really directly relevant
<mdz> mathiaz, cc registration requires that the cloud service and cc service are running
<doko_> fta: yes, besides I don't know why the python-tlslib is not in jaunty/karmic ...
<mdz> mathiaz, walrus registration requires that the walrus service and cloud service are running
<mdz> mathiaz, we should get nurmi in here
<mathiaz> mdz: well - I'm still not convinced that this is not an issue with the upstart jobs.
<kirkland> mdz: i just poked nurmi over here
<mathiaz> mdz: I'm trying to figure out why the cc-registration job is not started
<mdz> mathiaz, I know, I'm trying to help
<mathiaz> mdz: while the walrus-registration job is
<mdz> it worked for me in my tests yesterday
<mdz> mathiaz, did you try the status commands I suggested?
<cjwatson> mdz: FWIW, when I was trying to get usplash working with upstart yesterday, I hacked up http://paste.ubuntu.com/281538/ and ran upstart with that
<mdz> mathiaz, you said eucalyptus-cloud was running; what about eucalyptus-cc?
<cjwatson> the log format is screwy (times on a separate line) but I had better things to do than fix that
<mathiaz> mdz: they're all running: http://paste.ubuntu.com/281540/
<cjwatson> also that's a bit more than strictly necessary for you, I was trying to debug something specific :)
<nurmi> o/
<mdz> mathiaz, grep eucalyptus /var/log/syslog? upstart will log if any jobs failed
<kirkland> nurmi: we're discussing -cc auto registration
<nurmi> kirkland: nod
<kirkland> nurmi: seems we're successfully autoregistering walrus, but not the cc
<mathiaz> mdz: empty
<mdz> mathiaz, if you run 'start eucalyptus-cc-registration', that works, right?
<mdz> it's just not getting triggered at the right time?
 * mathiaz tries
<mathiaz> mdz: yes - it works as expected
<mdz> mathiaz, it'll write to /var/log/eucalyptus/cc-registration.log
<mdz> hmm
<mathiaz> mdz: so the job is not triggered
<mdz> is Keybuk on holiday?
<mdz> cjwatson, did you have to hack up that logging because the built-in debugging wasn't sufficient?
<Amaranth> no way, this gdm bug can't be as simple as commenting out one line of code
<ion> mdz: Proper logging of jobsâ output is in TODO list.
 * Amaranth builds
<seb128> Amaranth, the line which focus the first entry in the list? ;-)
<cjwatson> mdz: not for the very early stages, at least
<cjwatson> mdz: Keybuk is having DSL problems
<fta> doko_: it's no longer used, i should drop the build-dep or re-add my patch in chromium (it's a matter of /usr/bin/tls vs /usr/bin/tls.py)
<mdz> mathiaz, maybe something to try would be stopping and starting -cloud and/or -cc to see if that triggers it
<Amaranth> seb128: yeah, but it's obfuscated through 4 layers of custom widgets
<doko_> fta: good to know
<Amaranth> seb128: I figured with that much crazy going on I'd have to change more
<cjwatson> mdz: (early stages> I was trying to debug stuff happening before rsyslog ... but in any case I wanted a complete log of upstart's operation in one place)
<kirkland> mathiaz: i grabbed nurmi; do you know what mdz wanted from him here?
 * nurmi waves
<mathiaz> nurmi: I don't think we need you right now
<kirkland> nurmi: just idle here, if you don't mind
<nurmi> mathiaz: okay, available if needed for most of today (PST) :)
<kirkland> nurmi: we'll poke you if we need something
<nurmi> nod
<mathiaz> nurmi: I may have more questions later on the best way to make sure that one of the service is actually operational
<mathiaz> kirkland: for now, the symptom is that the cc-registration job is not started by upstart
<nurmi> mathiaz: got it, i'll try to help, although I am having trouble starting eucalyptus services (start eucalyptus-cloud hangs forever) on the latest build.  I can offer advice, but may be limited in testing
<mathiaz> nurmi: right. Advices is already better than nothing :)
<nurmi> mathiaz: :)
<fta> doko_, but if you want to have python-tlslib in the archives, feel free to takeover my branch
<doko_> fta: last release 2005? no, thanks. just remove the b-d
<fta> doko_, yes, but that means more 3rd party code in chromium
<nurmi> sorry folks, I have some meetings for a few hours, but please email/msg me with anything i can help with
<oxocoffee> Any one here can help with strange socket/multicast problem. I am getting data but double copy
<ogra> pitti, haha, spamalot :)
<mathiaz> kirkland: I've managed to get more debug
<mathiaz> kirkland: /sbin/initctl log-priority debug
<kirkland> mathiaz: pastebin?
<mathiaz> kirkland: ^^ add this as the first line of the pre-script from the eucalyptus.conf job
<mathiaz> kirkland: it's huge - a complete log
<kirkland> mathiaz: ack
<mathiaz> kirkland: http://people.canonical.com/~mathiaz/syslog
<kirkland> You don't have permission to access /~mathiaz/syslog on this server.
<mathiaz> kirkland: retry
<kirkland> mathiaz: i have my own here now
<mathiaz> kirkland: ok great.
<kirkland> mathiaz: looks like the cc job is registered
<mathiaz> kirkland: are you looking at my syslog file?
<kirkland> mathiaz: yeah, let's just look at yours for now, so that we're on the same data
<kirkland> mathiaz: though mine looks similar
 * mathiaz nods
<mathiaz> kirkland: hm - I don't see anything special here
<mathiaz> kirkland: except that the upstart configuration is reloaded
<mathiaz> kirkland: in the process
<mathiaz> kirkland: could that lead to lost events?
<Darxus> I could swear yesterday when I clicked "Also affects project" on launchpad, it gave me the option to enter a url for an upstream bug.  Am I wrong?  It's not there today.
<mathiaz> kirkland: http://paste.ubuntu.com/281576/ <- this is when the walrus-registration is started
<kirkland> mathiaz: cool, yep
<jdong> kees: is there a way to attach an apparmor profile to only a specific process without hardlinking galore?
<jdong> kees: as an example in OS X you can do something like sandbox-exec {profile} {executable}
<kees> jdong: libvirt does dynamic profile attachment, but it does require a little bit of code to implement it.
<kees> jdong: there isn't an arbitrary way to do it at the moment.  I'd like to see sandboxes implemented with apparmor.  Saw a demo of selinux sandboxing; it seems easy enough to do.
<jdong> kees: *nods* how does libvirt do it?
<kees> jdong: it creates a profile with a random UUID, then calls apparmor_change_profile from libapparmor before exec'ing, I think.  jdstrand would know the details better.
<jdong> kees: LOL ok :)
<jdong> kees: I might look at hacking up something similar to that
<jdong> kees: wanted to provide a way for people on a public shell server (standard users) to elect into their own AA restrictions
<jdstrand> libvirt has been modified to aa_change_profile() before the exec() as kees said
<jdstrand> profiles are created dynamically based on the uuid of the domain in question
<jdstrand> so each gets it's own unique, tailor made profile
<jdstrand> (each kvm/qemu process that is)
<jdong> jdstrand: ok, aa_change_profile() is the magic I need then
<jdong> thanks
<jdstrand> aa_change_profile() and change_hat() require that the application be modifed
<jdstrand> np
<jdstrand> most of the work on libvirt was creating the dynamic profiles sanely
<jdong> right
<jdstrand> simply calling aa_change_profile() is pretty straight forward. see the include in libapparor-dev
<jdong> theoretically it can be done from an agnostic "aa-exec" type wrapper, right?
<jdstrand> yeah
<jdong> cool
<jdstrand> that is kinda what virt-aa-helper does in libvirt
<jdstrand> well, not really-- it does the dynamic stuff, but sure you should be able to do that
<kees> this could be handy for gdm-guest-session too
<jdstrand> (virt-aa-helper is a wrapper around apparmor_parser, so libvirt isn't messing around with apparmor directly, but I digress)
 * jdong nods
<jdong> likely I'll need both something to interface with aa_parser and change_profile
<jdstrand> depending on your application, yeah
<jdong> I think if properly done the idea of voluntarily electing into an AA confinement domain is a very powerful feature
<jdstrand> I split out the apparmor_parser stuff so that I could confine libvirtd to using virt-aa-helper whnever messing with apparmor, to prevent bootstrapping
<jdstrand> it certainly sounds interesting
<jdstrand> fyi, aa has user-defined profiles on the Roadmap as well, but they aren't implemented yet
 * jdong nods
<rrva> Hi. Since upgrading to upstart boot process hangs after cryptdisks are enabled. I suspect mountall to not let boot continue. If I reconfigure control-alt-delete so that a getty is spawned I can see that filesystem / is read-only and swap is not enabled.
<slangasek> rrva: I've not heard of such a bug; mountall shouldn't block getting swap mounted and mounting the rootfs rw
<slangasek> rrva: can you post your fstab somewhere?
<rrva> yes
<slangasek> rrva: and can you try setting -v in /etc/init/mountall.conf?  Maybe it has something interesting to tell us
<rrva> yes
<rrva> I did
<rrva> but I only have one comp, so bear with me when rebooting
<slangasek> sure, understood :)
<slangasek> please bear with us while we shake out your bugs
<rrva> also udevd complains before the "hang"
<slangasek> there's a known udevd warning that's unrelated noise
<slangasek> "SYMLINK"?
<rrva> no
<slangasek> oh, perhaps you have another bug then
<slangasek> the exact error message would help
<rrva> posting fstab soon, then reboot, then error message
 * slangasek nods
<rrva> http://pastebin.com/f94435f
<rrva> away for reboot
<slangasek> rrva: hmmm, I wonder if we fail to handle swapfiles
<slangasek> anyone else here running with a swapfile with karmic?
<slangasek> ... anyone else want to *test* using a swapfile with karmic? :)
<rrva> udevd[533]: inotify_add_watch(6, (null), 10) failed: Bad address
<rrva> this is repeated many times
<slangasek> hmm
<rrva> * Starting init crypto disks ... [OK]
<rrva> is the last line
<rrva> I tried disabling swap
<slangasek> and no luck?
<rrva> no difference
<rrva> if I configure tty2 to run at runlevel 6, press control-alt-delete and quickly control-s, I can login on tty2 and kill the runlevel 6 killall scripts. This is how I get a running system at all.
<sharms> pitti: how does cups / userspace drivers work when the user has a usb2parallel adapter? LP #436495
<ubottu> Launchpad bug 436495 in cups "[regression] printing broken in karmic" [Undecided,New] https://launchpad.net/bugs/436495
<slangasek> rrva: the udev problem seems the most likely cause of your failure, then; could you please file a bug report about this in Launchpad?
<sharms> should it just be assumed they wont be autoconfigured in that scenario?
<slangasek> rrva: our udev expert is offline today due to DSL problems, so that's the best way to get the bug in front of the right eyeballs
<slangasek> sharms: the usb-parallel adapter won't be able to provide printer identification information, so yeah, I don't think that's going to autoconfigure
<rrva> how to file bug without working X?
<LLStarks> hi. is the ubuntu keyserver down?
<sharms> slangasek: I am wondering how that works since usblp is blacklisted by default now
<slangasek> rrva: https://bugs.launchpad.net/ubuntu/+source/udev/+filebug (I hope this is working currently... :/)
<slangasek> sharms: that part, I don't know
<mdke> slangasek: did you catch my hilight about gnome-user-docs?
<slangasek> mdke: ah - yes, then it slipped through my fingers into the stream of other beta preps :( pulling it up now
<slangasek> mdke: I agree that this is the wrong time to be changing the package split
<mdke> slangasek: awesome, thanks. I'd like to get it sorted by beta but having said that, I'm pretty sure you have plenty of other urgent things which are more important
<mdke> slangasek: nod
<slangasek> mdke: /usr/share/iso-codes/iso_639.tab has been rudely deprecated in favor of an XML file: /usr/share/xml/iso-codes/iso_639.xml
<mdke> aha. is it just a straight replace?
<slangasek> mdke: at this point we're already in the process of trying to vet final ISOs for beta, so I don't think we're going to get these changes in pre-beta - we should try to get it so it's ready to build immediately post-beta, though
<mdke> find by me
<mdke> fine*
<rrva> slangasek: bug #438962
<ubottu> Launchpad bug 438962 in udev "upstart/mountall does not boot after mounting crypto disks" [Undecided,New] https://launchpad.net/bugs/438962
<mdke> colin mentioned an application called iso-query but I don't know how it would fit in with the relevant line in debian/rules, because I can't understand that line :)
<slangasek> mdke: it's a straight replacement for the /content/, but of course instead of being a sensible text format it's now xml :P Perhaps iso-query is a tool they provide to convert the XML to text... I'll try to have a look later today
<mdke> slangasek: ok, thanks. Let me know if you need anything from me, and sorry to burden you with that
<mathiaz> kirkland: so I think it's a timing problem
<slangasek> mdke: no worries, I touched it last so I have it coming ;)
<mathiaz> kirkland: I was able to make the walrus-registration job not run by adding a sleep 10 as the walrus job script
<Hatl> hi! aptitude crashes if i want to start minesweeper: Aborted
<zul> slangasek: after beta I was going to upload samba 3.4.1
<slangasek> zul: feature freeze applies, please make sure the changes are appropriate for where we are in the release cycle
<zul> k
<zul> ill subscribe ubuntu-release
<rrva> could someone just add the info at http://pastebin.com/f94435f to 438962, i have only lynx and navigating is hard
<slangasek> pitti: so... is core-dev transitively a member of ubuntu-art-pkg, or is this another packaging branch with permissions that don't match the archive?
<mathiaz> kirkland: http://people.canonical.com/~mathiaz/syslog
<slangasek> rrva: will do, thanks
<mathiaz> kirkland: ^^ this is an updated log file - there are two boots in there
<rrva> thanks, i'll check back tomorrow if more info is wanted
<kirkland> mathiaz: hmm, so respawn should make it retry indefinitely, right?
<mathiaz> kirkland: the first one doesn't run walrus-register (because the walrus job has a sleep 10 as a script) while the second runs walrus-registration
<mathiaz> kirkland: respwan in walrus or walrus-register?
<mathiaz> kirkland: walrus-register is *not* even started in the former case
<kirkland> mathiaz: all of the registration ones have "respawn"
<mathiaz> kirkland: I don't think so
<mathiaz> kirkland: they're all task
<mathiaz> kirkland: instead of services (the default)
<kirkland> mathiaz: okay, tell you what ...
<kirkland> mathiaz: i'm going to shift my focus for a bit on euca_conf, and the part of the code that's throwing the "you need to be on the CLC host and the CLC needs to be running" error
<mathiaz> kirkland: yeah - I think we need the upstart expert to debug this
<rgreening> who the resident HAL expert? :) I need some assistance or advice on my bug 438316
<ubottu> Launchpad bug 438316 in udev "hal does not properly enumerate USB devices unless CD-ROM inserted as first device" [Undecided,New] https://launchpad.net/bugs/438316
<kirkland> mathiaz: he's still offline :-/
<mathiaz> kirkland: I'm going to update the euca bug with the current state
<slangasek> mathiaz, kirkland: can you summarize the problem?
<mathiaz> slangasek: sure - the eucalyptus-cc-registration job is not started
<mathiaz> slangasek: when its dependencies are satisified
<mathiaz> slangasek: while the eucalyptus-walrus-registration job is correclty started
<mathiaz> slangasek: eucalyptus-cc-registration.conf:start on (started eucalyptus-cc and started eucalyptus-cloud)
<mathiaz> slangasek: eucalyptus-walrus-registration.conf:start on (started eucalyptus-walrus and started eucalyptus-cloud)
<mathiaz> slangasek: eucalyptus-walrus is a job with a post-script that waits for the http service to be answering correclty
<mathiaz> slangasek: whereas eucalyptus-cc actually starts a process (via exec)
<c_korn> is it related to virtualbox that I still get this "Superblock last mount time is in the future" bug on restart ? all related bugs have been marked as fixed released
<mathiaz> slangasek: now if a script stanza (that sleep 10) is added to the eucalyptus-walrus job, eucalyptus-walrus-registration is not run as well
<slangasek> mathiaz: right; looking
<slangasek> mathiaz: oh, where are these -registration upstart jobs?
<sharms> if usblp is going to be disabled by default and no work around is found, who do I contact about getting it added to the release notes?
<mathiaz> slangasek: in /etc/init/eucalyptus-*
<mathiaz> slangasek: or you're asking in the source package?
<slangasek> yes
<slangasek> I don't see -registration upstart jobs in the eucalyptus core-dev branch
<kirkland> slangasek: what branch are you looking at?
<kirkland> slangasek: ~ubuntu-core-dev/eucalyptus/ubuntu
<slangasek> kirkland: yes, that one
<kirkland> slangasek: see debian/*regist*
<slangasek> oh
<slangasek> tab completion fail
<slangasek> kirkland, mathiaz: is there a reason to run apache2 in the foreground as opposed to using 'expect fork'?
<kirkland> slangasek: globs for the win!
<ttx> kirkland, mathiaz: I gather setting the external IP rather than localhost didn't help in any way ?
<kirkland> ttx: howdy, welcome back
<mathiaz> ttx: well - the job are not started
<slangasek> kirkland, mathiaz: and you've confirmed that 'status eucalyptus-cc' shows it started?
<ttx> mathiaz: hm
<mathiaz> slangasek: yes
<slangasek> ok, looks like an upstart bug to me, then :P
<kirkland> slangasek: yes, running
<ttx> mathiaz: it did start with me, when I did sudo stop eucalyptus / sudo start eucalyptus (error appears in /var/log/eucalyptus/*registration.log)
<mathiaz> ttx: to test whether a job has started, I've added a pre-script to all the registration job that touch a file in /var/tmp/
<mathiaz> ttx: right - I suspect a timing issue in upstart
<mathiaz> ttx: if I modify the walrus job to sleep for 10 seconds, then the walrus-registration job is not started as well
<ttx> mathiaz: be careful with "restart" btw, mdz saw that env isn't set in that case...
<mathiaz> ttx: slangasek: http://people.canonical.com/~mathiaz/syslog
<mathiaz> ttx: ^^ this is a syslog with upstart debug information
<ttx> which crashes eucalyptus-cc httpd (if EUCALYPTUS=/ is not set)
<mathiaz> ttx: I meants a system reboot
<mathiaz> ttx: the first boot doesn't start walrus-registration, while the second does
<ttx> mathiaz: ok.
<slangasek> mathiaz: yeah... really looks like an upstart bug to me
<ttx> mathiaz: that log looks a lot like an upstart bug.
<slangasek> mathiaz: I do wonder whether using 'expect fork', dropping the -f argument to apache, and dropping the post-start script would make a difference
 * mathiaz agrees that this really look like an upstart bug
<ttx> we all agree, cool ;)
<slangasek> if it works, it might make for a nicer job, though it's a workaround in any case
 * mathiaz flies to Europe to fix some DSL lines
<slangasek> (hmm, and maybe your post-start script depends on something more than just apache being started, so.)
 * ttx goes to sleep, you seem to be on the right track
<davmor2> mathiaz: say the word I'll drive over and get him ;)
<ttx> mathiaz, kirkland: if for whatever reason this can't be solved before the end of your day, please push the other fix on an ISO nevertheless.
<mathiaz> ttx: I think that's what we gonna do
<ttx> then we'll decide if that should still be solved for beta or if we stay with that known bug.
 * ttx disappears
<kirkland> mathiaz: i think i'm going to go ahead and upload my other fix
<kirkland> mathiaz: get that onto an iso
<kirkland> mathiaz: we can continue working this one in parallel
<mathiaz> kirkland: agreed.
<kirkland> slangasek: hey, did we merge those packaging fixes you gave us on Friday?
<slangasek> I don't know
<kirkland>   [ Steve Langasek ]
<kirkland>   * Move eucalyptus-nc "no VT" handling for LP: #426830 to a debconf script
<kirkland>     instead, so that users are a bit more likely to see this.
<kirkland>   * Drop the dpkg-statoverride check on /var/lib/eucalyptus/keys in the
<kirkland>     eucalyptus-common postinst; this was ineffective anyway because we'd done
<kirkland>     a chown -R immediately before that, so the only part that was respecting
<kirkland>     statoverride were the directory perms.
<slangasek> then yes :)
<kirkland> slangasek: does that look right?
<kirkland> slangasek: cool
<kirkland> mathiaz: anything else to include before i upload?
<mathiaz> kirkland: a cookie?
<kirkland> mathiaz: i just have that one /var/run/eucalyptus/net fix right now
<kirkland> mathiaz: an easter egg?
<mathiaz> kirkland: we can't talk about an easter egg in public though
<kirkland> mathiaz: slangasek: uploaded eucalyptus_1.6~bzr854-0ubuntu12_source.changes
<kirkland> slangasek: as soon as that builds, and a new iso comes along, we'll test it
<mathiaz> kirkland: iz noh lunger a zicret ozzerwize
<kirkland> mathiaz: you should make more liberal use of zzz's in your irc communications
<kirkland> mathiaz: itz zwould zound zo much more like you
<mathiaz> kirkland: oh!
<slangasek> kirkland: more beta-critical stuff in the current upload?
<kirkland> slangasek: yes, one beta critical bug fixed
<slangasek> ok
<kirkland> slangasek: one more still to go, though it's eluded us for most of the day
<levi_> hello I am new
<kirkland> slangasek: we're still trying to fix that one
<kirkland> slangasek: in case we don't, or can't, we wanted to make sure the other one was fixed and on an ISO
<kirkland> mathiaz: what evidence do we have that this might be an upstart bug?
<mathiaz> kirkland: updating the bug description right now whith my investigation
<kirkland> slangasek: could you poke us when the next iso is ready?
<kirkland> mathiaz: shall i mark it as affecting upstart?
<mathiaz> kirkland: probably yes
<kirkland> mathiaz: done
<Keevu77> Hello I am new
<Keevu77> hello I am new
<kirkland> Keevu77: you're probably looking for #ubuntu, then
<Keevu77> ok sorry I just wnt to listen bye
<sistpoty> being new is better than being old, I guess *g*
<oxocoffee> I have a problem with multicast application. I was wondering some one can put some light on it.
<oxocoffee> I have two sockets that bind to same port and ANY interface.
<oxocoffee> than bot of them join different muticast groups
<kirkland> mathiaz: have you gotten euca-describe-availability-zones verbose  to work yet?
<mathiaz> kirkland: nope
<mathiaz> kirkland: I've been debugging this registration failure for a day now
<mathiaz> kirkland: and I think that the VERBOSE cmd line is actually --verbose
<oxocoffee> when reading data I get double copy. Same data is beeing send over different multicast groups. But I read such data two times per socket instead of one copy per socket
<oxocoffee> This works on Windows. I do not have any other system to test right now.
<oxocoffee> Is there something different about linix that would explain this?
<slangasek> oxocoffee: this is not a forum for application development questions
<oxocoffee> I see. What would be the proper channel?
<oxocoffee> I tried sockets but not one is there
<slangasek> oxocoffee: I don't know offhand; a programming channel, I think
<joaopinto> oxocoffee, it dependson the language you are using, #python, #c, etc
<cr3> how can I query germinate somehow to determine if some packages are installed by default like apt-transport-https for example
<cjwatson> in this case, 'apt-cache show apt-transport-https' will show "Task: standard" and the standard task is installed by default
<cjwatson> you can also look at http://people.ubuntu.com/~ubuntu-archive/germinate-output/
<doko_> ubuntu-archive: uploaded gcc-4.3/gcj-4.3. please consider accepting only one of them, so you have a free buildd on every arch.
<cr3> cjwatson: ubuntu-moblin-remix doesn't seem to be on that page
<cjwatson> cr3: it's indexed by the name of the seed collection branch, not by product name
<cjwatson> I don't know if ubuntu-moblin-remix has seeds, or if so what they're called; if it does not have seeds then you cannot query germinate about them
<cjwatson> if it does have seeds but we don't have pre-generated germinate output for them, then germinate is a package and you can run it by hand on things assuming you know the location of the seeds
<cr3> cjwatson: I really need to learn more about these seeds
<cjwatson> but in any case, the standard seed is common to all products, or should be
<cjwatson> with some minor exceptions like minimal virtual machines
<maxb> Is there anything I should do about bugs which I think are important for karmic but don't seem to be getting attention (I've already done "nominate for release") ?
<kirkland> mathiaz: did you update that bug with your findings?
<kirkland> mathiaz: i don't see anything yet
<mathiaz> kirkland: not yet
<kirkland> mathiaz: that sounds like fun
<ScottK> maxb: Did you also milestone them for 9.10
<maxb> am I allowed to? (I'm not ubuntu-dev)
<cjwatson> doko_: at this point we're focused on getting the CDs built for beta release, and are deferring anything that doesn't directly contribute to that until after beta; is there a CD-relevant problem that gcc-4.3/gcj-4.3 is blocking?
<doko_> cjwatson: no, both are universe (and unaffected by the freeze). just wanted to point out the build times of these packages
<cjwatson> doko_: gcc-4.3 source is in main
<cjwatson> FWIW
<slangasek> maxb: in fact, nominating for release doesn't do anything useful (because everyone nominates everything for release).  If you have a regression, please use the regression-potential tag; otherwise, the next best (but not scalable) solution is to escalate to a developer directly
<cjwatson> we can probably nuke linux-ports (though at this point I'm not inclined to do it before beta), and then blas is the only remaining build-dependency on gcc-4.3
<cjwatson> in main
<cjwatson> TheMuso: is linux-ports dead now, or are bits of it still kicking for some reason?
<mdz> kirkland, any update on the registration stuff?
<doko_> cjwatson: blas is alpha only, there's no dependency left. thanks for noticing ... I wasn't aware that it was still in main
<doko_> could upload blas, would introduce a delta just for the gcc-4.3 dependency
<mathiaz> kirkland: I've added a comment to bug 438602
<ubottu> Launchpad bug 438602 in eucalyptus "Autoregistration of eucalyptus-cc sometimes fails" [High,In progress] https://launchpad.net/bugs/438602
<mathiaz> kirkland: with a syslog
<TheMuso> cjwatson: afaik linux-ports is dead, linux-ports-meta is still being used.
<cjwatson> TheMuso: ok, will kill that after beta then, thanks
<slangasek> kirkland: ETA 1h on the ubuntu-server respin
<mathiaz> kirkland: so running: sudo start eucalyptus-cc-registration
<mathiaz> kirkland: works as expected
<mathiaz> kirkland: and it even starts eucalyptus-sc-registration!
<mathiaz> kirkland: hm - sudo euca_conf --list-walruses doesn't return anything
<mathiaz> kirkland: same for --list-clusters and --list-scs
<mdz> mathiaz, did you try adding respawn to eucalyptus-cc-registration?
<mdz> since eucalyptus-sc-registration seems to work, and it uses respawn
 * mathiaz tries
<mdz> mathiaz, can you confirm that SC registration seems to work? that would be very interesting as it's supposed to wait until CC registration is completed
<mathiaz> mdz: adding respawn to  eucalyptus-cc-registration doesn't change anything: the job is still *not* started
<mathiaz> mdz: sudo start eucalyptus-cc-registration will trigger both cc anc sc registration
<mathiaz> nurmi: hi!
<mathiaz> nurmi: Even after registration the cluster, sd and walrus aren't listed: http://paste.ubuntu.com/281717/
<mdz> mathiaz, but walrus works?
<mathiaz> mdz: well -  sudo euca_conf --list-walruses
<mathiaz> mdz: doesn't return anything
<mdz> that's even weirder, because the upstart config for walrus and cc are much more similar
<directhex> walrus-related commands may be enough to interest me in ec2
<mdz> if -cloud and -cc are running, -cc-registration should be run
<mathiaz> mdz: ah - I see what you mean - yes walrus-registration works
<mathiaz> mdz: the main difference between the cc and walrus jobs are that the former actually starts something, while the latter doesn't
<mathiaz> mdz: it only waits for the service to be available
<chrisccoulson> seb128 - i've agreed on a xklavier fix with svu now, which will stop that g-s-d crash
<mdz> mathiaz, I just fixed a typo I noticed in the post-stop script.  shouldn't have any effect
<mdz> mathiaz, you can have it exec a sleep or something if you think it might help
<seb128> chrisccoulson, I was just reading the #c-c backlog ;-)
<mathiaz> mdz: well - that's what I've tried - added script sleep 60 to the walrus job
<chrisccoulson> i just realised i'm not in the room i expected ;)
<chrisccoulson> i thought i was on #ubuntu-desktop
<mathiaz> mdz: the result is that the walrus-registration job is *not* run
<chrisccoulson> darned truncated tabs in empathy
<mathiaz> mdz: that's why I suspect a timing issue with upstart
<mdz> mathiaz, hmmmm
<mathiaz> mdz: http://people.canonical.com/~mathiaz/syslog
<mathiaz> mdz: ^^ that has two boots - the first one with a sleep 60 for the walrus job
<mathiaz> mdz: and walrus-registration not run
<mathiaz> mdz: the second doesn't have a script section in the walrus job and walrus-registration is run
<mdz> mathiaz, just to check my sanity, can you try purging eucalyptus* and reinstalling it, and see if it registers everything then?
<mdz> I need to go to sleep :-/
<mathiaz> mdz: I'll give it a try
<mathiaz> mdz: good night!
#ubuntu-devel 2009-09-30
<mathiaz> mdz: hm..well - purging the eucalyptus* packages doesn't work
<mathiaz> mdz: it gets stuck on Removing eucalyptus-common
<mathiaz> mdz: processes look like this: http://paste.ubuntu.com/281724/
<mathiaz> mdz: http://paste.ubuntu.com/281725/ <- better
<mathiaz> mdz: hm - it worked - after 10 mn
<slangasek> kirkland, mathiaz: updated server ISO posted
<mathiaz> mdz: hm - on package reinstalltion everything works as expected
<mathiaz> mdz: clusters, sd and walruses are all registered and correctly listed
<kirkland> slangasek: thanks, i'm grabbing
<TheMuso> Does anybody happen to know of any particular cdimage mirror/machine that is not loaded with downloads? i.e is there a machine I could use to sync images a little quicker?
<slangasek> blink, is cdimage being flooded already?
<TheMuso> Well it feels slower for me compared to even a week ago.
<TheMuso> And this is after syncing once every day or two.
<kirkland> nurmi: ping, when you come back around
<kirkland> nurmi: i think i found a problem with node registration
<kirkland> nurmi: i want to sanity check this patch
<mathiaz> kirkland: did you file a bug for booting from a degraded raid1 array not working in karmic?
<kirkland> mathiaz: Bug 427048
<ubottu> Launchpad bug 427048 in grub2 "grub2 needs to install the bootloader to each disk in a RAID1 array providing /boot" [High,Triaged] https://launchpad.net/bugs/427048
<mathiaz> kirkland: ok
<mathiaz> kirkland: and how do I boot the system once I'm in the initramfs shell?
<kirkland> mathiaz: boot from the first disk
<kirkland> mathiaz: that should work
<mathiaz> kirkland: yes - it works - it drops to a initramfs shell since one of the disk is missing
<kirkland> mathiaz: you should get a prompt asking you if you want to boot from the degraded raid
<mathiaz> kirkland: I may have missed that prompt (which times out IIRC)
<mathiaz> kirkland: booting with bootdegraded=true on the kernel command line still fails though
<mathiaz> kirkland: http://people.canonical.com/~mathiaz/degraded_raid1.png
<kirkland> mathiaz: that sucks
<kirkland> anyone else here besides keybuk can help debug a hard upstart problem?
<slangasek> kirkland: one other than the one I already worked on and declared it to be an upstart bug? :)
<kirkland> slangasek: nope, same one
<TheMuso> c
<pitti> Good morning
<al-maisan> Good morning
<pitti> slangasek: art-pkg is a member of ubuntu-desktop, which is a member of ubuntu-core-dev, so yes; these branches are meant to match the archive; kwwii tends to not use UNRELEASED, so it might be that the branch is ahead
<slangasek> pitti: okie-day
<dholbach> good morning
<mdke> morning
<nixternal> good morning dholbach
<dholbach> hey mdke, hey nixternal!
<mdke> :)
<YokoZar> I'm trying to trace a nautilus crash but I keep getting (no debugging symbols found)...done.  even though I have nautilus-dbg installed
<mdke> pitti: how does UNRELEASED work?
<mdke> perhaps we should use that in the ubuntu-docs branches
<pitti> mdke: when you do changes to a package, you always keep the target as "UNRELEASED" (not karmic); this shows everyone looking at the branch that the next change will be documented in the same changelog record, and that the package needs uploading
<pitti> mdke: when you upload, you do "dch -r" (changes UNRELEASED to "karmic"), and "debcommit -r" (commits that change and tags it with the version number)
<pitti> mdke: so when you see a branch with "karmic", you know it's uploaded and you need to start a new changelog entry
 * pitti pats "DEBCHANGE_RELEASE_HEURISTIC=changelog" in ~/.descripts
<pitti> ^ this causes "dch" to automatically start a new entry if the target is not UNRELEASED
<YokoZar> pitti: relatedly, dch --create will also use UNRELEASED
 * hyperair uses C-c C-v in emacs
<hyperair> no more debchange for me. heheh
<mdke> pitti: ah, that's very useful to know, thanks
<pitti> hyperair: that opens a new buffer with debian/changelog, and calls dch?
<hyperair> pitti: no it doesn't. it just adds a new changelog entry on top
<pitti> ah
<hyperair> if there was anything i used dch for, it was for automatically generating -- line
<hyperair> the one with the timestamp
<hyperair> but that was when i used vim
 * pitti starts the karmic upgrade of his wife's computer and gets the asbestos pants
<StevenK> pitti: With, or without permission? :-P
<pitti> with :)
<pitti> but if it breaks, I still have to fix it, of course
<mvo> wehhh
<mvo> good luck!
<pitti> mvo: if update-manager breaks, I'll blame you :)
 * mvo hiddes
<mvo> pitti: the desktop upgrade tests look good but I did not test as much this time :/
<mvo> (as in previous cycles)
<robert_ancell_> Can someone explain this to me, if I look on http://git.gnome.org/cgit/gdm/log/daemon/gdm-display.c at the last change it shows modifications to gdm_display_real_get_timed_login_details() but if I look at the master version the changes arent there (http://git.gnome.org/cgit/gdm/tree/daemon/gdm-display.c). ???
<alexmurray> @robert_ancell: works for me - the change removed the FIXME comment and the comment isn't there from what I can see in the second link you posted
<robert_ancell> alexmurray, what about the branch "if (usernamep != NULL && *usernamep != NULL) {"
<alexmurray> I can't see that in the diff for the commit..
<alexmurray> thats in gdm-slave.c
<robert_ancell> alexmurray, ah, thanks.  I knew I was going mad :)
<dholbach> cjwatson, james_w: just FYI: ubuntu-reviews@ was created
<dholbach> I don't know how we could route merge proposals and stuff that way
<YokoZar> If I'm splitting a package should I wait for the child to be out of the new queue before uploading the parent version that depends on it?
<MacSlow> didrocks, ping
<slytherin> YokoZar: yes
<didrocks> MacSlow: pong
<MacSlow> didrocks, greetings
<slytherin> if I have uploaded a bug fix revision for a package which is waiting in 'unapproved' queue, when is it like to get approved? after beta?
<MacSlow> didrocks, do you have any idea how to work-around https://bugs.edge.launchpad.net/ubuntu/+source/anjuta/+bug/438792 until there's proper fix? (trying to downgrade anjuta atm)
<ubottu> Launchpad bug 438792 in anjuta "segfault in symbol_db_engine_file_exists()" [High,New]
<slytherin> tseliot: Are you handling -ati driver packages currently?
<tseliot> slytherin: yes, I am
<didrocks> MacSlow: yeah, seb128 ping me about this one. It was working when testing it in an unclean box. So, I'm preparing a new version just now, but I don't have a box to test before tonight
<slytherin> tseliot: is the problem described in the bug likely to be caused by bad driver - bug 422807
<ubottu> Launchpad bug 422807 in moovida "No icons on home screen" [Undecided,New] https://launchpad.net/bugs/422807
<tseliot> let me check
<MacSlow> didrocks, ah cool that you're on it already. For the time being I'll stick to the downgraded version (hope that works out as planned). Thanks!
<didrocks> MacSlow: can you tell me about the downgrade result? I guess libgdl is maybe guilty
<tseliot> slytherin: are you using Karmic? What card are you using?
<slytherin> tseliot: Yes I am using karmic. The card is Radeon 7000. The reason I suspect it is driver problem is because I get garbled display in notify-osd notifications as well.
<MacSlow> didrocks, seems to have worked... sofar. No segfault for using anjuta_2%3a2.27.5.0-0ubuntu2_amd64.deb and anjuta-common_2%3a2.27.5.0-0ubuntu2_all.deb
<tseliot> slytherin: I think I have a bug report about radeon 7000 and notify already
<slytherin> tseliot: can you please tell me bug number when you find it? I will see if I can add more info to it.
<tseliot> slytherin: I'll put the final release of mesa in a PPA. That might help
<didrocks> MacSlow: thanks for the feedback
<slytherin> tseliot: That will be great. I can test it anytime this week.
 * tseliot looks for the bug report
<tseliot> slytherin: bug #429295
<ubottu> Launchpad bug 429295 in xserver-xorg-video-ati "OSD showing corruption on ATI graphics" [Medium,Confirmed] https://launchpad.net/bugs/429295
<mvo> Riddell: do you have a opinion what to do in app-install-data with applications available for both kde3 and kde4 - should we just display both (that is what is done now) or should there be some cleanup for karmic-final?
<slytherin> tseliot: Right. Same behaviour on my PC.
<tseliot> slytherin: it looks similar to bug #416001
<ubottu> Launchpad bug 416001 in xserver-xorg-driver-ati "Notification and similar dialogs are displaying corrupted after update on Karmic" [Unknown,Confirmed] https://launchpad.net/bugs/416001
<tseliot> even though the corruption is orange in the 2nd case
<tseliot> (it might depend on the background colour)
<slytherin> I don'r remember what is colour of the corruption in my case. But the behaviour is same for notify-osd.
<tseliot> ok
 * hyperair stabs nm-connection-editor
<hyperair> accept my settings already damnit!
<hyperair> what the hell's wrong with this thing?!
<Riddell> mvo: got examples of kde 3 and 4 apps? there shouldn't be too many
<mvo> Riddell: kspread , kxsldbg, koffice, klinkstatus, mailody, kimagemaeditor, klpato - that seems to be aobut it
<cjwatson> pitti: did you upgrade lp:~ubuntu-core-dev/usplash/ubuntu?
<cjwatson> as in bzr upgrade
<pitti> cjwatson: yes, I did; did it break?
<pitti> (it still has the backup)
<pitti> bzr complained that it couldn't push there
 * pitti recently upgraded his local branches to 2a
<cjwatson> that's ok, I just wanted to know. bzr gets upset about mixed 2a and non-2a branches so it just means I have to upgrade too
<cjwatson> (I have a local non-2a repository in the directory above my usplash checkout, which I'm upgrading now)
<cjwatson> better now
<tkamppeter> pitti, hi
<pitti> hey tkamppeter
<pitti> tkamppeter: FYI, I fixed the raw printer usb device permissions in udev trunk, so that lsusb will work again
<cjwatson> I'm thinking that usplash really needs options to daemonise itself and write a pidfile
<cjwatson> this business with backgrounding usplash in the initramfs script is racy
<tkamppeter> pitti, I have patched the CUPS usb backend to support both usblp and libusb, including tolerating the URIs of method B when printing via method A.
<mvo> pitti: how is the release upgrade going?
<tkamppeter> pitti, what change did you exactly do on the usb device permissions? Simply made them world-readable?
<tkamppeter> pitti, here is the patch: http://pastebin.ubuntu.com/282020/
<tkamppeter> pitti, it has the following functionality:
<tkamppeter> pitti: It uses both libusb and usblp for discovery, I have done some fixes that at least the make/model part of the URIs is the same, extra info in the libusb URIs which can only be obtained via libusb I leave in the URIs.
<tkamppeter> pitti: For printing at first usblp is tried and if the device is not found libusb. If the device is not found there, too, the procedure is repeated after 5 seconds.
<tkamppeter> When printing the device is identified by matching the queue's URI with the discobvered URIs. I have modified this matching that libusb-generated URIs can be matched against usblp-generated ones and vice versa.
<tkamppeter> pitti: This allows loading and unloading the usblp kernel module between queue setup and printing or between print jobs in general. It also should make queue set up with Jaunty work under Karmic's CUPS, both with blacklisted usblp or usblp being loaded normally.
<slytherin> are we still processing package removals in sync with Debian?
<cjwatson> not in general, request ones you need
<cjwatson> continuing to process package removals after ceasing to process automatic syncs is a recipe for stuff going wrong :)
<slytherin> cjwatson: Ok. I want vecmath1.2 to be removed, but before that cdk needs to be synced. There is already a sync bug for cdk, no bug for vecmath1.2 removal.
<pitti> mvo: just finished, mostly ok; I have a short list of issues
<slytherin> cjwatson: The bug for cdk sync is bug #438525.
<ubottu> Launchpad bug 438525 in cdk "Sync cdk 1:1.0.2-4 (universe) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/438525
<cjwatson> slytherin: um, sorry, request -> in a bug report please - we won't be doing much extraneous archive admin until after beta
<slytherin> cjwatson: Ok. I will file bug for vecmath1.2 removal after cdk is synced.
<cjwatson> and I certainly won't in general process archive admin requests on IRC since that gets us into a world of pain :)
<pitti> cjwatson: on jaunty->karmic ugprade is it expected to stay with grub 1?
<cjwatson> yes
<sladen> cjwatson: FWIW, I haven't seen usplash during boot for a couple of weeks
<sladen> cjwatson: should it still be there (instead of the scrolling text)
<cjwatson> sladen: correct
<cjwatson> it was intentionally turned off; the intention is to get X up fast enough that we don't need it
<cjwatson> usplash actually slows that down
<cjwatson> so we use usplash only when it's needed (e.g. interaction like cryptsetup, known slow boot scenarios, etc.)
<pitti> mvo: biggest problem is that the cleanup stage removes all the language-support stuff (gimp and OO.o help and translations, etc.)
<pitti> mvo: we dropped language-support-translations-* in favor of a language-selector approach
<cjwatson> if you want it on your system, put USPLASH=y in /etc/initramfs-tools/initramfs.conf
<pitti> but the upgrade removes all of them
<sladen> cjwatson: I try to stick with the defaults, however four variants text scroll (font change, mode change, font change (again)) does look crap (total of 30.0 seconds spent in text mode)
<cjwatson> you're aware that you're looking at a work in progress
<sladen> cjwatson: I'd prefer a timer, and then fire up usplash after ~3 seconds.  A netbook will have got past that stage by then, hopefully
<cjwatson> talk to Keybuk
<cjwatson> (when he's around)
<slytherin> sladen: look at the positive side. You get to see error messages at boot time (if any) that you won't see otherwise unless you checked dmesg log. :-)
<ogra> sladen, echo "USPLASH=y" | sudo tee -a /etc/initramfs-tools/conf.d/mysplash && sudo update-initramfs -u
<cjwatson> any display of messages on the console by default before X starts is a bug, and I'd hope we can fix all that for final
<ogra> heh, you havent seen imx51 :P
<cjwatson> for x86 anyway
<ogra> but i hope that too
<ryanakca> cjwatson: /query ?
<cjwatson> ryanakca: if you want to /query me, just do so, don't ask
<ogra> cjwatson, what will be done about fsck then ?
<cjwatson> ogra: I *think* that if fsck needs to do anything non-trivial then we need to start up usplash for it
<cjwatson> but Keybuk may have other thoughts
<StevenK> As well as prompting for things like mount passphrases?
<cjwatson> I believe that's already done
<cjwatson> if you use cryptsetup then that's supposed to cause the USPLASH option to be turned on when generating the initramfs
<pitti> tkamppeter: dev permissions> yes, 0664 now
<cjwatson> well, at least for /, it may not be hooked up for other things yet
<pitti> tkamppeter: nice! great work
<tkamppeter> pitti, I am going to upload it to BZR.
<pitti> tkamppeter: did you already propose that to Mike? it seems to be much better than having to decide at compile tie
<pitti> tkamppeter: then we'll drop the blacklisting again, right?
<tkamppeter> pitti, not yet.
<tkamppeter> pitti, I have prepared the commit, I will commit now, then you can drop the blacklisting.
<ogra> hrm
<tkamppeter> pitti, committed.
<ogra> mat_t, the xsplash image is loaded dynamically and based on the name, right ? i'll do some tests if other formats change anything wrt "tree rings" once i'm done with my beta install tests
<mvo> pitti: language-support> hm, that stuff is not in the "translations" section? stuff from that section is not removed (or should not get removed)
<mvo> pitti: I'm curious about the other issues too
<mat_t> ogra: great, thanks!
<pitti> mvo: no, it's in doc (gimp-help-de, openoffice.org-help-de) or editors (openoffice.org-l10n-de) or whatnot
<mat_t> ogra: not sure how it's loaded, probably best to ask bratsche
<pitti> mvo: there are some difficulties with fvwm and xsplash (not upgrade specific, and not supported)
<ogra> mat_t, though i doubt i can easily change jpeg to svg
<pitti> mvo: the other main issue was that DNS hangs/times out for 10 seconds
<pitti> I first got that in karmic some months ago
<ogra> but i'll try png and whatever else comes to my mind
<pitti> it doesn't happen with jaunty, does happen with karmic, on the same router/ethernet
<mat_t> ogra: you could just create a simple svg with a gradient I guess
<pitti> but nobody else seems to have this problem
<pitti> I already played around with nssswitch, no change (to rule out avahi stuff)
<ogra> mat_t, oh, indeed, i thought you wanted me to use the jpeg as base
<mat_t> ogra: I can create one if that would help
<ogra> nah, i know my way around inkscape :)
<mat_t> :)
<mvo> pitti: hm, I look into the translation stuff today and add some transition code
<pitti> mvo: so for upgrade specific stuff, the translation stuff was the main issue
<pitti> mvo: ArneGoetje wrote a script to display missing packages for a language; perhaps this can be modified also to show required packages (even if they are still installed)
<pitti> without language-selector code it's not really easy to tell which are translation related
<mvo> pitti: yeah, I think it needs to include some code from the karmic l-s to ensure that it does the right thing
<pitti> mvo: the script is in the l-s tree now, but I guess it needs some tweaks to be useful for this case
<pitti> mvo: I'll file a bug to track and discuss this
<mvo> pitti: thanks
<pitti> mvo: the other option would be to collect the l-s-translations-* dependencies beforehand and substract them from the cleanup list?
<pitti> well, I'll elaborate in the bug
<mvo> pitti: that would work as well
<pitti> done in bug 439296
<ubottu> Launchpad bug 439296 in update-manager "jaunty->karmic upgrade removes former language-support-translations-* dependencies" [High,New] https://launchpad.net/bugs/439296
<pitti> tkamppeter: thanks; I removed the blacklisting (also on upgrade) and fixed the changelog; building now, will upload to sid later
<joaopinto> sox is not installable, because libgsm1 is not available, is this a temporary building problem or should I file a bug report ?
<joaopinto> hum, sox is in universe, better ask on motu :P
<tkamppeter> pitti, thanks. Now the only thing is that USB printing will more or less continue the old way: A printer is plugged and usblp automatically loaded. Then all printing goes automatically through usblp. This way all legacy add-ons (foo2zjs firmware load, escputil without print queue, libinklevel, ...) and also several manufacturer backends will continue working, but on the other side printers will not get accessed in libusb mode making us
<tkamppeter> e of the advantages of libusb-based access.
<tkamppeter> pitti, at least a program can detach a printer from the kernel module now (like HPLIP) and a queue based on the usb CUPS backend stays working.
<mdz> kirkland, did your localhost->lan IP change fix the registration issue?
<seb128> hum bug #439316
<ubottu> Launchpad bug 439316 in gdm "GDM won't start, hangs in upstart on "emit starting-dm"" [Undecided,New] https://launchpad.net/bugs/439316
<ogra> hmm, if i select an encrypted homedir during install i get usplash ?
<ogra> even though it doesnt ask me anything ?
<cjwatson> Keybuk: ^- bug 439316 - did I break something when I added that?
<ubottu> Launchpad bug 439316 in gdm "GDM won't start, hangs in upstart on "emit starting-dm"" [Undecided,New] https://launchpad.net/bugs/439316
<cjwatson> that "start: Unknown job: S04kdm" bit is a bit suspicious too, I wonder what's causing that
<cjwatson> leftover rc.d symlink to something that's now an upstart job?
<didrocks> MacSlow: seb128 confirmed that he doesn't have anjuta crashing either. I pinged upstream about the issue but nobody's present today. I'll still update anjuta to 2.28.0 as the work is done :-)
<ogra> mat_t, hmm, opening the existing xsplash wallpaper in gimp pops up a message about an embedded color profile ... could that be our issue ?
<mat_t> ogra: I'd be surprised if it was
<mat_t> ogra: app that does not deal with profiles would simply disregard it
<mat_t> ogra: I can give you a version without the profile if you have time to test it
<ScottK> mvo: I didn't see where you got an answer to your kde3/4 question.  My opinion would be show them both.  In all those cases the KDE3 versions are generally preferred because the KDE4 versions have maturity issues, but there will be people who want the KDE4 one anyway.
<ogra> i'm done with beta image tests for now, so i have time to look into xsplash
<slacker_nl> anyone else having troubles with the keyserver, unable to upload my key, keeps timing out
<Keybuk> cjwatson: reading
<Keybuk> (sorry, bit lagged, my laptop is a bit screwed so just trying to get set up on another)
<Keybuk> on the bright side, this means I'm actually doing CD testing ;)
<slacker_nl> lol
<Keybuk> cjwatson: what did you change?
<mvo> ScottK: ok, thanks. that is fine with me, its a bit ugly in the U Icurrently because the only difference in the description is the package name
<pitti> hey Keybuk, welcome back
<cjwatson> Keybuk: I upstartified usplash so that we could actually reliably make it go away when gdm starts
<Keybuk> cjwatson: oh, I had some packages for that
<cjwatson> this included making gdm emit a starting-dm event
<Keybuk> why not just use "starting gdm" ?
<cjwatson> or starting kdm or ... besides, I couldn't find a way to make that work with "text"
<Keybuk> fair point
<Keybuk> I'll need to look at what you did
<Keybuk> and compare it with what I was doing
<cjwatson> the thing that seems to be hanging is the initctl emit, but presumably that blocks until all the stuff hung off that event has finished
<Keybuk> exactly
<Keybuk> which is what you want
<cjwatson> yeah
<cjwatson> I don't see anything in the usplash job I added that could block indefinitely
<cjwatson> hmm, unless it's the usplash_write
<Keybuk> once I'm back up, I'll take a look
<cjwatson> that might block if nothing's on the other end of the fifo
<Keybuk> did you write the pid of usplash from the initramfs to /dev/.initramfs/usplash.pid ?
<cjwatson> yes
<Keybuk> neat :p
<cjwatson> that's a lovely upstart hack BTW
<Keybuk> yes, I thought so
<Keybuk> it's great because it means you can put all the "start on" stuff in the actual job
<Keybuk> so without-initramfs works too
<cjwatson> or, in this case, we can actually stop usplash on "stop"
<Keybuk> right
<cjwatson> yeah, I didn't do start stuff for this - I probably ought to have done
<Keybuk> I did start for the shutdown case
<cjwatson> I figured it wasn't the end of the world if without-initramfs didn't have usplash for the moment
<cjwatson> oh, I made that a separate job because I found that less confusing
<cjwatson> I fully expected you to tear it apart when you got back though :-) My bits do seem to work for a respectable number of people, but there's obviously the odd case where they don't
<cjwatson> it may be that the only reliable fix is to fix usplash's main loop so that we can just send it SIGTERM
<ogra> mat_t, ok, testing an svg i ran into something intresting ... apparently xsplash is not using the 1024x768 picture on my 1024x768 screen ...
<cjwatson> I had to nobble that in a really nasty way for the time being
<Keybuk> oh
<Keybuk> I didn't commit the SIGTERM patch? :)
<cjwatson> not so I noticed; the main loop is still a horrible bodge
<cjwatson> needs to be a proper select loop
<ogra> mat_t, i see the tree rings on the svg as well though, but that might be caused by scaling the image actually
<cjwatson> doing it in the current loop didn't seem possible in a non-racy way
<cjwatson> (may actually need to be pselect)
<ScottK> mvo: I agree about the ugliness, it's just that the ones that have both KDE3 and KDE4 versions have both for a good reason, so there's no way to really pick which to show.
<Keybuk> oh, I didn't bother about that
<mvo> ScottK: yeah, its a tiny amount, for the next cycle I think I will try to come up with some generic way to annotate if two names are identical
<Keybuk> I just changed "for (;;)" to "while (! exit_loop)"
<cjwatson> and if usplash just gets SIGTERM/SIGKILLed without cleaning up properly, then you get stuck at a console with no way to get out
<Keybuk> then select() returns -EINTR
<Keybuk> and all is fine
<cjwatson> at least that's what happened to me
<mat_t> ogra: did you create a new svg?
<Keybuk> it looks the same as a timeout then
<cjwatson> sorry, stuck at the splash screen
<mvo> mpt: actually - what do you think about adding the packagename behind the app name if there are multiple apps with the same name (happens e.g. for System Monitor - gnome-system-monitor and ksysguard) and also for kspread (kde3, kde4 version)
<ogra> mat_t, yup ...
<ogra> and it apparently uses 1280x1024 on a 1024x768 framebuffer
<mat_t> ogra: ok, so there's nothing wrong with the image then
<mpt> mvo, in brackets, that makes sense
<mpt> mvo, e.g. "System Monitor (ksysguard)"
<cjwatson> Keybuk: BTW, spotted a fun gotcha while using the initramfs import hack - totally doesn't work if your job doesn't have a main process defined :)
<cjwatson> hence my "exec true" hack for the time being
<Keybuk> right, indeed it deliberately checks for that ;)
<Keybuk> oh
<Keybuk> why do you have an "exec true"?
<Keybuk> why not just have *usplash* as the main process?
<Keybuk> then "status usplash" returns its pid and stuff
<cjwatson> that would be more correct, but I was up against beta CD rolling
<cjwatson> I think status usplash does work
 * Keybuk would have just left usplash off ;)
<ogra> mat_t, nope, gdm now uses the bg image too and it displays it just fine during boot ... which for me results in a "tree rings on, rings off, rings on, rings off, yay i see the desktop" effect
<cjwatson> I thought about that, but it's damnably ugly on live CDs
<Keybuk> working > ugly
<cjwatson> and we already force it on for cryptsetup
<cjwatson> do we not?
<Keybuk> true
<cjwatson> so had to make it go away somehow
<mpt> mvo, also, danilo just showed me how to generate a .pot file from the help .xml file. When would be a good time to go over that with you?
<ubuntu0ath1> What does staging drive mean ? I am talking about the rt2860 module and when will it become normal?
<cjwatson> in fact, FWIW, I don't think there's any way that 'exec true' could break 'status usplash', unless upstart is wrong :) by definition, if it's imported a running job from the initramfs, it shouldn't start it again
<cjwatson> and certainly it gets stopped correctly, which was what I was mainly concentrating on
<cjwatson> well, modulo this weird bug
<mvo> mpt: well, it needs to be done in both ways and we clarify if we can ship that via a update, otherwise I think its not that useful
<mvo> mpt: re multiple apps with the name name> I have a look at the code to see what can be done
<cjwatson> Keybuk: if you have that SIGTERM patch handy, I can probably run with it
<cjwatson> though probably leave it the way it is for beta now
<Keybuk> if things are working for you, I'd leave it alone
 * Keybuk would only break it again
<cjwatson> well, we know they aren't working for everyone, and I'm not actually *happy* with the current state
<mpt> mvo, ok, I reported bug 439353 with the details
<ubottu> Launchpad bug 439353 in software-center "Help file isn't localizable" [Undecided,New] https://launchpad.net/bugs/439353
<mat_t> ogra: right, not  a great experience then
<ogra> yup
<ogra> i'm looking at the xsplash code now to find out what kind of rednering it does
<mat_t> ogra: cool
<mat_t> ogra: keep in touch with Cody, he's assigned to the bug I think atm
<ogra> i'll report everything i can figure out there
<mat_t> great
<pitti> tkamppeter: tested it on my wife's computer, works fine again (was pretty broken before)
<mvo> mpt: thanks
<tkamppeter> pitti, CUPS usb patch is submitted upstream now: http://www.cups.org/str.php?L3357
<pitti> tkamppeter: nice, thanks
<mvo> mpt: I commited the multiple apps detection, that should be good enough for karmic, I think we could consider writing a "adopt app-install-data" position for someone (or a team) who has fun going over the apps in app-iinstall-data and checking what is appropriate, what is duplicated, what has a bad description etc
<mpt> mvo, I've just been discussing with bigjools and sinzui on the Launchpad team how to make that metadata user-editable
<mpt> so that package maintainers can say "ooh, I like that description better" -> ( Merge )
<Keybuk> pitti: usplash 40 ... did you upload yet?
<pitti> Keybuk: yes, it's in the queue; but we can just upload another one, or I reject that one and we un-tag
<Keybuk> pitti: it's ok - have some patches but we can do a .41
<pitti> sounds good; I just wanted to fire & forget
<pitti> so if it's not for beta, .41 seems easier
<cgregan> Anybody out there have a sec to talk about start-up applications and Gnome-do?
<Hatl> hi! i updated my kubuntu to 9.10. now i have the following error: http://pastebin.com/m25361f7b any suggestions?
<kirkland> mdz: it certainly caused the messages in all 3 of the registration logs to say "SUCCESS: ...successfully registered"
<kirkland> ttx: yo
<kirkland> ttx: i'm back from running now, syncing the .2 iso's
<ttx> kirkland: hey.
<kirkland> ttx: can you quickly bring me up to speed?
<ttx> the .2 is -0ubuntu12
<ttx> the one with the /var/run fix
<kirkland> ttx: and dropped the localhost fix?
<slytherin> cgregan: gnome-do is in universe repository. #ubuntu-motu is he ideal channel to discuss it.
<ttx> We need to revert the chages and upload a 0ubuntu14 that is code-equivalent to 0ubuntu12
<ttx> then take our time to understand what went wrong with 0ubuntu13
<ttx> except the unlucky number.
<ttx> kirkland: its -0ubuntu12. With all its known issues.
<ttx> so We document manual registration for beta
<cgregan> thanks slytherin
<kirkland> ttx: what does manual registration look like?
<ttx> kirkland: sorry for the total reversion but given how many people can actually test the whole process we don't have enough time left now
<slytherin> Hatl: Bug directx on #ubuntu-motu
<ttx> kirkland: http://testcases.qa.ubuntu.com/Install/ServerECluster
<ttx> kirkland: yes, I know, it's troubling.
<ttx> kirkland: especially since I ran those commands to try to "fix" 0ubuntu13 and it was still failing.
<kirkland> ttx: so IPADDRESSOFTHECLUSTER is the real IP, not "localhost" and not "127.0.0.1"
<ttx> kirkland: the NC seemed stuck on 127.0.0.1 no matter how much effort I put into it to make him forget it
<ttx> yes.
<kirkland> ttx: that bothers me
<kirkland> ttx: that's precisely the change i made in the code
<ttx> kirkland: yes, it's exactly what you do.
<kirkland> ttx: which i think is a good, necessary change
<ttx> kirkland: I couldn't make it work. It fails to start an instance on the NC
<ttx> for some very weird reason, I'm sure
<ttx> kirkland: do you have a full UEC setup at your disposal now ?
<ttx> kirkland: oe tat you can test the instance run on ?
<ttx> s/oe tat/one on which/
<kirkland> ttx: i will shortly
<kirkland> ttx: i suppose i need the .1 iso?
<ttx> kirkland: at this point we need to revert the changes and upload a ubuntu14 so that people that upgrade after beta don't run into 13
<ttx> kirkland: 20090930.1 = 13
<ttx> kirkland: 20090930.2 = 12
<ttx> I really was hoping that 13 would cure it all, it seemed very reasonable and conservative
<kirkland> what a mess
<ttx> kirkland: I hope its not a glitch in my test env, but since I'm the only one to test it from A to Z, we don't really have a choice
<Keybuk> kirkland: I hear you've been casting aspersions on Upstart? :)
<ogra> Keybuk, hey ... is there a way i could make a udev rule inject a property into /sys/devices/virtual/net/eth0 ?
<Keybuk> ogra: no.
<ogra> :(
<Keybuk> ogra: actually, what do you mean "inject a property" ?
<ogra> bug 438687
<ubottu> Launchpad bug 438687 in network-manager "FEC driver does not set "DRIVER" property in udev which makes network-manager fail" [High,New] https://launchpad.net/bugs/438687
<Keybuk> if DRIVER is not set, it means that the driver isn't bound to the device
<ogra> NM doesnt like our NIC driver because it doesnt expose "DRIVER"
<ogra> well, it works fine
<ogra> its just NM that doesnt recognize it because of that
 * Keybuk thought DRIVER was set by the pci subsystem
<ogra> there is no pci subsystem :)
<ogra> well, no visible one
<Keybuk> oh, fix your stupid architecture then <g>
<ogra> pfft
<liw> the totem BBC plugin is only useful for people in the UK, right?
<ogra> most arm arches dont expose the PCI bus, even if they have one
<Keybuk> so fix that
<ogra> liw, there are some free stations you cen get in other countries
<Keybuk> or fix whatever subsystem you do use
<ogra> Keybuk, can i broow your soldering iron ?
<Keybuk> if your kernel isn't setting DRIVER, that's a kernel bug
<ogra> its not visibly exposed by the HW
<Keybuk> so?
<Keybuk> visibly exposed doesn't make a difference
<Keybuk> DRIVER is set by a subsystem to indicate the subsystem driver being used
<ogra> so how should i invent a virtual PCI bus then
<Keybuk> you're being deliberately stupid, right?
<ogra> well, thats different on a SoC
<Keybuk> you still have kernel drivers
<Keybuk> and you still have kernel subsystems
<ogra> right, but often no subsystems at all ...
<Keybuk> you have subsystems
<Keybuk> even it
<Keybuk> even if the subsystem is "arm"
<ogra> the drivers often dont use the subsystems which makes merging the patches so hard
<Keybuk> they have to
<Keybuk> you can't have a driver outside of a subsystem
<ogra> right, might be arm
<MacSlow> popey, ping
<ogra> or in case of that board mxc
<popey> MacSlow: pong
<Keybuk> exactly
<Keybuk> so fix that subsystem to expose DRIVER
<pitti> liw: well, people from other nations might watch it, too; why?
<ogra> not the driver itself then ?
<pitti> liw: but I guess it's very UK centric indeed
<MacSlow> popey, hey Alan... can you revisit https://bugs.edge.launchpad.net/notify-osd/+bug/334863 again... this should not happen anymore.
<ubottu> Launchpad bug 334863 in notify-osd "notification are partially off-screen on res change" [Medium,Confirmed]
<Keybuk> ogra: no, the way driver core works is that most of this stuff is subsystem owned
<popey> MacSlow: sure
<ogra> Keybuk, ok
<MacSlow> popey, cool thanks
<Keybuk> otherwise you'd have to fix every driver
<liw> pitti, just curious, #421318
<ogra> well, thats what freescale likes to do apparently :)
<pitti> liw: oh, is it the bbc plugin which causes the totem crash?
<ogra> by working around as many subsystems as they can
<liw> pitti, there is crash if bbc is only plugin enabled; disabling it removes crash
<pitti> liw: this one is stupidly hard to track down apparently (seb128 and robert_ancell already beat on it for hours)
<liw> the proper fix is to stop using threads, but that's a bit of a non-intrusive change
<Keybuk> ogra: you're going to find that there are increasingly more things that expect the kernel to work a particular way
<ogra> Keybuk, in any case thats amitk country ... i was just looking for a quickfix through faking something via udev
<Keybuk> so hacked around or buggy drivers are going to simply not work
<seb128> liw, the bbc code didn't change at all since jaunty and that used to not crash
<ogra> yes, i know, i use that hardware every day and discover issues every day :)
<liw> seb128, that doesn't mean it isn't buggy
<seb128> liw, right, it's just weird that it started crashing where it was not beofre
<Keybuk> we have a hard enough problem making the things that work right work ;)
<liw> seb128, I've become convinced that any Python code that uses threads is inherently buggy; perhaps this just didn't happen to show earlier...
<liw> seb128, but it might be something in totem itself that just gets hit by the bbc plugin
<ogra> Keybuk, dont tell me ... :)
<pitti> seb128, liw: we also have new compiler options in karmic, etc., don't we?
<liw> pitti, yes; also, new kernel, and new libc, and ... anything might affect this
<liw> hm, epiphany has changed the default home page from what I had configured earlier to http://www.debian.org
<seb128> that's probably the switch to epiphany-webkit default
<liw> right
<liw> (it's still impolite of it)
<seb128> yeah, not discussing that there is a bug there
<Amaranth> doko__: for bug 300948 isn't the fix to just add compiz to the check? current it checks for metacity or kwin, right?
<ubottu> Launchpad bug 300948 in openjdk-6 "openjdk : SystemTray.isSupported() bug" [Undecided,Incomplete] https://launchpad.net/bugs/300948
<slytherin> seb128: Hi. totem-plugins-extra depends on a obsolete package (coherence), the package has been renamed to python-coherence. Should I file a bug about this or will you fix it in next upload (whenever it happens).
<seb128> slytherin, look if there is a bug open an file one if that's not the case
<seb128> it will be easier to track this way
<liw> hmm, totem-python-module.c calls PyEval_SaveThread but not PyEval_InitThreads, I wonder if that's a problem
<slytherin> seb128: ok
<liw> oh, the thread module calls is automatically, never mind
<pitti> liw: hang on, is it using gtk with threads?
<liw> pitti, totem uses gtk, the bbc plugin uses python threads, at least
<pitti> liw: I use threads in apport, and I noticed that Qt spectacularly fails if you have qt code in more than one thread
<pitti> I didn't quite get those crashes in apport-gtk, but still gtk is not thread safe
<pitti> if it works, it's sheer luck
<liw> indeed
<pitti> before I actually used two mainloops in two threads
<pitti> now I cleaned it up using some IPC to only have one main loop
<MacSlow> popey, btw... on which GPU/driver combo is this LP: #334863?
<liw> and indeed, the bbc plugin uses _both_ threads and gtk
<doko__> Amaranth: yes, somebody has to either dig out the upstream patch, or patch our jdk build
<Amaranth> doko__: I don't think I have enough RAM to build openjdk :P
<doko__> Amaranth: swap space is cheap ;p
<cjwatson> liw: the intention was that the bbc plugin would be useful outside the UK too, although with a restricted range of content
 * ogra offers some nbd swapspace to Amaranth 
<slytherin> Are alternate CD images for ports architectures likely to be recreated for beta? The images for powerpc and ia64 are oversized.
<kirkland> Keybuk: potentially; mathiaz investigated that more deeply while i looked for other solutions
<ogra> unlikely unless someone fixes them
<kirkland> Keybuk: any chance you can sanity check our eucalyptus upstart configuration?
<ogra> someone being community
<kirkland> Keybuk: one thing I don't understand is that there are several that we need to run in series, and it seems they're executing in parallel
<kirkland> Keybuk: which is causing non-deterministic behavior
<cjwatson> slytherin: do they actually build at the moment? I saw some build failures ...
<Keybuk> kirkland: if you tell me what packages to look at
<liw> hm, I see the same problem with the BBC plugin on jaunty
<kirkland> Keybuk: bzr branch lp:~ubuntu-core-dev/eucalyptus/ubuntu
<kirkland> Keybuk: they're all in the debian directory
<slytherin> cjwatson: they were built last on 29th September which is same as non-ports arch. - http://cdimages.ubuntu.com/ports/daily/current/
<cjwatson> slytherin: ok, somebody in the community will have to fix the oversizedness then, as ogra says
<cjwatson> (or tell us what to do)
<slytherin> cjwatson: Any hints where to look for root cause?
<Keybuk> kirkland: wow, messy
<Keybuk> I suspect you need "task" in some of them
<cjwatson> slytherin: not really, you just have to plug through the package list and work out what's unnecessary
<slytherin> hmm
<Keybuk> e.g. eucalyptus-cc-publication looks more tasky to me
<Keybuk> as does eucalyptus-cc-registration
<Keybuk> eucalyptus-cloud is just freaky
<Keybuk> no idea why that's done the way it is
<Keybuk> not even entirely sure that *works* :p
<Keybuk> eucalyptus-sc-registration looks tasky
<Keybuk> eucalyptus-walrus-registration looks freaky
<Keybuk> as does eucalyptus-walrus
<highvoltage> wow.
<crescendo> Is there a place I can see the reasons for package inclusion decisions in each release of Ubuntu?  For example, I'd like to see why xchat-gnome was chosen over xchat.
<popey> MacSlow: intel
<MacSlow> popey, ok
<seb128> crescendo, how chosen? it's not installed by default
<crescendo> seb128: Err, I suppose that package is a bad example, but xchat-gnome is now the only on in the "supported" repos, but xchat is not.  There are other packages that I'm interested in.
<seb128> I don't think there is one summary for those
<crescendo> seb128: mainly, to discern the differences between package distributions and come to a decision on which package I should use personally
<seb128> it's often mailing list or uds discussions ie blueprints
<crescendo> seb128: have a link, or is it non-centralized?
<seb128> as said there is not one location for those
<seb128> it depends of the software
<crescendo> Oi. Who manages the Ubuntu repos?  Maybe I could start there
<seb128> it's usually discussed by the group of people concerned
<directhex> or irc meeting logs
<seb128> ie ubuntu-desktop for desktop choices
<slytherin> cjwatson: Is there any way to create a local image so that I can compare it with the official one to check what is causing problem?
<cjwatson> slytherin: that's a lot of work and not actually very helpful in this kind of case, IME
<seb128> crescendo, the discussions come usually from teams working on those
<seb128> ie xchat-gnome is an #ubuntu-desktop topic
<seb128> the rational for this one is that it's using GNOME infrastructures, cleaner ui, etc
<cjwatson> the ubuntu-archive team manages the Ubuntu repositories, but we don't as a general rule take executive decisions on what to include or what not to include - we're an operational team
<slytherin> cjwatson: I wondered why we shipped both 32 bit and 64 bit kernels but that doesn't seem to have caused problem before this.
<cjwatson> as seb128 says, executive decisions are up to the teams with most direct knowledge
<cjwatson> slytherin: we have to, but it certainly puts more pressure on powerpc
<cjwatson> slytherin: there's no one kernel that boots on both powerpc32/64, although the userspace is the same
<crescendo> @cjwatson: is there a log kept anywhere as to who made what changes?
<cjwatson> crescendo: there's the seeds, https://code.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu.karmic et al
<cjwatson> crescendo: that's not everything, but it sounds closest to what you want
<cjwatson> also .../platform.karmic
<crescendo> aha, this is perfect. I have enough to chew on for a while now, thanks
<cjwatson> also http://wiki.ubuntu.com/SeedManagement
<cjwatson> and the germinate(1) manual page for the technical structure involved there
<MacSlow> popey, I can verify LP: #334863 to be fixed with the latest notiy-osd 0.9.22 under Karmic
<cjwatson> slytherin: ia64 would be a different problem, presumably, since I'm fairly sure it only has one kernel these days
<slytherin> cjwatson: I found one problem but that may not explain oversize. It just explains the uninstallability of many packages (http://cdimages.ubuntu.com/ports/daily/current/report.html). Older synaptic version (ubuntu4 instead of ubuntu5).
<cjwatson> slytherin: is the package out of date in the archive too?
<cjwatson> apparently not, presumably it was just slow to build
<cjwatson> slangasek: ok if I trigger a new ports/alternate build?
<slytherin> cjwatson: No. Looks like the ports images were built long before non-ports images. Hence this inconsistency.
<slangasek> cjwatson: go for it
<cjwatson> slytherin: not unusual
<cjwatson> </earworm>
<slytherin> cjwatson: may be the cron job time modified and not reverted later.
<slangasek> Keybuk: hmm, I was just going to call the job 'statd' actually; do you have a preference for 'rpc.statd'?
<cjwatson> slytherin: no, they're normally at different times
 * slangasek thinks the latter is ugly :)
<cjwatson> slytherin: they're intentionally independent cron jobs
<slytherin> cjwatson: That's all for now. I will take another look later for more analysis.
<Keybuk> slangasek: no preference
<slangasek> Keybuk: ok.  so, one outstanding corner case with the nfs-common stuff: pre-upstart, it was possible to have a system work reliably with /usr on an NFSv3 filesystem and /home on NFSv4 w/ gss; now, our choices are to wait for "FHS" (including /home) before starting gssd, or to assume /usr is local - any thoughts on that?
<slangasek> I think I'm going to go with "assume /usr is local", but it doesn't feel correct to me :)
<slangasek> conveniently, if /usr is on NFSv3, we don't /need/ rpc.gssd or rpc.idmapd, so it also doesn't hurt if they fail to start
<Keybuk> I'm not sure I'm following
<Keybuk> why doesn't it work?
<slangasek> Keybuk: rpc.gssd and rpc.idmapd are in /usr/sbin
<Keybuk> ok, so why can't you have them "start on filesystem" ?
<slangasek> to properly ensure /usr is available, we should start on filesystem
<slangasek> which precludes using NFSv4 for mounting /home
<slangasek> since 'filesystem' doesn't get signaled unless /home is mounted
<Keybuk> why does it preclude it?
<slangasek> "since 'filesystem' doesn't get signaled unless /home is mounted" - that's true, isn't it?  I know I saw bugs about that
<Keybuk> yes
<Keybuk> but why does it preclude it?
<Keybuk> if rpc.statd and rpc.nfsd are on /
<slangasek> if you want /home to be an NFSv4 mount?
<Keybuk> they are started on local-filesystems
<slangasek> you need idmapd (and possibly gssd) to do the NFSv4 mount
<Keybuk> oh, I see what you mean
<Keybuk> there's no event for "I have some of the filesystem but not /home"
<slangasek> right
<Keybuk> if we need that, we could add that ;)
<slangasek> I think it'd be a good thing to have
<slangasek> in the meantime, I'll wire it to use 'local-filesystems', I think that's closest
<Keybuk> *nods*
<Keybuk> kirkland: ignoring the "wow, I didn't know you could do that" and "I don't even know why you would want to do that" pieces of the scripts
<Keybuk> http://people.canonical.com/~scott/eucalyptus.png
<Keybuk> ^ that's how I think Upstart will run those
<Keybuk> if the aim is not to run things in parallel, fail appears to have happened <g>
<kirkland> Keybuk: :-)
<Keybuk> kirkland: what about that graph strikes you as wrong?
<Keybuk> without deeper understanding, I can't tell whether that's what's intended or not
<kirkland> Keybuk: well that's cool
<Keybuk> there are up to 5 parallel paths
<kirkland> Keybuk: let me check with euca-guys
<Keybuk> I should so write a Perl script to do that
<Keybuk> in fact, I'm going to!
<cjwatson> Keybuk: point of information: e8s ;-)
<cjwatson> "point of arithmetic", perhaps
<Laney> Keybuk: hey, that util-linux/udev bug (by-uuid symlinks pointing to block devices instead of mdadm partitions) seems fixed, is that right?
<Laney> http://dpaste.com/100429/
<slangasek> cjwatson: hah, you took the time to count? :)
<Darxus> I need a karmic live cd containing a package that went into the archive today to test a bug fix.  How do I get that?
<cjwatson> slangasek: my subconscious mind does it for me for words under about 12 letters, I think
<Darxus> Looks like my best option may be to wait for the next time this file is rebuilt?  http://cdimage.ubuntu.com/daily-live/current/karmic-desktop-i386.iso
<Keybuk> cjwatson: see, I can'
<Keybuk> cjwatson: see, I can't even figure out how many letters there are in that word!
<Keybuk> Laney: it should be fixed
 * ogra hands Keybuk a keyb-uk :)
<cjwatson> chrisccoulson: offhand, do you have any idea what happened to the syncio option in ntfs-3g, that we used to carry as an Ubuntu patch?
<Laney> Keybuk: good stuff
<Laney> thanks
<chrisccoulson> cjwatson - i'm not sure about that
<cjwatson> Darxus: if there isn't anything new enough in that location, then waiting (unfortunately until after beta) is probably your best option, yes
<chrisccoulson> i don't remember removing any patches
<cjwatson> chrisccoulson: I'm speculating whether it might be the cause of Wubi instability we're seeing
<Darxus> cjwatson: After beta?
<cjwatson> Darxus: yes, http://wiki.ubuntu.com/KarmicReleaseSchedule
<cjwatson> Darxus: what fix, out of interest?
<Darxus> cjwatson: https://bugs.launchpad.net/ubuntu/+source/alsa-utils/+bug/410933
<ubottu> Launchpad bug 410933 in alsa-utils "No sound in fresh jaunty install until disabling "external amplifier"" [Low,Incomplete]
<Darxus> Sound doesn't work by default on some hardware.
<Darxus> cjwatson: Oh, beta is tomorrow?  Why is that unfortunate?
<Darxus> Just because it would've been better to get the fix in before beta?
<cjwatson> Darxus: um, so
<cjwatson> Darxus: nobody claimed in that bug that any particular fix had gone into the archive
<slangasek> Darxus: there haven't been any alsa-utils changes accepted into the archive that aren't on that CD
<cjwatson> Darxus: Daniel just asked you to test with the most current thing
<Darxus> Ahh, thanks.
<Darxus> I can do that.
<Darxus> The bug will still be there though :P
<chrisccoulson> cjwatson - from a first glance, it looks like it might have been dropped off during a merge
<cjwatson> chrisccoulson: that's what it looked like to me; I was wondering if there was a reason you knew about, as the merger
<Darxus> I'm going to grab the iso I previously mentioned then....
<cjwatson> of course wubi passes it in such a way that I'm pretty sure it won't actually make it to mount
<cjwatson> but ANYWAY, I can fix that bit
<chrisccoulson> cjwatson - no, i don't remember dropping it off deliberately.
<Darxus> The fact that, at least briefly, the status was changed to "Fix Committed" was confusing.
<chrisccoulson> but that was sometime last cycle
<slangasek> Darxus: how do you know the bug will still be there?  The only information on the bug report is about jaunty, not karmic
<cjwatson> chrisccoulson: ok, thanks; I'll look at restoring it, so that at least we can eliminate that as a cause
<Darxus> slangasek: I'm just being pessimistic.
<kirkland> Keybuk: would you mind making a once-over pass across our upstart scripts, and making some suggestions?
<kirkland> Keybuk: sounds like you took a quick look and saw somethings that were non-standard
<cjwatson> chrisccoulson: we're seeing various symptoms, but at least one of them is consistent with stuff just not being synced to disk, hence this hunch
<Darxus> cjwatson: Could you clarify why you said that being after beta would be unfortunate?
<cjwatson> Darxus: it's irrelevant now, since you're not actually waiting for a fix that's in the archive; but if you had been, it would presumably be unfortunate for you that you would have needed to wait
<cjwatson> Darxus: FWIW Fix Committed never means fix-in-the-archive, in any case - that's Fix Released
<Darxus> cjwatson: Why would I have needed to wait?  Isn't beta tomorrow?
<cjwatson> ys
<cjwatson> yes
<cjwatson> but quite possibly late tomorrow
<Darxus> cjwatson: I'm not that impatient :)  Thanks for the clarification.
<seb128> cjwatson, in what templates are the ubiquity translations usually?
<seb128> cjwatson, ie the bootloader option screen
<cjwatson> seb128: which screen exactly? what's the text
<seb128> cjwatson, "Install boot loader" for example
<seb128> the whole screen is not translated in french there which seems weird
<cjwatson> that *is* odd, that string is translated in the source
<cjwatson> ubiquity/ubiquity-debconf, BTW
<cjwatson> I think the dialogs just aren't translated
<cjwatson> seb128: please file a bug on ubiquity about this specific thing
<seb128> cjwatson, ok, thanks
<Keybuk> kirkland: didn't I just do that?
<Keybuk> they look absolutely crazy to me
<Keybuk> like even just the first one
<Keybuk> you have a pre-start script to pick up options and write them to a file that the exec line picks up?
<Keybuk> WHY?!
<Keybuk>   script
<Keybuk>           . /etc/eucalyptus/eucalyptus.conf
<Keybuk>           exec avahi-publish -s $(hostname) _eucalyptus._tcp $CC_PORT txtvers=1 protovers=1.5.0 type=cluster\
<Keybuk>   end script
<Keybuk> etc.
<Keybuk> I'm entirely unsure why you need a post-start script, and can't just make apache daemonise
<Keybuk> (I don't think it detaches until it's listening, no?)
<Keybuk> there are scripts that only seem to exist to poll
<cjwatson> I think we do need to poll, there's a gap between eucalyptus listening on the port and actually working, AIUI
<mathiaz> Keybuk: ^^ yes
<Keybuk> so yes, I'm afraid of reviewing these in case
<Keybuk>  a) they eat me
<Keybuk>  b) it somehow results in me getting some kind of responsibility to fix them
<slangasek> one of those is polling apache; is that actually needed?
<maco> haha
<kirkland> Keybuk: alrighty, thanks
<kirkland> Keybuk: can you tell me how to figure out what this means:
<kirkland> Sep 30 11:45:40 cluster init: job_process_handler: Ignored event 1 (0) for process 844
<mathiaz> slangasek: well - apache2 is started with axis, which needs to deploy jar files
<mathiaz> slangasek: IIUC polling is necessary to know when the java services are actually operational
<Keybuk> kirkland: it means that process 844 exited
<Keybuk> and that Upstart didn't know about process 844
<Keybuk> well
<Keybuk> *maybe* didn
<Keybuk> 't know about it
<Keybuk> depends whether you see a message on the following line
<mathiaz> kirkland: are you still tracking down why the cc-registration job isn't started by upstart?
<Keybuk> well
<Keybuk> that could be because of the wacky way in which e8s cloud is written
<kirkland> mathiaz: yes, nurmi and i are looking at that right now
<kirkland> mathiaz: we're walking the verbose syslog line by line
<Keybuk> kirkland: may I see it?
<kirkland> Keybuk: http://pastebin.com/f10933e19
<kirkland> Keybuk: basically, the eucalyptus-walrus-registration *is* running
<kirkland> Keybuk: but eucalyptus-cc-registration and eucalyptus-sc-registration *are not*
<kirkland> Keybuk: we're trying to get to the bottom of why
<mathiaz> kirkland: in my testing sc-registration will run once cc-registration has run
<mathiaz> kirkland: I tested it by doing: sudo start eucalyptus-cc-registration
<mathiaz> kirkland: that run both the cc and the sc registration jobs
<Keybuk> maybe they timed out?
<Keybuk> if you comment out the "start on" in the dbus-reconnect.conf, do they work?
<Keybuk> (eventually)
<kirkland> Keybuk: checking
<Keybuk> e8s-cloud isn't started
<Keybuk> its post-start is still running
<cjwatson> seb128: confirmed that it's busted for ubiquity dialogs in general
<Keybuk> ah, right
<Keybuk> it finishes after dbus-reconnect
<Keybuk> you hit *that* bug ;)
 * Keybuk bets that disabling that job will make it work for you
<Riddell> mvo: the dist-upgrade tool still doesn't have the kbluetooth4 fix in it?
<seb128> cjwatson, it's weird, the dialog is displayed if I run ubiquity again
<seb128> displayed -> translated
<kirkland> Keybuk: disabling which job?
<kirkland> Keybuk: dbus-reconnect?
<Keybuk> eys
<kirkland> Keybuk: how do i disable a job properly?
<Keybuk> just comment out the "start on" line
<cjwatson> seb128: yep, that makes sense from the bug
<cjwatson> seb128: no need to file it if you haven't already, I'm fixing it now
<cjwatson> the bug is in the thing that translates widgets on the fly after you change the language on the first screen
<seb128> cjwatson, ok, no I didn't yet I was busy on something else, I just looked if there was one filed and I didn't find one
<seb128> cjwatson, ah ok, thanks for the quick fixing ;-)
<cjwatson> somebody on the translators list was complaining about something that sounded similar
<cjwatson> there we go, much better. just need to check Kubuntu too
<dpm> cjwatson, seb128: I think what was mentioned on the translators list was a problem with the slideshow, not with bootloader; bug 430719
<ubottu> Launchpad bug 430719 in ubiquity-slideshow-ubuntu "Slideshow is empty" [Undecided,Fix released] https://launchpad.net/bugs/430719
<cjwatson> dpm: not that, the stuff Timo Jyrinki was asking about
<dpm> cjwatson: ah, ok, sorry, I was following the wrong conversation
<cjwatson> he mentioned the partition create/edit dialogs not being translated, iirc, which is the same bug as seb128's
<dpm> ah, yes, thanks
<cjwatson> seb128: fix committed, thanks again
<avb> guys, seems update-initramfs has an issue. update-initramfs -u -k all doesnt pack usplash for me because its not processing framebuffer hook.
<kirkland> Keybuk: commenting out dbus-reconnect did seem to help quite a bit
<kirkland> Keybuk: what bug number is that, so that we can track it?
<avb> it has OPTIONS=USPLASH there and seems i dont have this option defined somewhere. I was upgrating from jaunty to karmic with apt-get
<cjwatson> avb: usplash isn't included by default any more except in certain situations. Put USPLASH=y in /etc/initramfs-tools/initramfs.conf if you want to force it on
<cjwatson> this is an intentional change documented in the changelog
<Riddell> cjwatson: what needs checked in kubuntu?
<avb> cjwatson: how is splash screen ought to work now?
<avb> cjwatson: thing is that im not getting splash at all. or it was designed like this?
<avb> another thing will release include 2.28.1 or it will be released with 2.28.0?
<cjwatson> Riddell: nothing, I checked it
<cjwatson> avb: the intent is to get to xsplash as quickly as possible; running usplash slows that down
<avb> i see
<Riddell> ok, thanks, for whatever it was :)
<cjwatson> avb: it's not quite all as neat as intended yet
<cjwatson> Riddell: translation bug that was only in the GTK frontend
<avb> :) i agree
<avb> thing is that gnome-display-properties has a bug with mirroring displays with a different resolution. and it will be fixed only in 2.28.1
<cjwatson> we've always included gnome point releases
<cjwatson> for some value of "always" anyway
<avb> now if you going to mirror 2 displays with diff resolutions, it will crash application
<avb> there is a patch in bugzilla, so i wonder if its needed to be backported
<cjwatson> 18:37 <cjwatson> we've always included gnome point releases
<avb> yeh. okay
<avb> thanks
<Keybuk> kirkland: it's more of a meta-bug
<kees> james_w: where are the distro-tracking bzr trees again?
<james_w> code.launchpad.net/ubuntu
<kees> james_w: ah-ha, thanks!
<james_w> with +source and /karmic/ etc. as usual
<james_w> sometimes things are where you would expect :-)
<kees> lp:ubuntu/$release/$source/$release ?
<mathiaz> kees: lp:ubuntu/karmic/openldap
<james_w> where "karmic" can be any suite
<james_w> e.g. jaunty-security
<james_w> if there was nothing uploaded to said suite then you will get "not a branch"
<seb128> cjwatson, thanks for fixing the issue ;-)
<kirkland> Keybuk: is it tracked in launchpad?
<Keybuk> kirkland: no
<Keybuk> unless you count a spec/
<Keybuk> https://blueprints.edge.launchpad.net/upstart/+spec/states
<mvo> Riddell: no, its still in the queue but its upload
<mvo> Riddell: you mean the kbluetooth -> kbluetooth4 fix, right?
<Keybuk> though that
<Keybuk> though that's a _very_ old draft ;)
<kees> james_w: aaah, cool
<james_w> haven't quite worked out the best way to say "latest in any pocket of series X" yet though
<mathiaz> james_w: lp:ubuntu/jaunty-latest/srcpkg ?
<mathiaz> kirkland: IIRC once you've aggreed to boot a degraded raid array, subsequent reboots should'd ask whether to boot from a degraded array - it should be automatic?
<kirkland> mathiaz: if you agreed in debconf, that's true
<mathiaz> kirkland: ah - in debconf
<kirkland> mathiaz: if you mean in the initramfs, that's true for your "current degraded event"
<mathiaz> kirkland: I aggreed in the initramfs - the first time
<kirkland> mathiaz: right, you only get that question in initramfs when mdadm detects that the raid has just become degraded
<kirkland> mathiaz: if you tell mdadm to boot it, then it says "okay, cool, so now you expect this raid to be degraded, i won't ask you again"
<mathiaz> kirkland: ok - so on the next reboots, it shouldn't ask?
<mathiaz> kirkland: ok - that's not happening then
<mathiaz> kirkland: I'm still asked what I wanna do
<kirkland> mathiaz: right; until you re-add the disk, and the raid is sync'd again
<kirkland> mathiaz: and you're not creating new degraded events in between boots?
<mathiaz> kirkland: hm wait - now it works as expected
<kirkland> mathiaz: right, the logic is slightly complicated
<mathiaz> kirkland: hm - missing drives aren't supposed to be automatically added to a degraded raid array, right?
<Keybuk> kirkland: can you file an ubuntu bug specifically about the dbus issue?
<Keybuk> there's a trivial fix for that I can do after beta
<slangasek> Keybuk: wrt sreadahead profiling automatically on boot - is there no need to have a "default" profile for the liveCD itself?
<Keybuk> slangasek: did we ever use readahead on the live cd?
<Keybuk> dunno ;)
<slangasek> it's installed in the livefs
<Keybuk> that probably means that sreadahead profiles the live cd right now? :)
<slangasek> but only on "first boot", so it doesn't help? :)
<slangasek> anyway, if the answer is that this isn't worth the effort, that's fine
<Keybuk> the problem was generating one for every single image
<Keybuk> otherwise you end up with kubuntu using a ubuntu profile
<Keybuk> and they whine
<slangasek> ah
<davmor2> Keybuk: no surely a whine profile would install windows ;)
<slangasek> Keybuk: I'm trying to work through the fact that upstart 'restart' doesn't have the same semantics as policy requires for init scripts... the only thing causing performance problems on boot is the /etc/rc*.d/ symlinks, right?  So if we don't have /those/, then an upstart-job symlink in /etc/init.d doesn't hurt; so we could arguably use the same invoke-rc.d handling for maintainer scripts in dh_installinit if we added those symlinks?
<slangasek> (reducing the debhelper delta, making it easier to get certain packages to dtrt - such as nfs-common, which needs to use restart-after-upgrade)
<Keybuk> but then what happens when we *do* what the right semantics?
<Keybuk> e.g. from debhelper
<Amaranth> I thought apparmor loading got moved into initramfs
<slangasek> well, that's a policy change that hasn't been worked through yet
<slangasek> but currently, we silently ignore all failures to start jobs
 * Amaranth still has an init script running for it too
<Keybuk> sure, there's bugs here and work items
<Keybuk> that's the side effect of developing things as we go ;)
<slangasek> and the reason restart-on-upgrade breaks for nfs-common is that the postinst snippet does "restart" if [ -n "$2" ] - so you can't use that when /upgrading/ from a pre-upstart version
<Keybuk> so that should be start
<Keybuk> ?
<slangasek> it should be start when upgrading from pre-upstart, yes
<slangasek> and restart otherwise
<slangasek> but the preceding debhelper snippet would have dtrt with "restart" anyway, by design
<slangasek> (for values of "dtrt" including "start the service on upgrade if it wasn't previously started", which is the behavior currently expected based on policy)
<Keybuk> it would have also started the service if it wasn't already running
<Keybuk> which is broken by design
<Keybuk> after all, half the bonus of designing a new init system is that you get to design a new policy at the same time
<Keybuk> and fix problems with the old
<Keybuk> it seems backward to tie ourselves to the old policy with the new init system
<Keybuk> especially the old policy isn't compatible with it
<slangasek> broken, perhaps; but known and consistent, and I'm not convinced that the new isn't also broken in ways that haven't been identified yet
<Keybuk> the point is that if we figure out ways in which the new is broken, we fix them ;)
<slangasek> and "can't use restart-on-upgrade for existing packages" isn't broken enough?
<slangasek> or do you have some other way to fix this?
<slangasek> having to write dozens of lines of postinst code by hand irks me
<Keybuk> I can't think of a way off hand to fix it
<Keybuk> but it's something we should figure out
<Keybuk> otherwise you're in a strange state where the old sysv service is still running
<Keybuk> but has no init.d script or rc0.d symlink to bring it down on shutdown
<slangasek> nah, I already wrote the code to stop the job by hand too
<Keybuk> this was why we talked about using invoke-rc.d for maintainer scripts that aren't upstart-only though right?
<Keybuk> as a temporary measure
<slangasek> well, that's exactly what I was proposing
<Keybuk> since the non-upstart-only ones have symlinks in /etc/init.d
<Keybuk> oh
<Keybuk> ;)
<Keybuk> right, I didn't have any objections to that
<slangasek> well, ok, not exactly - I'm also wondering if upstart-only shouldn't also provide the symlink in /etc/init.d and use invoke-rc.d in the maintainer script
<Keybuk> my objection has only ever been to things that didn't exist as init scripts before
<slangasek> right, ok
<Keybuk> because those are going to be written with upstart in mind
<Keybuk> so it's proper that they obey upstarty semantics
<slangasek> nfs-common has a pre-existing init script, but splits to 4 upstart jobs... so there's no good fit
<Keybuk> if it never existed in the sysv world, it's confusing to expect it to behave that way
<slangasek> anyway, --restart-after-upgrade --upstart-only is also broken for any package which adds a new upstart job
<Keybuk> is it?
<Keybuk> it won't result in it being started
<Keybuk> but it should also not result in it failing
<slangasek> yes, that's broken :)
<Keybuk> which is correct behaviour
<Keybuk> no, it's correct behaviour
<slangasek> it's "correct" behavior because you've specified this is what it will do, but I don't believe that's actually the behavior anyone wants
<Keybuk> really?  one of the biggest complaints I ever hear about Debian init script policy is that if you stop a service, it gets started again by apt-get upgrade
<slangasek> yes, I'm talking about a *new* upstart job
<slangasek> added to an existing package, and it needs to get started on upgrade
<Keybuk> then it wouldn't use restart? :)
<Keybuk> it'd use ordinary postinst scripts
<slangasek> if you're using --restart-on-upgrade --upstart-only, it would call restart and ignore the failure
<Keybuk> restart-after-upgrade itself is a workaround for brokenness in initscripts
<Keybuk> upstart will have quite different behaviours for this stuff
<Keybuk> I'm quite happy to work out what those should be in a way that makes sense though :)
<Keybuk> however if someone hands me a copy of Debian Policy as the "right" way, I shall burn it
<Keybuk> ...and them :p
<slangasek> if we don't use restart-after-upgrade, then we're calling "start", which doesn't restart the job if already running, right?
<Keybuk> slangasek: right
<slangasek> I'm flame-retardant :P
<Keybuk> but then restart doesn't do what you think either :p
<slangasek> Keybuk: so what ensures that we re-exec the newly-installed binary?
<Keybuk> stop && start
<slangasek> Keybuk: so the current init script snippets don't do that, either
<Keybuk> restart doesn't reload the *.conf file
<Keybuk> it restarts the service with the configuration it currently has
<Keybuk> one assumes after an upgrade that will have changed
<slangasek> so to get sensible package behavior (after upgrade, the right binary is running with the right config), we have to call stop && start, and that's not happening today
<Keybuk> stop ; start has the benefit of starting the service ;)
<Keybuk> (if it wasn't already running)
<slangasek> so that's what --restart-after-upgrade should actually be calling
<Keybuk> it does start sysadmin-stopped services
<Keybuk> but so does stop-in-prerm/start-in-postinst which most packages still do
<Keybuk> this is better fixed with the "mark for upgrade" functionality
<slangasek> is that available yet? :)
<Keybuk> lol, no
<slangasek> then I think it's important to fix the debhelper snippets to give behavior consistent with what we expect of sysvinit-using services on upgrade
<Keybuk> so stop ; start is probably right for that case
<Keybuk> sure, not disagreeing :)
<Keybuk> (you can tell when I disagree because I don't suggest workarounds :p)
<mathiaz> slangasek: I'd like to document bug 427048 for Beta - is https://wiki.ubuntu.com/KarmicKoala/TechnicalOverview#Known%20issues the right place?
<ubottu> Launchpad bug 427048 in grub2 "grub2 needs to install the bootloader to each disk in a RAID1 array providing /boot" [High,Triaged] https://launchpad.net/bugs/427048
<slangasek> mathiaz: yes, please!
<mathiaz> kirkland: is there a workaround for bug 427048?
<ubottu> Launchpad bug 427048 in grub2 "grub2 needs to install the bootloader to each disk in a RAID1 array providing /boot" [High,Triaged] https://launchpad.net/bugs/427048
<kirkland> mathiaz: manually install to each disk in the array
<mathiaz> kirkland: how do you do that? grub-install /dev/sdb?
<kirkland> mathiaz: up
<kirkland> yup
<Keybuk> if we put the boot loader in the partition instead of the mbr ...
<Keybuk> </age old whine of mine>
<kirkland> ttx: ping
<kirkland> ttx: how much disk space do you have on your cluster machine?
<ttx> kirkland: 160Gb
<kirkland> ttx: okay
<ttx> -6 swap
<kirkland> ttx: and on your node?
<ttx> node is 300Gb -6swap
<kirkland> k
<ttx> kirkland: how is it going ? did you reproduce it when starting an instance ?
<slacker_nl> anyone familiar with apprt, i cannot find the ubuntu-bug file in there
<kirkland> ttx: so the localhost/ipaddr change is "good", that results in successful walrus, sc, and cc registration *every* time
<kirkland> ttx: i wasn't able to reproduce the situation you had, where you had to restart the cloud
<kirkland> ttx: i just waited a few minutes, and everything was registered, and available just fine
<kirkland> ttx: i just tried to run an instance
<kirkland> ttx: that failed, but it's because I filled up my small hard disk (32G SSD)
<kirkland> ttx: so i'm starting over, with a bigger disk
<ttx> kirkland: did you check if the nc got polled ?
<ttx> nc.log should show stuff every 8 sec or so
<ttx> without a restart it never gets polled
<ttx> (at least in my case)
<kirkland> ttx: yes, nc polling is working like a champ
<kirkland> ttx: no restart
<ttx> beh
<ttx> did Dan confirm that it should not be needed ?
<ttx> (he always added it on his own testlogs)
<kirkland> ttx: he said he was surprised that i didn't have to restart
<kirkland> ttx: he says they have a fix upstream that we need to take to fix that
<ttx> kirkland: hm, I always had to as well.
<ttx> you should be able to confirm with your next run
<ttx> kirkland: did you test from ISO install or from package install ?
<kirkland> ttx: iso, purged 12, installed 13
<ttx> kirkland: I was wondering if that would not introduce a difference, the fact that you don't start up things during the iso install/postinsts
<ttx> kirkland: maybe it's possible to fake an ISO run by rebundling it
<kirkland> ttx: mdz did that a few times, with much error and great pain, last week
<ttx> kirkland: what we could do...
<ttx> kirkland: test that 13 is alright, test that installing beta (with workaround) + upgrading to 13 is alright
<ttx> releasing with what we have
<ttx> and then validate daily ISOs starting beta+1
<ttx> beta would be 12, users would upgrade to 13, and then we can take time to make sure daily ISOs with 13 are ok
<Keybuk> bzr: ERROR: 77afdcdf611d88cf3e8b0806fd04c56c.tix is not an index of type <class 'bzrlib.btree_index.BTreeGraphIndex'>.
<Keybuk> W. T. F.
<ttx> kirkland: how does that sound ?
<kirkland> ttx: that's what i've liked all along
<kirkland> ttx: i think 13 is the direction we need to go
<kirkland> ttx: though there are still bugs to be fixed
<ttx> kirkland: I'm concerned by the difference we experience in testing though
<ttx> (wrt the need to restart)
<kirkland> i'm going to leave my test env in my dmz for now
<kirkland> if you'd like to ssh in and watch along, let me know
<kirkland> i'll drop your ssh key on those boxes
<kirkland> ttx: nurmi and i are on it now
<ttx> please do the full run with 13, up to running instances. Ideally by setting up 12 with workaround first, then upgrade to 13
<ttx> if that works, we know we can leave 13 in
<ttx> I'll validate that as well tomorrow morning
<ttx> kirkland: what did you exactly do on the node side ?
<kirkland> ttx: on the node side?
<kirkland> ttx: i install byobu, and tail -f a bunch of log files
<kirkland> ttx: daz it
<ttx> kirkland: on the nc, you also installed 12, purged, and installed 13 ?
<kirkland> ttx: yes
<ttx> please also validate the beta+upgrade scenario on that side
<ttx> (I don't think it would change anything, but...)
<kirkland> ttx: okay, i'll do that
<kirkland> ttx: i'm reinstalling my cloud now
<ttx> kirkland: welcome to the club
<kirkland> ttx: how much longer are you around?
<ttx> a few minutes
<ttx> kirkland: please summarize your findings at the end in an email, saying that keeping 13 is apparently non-harmless for users to upgarde to, and allows to have dailies to debug the rest
<ttx> (of course if you manage to make it fully work in a 12 + manual reg + upgrade to 13 scenario :)
<ttx> I wish I had Dan in my box in my morning.
<kirkland> ttx: yikes
<kirkland> ttx: okay, will do
 * ttx shuts down
<cjwatson> Keybuk: for a long time we weren't putting it in a partition largely through inertia; but one problem that's become evident relatively recently is that if you put it in a partition boot record then you generally have to use blocklists, i.e. grub has to remember the location of all the blocks comprising what used to be called its stage1.5 (fs handling, etc.)
<Keybuk> why?  it shouldn't make any difference
<cjwatson> Keybuk: because most filesystem types don't leave significant enough space for a boot loader
<Keybuk> you have the same number of bytes as you do in the MBR no?
<cjwatson> no, not true
<Keybuk> ah
<cjwatson> if you put it in the MBR, there's normally 32KB or so space after it where the bootloader can be embedded
<cjwatson> which isn't used by any filesystem
<Keybuk> see, this is why we should just have a small FAT partition at the front of the disk, with all kernels and bootloaders and initramfses and stuff on them
<Keybuk> then you can write a trivially tiny bootloader to pick one
<Keybuk> someone should write a standard that requires that
<cjwatson> so, today, putting it in a filesystem means that more or less random filesystem changes (e.g. defragmentation in the case of ext4) can cause you to have to reinstall grub
<Keybuk> and then fail to get any OS developer or OEM to actually embrace it
<Keybuk> except Apple
<cjwatson> shame the EFI standard is a right pain in other areas really ...
<cjwatson> BIOS designed by committee, hooray
<cjwatson> or BIOS with big long method names for everything
<cjwatson> GPT is really the only good bit of it, and you don't need EFI for GPT
<Keybuk> aye, *sigh*
<bluefoxicy> whatthe friggin hell?
<bluefoxicy> plugging in a wire is fatal
<bluefoxicy> okay.
<bluefoxicy> that's retarded.
<bluefoxicy> okay
<bluefoxicy> there's actually a bug for this.
<mdz> kirkland, how goes it?
<bluefoxicy> okay what do i do about a "Fix Released" bug that's still a bug?  Remove "Fix Released" and see who gets pissed off?
<kirkland> mdz: testing again
<bluefoxicy> (double-bug because the "Fix" is idiotic, and the person who marked it as "Fix Released" made note of this explicitly)
<kirkland> mdz: i got to the point where i deployed an image last time around
<kirkland> mdz: and my 32GB disk filled up
<kirkland> mdz: so i've done a hardware swap-a-roo
 * kirkland realizes he should note that in the test wiki
<mdz> kirkland, filled 32GB, really? that's surprising
 * bluefoxicy unmarks #278485 and sees who bitches.
<kirkland> mdz: image was 10GB unzipped
<mdz> kirkland, what consensus did you and ttx come to with regard to the registration problems?  he said he could reproduce a problem, but it worked for you
<kirkland> mdz: i'm making sure that upgrading to my ubuntu13 doesn't break things in nasty ways
<kirkland> mdz: so far it's not; it's succeeding in auto registering the components
<kirkland> mdz: i'm trying to get back to the point where i reproduce ttx's failure to deploy the image
<bluefoxicy> uh  huh.
<bluefoxicy> It doesn't work because nm crashes.
<Keybuk> kirkland: just uploaded an upstart & dbus package to ubuntu-boot PPA ... appreciate some testing
<kirkland> Keybuk: okay
<kirkland> mdz: unfortunately, i'm at the part that takes a *really* long time
<kirkland> mdz: image preparation takes 20+ minutes
<kirkland> Keybuk: to fix the dbus-reconnect problem?
<Keybuk> yup
<kirkland> mdz: up to step 5 on http://testcases.qa.ubuntu.com/Install/ServerEConfig is working like a champ
<kirkland> mdz: with auto registration, etc.
<kirkland> mdz: step 6 is about a 45 minute process
<bluefoxicy> --- SIGSEGV (Segmentation fault) @ 0 (0) ---
<bluefoxicy> and apport refuses to report it
<slangasek> why does apport refuse?
<bluefoxicy> it said I had outdated libraries
<bluefoxicy> so I ran apt-get update/upgrade
<bluefoxicy> it doesn't bother telling me stuff crashed anymore
<bluefoxicy> i.e. "This crashed because it's out of date" and when I update it it doesn't care anymore because it's already decided it's out of date.
<slangasek> did it crash again while you were up-to-date?
<bluefoxicy> yes
<ScottK> My favorites are the crashes during the process of updating that can't be reported because you are out of date
<kirkland> mdz: arg
<kirkland> mdz: i think i'm confirming ttx's "instance don't run" bug
<kirkland> troubleshooting now
<kirkland> mdz: i notice that you didn't upstart the eucalyptus-nc job... any reason why?
<slangasek> Keybuk: hrm, you stomped on my upstart changes in the bzr repo
<Keybuk> I did?
<Keybuk> bzr has totally fucked up that repo
<Keybuk> so it's entirely possible that your changes were never committed
<slangasek> ok
 * slangasek re-pushes
<Keybuk> you can't even branch it via the smart-server right now
<slangasek> ah, yay
<Keybuk> what's your local revno?
<Keybuk> (pre-merge)
<slangasek> 1224
<Keybuk> right, so your change never made it into lp
<slangasek> it's let me push without warnings
<Keybuk> yeah it does
<slangasek> that's interesting, I see linear history here that shows your change on top of mine :)
<Keybuk> on top?
<slangasek> do you get my changes w/ bzr pull?
<Keybuk> that's weird
<Keybuk> bzr pull from you duplicates your change twice into the log
<lifeless> add nosmart+
<slangasek> yeah, the "telinit q" change shows up as a descendent of my last commit
<lifeless> or prefix rather
<slangasek> nosmart+bzr+ssh?
<Keybuk> lifeless: your revision control system is making me cry
<lifeless> slangasek: yes; bug filed on it this morning
<lifeless> Keybuk: I'm sorry!
<Keybuk> ;)
<Keybuk> it's ok
<Keybuk> I'm sure it's really an Upstart bug
<Keybuk> everything else is ;)
<lifeless> :)
<slangasek> Keybuk: oh, another case broken by dh_installinit not providing /etc/init.d/ symlinks for native jobs - third-party packages that rely on restarting services for key library upgrades using invoke-rc.d...
<Keybuk> how does that break?
<Keybuk> if they weren't there before, they won't be looking for them
<mdz> kirkland, I couldn't test -nc at all, I left it alone
<slangasek> Keybuk: oh right
<slangasek> Keybuk: just breaks my brain then, nothing to see here
<Keybuk> :D
<kirkland> mdz: i'm still fighting it
<kirkland> mdz: RESERVATION     r-39720716      admin   default
<kirkland> INSTANCE        i-38A7070E      emi-D5871527    192.168.0.250   172.19.1.2      pending         mykey   0       m1.xlarge
<kirkland> 2009-09-30T22:27:50.269Z        canyonedge      eki-8F0A139D    eri-E64F14E8
<kirkland> mdz: i can make the reservation
<mdz> kirkland, but the instance never starts up?
<kirkland> mdz: and I can see the nc trying to spin it up
<kirkland> mdz: i waited 30 minutes last time
<kirkland> mdz: no good
<slangasek> Keybuk: so wrt portmap / nfs-common... what's the correct stop policy to be setting here?
<slangasek> is there a particular teardown upstart job for unmounting remote filesystems that we should use?
<slangasek> (and is there not a way to express "always start this job first when I've asked to start that job", that's honored for sysadmin-started jobs?)
<Keybuk> no & no
<Keybuk> but we can invent one ;)
<slangasek> Keybuk: mmk :)
<slangasek> Keybuk: yet another question... I have a task that is a dependency of other jobs, but it really should only be run *if* those other jobs are being started... :)
<Keybuk> that's quite easy
<slangasek> I could just run it twice in each job, I guess, but I was trying to remove that duplication
<Keybuk> start on starting
<Keybuk> stop on stopped
<slangasek> oh
<Keybuk> a service can insert itself as the dependency of another service that way
<Keybuk> e.g.
<Keybuk> bunny:
<slangasek> ok, cool
<Keybuk>   start on starting pie
<Keybuk>   stop on stopped pie
<Keybuk> then
<Keybuk> start pie
<Keybuk> will first start bunny, wait for bunny to be started, and then start pie
<Keybuk> likewise if you stop pie, once pie has stopped, bunny would be stopped
<cjwatson> which indeed is more or less how usplash does it
<cjwatson> except with that custom event
<Keybuk> right
<Keybuk> it might be nice to get those custom events hardwired into upstart in some interesting way
<Keybuk> so you don't have to jump through hoops
<cjwatson> maybe. OTOH it's a good demonstration of custom events? :)
<cjwatson> or is that not what you meant?
<Keybuk> I mean making it easy to add custom events to jobs that effectively replace things like starting
<Keybuk> adding information
<Keybuk> "provides" I guess is what I mean
<cjwatson> oh, this reminds me, in the usplash-down job I couldn't find a way to tell what runlevel it's in when it notices gdm being stopped, short of actually calling runlevel
<cjwatson> I wanted to distinguish "somebody ran 'stop gdm'" from "system shutdown", but there was no RUNLEVEL key in the stopped environment
<cjwatson> was I missing something obvious?
<Keybuk> do you do stop on runlevel?
<cjwatson> no, 'start on (stopped gdm or stopped kdm or stopped xdm)'
<cjwatson> (dunno why I bothered to include xdm there)
<cjwatson> it does explicitly need to stop after X has handed the console back at the moment, I believe
<cjwatson> I'm pretty sure just stop on runlevel would break racily
<cjwatson> certainly, pre-upstart, running usplash_down before gdm stop broke
<slangasek> Keybuk: oh argh, 'status' returns a pid when the job is stopped?  how unintuitive
 * slangasek thinks upstart-job is completely broken right now, then
<Keybuk> slangasek: varies
<Keybuk> cjwatson: right, so you have no $RUNLEVEL environment because none of that infers a runlevel ;)
<Keybuk> slangasek: if the job is being stopped, but isn't yet stopped, it'll still return a pid
<Keybuk> ie. the pid is still in ps
<Keybuk> if the job has a post-stop script, it'll return that pid too
<slangasek> Keybuk: oh, then I found an upstart bug ;)
<Keybuk> it does tell you in detail which pid it's returning
<Keybuk> in a machine-parseable form
<Keybuk> slangasek: oh?
<slangasek> Keybuk: the pid it's returned isn't there
<slangasek> gssd stop/killed, process 20582
<slangasek> $ ps 20582
<slangasek>   PID TTY      STAT   TIME COMMAND
<slangasek> $
<Keybuk> and it's stuck in that state?
<Keybuk> are you using "export fork" or "export daemon" ?
<Keybuk> err, expect
<slangasek> expect fork
<Keybuk> ok, that's odd then
<Keybuk> usually daemon can produce that particular bug
<slangasek> (what's the difference between the two?)
<Keybuk> expect fork expects one fork()
<slangasek> yeah, it's stuck in that state, can't start it with start
<Keybuk> expect daemon expects two
<Keybuk> slangasek: weird, that implies that upstart didn't get the SIGCHLD
<Keybuk> don't suppose you can replicate that with initctl log-priority debug set?
#ubuntu-devel 2009-10-01
<slangasek> heh, doubt it; the sequence leading up to it was non-trivial (and was a result of bugs)
<kirkland> mdz: well, i could be just impatient
<kirkland> mdz: its still doing stuff
<Keybuk> I've tended to see that before with "expect daemon" and SIGCHLD handlers
<Keybuk> e.g. avahi
<kirkland> mdz: dd, specifically
<Keybuk> I guess you could get it with "expect fork" as well in that situation
<Keybuk> actually, if you had expect fork, the service daemonised instead of just forking, and put a SIGCHLD handler in - you could probably get that
<slangasek> mmk
<cjwatson> Keybuk: gdm is stopped due to a runlevel change; it would be nice if that information were passed on
<slangasek> let me reboot (I /think/ I haven't broken my own boot sequence... :) and try again
<Keybuk> cjwatson: I'm just trying to figure out in my head whether "export RUNLEVEL" in gdm.conf would work ;)
<cjwatson> happy to try it at some point
<Keybuk> I don't think it would
<Keybuk> I think you can only export start environment
<Keybuk> so you could know the runlevel gdm was in when it started ;)
<cjwatson> useful ;)
<kirkland> mdz: keeping a chronicle in https://bugs.edge.launchpad.net/ubuntu/+source/eucalyptus/+bug/439288
<ubottu> Launchpad bug 439288 in eucalyptus "1.6~bzr854-0ubuntu13 fails to run instances" [High,Triaged]
<Keybuk> though the stop environment stuff is all a bit broken
<Keybuk> it seemed like a good idea at the time
<Keybuk> (e.g. upstart doesn't even pass the exit code to the post-stop script)
<cjwatson> actually, is there any reason why all events shouldn't just come with the current runlevel attached?
<Keybuk> yes
<Keybuk> upstart doesn't implement runlevels
<Keybuk> ;)
<cjwatson> you can get the information anyway in a script, but it would allow you to match on them ...
<Keybuk> by that, I mean that the init daemon doesn't implement them
<Keybuk> it never knows what the runlevel is
<Keybuk> or even what *a* runlevel is
<cjwatson> yeah
<cjwatson> oh well. awkward.
<Keybuk> it's all done by the passing of events
<cjwatson> I suppose I want to be able to match on runlevel [06] as a state
<Keybuk> right, exactly!
<Keybuk> and that's definitely going to happen
 * cjwatson remembers an old spec with edge-triggered and level-triggered events ... ;-)
<Keybuk> it's funny you say that
<Keybuk> I remarked only last week how most of the work for upstart 0.10 is putting back in all the things we dropped out of the original design
<cjwatson> you're going to tell me I argued you out of including level-triggered events now, aren't you
<cjwatson> which is entirely possible, although I've forgotten it if I did :)
<Keybuk> no, I think that was mdz
<Keybuk> they "confused" people at the original Wiesbaden demo
<Keybuk> of course, in practice, we removed the wrong ones <g>
<cjwatson> running runlevel is an adequate hack for now, anyway, it's just inefficient
<Keybuk> yeah, it is ineffecient - but that's basically all upstart would be doing itself
<Keybuk> (until we get a runlevel state to replace the event)
<cjwatson> right, until it remembers the state of course
<slangasek> hmm
<slangasek> Keybuk: how is 'env' supposed to work?  Is there a document I should be looking at that tells me the available commands?
<cjwatson> man 5 init ?
<slangasek> heh
<slangasek> doesn't show up under 'man -k upstart', does it :)
<cjwatson> debmany upstart
<kirkland> mdz: \o/ \o/ \o/
<Keybuk> slangasek: no, but if you read the upstart(7) overview page, it'd tell you :p
<kirkland> mdz: RESERVATION     r-31500705      admin   default
<kirkland> INSTANCE        i-3BEB06F3      emi-D5871527    192.168.0.250   172.19.1.2      running         mykey   0       m1.xlarge
<kirkland> 2009-09-30T22:37:49.042Z        canyonedge      eki-8F0A139D    eri-E64F14E8
<Keybuk>        Processes managed by init are known as jobs and are defined by files in
<Keybuk>        the /etc/init directory.  See init(5) for more details.
<slangasek> heh
<Keybuk> just saying <g>
 * Keybuk rofls
<Keybuk> I just did apropos -h
<Keybuk> cjwatson: I think you may have a gettext bug there ;)
<Keybuk> _("") does not do what you might think <g>
<lifeless> ooo
<lifeless> I want to translate that now
<Keybuk> lifeless: it's the header of the .po file I assume
<Keybuk> probably done
<Keybuk> printf ("%s\n, _(""));
<lifeless>          ^"
<lifeless> damn, one space off
<slangasek> Keybuk: ho-hum, seems to be reproducible with both 'fork' and 'daemon'; continuing to debug
<slangasek> (in the meantime, fixed my terribly-wrong rpc_pipefs job)
<cjwatson> Keybuk: however, the same thing doesn't happen without langpacks in Debian, even with remarkably similar-looking .mo files
<cjwatson> Keybuk: so I think it may actually be a bug in our langpack integration
<cjwatson> (anyway, the code that's doing _("") is in gnulib, I think, rather than code I wrote directly)
<cjwatson> I've seen that before, it was a while back - never got round to tracing it all the way down though
<ion> fr.po
<ion> msgid ""
<ion> msgstr "le "
<Keybuk> cjwatson: maybe we're accidentally ending up with that string in the .mo file
<Keybuk> dunno whether you ordinarily do or don't
<cjwatson> I msgunfmt'ed the two .mo files, it's there in both langpack and non-langpack cases
<cjwatson> I do know what's causing it, it's that I have argp doc strings that start with a \v (\v is a separator for pre- and post- doc strings in argp-ese)
<cjwatson> but I consider it a bug in the argp implementation in gnulib that it doesn't deal with that properly
<cjwatson> one day I'll get round to sending them a fix for that
<cjwatson> still mystifying that it only happens with langpacks, though
<cjwatson> hmm, though I think I see a workaround
<cjwatson> yeah, there we go
<slangasek> Keybuk: aha, got it; upstart isn't happy with me if my script spawns a number of short-lived subprocesses, then execs the daemon, which forks
<slangasek> so a pre-script fixes this
<Keybuk> hah
<Keybuk> yes
<slangasek> this is probably user error, but OTOH, it would be good for init to not get wedged
<Keybuk> indeed
<Keybuk> there's no solution to that using ptrace() though
<Keybuk> that's why I plan to switch to using proc_connector
<cjwatson> Keybuk: worked around, http://bzr.savannah.gnu.org/lh/man-db/trunk/revision/1148
<slangasek> Keybuk: <whimper> ok, and in the case of statd, the daemon itself spawns a subprocess before it detaches
<slangasek> Keybuk: how do I make /that/ work?
<Keybuk> meh
<Keybuk> I don't think you can\
<Keybuk> not without patching the code
<Keybuk> you could make statd raise (SIGSTOP);
<Keybuk> and use "expect stop"
<Keybuk> instead of making it fork
<slangasek> whee
<slangasek> or I could pass the -L argument to tell it not to call sm-notify
<Keybuk> ;)
<Keybuk> so yeah, it probably got fixated on sm-notify
<Keybuk> and then never got SIGCHLD for it
<evand> anyone have an Ubuntu CD/USB, a SD card, and a willingness to destroy whatever data is on it?
<kirkland> evand: sure
<kirkland> evand: usb stick
<evand> kirkland: cool.  Can you boot from the USB stick and try to install to the SD card with ubiquity?
<evand> I probably should've mentioned you'll need at least a 2.3GB SD card
<evand> it may explode when it gets to grub-installer.  Either way I'm happy.
<slangasek> the SD card may explode?
<kirkland> evand: hmm, all i have is 2GB cards
<evand> damn
<evand> thanks the same
<kirkland> evand: sorry
<evand> no worries.  Worst case I head to argos/currys tomorrow
<evand> err actually, that won't work
<yuriy> pitti: ping
<TheMuso> yuriy: He is likely not around at the moment. I suggest either emailing him or simply leaving a message for him on IRC and waiting till he responds.
<evand> nevermind about the SD card.  I found a machine that can read SDHC.
<evand> what's the magic rune for changing the privacy of a bug in the new Launchpad UI?
<cjwatson_> edit icon next to "This report is private", top right?
<spstarr> hrm, if you build a custom kernel via https://wiki.ubuntu.com/KernelTeam/GitKernelBuild,  you do not see /proc/filesystems show usbfs.. yet ubuntu's kernels do even using ubuntu's .config what gives?
<spstarr> is there something broken in make-kpkg?
<TheMuso> spstarr: Do your kernels have an initramfs? That might be whats responsible for mounting usbfs, however I am not entirely sure.
<spstarr> they do, i do not know what default modules it uses though
<spstarr> i can explode the ramfs to check
<spstarr> i may need to explicitly mention --added-modules usbcore (even though ubuntu compiles this into kernel anyway)
 * spstarr looks at the debian/* dir
<spstarr> oooh
<spstarr> wait  a second
<spstarr> yes i do have one, initrd.img-2.6.31.1-custom it wouldn't boot otherwise
<spstarr> but how this is getting built is what im curious about
<spstarr> where can I find the default fakeroot for the initramfs images?
 * spstarr gets source of ubuntu deb kernel
<TheMuso> spstarr: The pieces that get put into the initramfs as well as scripts to copy binaries over are found in /usr/share/initramfs-tools
 * spstarr looks
<spstarr> aha that's the init i was looking for
<spstarr> however.. /proc/filesystems only gets usbfs if usbcore is loaded
<spstarr> afaik
<spstarr> since usbcore has to register the filesystem to /proc/filesystems
<spstarr> so this is why im confused :)
<TheMuso> spstarr: Not sure why things aren't working for you sorry
<spstarr> if i compile usbcore or leave it compiled into kernel
<spstarr> you'd assume /proc/filesystems would have usbfs
<spstarr> unless its depending on the machine im building the deb on
 * spstarr examines both initramfs
<spstarr> and sings the little song "one of these ramdisks is not like the other"
<spstarr> my initramfs has usbcore in it
<spstarr> even more odd is i did see
<spstarr> [    0.229755] usbcore: registered new interface driver usbf]
<spstarr> usbfs
<spstarr> hmmmmmmmm
<spstarr> bug #417748
<ubottu> Launchpad bug 417748 in linux "Please enable CONFIG_USB_DEVICEFS" [Medium,Fix released] https://launchpad.net/bugs/417748
 * spstarr looks at this
<spstarr> ewwwww
<spstarr> it seems everyone is using the WRONG PATH for usbfs
<spstarr> you should be using /sys/bus/usb/drivers now not /proc for it anymore
<spstarr>  if you do not enable CONFIG_USB_DEVICEFS doesn't it defer to both /sys/bus/usb/drivers AND /proc/bus/usb??
<slangasek> "everyone"?  I'm not aware of anything in Ubuntu using the /proc path anymore
<spstarr> aha
<spstarr> # CONFIG_USB_DEVICEFS is not set
<spstarr> thats why my custom kernel fails
<spstarr> karmic has this turned OFF
<spstarr> which thus disables usbfs period
<spstarr> aha
<spstarr> damint
<spstarr> config-2.6.31-10-generic:CONFIG_USB_DEVICEFS=y
<spstarr> config-2.6.31.1-custom:# CONFIG_USB_DEVICEFS is not set
<spstarr> config-2.6.31-9-generic:# CONFIG_USB_DEVICEFS is not set
<spstarr> I took -9 :D
<spstarr> ahahahaha fsck me
<spstarr> you just fixed this issue
<spstarr> slangasek: don't you love it when a bug happens JUST like this?
<spstarr> :)
 * spstarr adds to the bug for anyone else looking
<spstarr> there
<spstarr> but since buntu enabled the option, nobody will run into this issue again
<Darxus> I provided the missing information which caused an LP bug to be marked incomplete.  Can I change its status?  To what?
<Darxus> The previous status was Fix Committed.
<Darxus> I switched it to confirmed.
<lifeless> Darxus: if it was fix committed, then the bug was fixed, wasn't it ?
<Darxus> lifeless: I was told that fix committed doesn't mean a new package was uploaded.  And, in fact, a new package was not uploaded.
<Darxus> That would be Fix Released.
<slangasek> LaserJock: do you have anything you'd like to highlight about Edubuntu 9.10 in https://wiki.ubuntu.com/KarmicKoala/BetaAnnouncement ?
<Darxus> #410933
<Darxus> https://bugs.launchpad.net/ubuntu/+source/alsa-utils/+bug/410933
<ubottu> Launchpad bug 410933 in alsa-utils "No sound in fresh jaunty install until disabling "external amplifier"" [Low,Confirmed]
<slangasek> cody-somerville: are there particulars to Xubuntu 9.10 that you'd like highlighted on https://wiki.ubuntu.com/KarmicKoala/BetaAnnouncement ?
<slangasek> superm1: ^^ mythbuntu
 * cody-somerville nods.
<slangasek> luisbg, TheMuso: ^^ ubuntu studio :)
 * cody-somerville grabs the edit lock.
 * slangasek grabs the dinner lock
 * superm1 doesn't have any locks left to grab
<Darxus> Just read through launchpad's definitions of status and I'm happy with "confirmed".
<TheMuso> slangasek: Not really, this cycle has not been big for us at all, due to a lack of participation in general from the team.
<slangasek> TheMuso: ok; I'll omit the break-out section for US then, rather than asking people to make things up :)
<Darxus> A "backtrace" is only available after something crashes, right?
<LaserJock> slangasek: maybe let's do the same for Edubuntu. We haven't really changed anything since Alpha6
<slangasek> LaserJock: what about changes since jaunty?
<LaserJock> slangasek: well, the whole DVD thing is a pretty radical change
<LaserJock> slangasek: perhaps also ltsp-cluster might be of note, beyond the usual fixes and updated packages
<TheMuso> 6/c
<ScottK> LaserJock: I think you have to write for the audience that didn't notice until the beta release.
<slangasek> indeed
<LaserJock> slangasek: ok, I'll take a crack at it then
<Darxus> The version of Debian that will be merged into Karmic is.. what?
<lifeless> None
<lifeless> karmic is frozen
<lifeless> specific packages can be merged by special request, and they can come from anywhere
<Darxus> Sorry, I should have used past tense.  Sid / unstable is the answer.
<Darxus> Shame, the reasonably current version of hugin didn't make karmic :/
<Darxus> I guess there's nothing for me to do though, it'll get merged for Lucid.
<Darxus> Ah, the bug wasn't even opened until 2 days after Debian import freeze.
<ScottK> Darxus: For a game, a freeze exception is quite possible.
<Darxus> It's not a game, it's a photo stitching program.
<Darxus> Is that possible?
<Darxus> Why is debian import freeze 4 months before final release?
<jdong> automatic debian import freeze is so, to start the process of stabilizing things
<jdong> during that phase sync requests are quite generously granted IMO
<Darxus> https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/416101
<ubottu> Launchpad bug 416101 in pulseaudio "Ubuntu's switch to pulseaudio broke accessibility for the blind." [Undecided,New]
<Darxus> Seems like that should be high priority for karmic.
<Darxus> jdong: Cool, thanks.
<ScottK> Darxus: Right.  I got my packages mixed up.
<ScottK> TheMuso: Do you have an opinion on 416101?
<slangasek> cody-somerville: hmm, was hoping for something a bit shorter on Xubuntu; can you pick one or two key features and link off to the Xubuntu page for the rest, please?
<cody-somerville> slangasek, aye
 * TheMuso looks
<spstarr> PA should be pulled, period :p
<spstarr> even the PPA builds still spectacularly fail
<TheMuso> ScottK: Oh right, will take care of that. Unfortunately pulse still causes a11y issues, but I have work-arounds in place to at least try and lessen the problems.
<TheMuso> spstarr: How do they fail? Please file a bug.
<spstarr> ALSA finally works with my multiple audio apps
<spstarr> TheMuso: i did, but is marked as incomplete and nobody has changed it
<spstarr> i gave all the debug crash info
<TheMuso> spstarr: Bug number?
<TheMuso> spstarr: Its likely because we have been too busy with other bugs.
<spstarr> getting
<spstarr> TheMuso: well I pulled PA out and now Second Life works, VirtualBox works sharing same audio input/output
<spstarr> using ALSA only
<TheMuso> spstarr: THats a work around, but it would be good to fix pulseaudio.
<TheMuso> spstarr: You have tried the absolute latest version in the ubuntu-audio-dev PPA?
<spstarr> well, yeah, but we should be asking, why can't we fix ALSA to do most of what PA wants to do and strip PA down to just a network audio daemon?
<spstarr> well, not the newest PPA bug # is
<spstarr> bug #424551
<ubottu> Launchpad bug 424551 in pulseaudio "Pulseaudio crashes if you repeat audio too much" [Undecided,Incomplete] https://launchpad.net/bugs/424551
<TheMuso> spstarr: This discussion has bene covered many times and in many different places. I can't remember where such discussions are on the web atm, but I'll see what I can dig up.
<spstarr> TheMuso: well, if ALSA has deficiencies (and it does) time for another audio rewrite for kernel?
<spstarr> i mean, we can replace the scheduler subsystem, etc, why not sound? :)
<spstarr> IANAKD
<TheMuso> Hrm regarding this bug, dtchen is much better at working out whats going on than I am. Feel free to change the status back to new, so it is more likely to be noticed again.
<spstarr> the problem i have with PA is the fact it is a userspace daemon
<TheMuso> spstarr: As for your arguments re audio, again, I know why, but I am not very good at expalining it ni an understandable way, so I'll have to find you some discussion references.
<spstarr> if it keels over there goes ALL your audio
<TheMuso> spstarr: Well floating point maths is not allowed in the kernel PERIOD.
<spstarr> that's right
<TheMuso> spstarr: And other OSs are doing something similar, i.e audio processing in userspace.
<spstarr> but PA seems so not ready for production
<spstarr> it cannot handle heavy loads
<spstarr> i can count how many times PA has burned me so much i ripped it out, now I am not willing to put it back for a least a few years
<TheMuso> spstarr: Perhaps you want to take this up with upstream. I suggest going into #pulseaudio and chatting with mezcalero/Lennart when he is around.
<spstarr> now that ALSA is cooperating with me finally
<spstarr> TheMuso: that could get very messy :)
<TheMuso> spstarr: Have you tried other distros, to see if they behave the same?
<TheMuso> spstarr: Only if you let it.
<spstarr> yep
<spstarr> I used Fedora prior, Debian prior that (with a splash of buntu in 2006)
<spstarr> now (k)buntu
<TheMuso> Well pulse has come a long way since then, so if you can't reproduce these problems in Fedora for example, then we are doing somethnig wrong and need to address it.
<spstarr> or as I call it, buntu :)
<spstarr> I can reproduce them in Fedora :)
<TheMuso> Ok then.
<TheMuso> My suggestino still stands. Chat to Lennart on IRC in #pulseaudio when he is around, or email the mailing list.
<TheMuso> suggestion even
<spstarr> yes
<spstarr> but for now, ALSA is working for my needs (amazingly)
<spstarr> brb
<al-maisan> Good morning!
<dholbach> good morning
<rgreening> hey dholbach
<dholbach> hi rgreening
<pitti> Good morning
<pitti> hey yuriy
<dholbach> james_w: looks like we should be quick for UOW if we don't want a 23 UTC slot for our session: https://wiki.ubuntu.com/UbuntuOpenWeek/Prep - shall we do a double session?
<dholbach> james_w: maybe we can still move things around a little bit :)
<dholbach> cjwatson: how can I run ubiquity on an installed system just to do a few screenshots?
<cjwatson> I'm not going to give advice on that because I consider it very unwise!
<dholbach> oh ok
<cjwatson> you can install the package and run it, but it may make changes to your system even before the summary screen
<dholbach> ok, I see
<cjwatson> since it assumes that it's OK to make changes to the live environment
<dholbach> I'll use a VM then - no worries
<dholbach> it's just to update a few screenshots
<cjwatson> yeah, that's much safer and easier
<dholbach> example-content still speaks about "espresso" ;-)
<florian__> hey guys... Florian from France. Does anyone know when exactly the beta will be released ?
 * dholbach fixes that :)
<cjwatson> dholbach: hah
<cjwatson> florian__: please don't ask that sort of thing
<cjwatson> florian__: the people with specific information on exactly what time are also critical-path to getting it out
<cjwatson> so we do not encourage bugging them
<cjwatson> it will happen at some point, go and enjoy yourself in the meantime :)
<cjwatson> if you're a mirror operator, then #ubuntu-mirrors might have more information, or you could arrange to have yourself set up as a push mirror
 * cjwatson -> breakfast
<florian__> cjwatson: I'm not... I guess i just can't wait... :)
<florian__> cjwatson: what do you mean by critical-path ?
<dholbach> pitti: uploading an updated example-content now - it should free up 1M! :-)
<dholbach> accept whenever it seems suitable
<pitti> yay you!
<pitti> dholbach: we'll flush the queue after beta release
<dholbach> cool
* mthaddon changed the topic of #ubuntu-devel to: Codehost/Codebrowse down 10:00 UTC - 10:30 UTC | Karmic Alpha-6 released | Archive: frozen for beta; FeatureFreeze, UIFreeze | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-jaunty | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<pitti> hrmpf gdm == GodDammit Bugpile
* slangasek changed the topic of #ubuntu-devel to: Codehost/Codebrowse down 10:00 UTC - 10:30 UTC | Archive: frozen for beta; FeatureFreeze, UIFreeze | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-jaunty | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<slangasek> Keybuk: shouldn't upstart have respawn rate limiting that would prevent bug #431166?
<ubottu> Launchpad bug 431166 in gdm "karmic gdm restarts X infinitely when video driver fails to load" [Low,Confirmed] https://launchpad.net/bugs/431166
<lidaobing> hello, help check bug #427725, whether we can sync ibus-m17n from debian?
<ubottu> Launchpad bug 427725 in ibus "Typing "lian" in py-b5 makes ibus-m17n crash" [Undecided,Confirmed] https://launchpad.net/bugs/427725
* mthaddon changed the topic of #ubuntu-devel to: Codehost/Codebrowse down 10:00 UTC - 10:40 UTC | Archive: frozen for beta; FeatureFreeze, UIFreeze | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-jaunty | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<Keybuk> slangasek: gdm restarts X indefinitely
<Keybuk> it's not gdm that's restarting
<slangasek> oh
<slangasek> doh
<slangasek> excuse my wayward task opening, then
<seb128> the previous gdm had code to avoid that
<seb128> yet another thing the new codebase does in a buggy way compared to the previous one
* mthaddon changed the topic of #ubuntu-devel to: Karmic Alpha-6 released | Archive: frozen for beta; FeatureFreeze, UIFreeze | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-jaunty | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<dmart> Slightly related to this, I eventually abandoned trying to get XDMCP connections to work for connecting to Karmic's gdm...  I added a /etc/gdm/custom.conf with [xdmcp]/Enable=true, and added an appropriate entry in hosts.allow, but that isn't adequate.
<dmart> I also found I had to set [xdmcp]/DisplaysPerHost > 1 for the querying host to be able to connect at all, and even then I just get a blank display, with gdm appearing to do nothing after the initial connection.
<dmart> Any thoughts?  I'm using Cygwin/X here, which may be part of the problem.  Worked with Jaunty though.
<Keybuk> seb128: a side conversation at plumbers was that you can *almost* entirely replace gdm with upstart
<Keybuk> since new gdm has gotten so basic
<pitti> oh, can I stop fiddling with this gdm keyboard mess then? :-)
<slangasek> heh
<pitti> seb128: ugh, the new gtk theme for gdm is pretty ugly; I already thought I broke something..
<pitti> until I realized that bzr head had a newer version
<seb128> pitti, hey, rick was wondering if it was not better with the standard one
<pitti> bubble help has no contrast any more and looks buggy
<Dennis-Beekman> afernoon everyone
<Dennis-Beekman> do we have a beta yet ?
<davmor2> no
<Dennis-Beekman> :-(
<Dennis-Beekman> when is it expected ?
<Dennis-Beekman> any time indication ?
<slangasek> mdke: lp:~vorlon/gnome-user-docs/ubuntu-karmic/ - I can't commit directly to the ubuntu-core-doc branch, so please merge
<slacker_nl> Dennis-Beekman: just await the announcement
<Dennis-Beekman> https://wiki.ubuntu.com/KarmicKoala/BetaAnnouncement
<Dennis-Beekman> it's here !!
<Dennis-Beekman> none off the mirror's have the actual image yet though :-(
<slangasek> that's an email draft.
<alourie> slangasek: I wanted to ask you something about that draft, but didn't want it to make to the maillist...
<Dennis-Beekman> yeah.. but it's the actual announcement
<slangasek> no, it's not the "actual announcement", it's an email draft.
<slangasek> alourie: oh?
<alourie> in the "under the hood" section you mentioned python version
 * slangasek nods
<alourie> slangasek: is it that basic that it should be mentioned? What about, say, perl?
<alourie> I mean, is it on the level of kernel/gcc ?
<slangasek> alourie: python is central to Ubuntu's development environment; perl less so :)
<liw> Dennis-Beekman, when it is announced, there will be an e-mail on ubuntu-devel-announce; until then, it is not announced and it is not released, please be patient
<alourie> slangasek: yea, that's what I thought. That's why I didn't send this to the maillilst...
<slangasek> liw: ubuntu-announce, actually
<alourie> slangasek: thanks, that answers my question. Besides that, I think it's perfect :-)0
<slangasek> alourie: ok, great :)
<cjwatson> Dennis-Beekman: we appreciate your enthusiasm, but rushing around like this actually consumes time from the people who are responsible for preparing the release, so please don''t
<cjwatson> Dennis-Beekman: and when the release manager tells you that something isn't the actual announcement, he probably actually knows better than you ... :-)
<yuriy> pitti: any ideas on bug 419501? I'm finding a lot of dupes, and most of them are in apport, but a few in other apps
<ubottu> Launchpad bug 419501 in libxcb "apport-kde assert failure: python: ../../src/xcb_io.c:242: process_responses: Assertion `(((long) (dpy->last_request_read) - (long) (dpy->request)) <= 0)' failed." [High,Triaged] https://launchpad.net/bugs/419501
<pitti> yuriy: I'm afraid not; I tried it in Kubuntu as well, but coulnd't reproduce
<yuriy> yeah I haven't seen it myself, but was concerned because I was finding so many reports
<liw> seb128, about #421318 (totem python crash): I've attached a patch, could you upload once the beta freeze is over?
<slangasek> liw: oh cool, you caught that bug?
<liw> slangasek, I asked upstream, upstream replied with patch
<slangasek> ah
<slangasek> :)
 * liw is totally innocent of any actual bug fixing here
<seb128> liw, thanks, will do, the change is quite easy which is good
<seb128> I was not sure if you were going to rewrite half of the code yesterday ;-)
<liw> seb128, I still maintain that the proper fix is to not use the combinations gtk+threads or python+threads (or gtk+python+threads), but I'm happy this particular bug got fixed easy :)
<liw> seb128, I don't see a bug about this in Debian, but if I missed one, I assume you'll take care of it there as well
<seb128> liw, debian doesn't have the bbc change, it's an ubuntu one, it's still being discussed upstream and not accepted there yet
<seb128> liw, I will update the upstream bug though
<seb128> liw, but nice to see it fixed so quickly ;-)
<liw> seb128, ah; otoh, the bug was actually generic for all Python plugins
<seb128> liw, right, I was expecting something like that but not sure, contacting upstream was a good idea there
<seb128> liw, is there any other python one in the default set?
<liw> seb128, coherence_upnp, dbus-service, opensubtitles?
<seb128> liw, ok, I didn't look to those, just weird that they didn't crash
<seb128> anyway that's fixed so all good now
<Darxus> The switch to pulse audio took place in jaunty?
<Darxus> Ah, looks like Hardy.
<seb128> what do you call switch?
<seb128> it's installed since hardy
<Guest87434> when will 9.10 beta be out?
<cjwatson> please don't ask that here
<pitti> for every question like this it'll release an hour later :)
<cjwatson> for that matter, please just don't ask it - wait :)
<Guest87434> ok :P consider it not asked
<Guest87434> BTW, nice work ;)
<Pici> Guest87434: If you want somewhere to wait, #ubuntu+1 will be abuzz when its actually released.
<Guest87434> Pici: Thnks
<pitti> Keybuk: for bug 397734, do you think we can/should change the default in our kernel for karmic?
<ubottu> Launchpad bug 397734 in procps "can't eject unmounted cdrom with hardware button" [Medium,In progress] https://launchpad.net/bugs/397734
<pitti> Keybuk: default -> CD tray locking state, I mean
<Keybuk> pitti: if it's unlikely to introduce regressions
<Keybuk> I'd rather it was done by changing the in-kernel default though
<Keybuk> adding a config file to run on boot costs time
<pitti> Keybuk: yes, that's what I meant
<yuriy> pitti: what is now the policy for apport after release? does it get disabled?
<pitti> yuriy: we'll disable crash interception right after the release candidate, but of course we'll keep it for bug reporting
<pitti> (or for people enabling it manually)
<dholbach> yuriy: get too many bug reports for a crash? :)(
<yuriy> ok it's the crash interception i'm wondering about.  I'm not sure what to do with it. the way we have it set up now is KDE will fall back to its own crash handler if apport is disabled, which means upstream will get the report if the user chooses to send it, and I don't think we want that (IMO, will bring it up at the next kubuntu meeting) but otherwise apps will just fail silently
<yuriy> pitti: do gnome apps just crash silently if apport is disabled?
<pitti> s/gnome//, yes
<yuriy> s/gnome/non-KDE
<Keybuk> wow, O'Reilly are "not publishing books on Linux internals any more"
<jdong> Keybuk: what! :( I liked some of those books
<jdong> is it only cool to have 1000 page screenshots of GNOME these days?
<Keybuk> or books by jono ;)
<jdong> haha :)
<jono> screw you guys, I'm going home
<jdong> hahah :)
<dholbach> jono: you're at home already! :)
<jdong> hmm are all policykit "Actions" supposed to show up in the Authorizations GUI thingie?
<jdong> I'm trying to figure out how to give a user authorization to use update-manager
<pitti> yuriy: ah, you keep the KDE crash handler enabled for release?
<Keybuk> james_w: your patch needs to be done with git format-patch ;)
<james_w> you mean git can't accept normal patches?!?!?
<mbiebl> jdong: you mean with policykit-1?
<Keybuk> james_w: upstream policy
<Keybuk> you have a git clone of dbus already I assume?
<jdong> mbiebl: yeah I suppose that's what we use in Karmic
<Keybuk> in which case "git commit -s" to commit your patch with a signed-off-by line
<yuriy> pitti: it was enabled and untouched until Intrepid.  In Intrepid, we started disabling it if apport is enabled, but never did anything about it after release.
<Keybuk> first line of the commit is the "subject"
<Keybuk> then blank line
<Keybuk> then body explanining change
<james_w> I don't have a clone
<Keybuk> oh, where did you get the Index: lines from?
<james_w> quilt
<Keybuk> ah
<Keybuk> s'ok, I'll do it for you then ;)
<james_w> thanks
<mbiebl> jdong: the idea with pk 1 is to use groups again to grant access automatically for certain actions
<Keybuk> james_w: you wrote the patch?
<james_w> I did
<james_w> with my own two hands
<jdong> mbiebl: ah, I see; how do  you associate a group with an action then?
<Keybuk> ok
<mbiebl> jdong: this is an example from the fedora package: http://pastebin.ca/1587773
<jdong> mbiebl: aha, that helps
<zul> james_w: ping can you place samba in the bzr for distributed development?
<Keybuk> james_w: http://cgit.freedesktop.org/dbus/dbus/commit/?id=03cc20707a3e7b2d8629e84d7a766f41edb8b444
<james_w> zul: sorry, samba failed, I need to investigate what the fix is, so it's not a two minute job
<zul> james_w: ah ok thanks
<Chipzz> pitti: or: "Every time someone asks, god kills a kitten" ;)
<james_w> thanks Keybuk
<zul> pitti: is it done yet is it done yet how about now?
<pitti> meeeeeeeeeeeeeeeeeeeoooooooooooowwww!!
<BenjaminKreuter> does anyone know if there is a way to monitor all patches that are merged into all ubuntu packages?
<ogra> http://patches.ubuntu.com/ probably
<joaopinto> check the .diff.gz for each package :) ?
<joaopinto> ogra, is that build from debian/patches ?
<pitti> lool, doko_: .eh_frame armel> awesome work! do you still want the genTOObuntu OO.o to be built, or shall I reject it from the queue? (you mentioned that an easier workaround was to use -fno-dwarf2-cfi-asm)
<ogra> joaopinto, no idea
<dholbach> or there's the ubuntu-patches mailing list
<ogra> dholbach, stop stating the obvious :P
<pitti> Keybuk: want me to do the sysvinit upload to drop the sysvinit binary? Or do you have other changes queued for sysvinit anyway?
<BenjaminKreuter> dholbach, ogra: thanks
<joaopinto> ubuntu.patches is for ubuntu vs debian
<doko_> pitti: good question: I was thinking about turning off the armel buildds until we have the fixed toolchain in place, then rebuild.
<BenjaminKreuter> joaopinto: yeah i noticed; that is somewhat useful for what i am trying to do
<Keybuk> pitti: I have nothing queued, be my guest
<Keybuk> pitti: personally I'd wait until after beta freeze is over for that upload
<Keybuk> but I'm more scared of slangasek than you ;)
<pitti> doko_: fine for me, too; just asking because OO.o takes so long to build on arm, so we probably don't want to do it in vain
<doko_> pitti: when do you plan to open the gates?
<pitti> Keybuk: I keep uploading to the queue since Tuesday *shrug*
<pitti> doko_: after the beta release :)
<pitti> Keybuk: I wasn't meaning to accept it before beta :)
<slangasek> yes, uploading to the queue is allowed as long as you don't expect it to get into beta
<Keybuk> pitti: but then you potentially block critical fixes
<Keybuk> if a patch is necessary for the release
<Keybuk> but you've queued a bigger uploade
<Keybuk> it becomes difficult
<Keybuk> e.g. version numbers already claimed, files already existing, etc.
<slangasek> Keybuk: speaking of which, I'd love to have an upstart upload in the queue that fixes the behavior of upstart-job, but don't want to upload if you've got other stuff in progress
<slangasek> (oh, and I don't have time to upload it right now anyway :P)
<robbiew> heh
<Keybuk> slangasek: there's the e8s fix pending
<slangasek> Keybuk: nope, unapproved queue doesn't claim the version numbers
<slangasek> unless you count bzr history
<slangasek> but history is mungible
<Keybuk> slangasek: you can't upload two things into it with the same version number without rejecting
<slangasek> yes, you can
<Keybuk> you can?
<slangasek> unapproved is special that way
 * Keybuk didn't know that ;)
<doko_> pitti, lamont: is there a way to accept single builds for armel only?
<Keybuk> so should I upload these dbus and upstart packages to the queue?
<ogra> and possibly route them to the marvell buildd :)
<pitti> Keybuk: sure, go ahead
<pitti> doko_: not for me
<ogra> doko_, ask lamont to put all buildds but safou on manual after your upload, so oo.o must build on the speedy buildd :)
<ogra> s/after/right before/
<ogra> i bet that gains you some hours
<doko_> pitti, lamont: proposal to prepare binutils, eglibc and gcc-4.4 uploads, accept these before lifting the freeze, then setting all armel buildds to manual
<pitti> doko_: hm, that would mean that we would have to set all buildds for the other arches to manual, too, though?
<lool> pitti: Please keep the oo.o we have in the queue, I think we're still testing the rebuild oo.o
<pitti> lool: *nod*; just asking :)
<doko_> pitti: no
<pitti> doko_: or alternatively hack soyuz to drop the build records for !armel
 * cjwatson vetoes hacking soyuz right now
<cjwatson> bad plan
<doko_> pitti: I think that's not necessary
<pitti> but then they'd be out of date on all other archies
<pitti> it sounds very hackish
<pitti> I think we should just wait the few hours until the release
<pitti> doko_: private armel PPA and binary copying?
<cjwatson> I don't have a problem putting the armel buildds on manual, though I think doko can do that too
<pitti> sounds much safer to me
<doko_> pitti, cjwatson: does binary copying work? Then I could start the builds now
<cjwatson> I would prefer them to be built in the main archive, to be honest
<doko_> ok
<cjwatson> complicated archive games are not my idea of fun at the moment ...
<pitti> Keybuk: sysvinit> oh argh, dh compat 1; that becomes much more intrusive than I thought
<lamont> pitti: _1_???  wow
<pitti> anyway, uploaded
<jdstrand> Keybuk: could an sreadahead segfault interrupt the boot process?
<jdstrand> Keybuk: (hi btw)
<jdstrand> Keybuk: I just filed filed bug #440046
<ubottu> Launchpad bug 440046 in sreadahead "sreadahead crashed with SIGSEGV in __pause_nocancel()" [Undecided,New] https://launchpad.net/bugs/440046
<Keybuk> I don't see how
<jdstrand> Keybuk: there are several private bugs that are likely dupes
<jdstrand> hmmm
<Keybuk> *shrug*
<kees> lool: I have tools that scan the archive for all sorts of things (e.g. ELF sections).  How can I help with your ARM stuff?
<Keybuk> I ignore all private bugs
<Keybuk> well, that's not quite true
<Keybuk> private bugs don't end up in my INBOX
<Keybuk> so I never see them
 * jdstrand wonders if it was the recent gdm change that kept it from starting...
<Keybuk> it's like the difference between abstinence and being ugly
<jdstrand> heh
<jdstrand> Keybuk: if you are interested, I could hook you up on those private bugs ;)
<Keybuk> not especially :p
<Keybuk> oh, I've seen that stack trace before
<lool> kees: That would help a lot
<Keybuk> there's zero useful information in it :-/
<lool> kees: That's exactly the type of help-ing stuff I was looking for, thanks   :-)
<kees> lool: the down-side is that the current tool expects a local mirror.  perhaps it can be run on rookery, though.
<lool> kees: It's ok, I'm building one
<kees> lool: so what characteristics are you checking for?
<lool> kees: It's not entirely in stone yet, it seems we want to look for to scan for R_ARM_RELATIVE in TEXTREL sections
<kees> lool: what command line would show that?
<lool> kees: It's not clear whether I need to scan for eh_frame sections too
<lool> kees: I'm not sure; I shall start with binaries matching readelf -a | grep TEXTREL
<kees> lool: do you know of one that matches currently?
<lool> kees: I'm still trying to get input on what exact characteristics to look for in the binaries and whether that really implies in all cases that they are borken
<lool> kees: libc
<lool> lool@dove:~$ readelf -a /lib/libc.so.6 | grep TEXTREL 0x00000016 (TEXTREL)                    0x0
<lool> kees: Sorry, after TEXTREL is the output
<lool> Output is:
<lool>  0x00000016 (TEXTREL)                    0x0
<lool> (IRC client being too clever)
<jdstrand> cjwatson: hi! so, I'm having a problem with usplash 0.5.39 and gdm 2.28.0-0ubuntu8. I upgraded this morning, dutifully rebooted (as I was told to) and the boot hung and gdm did not start.
<jdstrand> cjwatson: this was with usplash 0.5.39 and gdm 2.28.0-0ubuntu8
<jdstrand> cjwatson: I downgraded usplash to 0.5.38 (but not libusplash0 as I just noticed) and gdm to 2.28.0-0ubuntu6, rebooted and it worked fine
<jdstrand> cjwatson: unfortunately, I am rather notoriously bad at debugging usplash, and not sure where to start
<cjwatson> jdstrand: can you find what processes are running?
<cjwatson> when it hangs
<cjwatson> ps aux | grep usplash is probably a good start
<jdstrand> cjwatson: ok, let me upgrade and reboot
<kees> lool: http://bazaar.launchpad.net/~ubuntu-security/ubuntu-security-tools/trunk/files/head%3A/repo-tools/  look at "for-archive", and the tools in the "for-archive-tools" directory
<kees> lool: the comments at the top of for-archive detail some example runs
<kees> lool: it was originally built for scanning source, but it works on binaries too
<kees> lool: the execstack one is a good example of that.
<kees> lool: the "for-archive-tools/has-execstack" is probably a reasonable starting point for the tool you'll want to create that does the TEXTREL test
<lool> kees: Cool thanks
<kees> lool: let me know if you have any questions, some of it is a bit non-obvious.  :P
<jdstrand> cjwatson: ok. first off-- no splash screen at all
<jdstrand> cjwatson: second, ps auxww|grep usplash shows usplash is not running
<lool> kees: Ok
<cjwatson> jdstrand: ok, are there any usplash-related processes running, such as usplash_write?
<jdstrand> cjwatson: I see output from the last script in /etc/rc2.d
<cjwatson> jdstrand: also, | grep initctl
<jdstrand> cjwatson: the new initctl emit you added is present
<cjwatson> jdstrand: can I see a complete ps auxfww?
<jdstrand> initctl emit starting-dm DM=gdm
<jdstrand> hold on
<cjwatson> right, I expect it's blocked on something, but would like to find out what
<jdstrand> cjwatson: http://paste.ubuntu.com/283083/
<jdstrand> initctl emit and found it sometimes would hang...
<jdstrand> err
<jdstrand> I totally lost the first part of that sentence
<jdstrand> cjwatson: fyi, in my recent foray into upstart I played with 'initctl emit' and found it would hang. I figured I was doing something wrong and abandoned using it
<Keybuk> jdstrand: what does "status usplash" say?
<jdstrand> Keybuk: usplash stop/killed, process 439
<Keybuk> and you have no process 439?
<jdstrand> Keybuk: correct
<Keybuk> don't suppose, before the call to initctl emit, you could add a ps dump and status usplash command
<Keybuk> log them somewhere
<Keybuk> and reboot until you get the hang again?
<jdstrand> sure I could
<Keybuk> then we'd have a log of what the usplash pid really was
<Keybuk> what upstart thought it was
<Keybuk> etc.
<cjwatson> jdstrand: initctl emit blocks until any jobs that hook off that event are done
<jdstrand> Keybuk: http://paste.ubuntu.com/283095/
<Keybuk> interesting
 * Keybuk wonders whether that pid is even right
<jdstrand> I have 'quiet splash' on the kernel line
<slangasek> it must be right, pid 1 isn't allowed to be wrong :P
<cjwatson> maybe this is a consequence of my stupid 'exec true' hack
<cjwatson> I bet it works if you put USPLASH=y in /etc/initramfs-tools/initramfs.conf
<cjwatson> because that pid is higher than all the processes started in the initramfs, so it must have been started later
<jdstrand> I don't have a USPLASH=... line in there at all
<jdstrand> shall I add it?
<cjwatson> it should work as a workaround, but (a) it's not the desired distro default and (b) Keybuk may want to debug more first
<cjwatson> oh, hmm, maybe it isn't higher than all the initramfs processes, I can't read
<cjwatson> line numbers != pids
<jdstrand> ok, wasn't sure if maybe my file should've had it
<cjwatson> no
<cjwatson> Keybuk: I'm properly stumped now as to what it's blocked on, though, since apparently usplash_write wasn't running
<Keybuk> upstart thinks it is
<Keybuk> with pid 439
<Keybuk> so it's waiting for SIGCHLD with that pid
<Keybuk> since that pid doesn't exist, that will never happen
<Keybuk> could be maybe usplash exited before the initramfs?
<jdstrand> I might say that usplash has been wonky on this machine in the past
<mdz> kirkland, I have cleaned up some of the upstart scripts based on the earlier discussion with Keybuk.  I've eyeballed the changes, but can't quite test them at the moment.  is it ok if I push to the ubuntu branch anyway, and you bring them into your next upload?  if I made any mistakes, they should be easy to spot and correct
<Keybuk> jdstrand: when do you see it vanish?
<jdstrand> I'd see it on boot, and then it would go away and I'd see text
<jdstrand> Keybuk: currently, I never see it. if I downgrade usplash/gdm, I can check
<Keybuk> hmm
<cjwatson> it's possible for it to time out before the initramfs of course ...
<Keybuk> cjwatson: sounds like jdstrand's bug is that a usplash pid is being written, but when upstart starts, there's nothing with that pid
<cjwatson> (in general, presumably not for jdstrand)
<Keybuk> the hack could probably do with more safeguards
<jdstrand> Keybuk: would it be helpful to downgrade usplash and let you know where I stop seeing it?
<Keybuk> (pid exits, parent is 1, etc.)
<cjwatson> this *might* be fixed by the --pidfile thing I'm working on
<Keybuk> cjwatson: indeed
<cjwatson> haven't had an opportunity to reboot since I put that together
<cjwatson> should I make usplash remove the pidfile if it exits too?
<cjwatson> with the caveat that it might not get the chance to do so
<cjwatson> I can't remember if that's standard practice; I thought not, though
<Keybuk> I guess
<jdstrand> cjwatson, Keybuk: do you guys need more debugging on this machine in the current state?
<cjwatson> start-stop-daemon never removed it
<Keybuk> upstart-wise I understand the problem
<Keybuk> cjwatson: leaving an invalid pid file is bad though in this case
<Keybuk> e.g. what if the pid is 1 ? :)
<Keybuk> you'll always get an indefinite hang
<cjwatson> we can't guarantee to always remove it
<cjwatson> so I think we need to ensure that the initial pid is sane (not 1!), but otherwise rely on upstart to notice if the pid has vanished
<cjwatson> this fails if pids manage to wrap round in the initramfs, I agree
<cjwatson> but that seems like a problem sufficiently unlikely that we can live with it until upstart is managing the initramfs too? :)
<slangasek> aww, but I wanted to run usplash+upstart on my 8-bit processor
<jdstrand> cjwatson: is there any more I can do to help atm?
<cjwatson> jdstrand: not for me, Keybuk might have something else
<jdstrand> have you filed a bug yet? if not, I weill
<jdstrand> will
<fale> hi
<cjwatson> I have not
<mdz> slangasek, are there logs available for the UEC image build process?
<mdz> slangasek, I asked recently if it used gzip --rsyncable, and was told yes, but experimentally I'm not seeing it rsync properly
<LaserJock> when is the deadline for Beta .iso testing?
<jdstrand> cjwatson: fyi-- bug #440071
<ubottu> Launchpad bug 440071 in gdm "initctl emit hangs boot" [Undecided,New] https://launchpad.net/bugs/440071
<jdstrand> cjwatson: I nominated for release and added the regression-potential tag, but otherwise did no triaging
<slangasek> mdz: logs don't offer detail on gzip invocation, only on the vmbuilder run itself
<slangasek> mdz: confirmed in the source that it's calling --rsyncable, though
<jdstrand> cjwatson, Keybuk: I killed of the initctl process which allowed gdm to start. please feel free to ping me if you need anything else
<jdstrand> killed *off*
<cjwatson> jdstrand: it's unequivocally not a gdm bug
<cjwatson> jdstrand: it has a usplash component, and an upstart component
<jdstrand> yeah, I realized that after I filed it
<cjwatson> I don't have a functional browser right now since I'm testing the usplash part of the fix
<jdstrand> I'll adjust
<Keybuk> cjwatson: I don't think it's strictly an upstart bug
<Keybuk> because it's just doing what it's told
<Keybuk> that's always the dangerous thing about a "pretend you know about $PID" hack
<Keybuk> if you get $PID wrong, you're inherently violating assertions that upstart makes true
<Keybuk> but as you say, this is probably trivially fixed ;)
<cjwatson> sure, but do you agree with me that there's no way for a process starting in the initramfs to be certain about removing the pidfile if it crashes?
<cjwatson> I mean, it can do its best
<Keybuk> I do
<Keybuk> but there's no fix for that
<Keybuk> if that happens, you're screwed
<cjwatson> if the pid just plain doesn't exist when upstart tries to import that pidfile, there is no sense in it waiting for SIGCHLD for it, is there?
<cjwatson> I agree and understand that there are corner cases
<jdstrand> well, changed to have upstart and usplash. usplash marked as Triaged. upstart untriaged (I'll let you decide). I have not milestoned it
<cjwatson> but I don't see how they're worse
<cjwatson> I don't suppose I'm saying that it's an upstart *bug* as such, but in the sense of a Launchpad bug task, i.e. a to-do item to add a sanity check, I don't think it's too unreasonable?
<cjwatson> Keybuk: of course, now I look at it, our previous conjecture about usplash_write QUIT was entirely bogus
<cjwatson> Keybuk: if no process has a FIFO open for writing, then open() returns ENXIO
<cjwatson> and usplash_write just exits zero
<jcastro> Lots of slots left, get em while they're hot! https://wiki.ubuntu.com/UbuntuOpenWeek/Prep
<jcastro> Missing lots of foundations talks (hint hint!)
<slangasek> "how to write an upstart job that will hang on reboot"
<slangasek> :-)
<kirkland> mdz: yes, please do push your upstart fixes
<mdz> kirkland, just to be clear, I don't think they fix anything (the behavior should not change), but they're more correct based on what I learned
<kirkland> mdz: right, it's good to have those, as it slightly increases the probability that Keybuk might help us debug future issues with them ;-)
<mdz> kirkland, done
<kirkland> mdz: thanks
<kees> Riddell: so, uhm, koffice 1.x is unsupported by KDE now.  Was there some kind of plan to move to koffice2?
<Keybuk> slangasek: the point is that it isn't an upstart job
<Keybuk> it's pretending that something an initramfs script was *really* an upstart job all along
<Keybuk> despite upstart having nothing to do with it
<slangasek> Keybuk: sorry, I'm talking about a *different* way to hang on reboot
<Keybuk> lying, in this case, results in a severe penalty card
<Keybuk> oh :p
 * cjwatson remembers that _exit is kind of a good idea in processes involving atexit
 * LaserJock gives davmor2 a hug
<davmor2> LaserJock: you need to look at postgresql backend to moodle and ltsp
<davmor2> LaserJock: out of interest why is there only ubuntu-desktop and edubuntu-server as default seeds on the dvd for debian-installer?  It means you don't get the edubuntu desktop on the installed system, which seems counter intuitive some how
<cjwatson> davmor2: that's a bug which I fixed in debian-cd not long ago
<cjwatson> davmor2: debian-cd was preseeding edubuntu-desktop-addon, but the task name changed to edubuntu-desktop-gnome
<cjwatson> and we hadn't kept track
<davmor2> ah
<mdz> slangasek, thanks for checking re: vmbuilder and --rsyncable
<slangasek> mdz: sure
<kees> jcastro: hey, sign me up for a "writing secure code" session, if you've still got room. 1900 or later is best.
<jcastro> kees: awesome, on it
<kees> cool
<didrocks> MacSlow: Can you pease try my patched anjuta available in my ppa? (https://launchpad.net/~didrocks/+archive/ppa). I think the crash is specific to amd64.
<Lazy> hi, is my bug report in wrong category? https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/437087
<ubottu> Launchpad bug 437087 in update-manager "Update manager fails while trying to update from Jaunty to Karmic alpha 6" [Undecided,New]
<Lazy> If the beta is released today there might be lots of people who can't upgrade if this is a common case
<Riddell> kees: who says it's unsupported?  we're sticking with KOffice 1 reluctantly because they want us not to switch to KOffice 2 yet
<kees> Riddell: KDE emailed ubuntu security and said it's unsupported.  :(
<Riddell> kees: who from KDE?
<kees> Riddell: David Faure
<Riddell> kees: and what's the issue you were asking him?
<kees> Riddell: we had asked koffice about xpdf issues in koffice 1.x.  they just got back to us today with "koffice 1.x is unsupported, and xpdf isn't used in koffice 2.x"
* slangasek changed the topic of #ubuntu-devel to: Ubuntu 9.10 Beta released! | Archive: FeatureFreeze, UIFreeze | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-jaunty | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<Riddell> ooh!
<slangasek> superm1: please go live with http://mythbuntu.org/9.10/beta
* slangasek changed the topic of #ubuntu-devel to: Ubuntu 9.10 Beta released! | Archive: frozen briefly for armel toolchain massaging; FeatureFreeze, UIFreeze | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-jaunty | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<pitti> ogasawara: I see a lot of reports that people in karmic have problems with CDs/DVDs (lots of I/O errors in dmesg, like bug 435237 or bug 438065; did you see other reports about that? is there a master bug?
<ubottu> Launchpad bug 435237 in linux "[Karmic] wodim is unable to burn cds" [Undecided,New] https://launchpad.net/bugs/435237
<ubottu> Launchpad bug 438065 in linux "Karmic: DVDs cannot be mounted" [Undecided,Confirmed] https://launchpad.net/bugs/438065
<pitti> slangasek: wohoooo! congratulations!
<MacSlow> didrocks, just downloaded them...
<pitti> ogra: I also saw "[sr0] unaligned transfer" a lot
<robbiew> slangasek: nice job on Beta...as usual ;)
<superm1> slangasek, it's available now
<MacSlow> didrocks, still segfaults here -> http://paste.ubuntu.com/283271
<didrocks> MacSlow: ok thanks, i'm still working with upstream on this
<didrocks> MacSlow: I'll try to grab a new amd64 machine to confirm that the issue is architecture related
<MacSlow> didrocks, great... thanks for the effort!
<MacSlow> didrocks, I'm still fine with the older anjuta for the time being.
<didrocks> MacSlow: yep, but I'll prefer to fix this the sooner, the better :)
<MacSlow> didrocks, of course
<seb128> the queued uploads are still hold for a reason?
<seb128> oh, I guess it's in the topic
<seb128> annoying I wanted to make sure nothing was too broken when everything is built
<ogasawara> pitti: we're tracking a similar bug where blank cd's were failing to be recognized and indeed has I/O errors in the logs, but we do not have one master bug
<pitti> ogasawara: ok, these reports are all for data CDs (not blank)
<ogasawara> pitti: I'd would like to look into bug 438065 more since it noted it's not an issue with 2.6.32-rc1
<ubottu> Launchpad bug 438065 in linux "Karmic: DVDs cannot be mounted" [Undecided,Confirmed] https://launchpad.net/bugs/438065
<pitti> ogasawara: also, dtchen reported that he could reproduce, and it was fixed in 2.6.32rc1, so perhaps there's a patch we should cherrypick
<pitti> heh, right :)
<pitti> ogasawara: thank you
<ogasawara> pitti: I'll make sure it gets on our list of bugs to track
<rrva> hi.. trying to figure out how to solve http://bugs.launchpad.net/bugs/438962 blocks me from booting
<ubottu> Launchpad bug 438962 in udev "upstart/mountall does not boot after mounting crypto disks" [High,Confirmed]
<seb128> is there any estimation for when uploads will be accepted?
<seb128> ie is that worth hanging around waiting for that or that's not going to be tonight?
<slangasek> seb128: not tonight
 * seb128 is not there tomorrow and would like to flush all the things he has pending today
<seb128> :-(
<slangasek> that doesn't mean you can't upload, though?
<seb128> there is quite some syncs I want to do
<seb128> and I want to be around in case there is an issue
<slangasek> ah
<seb128> I guess I will have to work tomorrow
<seb128> *shrug*
<seb128> thanks anyway
<pitti> seb128: just mail me a list of syncs, I'll do them for you
<seb128> pitti, no, I want to be around and not sync a new gtk on friday before everybody goes away
<pitti> heh
<seb128> but thanks
<pitti> oh, we can sync gtk now? nice
<seb128> yes ;-)
<seb128> I guess there is no way to just tell the armel builders to not build?
<seb128> so people could get work done on other arches ;-)
<cjwatson> seb128: actually, I was thinking that myself - we have them on manual anyway
<cjwatson> slangasek: any reason you can think of why we shouldn't just flush the queue and just gradually filter stuff through on armel?
<cjwatson> I can force the ordering by way of scores
<Nivex> I'm trying to do an iSCSI install of Karmic Server Beta in a VM.  The VM has no hard disks defined.  I am not being prompted for iSCSI targets as the tech overview says I should be.  I don't even know where to begin so I can file a useful bug report.
<rrva> how can i roll back upstart to sysvinit ?
<LaserJock> how is the d-i tasksel task list populated? is it based on the packages on the disk?
<mdke> slangasek: will do, thanks very much
<mdke> slangasek: shall I upload? I guess it can sit in the queue happily until after beta?
<sbasuita> It seems there is a problem with the beta torrents: "ubuntu.com: Error: Requested download is not authorized for use with this tracker." (from deluge on the amd64 desktop). I saw a forum post with the same issue on the i386 one as well. Is this known?
<cjwatson> rrva: you can't, not in karmic
<cjwatson> LaserJock: yes, Task-Key fields
<mdke> slangasek: got the answer from the topic, uploaded. Congrats on the beta and thanks again
<TheMuso> killall speech-d
<TheMuso> woops
<Darxus> There's no chance of a new major revision of hugin making it into karmic at this point, without a security fix, right?
<Darxus> Somebody is trying to get me to test his package because he thinks he can get it in karmic.
<cjwatson> Darxus: depends, https://wiki.ubuntu.com/FreezeExceptionProcess
<cjwatson> and https://wiki.ubuntu.com/FeatureFreeze
<Darxus> cjwatson: Thanks.  This doesn't seem to meet the requirements during Beta Freeze.
<Darxus> As much as it sucks for this package to be so far behind in karmic.
<cjwatson> we are not in beta freeze
<cjwatson> beta freeze is the period between a week before beta release and the beta release
<cjwatson> after the beta release (which just happened) we return to feature freeze
<cjwatson> the purpose of beta freeze is to stabilise things so that we can get the beta out
<Darxus> cjwatson: What?  The karmic release schedule says beta freeze started on september 24th?
<cjwatson> Darxus: yes, and it ends when the beta releases, which just happened
<Darxus> Oh.  I didn't realize... I object to things being allowed in more permissibly after the beta release :P
<Darxus> Thanks.
<cjwatson> Darxus: if you follow the link to BetaFreeze from the schedule, you will see this described
<Darxus> Thanks.
<Darxus> Oh, that's what FFE stands for :P
<Darxus> I still don't think testing by just me and the packager would be sufficient?
<cjwatson> dunno, certainly not going to look at this time of night :)
<Darxus> Heh.
<cjwatson> it's less testing and more the quantity and type of changes
<cjwatson> though obviously testing is important
<Darxus> Well, it's a major revision of hugin, so I expect the changes to be substantial.
<sharms> pitti: did you get my message about usblp
<sharms> pitti: by disabling usblp by default people using the usb-parallel adapters for a variety of tasks will no longer be able to use them, is there is work around, and if not how do I get that added to the release notes?
<sharms> or anyone for that matter, since blacklist usblp is in /etc/modprobe.d/blacklist-cups.conf, these adapters will stop working unless they all get userspace drivers for them right
#ubuntu-devel 2009-10-02
<elmo> I think I must be losing my mind; I just upgraded to karmic and 'apt-get install amarok' is failing, even though I can see the package in main
<lifeless> elmo: what error?
<dtchen> Darxus: your intel8x0 quirk may not land in Karmic final but will be in Lucid for certain
<MenZa> I hope this isn't offtopic. I'm curious as to why the ncurses interface of the alt cd doesn't spend ages re-scanning partitions when manually setting a partition layout, and ubuquity makes me want to stab myself. Could anyone tell me if this is a technical limitation of ubiquity or the library used for it? :\
<ryanakca> Hmmm.. http://summit.ubuntu.com/openid/login?next=/uds-l/sponsorship/done/ sends me on a redirect loop between summit.ubuntu.com and login.launchpad.net
<ryanakca> (to whoever runs summit.ubuntu.com)
<MenZa> ryanakca: Believe I had that with Ubuntu One earlier today as well.
<jdong> I'm assuming seeing the [sda] assuming write-through doesn't go well with our "pretty silent bootup" goal?
<arand> Is there some problem with the torrents for the beta, there's a few people mentioning  tracker authorization issues in #+1 due to missing files on tracker?
<ewrjiwor> !ops
<ubottu> Help! bhale, infinity, Hobbsee, jdub, thom, fooishbar, fabbione, mdz, lamont, or Keybuk
<Pricey> ewrjiwor: Hi?
<Rashko> hi all
<ewrjiwor> sup
<ewrjiwor> Ban me
<Rashko>  I need help please
<Rashko> How to enable ubuntu 8.04 supoort multiport pci card ?
<nixternal> Pricey: he just wanted to get banned, not K-lined :p
<slangasek> cjwatson: think> no ;)
<al-maisan> Good morning!
<dholbach> good morning
<nixternal> good morning to you sir!
<dholbach> hey nixternal!
<dholbach> pitti: does 'fix committed' in bug 415297 mean that it's all sponsored already?
<ubottu> Launchpad bug 415297 in evolution-couchdb "Missing supported fields in evolution-couchdb" [Medium,Fix committed] https://launchpad.net/bugs/415297
<dholbach> if so, I'll unsub the sponsors team
<pitti> Good morning
<pitti> dholbach: yes, I should have noted that in the bug trail
<pitti> dholbach: I sponsored pretty much all the pending DX/OLS stuff last night
<dholbach> pitti: I'l unsub the sponsors
<pitti> sharms: usblp> it's back in the cups upload in unapproved
<pitti> sharms: but no, I didn't get your message; where did you send it, /query?
<dholbach> slangasek: does bug 432578 look OK to you? acpi-support portion?
<ubottu> Launchpad bug 432578 in ubuntu-moblin-remix "Recognize Moblin's dalston as a power manager" [Medium,Confirmed] https://launchpad.net/bugs/432578
<dholbach> bug 425155 probably too
<ubottu> Launchpad bug 425155 in acpi-support "Recognize xfce4-power-manager" [Wishlist,Fix committed] https://launchpad.net/bugs/425155
<Mez> is there a channel for jammers?
<dholbach> Mez: #ubuntu-locoteams (and #ubuntu-devel #ubuntu-bugs #ubuntu-doc #ubuntu-testing #ubuntu-translators)
<Mez> dholbach: I was thinking there might be a channel specific to the jam like last time :D
<dholbach> I can't remember if there was
<dholbach> as you can see above - there's a bunch of channels already :)
<dholbach> tjaalton: HAPPY BIRTHDAY!!!
<tjaalton> dholbach: :)
<tjaalton> thanks
<Mez> dholbach: there was #ubuntu-bugjam
<Mez> and a couple of uk based ones
<dholbach> Mez: might be, I just think it's a good idea to bring people together with others who do packaging/translations/documentation/bugs/testing more regularly
<Mez> dholbach: but probably not for announcing video feeds of jams etc etc
<dholbach> I'm not going to stop you open up another channel :)
<Mez> dholbach: unless you use your CC powers to overrule the IRCC, you can't :D
<Mez> and I doubt you ever would.
<Mez> tis just lonely in there.
<Mez> dholbach: so, ready for the shock of me actually doing some ubuntu work again ? :P
<dholbach> I have to get used to the thought ;-)
<Mez> dholbach: :P I'm actually working towards my Ubuntu certified professional ')
<dholbach> nice
<Mez> but for most of my stuff, (packaging et al) its easier to filter down from debian (no delta needed)
<dholbach> right
 * dholbach takes the dog for a walk - bbiab
<Mez> have fun
<dholbach> :)
<robert_ancell> hey, does anyone know where http is handled in gio?
<cjwatson> MenZa: it's somewhere between a technical limitation of ubiquity and a bug
<cjwatson> MenZa: actually, the slowness is evident in d-i too, you just don't notice it so much because of the different UI structure
<cjwatson> MenZa: ubiquity's partitioner tries very very hard to use the same logic as d-i's (I don't ever want to end up maintaining two different installer partitioners ...)
<cjwatson> MenZa: and the way it does this is sort of the equivalent of driving the underlying partitioner around to get all the information it needs to display
<cjwatson> MenZa: so the "scanning disks" stage is about the same speed as it would be to select each partition in turn in the text interface
<cjwatson> MenZa: some of this should be solved by just plain making the underlying interface faster (perhaps by rewriting some inner-loop bits in C, although that's trickier than it looks), and some of it should probably be solved by smarter caching or even just utter hacks at the ubiquity level
<cjwatson> MenZa: there's been a bug open about it for a good while, but it's not straightforward
<pitti> seb128: flushing unapproved, and asking IS to thaw, FYI
<seb128> pitti, rock on!
<liw_> I upgraded my laptop to karmic, and the upgrade seemed to go OK. But it can't boot into the upgraded system: I get just a b&w Ubuntu logo about a second or two into the boot, and then nothing. Ideas? Could this be related to the laptop disk being encrypted?
<pitti> liw_: try booting without "splash"?
<liw_> the command line in grub does not have splash in it
<pitti> uh, that's not tested any more?
<liw_> perhaps I just don't know how to use grub
<dholbach> holy crap - that's a lot of uploads
<chrisccoulson> heh, it's going to be an interesting afternoon of updates ;)
<liw_> pitti, what should I actually do to avoid splash?
<pitti> liw_: you can explicitly specify "nosplash"
<pitti> liw_: however, it shouldn't start at all if there's no "splash" in the kernel command line
<pitti> reading /usr/share/initramfs-tools/scripts/init-top/usplash, anyway
<pitti> dholbach: stuff piled up over the freeze :)
<liw_> if I change "quiet" to "nosplash" and then press b in grub, it blackens the screen, and about a second later shows me the bios post screen
<pitti> oh, right, that's still grub 1
<pitti> hm, that sounds bad..
<pitti> liw_: is that an intel card?
<liw_> meh, sorry about that, having trouble with pidgin's UI
<Chipzz> liw_: there was someone complaining about not being able to boot from a crypted partition earlier this night too
<liw_> pitti, lenovo x200s, I'll need to check the graphics chipset
<Chipzz> not at all sure if it's related
<pitti> liw_: if it's intel, you can try with "i915.modeset=0" to disable KMS
<liw_> pitti, yeah, it's intel
<pitti> I didn't try with encrypted disk recently, that very well sounds like a potential problem source
<liw_> pitti, no change with i915.modeset=0
<pitti> liw_: does init=/bin/bash work?
<Chipzz> pitti, liw_:
<Chipzz> 22:25 < rrva> hi.. trying to figure out how to solve http://bugs.launchpad.net/bugs/438962 blocks me from booting
<ubottu> Launchpad bug 438962 in udev "upstart/mountall does not boot after mounting crypto disks" [High,Confirmed]
<Chipzz> 22:25 < ubottu> Launchpad bug 438962 in udev "upstart/mountall does not boot after mounting crypto disks" [High,Confirmed]
<liw_> just to be sure, after I edit a kernel command line parameter in grub, is the b key the right way to boot into the system with the edited command line?
<Chipzz> like I said, not sure if it's related at all
<cjwatson> liw_: that should be right
<cjwatson> (with grub1; it's C-x in grub2)
<liw_> hm, after minutes of waiting at the "ubuntu logo" screen, with the machine not responding to any keypressed (ctrl-alt-del, alt-f1, ctrl-alt-f1, caps lock, ...), it dropped into a busybox shell, complaining it can't see the disk (partition), named via a uuid
<liw_> unfortunately, I didn't see more details, I was pressing the power button at the time, and a second later the machine powered off
<liw_> after rebooting, the hard disk is making whining noises... I know how it feels
<pitti> liw_: right, that seems it spins for the root fs and times out; cryptsetup/upstartification regression apparently :-(
<liw_> pitti, in that case, I'll need to reinstall?
<pitti> liw_: you should be able to unlock the root fs in the initramfs prompt?
<liw_> pitti, how?
<pitti> try "cryptsetup luksOpen /dev/yourrootdevice myroot
<pitti> the value for "myroot" shouldn't matter much
<pitti> since fstab should be uuid-based
<pitti> but you can search for "crypttab", it shuold be somewhere in the initramfs
<pitti> probably just in /etc/
<liw_> there is no crypttab
<liw_> the cryptsetup command worked, what next?
<pitti> hm, that sounds wrong
<pitti> liw_: what was the root= argument on the kernel command line?
<pitti> uuid or dev/mapper/myroot ?
<liw_> pitti, how do I check?
<pitti> liw_: cat /proc/cmdline
<liw_> ah, of course
<pitti> liw_: if its' UUID, just pressing Ctrl-D should work
<liw_> pitti: root=/dev/mapper/havelock-root
<pitti> liw_: if it's name-based, you need to specify "myroot" at cryptsetup lulsOpen
<pitti> "havelock"?
<liw_> hostname
<pitti> ah :)
<pitti> liw_: ok, so please:
<pitti> cryptsetup luksClose myroot
<pitti> cryptsetup luksOpen /dev/yourencryptedrootdev havelock-root
<pitti> exit
<liw_> luksClose failed: Device busy
<pitti> bah
<pitti> liw_: perhaps just reboot, and do it again
<liw_> ack, doing that
<liw_> pitti, rebooted, waited for initramfs busybox prompt, said "luksOpen /dev/sda1 havelock-root", then "exit", immediately got back the prompt, with some preceding error messages saying the disk by-uuid doesn't exist
<pitti> liw_: hmm
<pitti> shouldn't udev generate those automatically?
<liw_> I would assume so
<liw_> attempting to mount the rootfs manually (just to see if it's ok), I get an error saying the mount command does not exist
<pitti> bwah
<pitti> liw_: I guess it's some magic mountall invocation now
<pitti> liw_: does calling that do anything?
<liw_> but if I run just "mount" it lists the mounted filesystems
<liw_> mountall: not found
<pitti> liw_: hm; I'm afraid this needs Keybuk now
<pitti> I'm not familiar yet with the new boot process, I'm afraid
<liw_> Keybuk is not present, hmm
<liw_> I'm going to be needing this laptop to do useful stuff, so I guess I'll have to reinstall now :(
<cjwatson> mountall isn't used in the initramfs
<cjwatson> the initramfs mounts the root filesystem in the usual way; mountall takes over for everything else after that
<pitti> liw_: hm, so if just "mount" works and displays the mounts, how can it "not exist" when you try to monut the root fs? or did you mean the device doesn't exist?
<liw_> pitti, "/bin/sh: mount: not found" -- that's the error I get
<liw_> both the device node and the target directory exist
<pitti> liw_: does mount --help work?
<liw_> pitti, yes
<pitti> liw_: do you have some stuff in /conf/conf.d/cryptroot which looks enlightening?
 * pitti just stabs into the dark now, there's not much more I can squeeze out of reading /usr/share/initramfs-tools/scripts/local-top/cryptroot
<pitti> the heart of this is to call cryptsetup luksOpen with the correct name, so that the root device appears (/dev/mapper/whatever), and the normal root mounting can go on
<liw_> pitti, that /conf/conf.d/cryptroot file contains two lines, with target=sda1_crypt,source=/dev/disk/by-uuid/.....,key=none,lvm=havelock-root in one, and s/-root/-swap_1/ for the other
<pitti> right
<pitti> swap shoulnd't be utterly importnat, but of course you can unlock it, too
<pitti> liw_: last time I did that, I just had to luksOpen and control-d
<pitti> but that was some 1.5 years ago..
<liw_> hm, how do I unlock the swap partition?
<liw_> modifying the luksOpen command results in an error saying it's not a LUKS partition
<pitti> so perhaps you don't have encrypted swap then, or it's encrypted without luks and a random passphrase
<pitti> but it shouldn't really stop the boot
<liw_> it should be luks + random passphrase
<liw_> ok, starting re-install now
<Laney> where are u-m hints stored?
<dholbach> /var/lib/update-notifier/user.d/
<Laney> thanks
<ogra> when did we drop the video group from the default user groups (and why)
<liw_> hngh, installed karmic from scratch, installed epiphany-webkit, it just core dumps
<maxb> Are there any gdm specialists around? I have a regression-potential nominated-for-karmic bug that I'd really like some more eyes on: bug 401047
<ubottu> Launchpad bug 401047 in gdm "Greeter doesn't have the right keymap set" [Undecided,Confirmed] https://launchpad.net/bugs/401047
<unimatrix> X server 1.7 is finally out with MPX support \o/
<unimatrix> what are the chances we see it in Karmic?
<pitti> maxb: hi! still? I spent half a day to fix gdm/g-s-d
<maxb> Also, bug 407457 is apparently going to be an actual regression in karmic, how can I submit it for release-noting?
<ubottu> Launchpad bug 407457 in openoffice.org "[upstream] [3.2] Regression in Microsoft Word import, tables disappear (architecture specific: amd64 broken, i386 OK)" [Medium,Triaged] https://launchpad.net/bugs/407457
<pitti> maxb: ah, actually sounds like the very thing I fixed; new gdm is currently building
<maxb> pitti: Still as of last time I booted, in the last ~24 hours. Let me do an update+reboot ... ah.. ok.... I will wait for that to build then :-)
<pitti> maxb: will take a bit to build; marked as a dupe
<maxb> whoa, impressive build queue
<maxb> :-)
<maxb> pitti: I don't see anything particularly related in the gdm 2.28.0-0ubuntu9 changelog?
<ogra> pitti, do you know why we have no video group anymore in the default groups ?
<pitti> maxb: you want ubuntu10
<pitti> maxb: see the master bug (bug 412121)
<ubottu> Launchpad bug 412121 in jessyink "Â»viewsÂ« feature does not work in Opera" [Medium,Fix released] https://launchpad.net/bugs/412121
<pitti> meh, not that one; well, you should have bug mail
<pitti> ogra: why would we need it?
 * ogra is currently packaging API libs for imx51 boards that need access to certain specific devices for image and video processing, i dont want to include udve rules making the devices 777
<ogra> *udev
<ogra> the users need to have rw access to these devices
<pitti> ogra: local users get permission to /dev/dri* stuff from udev-acl
<ogra> ah, cool, i'll take a look
<dholbach> slangasek, pitti: will there be new dailies tomorrow (with all the fixes after beta)? I'm aksing because there's lots of ubuntu jams happening over the WE and people will test CDs like mad
<ogra> i guess for the simcard device i also support i can just use dialout
<ogra> or is that going away as well ?
<maxb> bug 421212
<ubottu> Launchpad bug 421212 in gnome-settings-daemon "gdm ignores keyboard layout selection for variants" [High,Fix released] https://launchpad.net/bugs/421212
<maxb> pitti: My issue is not with variants, it's GB vs USA
<pitti> dholbach: CD cronjobs are still off, but I guess we can re-enable them today; I leave that to slangasek, though, there might be a reason
<pitti> maxb: hm, you said "dvorak"
<dholbach> pitti: alrightie
<maxb> I never did :-)
<pitti> and since these are variants, they would be broken right now (and fixed in that bug)
<dholbach> pitti: in any case I'll run another rsync tomorrow morning, so if ISOs change we can test them too
<pitti> My symptoms are the same as bug 395103: although my keymap is set to dvorak in HAL, and previous versions of gdm honored this, it's now using a USA keymap.
<pitti> maxb: ^
<cjwatson> oh, glad to hear that, I got some baffling installer bug reports about broken variants
<ubottu> Launchpad bug 395103 in gdm "Gnome doesn't have my configured keyboard layout after login anymore" [High,Fix released] https://launchpad.net/bugs/395103
<cjwatson> I think somebody was complaining that es_ast was broken
<maxb> Oh, I guess my problem is subtly different to the original reporter's after all :-/ I'll wait for the builds, and retest
<liw> *phew* things are slowly starting to work for me in karmic
<pitti> liw: did you reinstall with crypted root?
<liw> pitti, nope, I'd rather not hit my head against the desk more than necessary this month
<pitti> liw: I gave up cryptroot when ecryptfs came along..
<liw> I am not convinced ecryptfs is a sufficient solution for any use case I have, though
<liw> hngh, every time I start a new app in karmic, I find bugs... only reporting those that make me angry, though
<mwider> hi
<liw> there is no gdm.conf anymore?
<mwider> I have one question about debuging package
<liw> I mean /etc/gdm/gdm.conf
<pitti> liw: no; what are you trying to do? There's still a custom.conf
<pitti> (created by gdmsetup)
<liw> pitti, I want to shut gdm up
<liw> it makes a noise when it starts up
<pitti> liw: normal GNOME session startup sound, I presume?
<liw> no, before I even type a username
<pitti> liw: right; gdm _is_ a gnome session
<liw> when I logged in the first time, the african-style noise soudned; when gdm starts up, it's more of a bleep kind of noise
<zul> morning
<cjwatson> initramfs debugging can be fearsomely difficult
 * cjwatson has been at it for three hours now
<cjwatson> I'm leaving straces lying around for myself in /dev/.initramfs :)
<asac__> ogasawara: hi. we get more reports saying that ath9k is in not so good shape :/ see 439723 and 414560 ... previously we only had issues with background scanning. now it seems to be unstable for "older" chipsets even without that
<liw> so, what is the way to configure the gdm "gnome session"?
<tkamppeter> Riddell: What is currently the standard tool in KDE for running an application as root (GUI-based sudo, like gksudo or gksu)?
<Riddell> tkamppeter: /usr/lib/kde4/libexec/kdesu
<Riddell> tkamppeter: also in a .desktop file X-KDE-SubstituteUID=true will make it start with the right app (unfortunately that's not in the .desktop spec)
<tkamppeter> Riddell: Thanks, seems to change from version to version, there are always reports that HPLIP does not find this tool.
<tkamppeter> Riddeel, is there perhaps some xdg-utils wrapper so that one does not need to add a new tool to the list for every release?
<tkamppeter> Riddell: ^^
<Riddell> tkamppeter: it has always been /usr/lib/kde4/libexec/kdesu in KDE 4, although you could also use kdesudo (we set kdesu as a link to kdesudo in Kubuntu).  I'm not  aware  of an xdg-wrapper tool, the "menu" package from Debian has su-to-root but I don't know how well t hat  works
<tkamppeter> Riddell: Thanks.
<tkamppeter> Riddell: For me /usr/bin/kdesudo is a binary executable from the kdesudo package.
<tkamppeter> Anyone knows what is the default replacement for System->Administration->Services (managing and starting/stopping/restarting services)? See bug 440397.
<ubottu> Launchpad bug 440397 in system-config-printer "Obsolete instructions in the printing troubleshooter" [Undecided,New] https://launchpad.net/bugs/440397
<Riddell> tkamppeter: yes, and /usr/lib/kde4/libexec/kdesu will point to it via an alternate
<ScottK> Riddell: My experience with su-to-root has been good, but we'd probably have to split the menu package to avoid pulling it all into Main.
<Amaranth> tkamppeter: there isn't a replacement for that yet
<Rashko> hi all
<Rashko> I need help please
<Rashko> please any one help me
<tkamppeter> Amaranth: So Karmic will ship without a GUI tool to restart services?
<Rashko> need to enable ubuntu 8.04 more than 4 serial port pci card
<Amaranth> tkamppeter: I guess so
<thatscoteng> hi folks,
<thatscoteng> I am wanting to report a problem with the installer system but not sure of the package
<thatscoteng> I had selected dvorak keyboard during the install of karmic beta, but this has been ignored and I have been given the default keyboard
<thatscoteng> dholbach sent me here, cjwatson or  evand may have been discussing it earlier
<Pici> thatscoteng: If its on the Live CD installer the package name is ubiquity, on the alternate/server cds its debian-installer
<thatscoteng> thanks
<evand> thatscoteng: it's already reported
<evand> one second, I'll find you the bug number
<thatscoteng> bug #40627 ?
<ubottu> Launchpad bug 40627 in ubiquity "wrong keyboard layout after install" [Medium,Incomplete] https://launchpad.net/bugs/40627
<evand> thatscoteng: bug 421212
<ubottu> Launchpad bug 421212 in gnome-settings-daemon "gdm ignores keyboard layout selection for variants" [High,Fix released] https://launchpad.net/bugs/421212
<thatscoteng> thanks
<evand> so it will be fixed soon
<davmor2> ttx: Dude I'll have another look at the test docs, next week when things have settled a bit.  I'll work through the stages and track what worked.
<ttx> davmor2: ping me if you need me
<davmor2> ttx: will do probably start monday afternoon.
<ttx> ok
<MenZa> cjwatson: Thanks for that very verbose answer :D
<thatscoteng> what package does gnome-keybinding-properties belong to?
<thatscoteng> (or how do I find out which package ...)
<joaopinto> thatscoteng, dpkg -S gnome-keybinding-properties
<cjwatson> thatscoteng: if it's installed on your system, use dpkg -S; otherwise, packages.ubuntu.com
<thatscoteng> thanks
<thatscoteng> (twas gnome-control-center if anyone else cares)
<maxamillion> I was curious how the local mail from cron and logwatch was being handled since there is no longer a MTA by default, was there some patch, a trick, or are the messages just simply lost?
<siretart`> fun: empathy segfaults on startup only on the local display, though it works via ssh-x11-forwarding...
<siretart`> segfaults happens somewhere in libgobject
<liw> a lot of gtk apps are crashing on karmic, it seems
<siretart`> liw: details?
<cjwatson> evand: are you working on a new devicekit-disks for bug 419796 now that beta's out, or is somebody else?
<ubottu> Launchpad bug 419796 in devicekit-disks "PartitionTableCreate method times out when 'none' is specified as a parameter." [Medium,Confirmed] https://launchpad.net/bugs/419796
<evand> cjwatson: already sorted
<evand> we have 007 in the archive
<evand> I'll close the bug
<cjwatson> ah, thanks
<mat_t> cjwatson: hi and sorry for a lame question - if I perform a clean install now, will I get GRUB 2 automatically?
<cjwatson> mat_t: yes
<cjwatson> mat_t: just not on upgrades
<mat_t> cjwatson: ok, thanks!
<slangasek> pitti: debian-cd still needs set back to !beta before re-enabling the cronjobs
<cjwatson> slangasek: oh, that was my fault, sorry
<cjwatson> Keybuk: is bug 438335 basically a duplicate of bug 431184?
<ubottu> Launchpad bug 438335 in Ubuntu Karmic "Boot messages show before xsplash kicks in" [Medium,Confirmed] https://launchpad.net/bugs/438335
<ubottu> Launchpad bug 431184 in usplash "no usplash during boot when X takes too long to start" [Medium,Triaged] https://launchpad.net/bugs/431184
<dholbach> cjwatson, slangasek: does that mean new dailies tomorrow? :)
<cjwatson> (don't want to dup without asking, but they're both on the agenda for the release meeting and seem to have basically the same status)
<cjwatson> dholbach: yes
<dholbach> yoohoo
<dholbach> gracias
<Keybuk> cjwatson: who knows
<cjwatson> dholbach: wouldn't have been any point today for the most part
<Keybuk> you're ALWAYS going to see console text
<sharms> I cant seem to download any packages today from archive, I guess beta is taking its toll
<Keybuk> because certain developers really can't stop themselves deliberately adding it
<cjwatson> Keybuk: for karmic, I assume we'll want to both chip away at messages, as well as the splash timeout discussed at UDS?
<dholbach> cjwatson: sure... I was just going to ask a bunch of jam participants tomorrow in Berlin to test-install and I know that a bunch of bugs have been fixed directly after beta, so I'll rsync tomorrow before I head out
<cjwatson> (according to pitti anyway, I don't have a very good memory of that discussion)
<Keybuk> cjwatson: for lynx
<Keybuk> for karmic I've lost the will to care ;)
<Keybuk> especially when I sit and tell people we don't want console messages for over an hour
<Keybuk> and they go and stick one in anyway
<cjwatson> which one in particular?
<Keybuk> there were ones in ufw, apparmor, etc.
<zul> asac: ping when you get a chance can you look at #434836
<jdstrand> I don't recall being told not to do it...
<jdstrand> (before I did that is)
<doko_> gah, type 'reset' in a gnome terminal, and all windows close :-/  that was fixed before ...
<dholbach> doko_: I can't see the problem here
<liw> doko, oh foo, I just tried that
<doko_> dholbach: amd64?
<dholbach> doko_: yes - vte 0.22.0-0ubuntu1?
<liw> happens on both my karmic machines
<liw> (both amd64)
<doko_> liw: there must be another condition, now I can't see it with a newly opened window
<liw> doko, me neither
<mdz> kirkland: good morning
<kirkland> mdz: howdy
<mdz> kirkland: do you have a view yet on merging eucalyptus from trunk?
<kirkland> mdz: ttx and I decided to do it together, on a shared screen session on Monday
<mdz> kirkland: so it's on hold until then?
<kirkland> mdz: i was going to spend today trying to solve the kvm attached storage issue, testing the new iso with ubuntu13, and figuring out the cloud restart problem
<mdz> kirkland: ok
<robbiew> Keybuk: question, if we set console=tty6 on the kernel line, it seems to help silence the non-kernel messages at boot....but obviously redirects messages to tty6...if we did this by default, what breaks? :P
<kirkland> mdz: unless you'd like me to reprioritize it above that ^
<kirkland> mdz: ttx and I agreed that it would be good to have two sets of eyes on the merge
<Keybuk> robbiew: booting without "quiet"
<kirkland> mdz: particularly considering that neither of us have done it before
<ogra> systems that dont use 6 ttys
<ttx> ... and that lots of our changes need to be dumped.
<robbiew> Keybuk: we use quiet by default, so presumably anyone removing that would redirect console to wherever
<robbiew> ogra: good point
<robbiew> ogra: what about tty2? :P
<robbiew> i suppose same arguement holds
<ogra> robbiew, dropping quiet switches on the text messages in usplash if you keep splash ion place
<robbiew> all I know is that it sure cleans up the fsck and apparmor and other chatter
<ogra> i assume that would break as well
<robbiew> ogra: I know what quiet does...I'm saying if the problem with moving the console away from tty1 is that dropping "quiet" won't work...then we don't have a problem, because a user has to edit the default line to remove quiet anyway
<robbiew> so he/she could also remove the console line
<ogra> so you would put it on cmdline, not tell the kernel to default to it
<robbiew> right..sorry, by default I meant in the default grub line :/
<robbiew>  /etc/default/grub
<ogra> right
<robbiew> i wonder if we could detect the number of ttys on a system during install, and then add "console=tty6" to systems with the standard setup
<liw_> is the number of ttys ever different from what we set it to during install? I guess post-install the user may change it
<ogra> well, the actual number is only limited by the kernel actually ...
<ogra> what we set during install (or what Keybuk sets during install of upstart) are the 6 gettys that run on ttys
<Keybuk> that's irrelevant
<Keybuk> console=tty6 would still work
<ogra> and now that i think of it, i dont think systems with less than 6 ttys will have any prob, the kernel doesnt care where you direct the boot output
<robbiew> I just think it's an easy solution to a lot of the boot messages
<robbiew> that aren't kernel related
<ogra> you will definately get complaints from power users
<mvo_> Mirv: hey! is lp:~timo-jyrinki/language-selector/evol_ooo still relevant/needed (sorry, I'm not fully up-to-date with language-selector anymore)
<ogra> the "something changed we are used to" factor :)
<robbiew> ogra: power users can just turn it off
<ogra> yeah
<asac> zul: yes i have time to MIRs now that beta is out. will do that latest monday morning
<zul> asac: great thanks..
<doko_> cjwatson, pitti: can gcc-4.3 be demoted? there are only references to archs in the b-d's which are not in ubuntu
<cjwatson> doko_: IIRC you filed a bug, which'll be in the archive admin queue
<doko_> ok, just seen it building on the buildds ... will lower the prio manually
<cjwatson> it should be demotable, I just haven't had time to look yet
<mdz> cjwatson: given we didn't get bug 364649 in, should I implement cr3's casper.log hack instead?
<ubottu> Launchpad bug 364649 in ubiquity "Please include installation media build number in installation logs" [Wishlist,Triaged] https://launchpad.net/bugs/364649
<cjwatson> mdz: oh, yeesh, that's trivial, we'll get it done
<cjwatson> evand: ^- could you look at that please?
<mdz> cjwatson: don't want to distract from more important things
<cr3> cjwatson: thanks!
<cjwatson> evand: should just be a matter of dumping out .disk/info to a specific file if it exists
<evand> indeed, will do
<cjwatson> err, /cdrom/.disk/info
<cjwatson> evand: ideally, both in ubiquity and in d-i (installation-report)
<Ng> http://www.ubuntu.com/testing/karmic/beta#Upstart links to alpha5 which isn't on cdimages anymore
<Ng> seemingly none of the alphas are there anymore
<Keybuk_> Warning: testing usplash can be detrimental to your X server, or any applications running on it
<ogra> pfft, X ...
<robbiew> lol
<jpds> Ng: Sounds like something for -website.
<Ng> a good point
<siganderson> I installed emesene 1.5 on kubuntu karmic koala beta, I can't connect because I can't write in the username field! What happened?
<Riddell> support requests in #ubuntu or #ubuntu+1 siganderson
<Riddell> cjwatson: is archive reorg active now?
<maco> siganderson: +1 in this case since karmic
<c_korn> I have a half-translated gnome. against what package should I file a bug ?
<cjwatson> Riddell: well, ish. we still don't have a kubuntu development team that we might approve for kubuntu upload rights, afaik
<Riddell> cjwatson: so it's just blocking on us?
<maco> haha
<siganderson> ok I will request there
<cjwatson> well, until you unblock at which point it will block on the TB again to approve that team, but hopefully only fairly briefly
<olmari> would sort-of-bug-squashing report be proper to discuss here?
<Riddell> cjwatson: and having done that is there an agreed  protocol for  how  we add  people to it?  i.e. should can kubuntu-council act alone or should developer-membership-board be consulted somehow?
<maco> olmari: triaging, or development? if the former, #ubuntu-bugs
<maco> (unless -bugs people already went "uhh....ask a dev")
<cjwatson> Riddell: we would like you to define that protocol, and we'll look it over; we're having a bit of an, er, discussion about the minimum requirements, but I think there's some consensus that the application process needs to be fairly similar to the MOTU Council's, and the way you report new developers should be similar too, but you may want to vary how you approve people; you might as well start with the MC's process as a ...
<cjwatson> ... guideline if that's OK with you
<olmari> maco: well I'm not sure... I found out that 1) when I "eject" the usb dvd drive in karmic and reconnect it (at any later time) it changes device number
<olmari> I mean when it is first on /dev/sr1, then when I take it out and put back it becomes /dev/sr2
<olmari> until sr4 is used and then havoc"
<maco> olmari: so youre needing to figure out which package to report the bug against?
<olmari> maco: well... that too I suppose, but generally also that there is such bug and also I have second bug related to at least dvd if not more generally to device handling...
<maco> olmari: is there a bug filed already or no? i heard dtchen talking about a dvd bug yesterday
<olmari> maco: don't know... sorry... I'm starting to feel too stupid here :-p
<maco> olmari: ok well lets move to #ubuntu-bugs and talk there
<sharms> asac__: any idea if the commit was made yet that resolves LP #300438
<ubottu> Launchpad bug 300438 in network-manager-vpnc "additional routes not saved via gui" [Undecided,Confirmed] https://launchpad.net/bugs/300438
<asac__> sharms: please try todays/yesterdays trunk build: https://edge.launchpad.net/~network-manager/+archive/trunk
<asac__> let me know
<sharms> will do thanks
<Riddell> cjwatson: kubuntu-dev created, I invited developer-membership-board to be a member who I can make an admin
<ScottK> cjwatson: Could we use the protocol of "must be approved by the developer membership board" until we get a delegated protocol written and approved?
<Darxus> Launchpad still won't let me nominate for Lucid :P
<cjwatson> ScottK: I'd really prefer we didn't, there's limited benefit unless we delegate and the DMB is not really all that directly aware of who's useful
<robbiew> Keybuk: is couchdb still starting automatically?
<robbiew> I thought that was fixed
<cjwatson> Darxus: no, and it won't until lucid is open, which won't be until right after karmic releases (long-standing limitation)
<ScottK> cjwatson: OK.  We've got a couple of people who are clearly ready, and it'd be nice if they didn't get blocked too long on procedure.
<Keybuk> robbiew: I think that's fixed
<robbiew> okay...that's what I thought
 * robbiew is triaging a boot bug...fun times
<cjwatson> ScottK: if you wanted to just use the motu-council procedure with the serial numbers filed off by substituting kubuntu-council (or other appropriate body) for motu-council, I think that would be fairly uncontroversial
<cjwatson> I thought there was some concern about whether kubuntu-council was the right body?
<cjwatson> or did that get resolved / I was just confused?
<ScottK> I mentioned that as it's not a developer body.  It's more broadly based.
<ScottK> I need to discuss it with Riddell.
<nixternal> ScottK: I think I might be able to lend a hand when it comes to approving :)
<ScottK> Yeah, well we need to figure out the right group.
<mdz> checking status of bug 429379, bug 429004, bug 428188, bug 428010
<ubottu> Launchpad bug 429379 in eucalyptus "Eucalyptus returns 403 with valid credentials on image registration (dup-of: 417217)" [Undecided,New] https://launchpad.net/bugs/429379
<ubottu> Launchpad bug 417217 in eucalyptus "Whitespaces in parameters are encoded as "+" instead of "%20" with REST" [High,Fix committed] https://launchpad.net/bugs/417217
<ubottu> Launchpad bug 429004 in eucalyptus "Eucalyptus hangs & euca-upload-bundle doesn't return" [Medium,Confirmed] https://launchpad.net/bugs/429004
<ubottu> Launchpad bug 428188 in eucalyptus "500 server error when attempting to register ramdisk image" [Medium,Incomplete] https://launchpad.net/bugs/428188
<ubottu> Launchpad bug 428010 in eucalyptus "Eucalyptus cloud controller stops working suddenly (dup-of: 436885)" [High,Confirmed] https://launchpad.net/bugs/428010
<ubottu> Launchpad bug 436885 in eucalyptus/1.6 "over time, c3p0 causes deadlock condition in CLC" [Critical,Fix committed] https://launchpad.net/bugs/436885
<Amaranth> hmm, how do you go about getting a package removed? just file a bug against it?
<cjwatson> Amaranth: yes, and subscribe ubuntu-archive
<Amaranth> Will do
<kirkland> cjwatson: testing today's iso, the node-preseed file isn't available; where is that supposed to be located on the filesystem?
<cjwatson> kirkland: /etc/eucalyptus/node-preseed.conf
<kirkland> cjwatson: bummer, that wasn't created
<kirkland> cjwatson: looks like a regression since beta
<kirkland> cjwatson: ideas, before i start digging?
<cjwatson> kirkland: surprising that that would have regressed, since I didn't think that code had been touched. Did you definitely use the UEC installation option, not server?
<cjwatson> as in, at the CD boot menu
<kirkland> cjwatson: absolutely
<cjwatson> check syslog I guess
<cjwatson> see if the eucalyptus-udeb finish-install script got run
<kirkland> cjwatson: uh, /var/log/installer doesn't exist
<kirkland> cjwatson: this install is b0rked
<kirkland> i'm starting over
<cjwatson> this time, check before you reboot, and if /target/var/log/installer/ doesn't exist, extract /var/log/syslog
<maco> is it too late to do a FFe for yanking a package from Sid to Universe in Karmic?
<apw> cjwatson, is there any issues with having a large debian/changelog file?
<cjwatson> no
<cjwatson> other than simple size
<apw> so having one of the order of a 1M is nothing to worry about?  is there a size when it is to be worried about?
<cjwatson> so the only issue really is that it will all be in the binary package and take up CD space and such, and you should look at the *compressed* size (changelogs tend to compress well)
<cjwatson> if you're concerned about the size, you could have debian/changelog.old
<apw> does changelog.old get handled automatically ?
<liw_> changelog.old would remain in the source package, I assume
<cjwatson> the purpose of changelog.old is to avoid it all going in the binary package, which some packages want, so there's no handling to do
<apw> i think this thing is wanted installed
<cjwatson> there are a few packages that keep very long piles of changelog entries in that way
<liw_> my current largest compressed changelog.Debian* is 194817 bytes, so a megabyte compressed is a bit big
<cjwatson> debconf for example does this, and puts the full changelog in debconf-doc
<cjwatson> you might consider putting the whole thing in linux-2.6.31-doc or something
<cjwatson> is it in fact a megabyte compressed?
<apw> cjwatson, yeah i think the desire is to be about to get it out
<apw> no it is currently 600k uncompressed
<cjwatson> my desire, personally, is to have the information available without having to dig through revision contorl
<cjwatson> having it in the source package would be fine by me, although if possible it would be good to have in a binary package
<apw> 215k compressed
<apw> ok, am looking at putting it in the binary package, but i guess its coming out of your CD size if i do that
<cjwatson> consider my -doc suggestion
<cjwatson> debconf does:
<cjwatson>         # Changelog reduction hack for debconf. Only include top 100 entries.
<cjwatson>         perl -ne '$$c++ if /^debconf /; last if $$c > 100 ; print $$_' \
<cjwatson>                 < debian/changelog > debian/debconf.changelog
<cjwatson>         dh_installchangelogs
<cjwatson> obviously would need some modification
<apw> well actually ... this is going in the binary either way ... as this is just the changelog back to 2.6.30
<cjwatson> mdz: do you object to the full untrimmed changelog only going in the binary package?
<cjwatson> apw: uh, I don't get it, that's what's in the package right now
<cjwatson> 33KB uncompressed back to 2.6.30
<cjwatson> what would be really valuable would be to restore the full Ubuntu history
<cjwatson> which was truncated in the past, over objections ...
<apw> cjwatson, there are two parts to the issue, 1) that all history back to older packages is not avalable at all
<apw> and the second is that the upstream commits are not listed
<mdz> cjwatson: that would be a distinct improvement on the status quo
<apw> if i add upstream commits then it balloons
<cjwatson> oh god, don't put every single upstream commit in
<cjwatson> where did that idea come from? no other package does that
<cjwatson> well, no, that's not quite true, some do have a ChangeLog where that's explicitly maintained by upstream
<apw> that is the request as i got it
<cjwatson> but we don't generally go out and create it, and it's pretty acceptable not to put it in binary packages when it's huge
<cjwatson> mdz: surely restoring the old Ubuntu history is much more important than getting a full git log
<apw> mdz, i think you were at the head of the request here, so perhaps i have miss interpreted
<cjwatson> mdz: BTW, sorry, I misspoke above, I meant "do you object to the full untrimmed changelog only going in the source" package?
<cjwatson> can't type today
<kirkland> cjwatson: hmm, okay, reinstalled
<kirkland> cjwatson: it dropped me back to the installation menu after the "Finish Installation" step
<kirkland> cjwatson: no errors to tty1
<kirkland> cjwatson: i'll check the logs now
<kirkland> cjwatson: http://paste.ubuntu.com/284013/
<kirkland> cjwatson: some missing modules
<kirkland> cjwatson: maybe a grub-installer bug
<kirkland> cjwatson: this isn't an md setup, but those changes might have regressed grub installation?
<cjwatson> I only just uploaded that, I doubt it's on your CD yet
<cjwatson> let's see
<cjwatson> well, clearly an iscsi problem
<cjwatson> Oct  2 17:40:23 finish-install: /usr/lib/finish-install.d/10open-iscsi backed up
<cjwatson> ah, I see
<cjwatson> I'll fix it
<cjwatson> surprised that didn't break before, actually
<kirkland> cjwatson: cheers, thanks
<kirkland> cjwatson: any chance you could push a new server iso build thereafter?
<kirkland> cjwatson: also, what can i do to finish this install by hand, and use it?
<cjwatson> oh, it probably broke because partman-iscsi is now installed as standard
<cjwatson> rm -f /usr/lib/finish-install.d/10open-iscsi, try the menu item again
<cjwatson> I can't spin a new server ISO build afterwards, I'm afraid, I'm way over hours for this week and need a rest
<kirkland> cjwatson: bingo
<cjwatson> there should be some US-timezone people who can
<kirkland> cjwatson: no problem, i'll poke slangasek
<slangasek> cjwatson, kirkland: yo
<kirkland> slangasek: can you push another iso build after cjwatson fixes partman-iscsi?
<kirkland> slangasek: today's server iso build is broken until then
<slangasek> yes
<cjwatson> not partman-iscsi, open-iscsi
<cjwatson> I fixed partman-iscsi earlier today ;-)
<cjwatson> upload's in the queue, I'm sure it'll take a while to build at the moment though
<cjwatson> well, "fixed", I realise now I broke this case, but before that iscsi installation was broken
<kirkland> cjwatson: great, thanks
<james_w> Keybuk: is dbus supposed to be native-package-with-dash-version?
<slangasek> cjwatson: oh, "in the queue" - we still need to unfreeze, don't we
<Keybuk> james_w: no, it was an accident, I'll fix it for the next version
<james_w> ok
<Keybuk> .orig.tar.gz repacking for the lose
<cjwatson> slangasek: I thought we had; I meant the accepted queue
<cjwatson> or build queue or whatever
<ScottK> slangasek: It's unfrozen, but the backlog is long
<slangasek> ok
<slangasek> apparently still in the accepted queue, yes, doesn't show up on the LP page yet
<slangasek> cjwatson: what version am I looking for? -0ubunutu12?
<cjwatson> slangasek: aye
<slangasek> ok, queued
<hyperair> what's the upstart version of /etc/init.d/script reload?
<cjwatson> hyperair: 'reload script'
<cjwatson> hyperair: (or you can use the 'service' wrapper if you don't know which it i)
<cjwatson> is
<hyperair> cjwatson: and how do you write upstart jobs with a reload action?
<hyperair> or does reload really just restart the job?
<cjwatson> hyperair: it just sends SIGHUP to supervised processes
<cjwatson> cf. bug 433544
<ubottu> Launchpad bug 433544 in upstart "âservice foo reloadâ complains about using the init script and recommends using service" [Medium,Fix released] https://launchpad.net/bugs/433544
<hyperair> ah i see.
<peol> Any devs for the gnome-control-center here?
<peol> Or should I try in #gnome?
<Mez> how do I disable encrypted swap?
<kirkland> Keybuk: is the dbus-reconnect error thought to be fixed now?
<Keybuk> yes
<kirkland> ii  dbus                                     1.2.16-0ubuntu7                   simple interprocess messaging system ?
<Keybuk> it's the upstart package you need to check
<kirkland> Keybuk: i'm still seeing the problem where those registration jobs don't run
<kirkland> ii  upstart                                  0.6.3-6                           event-based init daemon
<Keybuk> that should have the patch
<Keybuk> check that you don't have an /etc/init/dbus-reconnect.conf ?
<kirkland> Keybuk: i most certainly do have that file
<Lure> Keybuk: if mountall fails to mount all fs and drops me to shell, is there a way to continue boot when I manually mount missing FS - see bug 437801?
<ubottu> Launchpad bug 437801 in mountall "often fails to fsck /home on dm-crypt/lvm " [High,Confirmed] https://launchpad.net/bugs/437801
<kirkland> Keybuk: should the package maintenance purge that file?
<Keybuk> kirkland: yes
<Keybuk> argh
<Keybuk> I see the issue
<Keybuk> kirkland: upstart -7 should fix that
<kirkland> Keybuk: in the mean time, i should just rm -f /etc/init/dbus-reconnect.conf ?
<Keybuk> if you updated from the PPA it may not have removed the file
<Keybuk> yes
<kirkland> Keybuk: okay, once i remove that file, things look much better
<Keybuk> that doesn't break anything either - since reconnect is done elsewhere
<Darxus> $ sudo do-release-upgrade
<Darxus> Checking for a new ubuntu release
<Darxus> No new release found
<Keybuk> all that file was doing was forcing a reload - which is bad
<Darxus> http://www.ubuntu.com/testing/karmic/alpha2 seems to indicate that should work.
<Keybuk> Darxus: Alpha 2 was a very long time ago, read http://www.ubuntu.com/testing/karmic/beta
<Darxus> Yeah I was just going to ask, why isn't the beta listed on http://www.ubuntu.com/testing/ ?
<Keybuk> oversight I guess
<slangasek> webmaster notified
<Darxus> slangasek: That beta isn't listed on that page?
<Darxus> Cool, the -d that the beta page said to use appears more functional.
<Darxus> I backed up /home and /etc and I think I'm going to upgrade when I get home.
<slangasek> Darxus: yes
<jdong>   
<Darxus> slangasek: Cool, thanks.
<Darxus> What will it take to sync a package from debian once lucid is open?
<ScottK> Darxus: Nothing if the package is either not existing or not modified in Ubuntu
<sistpoty> Darxus: otherwise a sync request, specifying for each ubuntu change why it can be dropped (there's a wiki page somewhere with details)
<Darxus> Cool.
<Darxus> How is a sync request done?
<Darxus> (googling)
<Darxus> Got it.
<Darxus> https://wiki.ubuntu.com/SyncRequestProcess
<sharms> is anyone aware that the archive.us.ubuntu.com is effectively down, atleast in the us?
<sharms> it must be a problem with that address not routing requests, because the individual mirrors are working correctly
<Darxus> $ host archive.us.ubuntu.com
<Darxus> Host archive.us.ubuntu.com not found: 3(NXDOMAIN)
<sharms> sorry us.archive.ubuntu.com
<Darxus> I can load http://us.archive.ubuntu.com/ (in the US)
<Darxus> But http://downforeveryoneorjustme.com/us.archive.ubuntu.com says it's down.
<sharms> right I wouldnt have said anything without testing it
<sharms> and its down both from my atlanta site, cincinnati site, and san jose site, and not 404 down but 2b/s or less down til timeout
<nixternal> if you aren't using karmic in the us, the anl.gov mirror is the fastest (nice living 10 minutes from it too) :)
<sharms> lol I have working mirrors
<sharms> but I am assuming someone takes care of the load balancing, and would like to know
<sharms> incase its geographically isolated and they may not be aware
<nixternal> sharms: this happens all the time, I am used to it by now :)
<sharms> nixternal: I have a bunch of Ubuntu converts in the office I told to upgrade to karmic, they tried and now its blowing up :)
<nixternal> lol
<nixternal> ya, same here
<nixternal> people prepping for the Global Jam this weekend have been complaining today in #ubuntu-chicago
<sharms> even help.ubuntu.com is intermittant at times
<nixternal> jeesh, I just need to do 'apt-get update' to pick up my packages in a test repo..should have commented out the others
<Darxus> sharms: You told recent converts to upgrade before release why?
<sharms> Darxus: it's ready for beta testing, and I can overcome any problems they have.  Make sense?
<Darxus> Yeah, I guess.  They understand what "beta" means?
<sharms> right, but I am much more concerned about the mirror address on this channel :)
<Darxus> sharms: whois for ubuntu.com lists:  hostmaster@canonical.com +44.1624643643
<Darxus> Try them.
<ScottK> Or even #canonical-sysadmin
<jdong> hmm any plans/milestoning magic / whatnot for bug 141494?
<ubottu> Launchpad bug 141494 in nspluginwrapper "Flash not responding to mouse clicks with Xgl/Compiz" [Medium,Confirmed] https://launchpad.net/bugs/141494
<jdong> IMO it's quite serious if it does affect all x86-64 users...
<jdong> flash applets on Karmic x86-64 do not accept mouseclicks at all
<Guest45216> Hi Can anybody tell me how I can have a ubuntu usb with only browser?
<Guest45216> Hello
<Guest45216> Anybody here can help me with ubuntu usb stick?
<Guest45216> anyone?
<ScottK-desktop> Guest45216: Help in #ubuntu or #ubuntu+1 for Karmic
<Guest45216> OK thanks scottK
<WildBill> Hey, my network install of ubuntu seems to have a dependency early on (downloading additional kernel drivers) on security.ubuntu.com. I suppose that's buried in the initrd somewhere... is there a command-line override for that?
<slangasek> Keybuk: I've uploaded my changes to portmap and nfs-utils to fix the /home-or-/usr-on-NFS problem, but we still have an issue on shutdown because sysvinit is still handling unmounting
<slangasek> kirkland: hmm, open-iscsi still hasn't published on amd64?
<kirkland> slangasek: i haven't been watching
<slangasek> I just polled it now in response to your mail
<kirkland> slangasek: my day is ending now
<kirkland> slangasek: as long as it makes it onto an iso by Monday, I'm happy
#ubuntu-devel 2009-10-03
<slangasek> kirkland: well, hopefully the buildds will catch up by then
<kirkland> slangasek: let's hope there's more bandwidth too by then
<Darxus> Starting my first upgrade to a pre-release.
<jdong> :) it's not all that painfull
<jdong> as long as upstart doesn't bite ;-)
<Darxus> Heh.
<sistpoty> !jdong
<ubottu> Sorry, I don't know anything about jdong
<slangasek> well, the NFS-hanging-boot bug should be fixed now
<Darxus> I've done some pretty dumb stuff, intentionally, and survived.
<Darxus> And I have a full backup, and both the beta cd, and the jaunty cd.
<sistpoty> jdong: meh, who "fixed" ubottu :P
<jdong> sistpoty: IRC council I'd guess :)
<sistpoty> hehe
 * feat testing
 * feat testing Ubuntu 9.10 - acer aspire one D150
<feat> ?
<Darxus> 1779M to download, eta 2 hours 27 minutes.  Damn.
<feat> yep
<feat> 3 hrs Ã§
<feat> xD
<Darxus> 33 packages removed, 392 new packages, 1605 upgraded.
<Darxus> It's amaizing this ever works :P
 * Darxus loves on apt.
<feat> :O
<feat> you speak spanish
<feat> ?
<Darxus> Me?  No, I'm an ignorant american :(
<feat> LOL
<Darxus> I have aspirations of learning esperanto and lojban.
<feat> esperanto WTF  >XD
<Darxus> Ugh, eta 11.5 hours.
<Darxus> feat: ?
<feat> ?
<feat> WTF   1 Day 12 hrs
<feat> xD
<sistpoty> feat, Darxus: maybe you'd like to take your conversation to #ubuntu+1?
<feat> ok
<feat> sorry
<sistpoty> no problem
<maxb> Hrm. I think there's a real problem with gdm upgrades
<maxb> it seems you can't upgrade gdm whilst a session is running any more
<ion> Heh. upgrade to the most recent stuff, switch from fi.archive.ubuntu.com to archive.ubuntu.com and upgrade to the most recent stuff: 164 packages upgraded, 1 newly installed, 2 to remove and 0 not upgraded. Itâs almost as if the mirror were *gasp* a bit behind. :-) (I realize itâs possible a lot of packages were just published by an archive admin, though.)
<Darxus> I just submitted a bug, and it was marked as a duplicate of https://bugs.launchpad.net/bugs/365371 but that page is saying "Sorry, you don't have permission to access this page.  You are logged in as Darxus."  What's up with that?
<ubottu> Error: This bug is private
<Darxus> Hah.
<Darxus> WTF?
<Linux_Boricua> Hello
<Linux_Boricua> ola
<Linux_Boricua> alguien ke me ayude
<Linux_Boricua> por favor
<Linux_Boricua> alguien que hable espaÃ±ol
<Linux_Boricua> ????
<LaserJock> Darxus: so it got dup'd to a private bug
<Linux_Boricua> What??
<Linux_Boricua> I do not speak English
<LaserJock> Linux_Boricua: #ubuntu-es ?
<slangasek> Linux_Boricua: este no es un canal de ayuda; le recomiendo preguntar en #ubuntu-es
<Linux_Boricua> mmm
<Linux_Boricua> bueno este
<Linux_Boricua> es que quiero saber
<Linux_Boricua> algo solamente
<Darxus> LaserJock: Yes.  What's up with the bug being private?
<Linux_Boricua> :D
<Linux_Boricua> es que no quiero ayuda en esencial solo quiero aclarme unas dudas
<Linux_Boricua> :D
<Linux_Boricua> jajaj
<LaserJock> Darxus: crasher bugs are automatically marked Private, that could be the issue
<Darxus> Weird.
<Darxus> I can't even figure out who marked it duplicate....
<LaserJock> Darxus: it was automatically dup'd
<LaserJock> Darxus: the apport retracer detected that it was a dup
<LaserJock> Darxus: the private bug looks like it could be made private, but I don't know for sure
<LaserJock> be made public, rather
<Darxus> Okay.  I'll try to stop worrying about it :P
<Darxus> Thanks.
<zsoc> ~seen Mithrandir
 * zsoc wonders if there's a similar working bot command to the one he just embarrassedly failed at
<Darxus> zsoc: Doesn't look like it.
<Darxus> zsoc: That nick has not occurred in this channel while I've been here.
<Darxus> --- Log opened Mon Sep 21 19:07:49 2009
<zsoc> Wow, hm. I am going a bit back. Thanks for checking the logs :) Guess I'll send him an email.
<Darxus> You're welcome.
<ccm> is the channel for the global jam?
<ccm> dholbachc: is the channel for the global jam?
<ccm> erm
<ccm> dholbach: is the channel for the global jam?
<dholbach> ccm: I don't know :)
<dholbach> #ubuntu-locoteams maybe?
<dholbach> bdrung: can you all yourselves to https://wiki.ubuntu.com/Bugs/Events
<mdz> cjwatson, apw, sorry, I was confused by cjwatson's comment. I think it's important to have a full changelog in the binary package. just having a copy of the old debian/changelog (all of it!) installed as changelog.Debian.old would be good enough
<dholbach> does anybody know how an upgrade from CD is supposed to work?
<ogra> isnt there a cdromupgrade script on the alternate CD ?
<dholbach> when I put in the CD a dialogue asks me something and if say "Yes", it opens synaptic
<dholbach> that was a desktop cd
<dholbach> hi ogra :)
<ogra> ah
<ogra> you cant upgrade from desktop
<ogra> hey
<dholbach> ah...!
<dholbach> ok
<ogra> desktop only has a few actual packages, the real system is in the squashfs and gets copied 1:1 on install
<dholbach> yeah
<dholbach> ok
<dholbach> that makes sense
<dholbach> we have to wait a bit then :-)
<tormod> dholbach, for user support, ask in #ubuntu ;)
<ogra> lol
 * dholbach slaps tormod with a trout
<dholbach> hi tormod :)
<tormod> hi dholbach, trying "dogfood" ?
<dholbach> we're test-installing a bunch of machines during the Ubuntu Berlin Jam here
<dholbach> and #ubuntu-testing is asleep
<tormod> dholbach, how many are you?
<dholbach> 8
<dholbach> and 1 dog
<dholbach> but we just started to get rolling
<directhex> ARGH, still no audio via hdmi, even on karmic
 * directhex prods dtchen 
<mnemonikk> i've got a problem with booting karmic, the root device isn't recognized during booting if i specify it by uuid. It says that /dev/disk/by-uuid/... doesn't exist. If I specify it by its traditional device name it works fine, in /etc/fstab i also use uuids with no problem. Is this a problem of the linux kernel or an upstart problem? Maybe it's a problem that I'm still using murder^Wreiserfs?
<tormod> mnemonikk, /dev/disk/by-uuid/.. doesn't exist after booting either?
<mnemonikk> tormod: well, that's what it says.
<mnemonikk> tormod: i can't do much in the init shell, though.
<tormod> mnemonikk, when you boot with trad name, there is still no by-uuid link after boot?
<tormod> mnemonikk, ls -l /dev/disk/by-uuid/ should show the uuid
<mnemonikk> tormod: if i boot with root=/dev/sdaX, then /dev/disk/by-uuid/.. exists.
<mnemonikk> tormod: i've got other partitions apart from the root partition that get mounted properly, and they are specified by uuid in the /etc/fstab.
<mnemonikk> tormod: yes, that works, the link is there.
<mnemonikk> tormod: does the fs type play a role in generating these uuids?
<tormod> mnemonikk, should not, especially since it works later
<mnemonikk> tormod: me still using reiserfs is a bit unusual, which would explain why no one else fixed this earlier.
<tormod> mnemonikk, I guess so
<mnemonikk> tormod: i could imagine something like that the reiserfs module is not loaded and so the proper uuid cannot be generated.
<tormod> mnemonikk, yes that would explain it. do you have reiserfs (?) in /etc/initramfs-tools/modules?
<mnemonikk> tormod: no, nothing.
<tormod> mnemonikk, try that. the installer or initramfs-tools should add that module if root is on reiserfs IMO. how did you install?
<mnemonikk> tormod: should i add it, do update-initramfs and try again?
<tormod> mnemonikk, yes
<mnemonikk> tormod: I think the last install was feisty, or something... upgraded since then.
<mnemonikk> tormod: I'll try that now.
<tormod> mnemonikk, I am just checking /usr/share/initramfs-tools/hook-functions and I see reiserfs is in the "base" modules. try modprobe reiserfs in the initrd shell.
<mnemonikk> tormod: I get into the initramfs shell when I press the power button. is that the right way to do it?
<mnemonikk> tormod: and resume with ^D?
<tormod> mnemonikk, not sure I follow, when you press the power button?
<mnemonikk> tormod: added reiserfs to /etc/initramfs-tools/modules, did sudo update-initramfs -u and tried with the uuid again, didn't work.
<mnemonikk> tormod: i press the power button when I think it's waiting for the root fs too long. Or how am I supposed to get the initrd shell?
<tormod> mnemonikk, oh I see, it's hanging. it should time out after a minute or so.
<mnemonikk> tormod: so maybe it was just a coincidence.
<mnemonikk> tormod: hold on...
<tormod> mnemonikk, in the initrd shell, see if reiserfs module has been / can be loaded. then check ls -l /dev/disk/by-uuid there.
<pgraner> kirkland: ping
<mnemonikk> tormod: i did a modprobe, it still can't find /dev/disk/by-uuid/xxx.
<mnemonikk> tormod: there's no "ls" in my initrd.
<tormod> mnemonikk, then your initrd must be broken. you are not running out of disk space?
<mnemonikk> tormod: hum, no, not currently.
<mnemonikk> tormod: "update-initramfs -u" is the correct incantation?
<tormod> mnemonikk, yes, as long as your booting the same (or one) kernel that your initrd is for, otherwise add "-k all"
<mnemonikk> tormod: ok... any idea what else I could try?
<tormod> mnemonikk, if "ls" does not work I wonder if something is really broken. Otherwise, see if your disk device exist (ls -l /dev/sd*) and check the UUIDs on them with "/sbin/blkid /dev/sda1" etc
<mnemonikk> tormod: you mean, I should call blkid from initrd?
<tormod> mnemonikk, yes, you can try it out in the booted system to get the hang of it, it should be the same, but we want to see if it works in the initrd
<mnemonikk> tormod: i have to try that later, have to go now. thanks for your help!
<tormod> mnemonikk, please file a bug or question, and feel free to subscribe me to it
<directhex> dtchen, poke poke?
<dtchen> directhex: hi
<directhex> dtchen, is there some documentation on how to debug a distinct lack of sound via hdmi on karmic?
<dtchen> directhex: not consolidated, and mostly trial-'n-error
<dtchen> directhex: namely, make sure it works in ALSA first
<dtchen> directhex: so the process is (briefly): disable PA autospawn; test the plug HDMI device using speaker-test
<dtchen> directhex: (and killall pulseaudio immediately after disabling PA autospawn)
<directhex> how would one disable PA autospawn on a temporary basis?
<dtchen> echo autospawn = no|tee -a ~/.pulse/client.conf
<Amaranth> Isn't there a pa suspender program or something for that too?
<dtchen> Amaranth: it does the wrong thing when you're trying to test certain functionality
<Amaranth> ah
<dtchen> directhex: i presume you've tested pavucontrol, too, and are able to reproduce this symptom using it?
<dtchen> directhex: also, it would be quite useful if it's reproducible in PA 0.9.19 (in the ubuntu-audio-dev PPA)
<directhex> aha! made it work via alsa!
<directhex> had to unmute an IEC in alsamixer
<directhex> so, now to see what happens if i turn PA back on
<directhex> hurrah, audio in mythtv!
<directhex> first time since i built this pc
<directhex> now to see if it persists across reboots
<kees> kenvandine, pitti: erm, your upload of xsplash (0.8.2-0ubuntu1) did not include the 0.8.1-0ubuntu2 changes...
<Darxus> I'm trying to test the debian experimental version of the hugin package under karmic, to get it moved to sid and then synced to lucid.
<Darxus> Oh, hmm, maybe it's not in main.
<Darxus> No, it's in main.
<kirkland> pgraner: pong
<Darxus> http://www.chaosreigns.com/ubuntu/experimental.txt
<Darxus> ^ Contents of /etc/apt/preferences, and the output of apt-cache policy hugin, showing that the version from experimental is available but not getting the priority I set in preferences.  Why not?
<pgraner> kirkland: question on enc-swap
<kirkland> pgraner: yo
<pgraner> kirkland: is there a way to temp disable to test to see if  a hibernate prob is due to the enc-swap?
<kirkland> pgraner: i don't understand your question
<pgraner> kirkland: someone has issues with hibernate and he is using enc-swap. I need to have him test without they enc-swap to see if that make the prob go away
<pgraner> kirkland: I'm looking for a enc-swap=0 on the kernel command line or something
<kirkland> pgraner: oh, yeah, you can't resume from hibernate if you have encrypted swap
<pgraner> kirkland: do we have that documented somewhere I can point to
<kirkland> pgraner: yeah, a bunch of places
<kirkland> pgraner: i'll grab you a link
<pgraner> kirkland: I googled all over and came up with nadda
<kirkland> pgraner: you can turn it off in /etc/crypttab
<kirkland> pgraner: hmm, we were supposed to remove the "Hibernate" button from the Shut Down menui
<kirkland> pgraner: i see that hasn't happened yet
<pgraner> kirkland: ok, if you can point me to the "hibernate is not supported" reference material I can get rid of one "regression" bug :-)
<kirkland> pgraner: i'm writing it now
<kirkland> pgraner: i found it scattered in a few places
<kirkland> pgraner: but nothing comprehensive
<kirkland> I'm putting something up now
<kirkland> pgraner: on help.ubuntu.com
<pgraner> kirkland: great thanks man, you rock.
<kirkland> pgraner: and then i'm going watch football :-)
<pgraner> kirkland: I'm at the nc Global Jam squashing bugs in real time....
<pgraner> kirkland: dude get some dedication :-)
<kirkland> pgraner: i am dedicated ... to the Texas A&M v. Arkansas game at the new Jerry Jones Deathstar in Dallas
<pgraner> kirkland: yea yea I hear ya
<pgraner> kirkland: drop me the link when your done
<kirkland> pgraner: nearly done
<kirkland> pgraner: https://help.ubuntu.com/community/EncryptedHome
<pgraner> kirkland: thanks dude. Enjoy the game
<kirkland> pgraner: thanks
<kirkland> pgraner: watching LSU v. Georgia first
<Darxus> I believe I found a bug in apt pinning in karmic, I'd appreciate confirmation:  https://bugs.launchpad.net/ubuntu/+source/apt/+bug/441585
<ubottu> Launchpad bug 441585 in apt "Pinning doesn't work for the debian experimental archive." [Undecided,New]
<ebroder> Ugh - are there any more local mirrors (to the US) of the daily CD builds than cdimage.ubuntu.com
<LaserJock> ebroder: I don't think so
<ebroder> :(
<zsakr> Hello, any one know how I can determine the  size(in bytes and/or blocks) of  an iso filesystem if it's  in a  larger container?  Am willing to read superblocks in hex.
<zsakr> t's in a larger contaner, so the reported size is  too big.
<zsakr> if I do something like like ls -l file.iso that is
<zsakr> Some thing like ckisofs or tun(e)isofs, I've looked for docs describing the superblock but  couldn't fnd any.
<devned> anyone know for sis mirage 3D (M671/M672) driver on ubuntu 9.04 ? And who can make it ? becouse from sis  declaned support for this product
<devned> i was geting only for SuSe pack files for this project byt i not have enought skills on c++
<ScottK> devned: support is in #ubuntu
<ScottK> zsakr: You too ^^^
<devned> Scottk thanks
<Darxus> apt-get and aptitude keep telling me stuff is not installable that apt-cache policy says is installable.  How can I figure out what the hell is going on?  https://bugs.launchpad.net/ubuntu/+source/apt/+bug/441626
<ubottu> Launchpad bug 441626 in apt "apt-get "Couldn't find" package listed as a Candidate by apt-cache policy." [Undecided,New]
<kanuha> If I wanted to add KDE to the Ubuntu 9.10 Beta, which package would I need to install? kdebase-workspace?
<ScottK> kanuha: kubuntu-desktop
<ScottK> That will bring you a full KDE system
<kanuha> ScottK, thx
<Darxus> How does apt-get decide what is installable?
<Darxus> This seems like a pretty major karmic bug.
<ScottK> Darxus: Check and make sure the exact same version of libpano13-0 is also available.
<ScottK> If not, it will be available, but not installable.
<Darxus> Ah.
<Darxus> Hmm, the install just worked.
<highvoltage> jono: glad to see I'm not the only one working on a saturday night :)
<jono> highvoltage, hehe
<jono> what are you working on?
 * MenZa sips his tea.
<highvoltage> jono: I was working on ltsp-related bugs for a client. tight now I'm actually playing with snowy (http://brad.getcoded.net/blog/entry.php?e=348085118)
<highvoltage> (s/tight/right)
<ScottK> Darxus: Probably libpano13-0 hadn't quite published the first time you tried.  Generally it's better to show up and ask something like "I don't understand why ..." that announce "OMG, bugz."
<jono> highvoltage, cool
<porcorico> hey ubuntu devs
<porcorico> how y'all doing?
<porcorico> I just came here to tell you that I am enjoying the beta
<porcorico> and also to ask info on the HP printer thingie hidden in the Main Menu...
<porcorico> This thingie right here: http://imgur.com/8CFbh.png
<porcorico> I don't understand what is that
<porcorico> I don't have printers installed
<DexterF> 'evening
<DexterF> what's the recommended procedure for 9.04->9.10b?
<DexterF> is there an upgrade-manager yet or is it safe to do it with aptitude?
<ebroder> DexterF: `sudo do-release-upgrade -d`, but #ubuntu+1 is more appropriate for that sort of question
<ebroder> (upgrade-manager would presumably also work)
<DexterF> ah, thanks.
<YokoZar> What's the user-friendly way of figuring out if you're on i386 or amd64?  We don't mention this in System->About Ubuntu, About Gnome, or even in System Monitor
<sistpoty> YokoZar: my best guess would be /proc/cpuinfo
<jpds> YokoZar: uname --machine ?
<LaserJock> we don't need Release Team approval for uploads yet do we?
<ebroder> Just bugfixes should still be OK, right?
<sistpoty> LaserJock, ebroder: for bugfixes only, I assume it's still ok (otherwise I'm violating the policy :P)
<YokoZar> sistpoty: jpds: was hoping for a non-terminal command ;)  oh well
<dtchen> YokoZar: System -> Administration -> Log File Viewer -> dmesg
<dtchen> YokoZar: or Xorg.0.log, since it prints the current operating system
<ion> zul: Hi. Please see bug 441518. Debdiff attached.
<ubottu> Launchpad bug 441518 in libaugeas-ruby "Missing /usr/lib/ruby/1.8/i486-linux/_augeas.so" [Undecided,New] https://launchpad.net/bugs/441518
#ubuntu-devel 2009-10-04
<ebroder> Anybody want to sponsor my fix for bug #435505?
<ubottu> Launchpad bug 435505 in system-config-printer "system-config-printer.py crashed with IOError in _report_traceback()" [Medium,In progress] https://launchpad.net/bugs/435505
<slacker_nl> why do some packages have their version number in the package name, an upgrade of the package will actually remove/install package, if only the version number would change I would only see a normal upgrade, eg, libuniconf4.4 to libuniconf4.6
<sistpoty> slacker_nl: (binary) library packages have the soname denoted in the package name
<sistpoty> slacker_nl: the reason is to have these coinstallable (e.g. if another package still needs the old and incompatible library)
<slacker_nl> sistpoty: ahh, isee
<ebroder> Can someone from ubuntu-release look at bug #429445?
<ubottu> Launchpad bug 429445 in zephyr "[Karmic FFe] Sync zephyr 3.0~rc.2544-1 (main) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/429445
<ebroder> I really don't believe that this needs an FFe, but it seems like it might be easier to just get one than to argue the point
<geofft> has there already been some discussion and/or flamage about Launchpad redirecting +filebug to the wiki page?
<geofft> I want this not to happen (at least for my account) but I'd rather not file a new bug if there's some existing forum
<dtchen> libuniconf4.6 is failing to upgrade due to debian 540320, which is resolved in wvstreams 4.6-2
<ubottu> Debian bug 540320 in libuniconf4.6 "libuniconf4.6: Error during installation" [Normal,Closed] http://bugs.debian.org/540320
<dtchen> (i.e., Karmic needs a sync of 4.6-2)
<ScottK> Does wvstreams build?
<dtchen> ScottK: yes, on both i386 and amd64
<dtchen> i ran piuparts on a locally pbuilt sync of 4.6-2
<ScottK> dtchen: If you file a sync request, I'll ack it.
<jdong> hmm is asac on leave recently?
<dtchen> ScottK: bug 441936
<ubottu> Launchpad bug 441936 in wvstreams "Please sync wvstreams 4.6-2 from Debian unstable main" [Undecided,New] https://launchpad.net/bugs/441936
<ScottK> dtchen: Ack'ed.  Thanks.
<dtchen> ScottK: thanks
<ScottK> You're welcome.  Thanks for looking into it.
<foxbuntu> evening everyone, I am just doing a little research trying to understand where the jobs are for upstart to start xsplash, cant seem to find the information i am looking for, anyone able to point me to it?
<hyperair> does anyone notice bash completion being a little broken in karmic?
<hyperair> for example, when using mv, completing a filename multiple times doesn't appear to work.
<hyperair> hmm specifically when there are spaces in the filename.
<hyperair> it completes until "stuff_before_first_space\ " and then it stops
<fabrice_sp_> hyperair, that's strange, because it's working here, even with spaces
<hyperair> is it?
<hyperair> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=543982
<ubottu> Debian bug 543982 in bash "bash: Completion with spaces broken." [Normal,Open]
<hyperair> this is the bug i'm seeing
<fabrice_sp_> it has just completed "test fabrice/prueba" without pb
<hyperair> could you grep your .bashrc for /etc/bash_completion?
<hyperair> the bug says that removing /etc/bash_completion from bashrc fixes the problem
<fabrice_sp_> sure
<fabrice_sp_> I don't have a /etc/bash_completion file on karmic :-)
<fabrice_sp_> that would explain why it's working in my case
<hyperair> ah
<hyperair> i see
<hyperair> also, only some commands seem to fail
<hyperair> i think it's those that are overridden in /etc/bash_completion
<cody-somerville> It works for me and I do have /etc/bash_completion
<hyperair> in karmic?
<cody-somerville> yup
<hyperair> which command did you use?
<hyperair> mv seems to fail
<cody-somerville> cd
<cody-somerville> mv works for me as well
<hyperair> is it sourced in your bashrc?
<hyperair> cd fails for me
<cody-somerville> yes
<hyperair> hmm how strange.
<hyperair> did you type until the \ before pressing tab?
<hyperair> or did you press tab before that?
<cody-somerville> not sure I understand your question
<hyperair> sorry.
<hyperair> basically filenames with spaces are generally tab completed to: bla\ bla
<hyperair> the completion fails if you type until "bla\ "
<hyperair> and then press tab
<hyperair> for me, that is
<hyperair> and as mentioned in the bug report
<cody-somerville> are you saying that if you type "mv blah\" and then hit tab that its not completing for you?
<hyperair> note the trailing space.
<hyperair> "mv blah\ "
<cody-somerville> yea, that doesn't work for me either
<hyperair> and that's what i meant.
<hyperair> it worked previously
<cody-somerville> try not typing the \ and just a space
<hyperair> heh?
<hyperair> then it'll be interpreted as the next argument already
<hyperair> and also, i didn't type the \. bash did.
<hyperair> if i've got files "blah blah" and "blah asdf" then typing "b" and pressing tab will bring you to "blah\ "
<cody-somerville> hyperair, type also one letter of the next word and it will complete it
<hyperair> after which completion afils.
<hyperair> fails*
<cody-somerville> and if bash does the \ for me, then it does work
<hyperair> doesn't work for me =(
<hyperair> http://pastebin.com/f1281dbd2
<hyperair> and completion fails
<cody-somerville> yea, that does appear to be broken
<hyperair> i suspect the _filedir function in /etc/bash_completion broke somewhere between jaunty and karmic
<hyperair> or _filedir_xspec?
<hyperair> hmm looks like it's not bash-completion that broke, but bash changed
<gp_will_be_back> hi
<gp_will_be_back> is net conections manger fixed in karmic koala
<gp_will_be_back> ?
<gp_will_be_back> https://bugs.launchpad.net/network-manager/+bug/279384
<ubottu> Launchpad bug 279384 in network-manager "NetworkManager does not provide a way for static IP configuration with DHCP-provided DNS, gateway etc." [Unknown,Confirmed]
<gp_will_be_back> as per gnome bug page it works on gnome but due some custom patch by ununtu not working in ubuntu
<hyperair> gp_will_be_back: it will be fixed. (asac said so) for now you can use the network-manager trunk ppa.
<hyperair> it works there.
<hyperair> oh wait, that, i'm not sure
<hyperair> i was thinking about the wrong bug
<hyperair> i don't think so, but the other way is possible
<gp_will_be_back> what is that way ?
<gp_will_be_back> manually edit /etc/network/interfaces ?
<gp_will_be_back> ;-)
<gp_will_be_back> also that ubuntu one thing NEVER works
<gp_will_be_back> but ubunto one stuff  not crtical .....networking connections applet stuff is
<gp_will_be_back> feature is there never works .....unbutu....going M$ way hehe ....i remember have same exp in kubuntu 9.04 .....network manager didnt work ..............i asked kde team they said custom ubuntu patch was to be blammed
<gp_will_be_back> does it works in karmic koala kubutu now ?
<gp_will_be_back> why doesnt ubuntu use stuff that works like wicd rather half boiled patches
<disown> Any channels where you can ask questions related to app development on ubuntu?
<ion> The channel for the library/editor/build system/whatever youâre interested of.
<disown> ion: I would like to find some info on how to integrate packaging, installation and testing in a dev cycle. I'll try the apt channel then?
<ion> #ubuntu-motu should help with packaging.
<disown> thanks
<Chipzz> 11:35 < gp_will_be_back> why doesnt ubuntu use stuff that works like wicd rather half boiled patches
<Chipzz> how about you read the actual gnome bug report and stop twisting the facts?
<Chipzz> the actual quote from the gnome bug report:
<Chipzz> > Dec  2 20:26:47 xendor NetworkManager: <debug> [1228229807.892297]
<Chipzz> > probe_modem(): Couldn't get caps
<Chipzz> Modem probing in NM is a custom Ubuntu patch and not in NetworkManager itself.
<Chipzz> Please file a bug in launchpad for your problem.
<Chipzz> that comment refers to modem probing, and has NOTHING to do with assigning a static IP address
<gp_will_be_back> it works in vanilla Gnome doesnt it ?
<gp_will_be_back> there is already bug filled regarding static ip and still unassigned
<gp_will_be_back> https://bugs.launchpad.net/network-manager/+bug/279384
<ubottu> Launchpad bug 279384 in network-manager "NetworkManager does not provide a way for static IP configuration with DHCP-provided DNS, gateway etc." [Unknown,Confirmed]
<gp_will_be_back> oh wait its assigned to gnome bug --->> https://bugzilla.gnome.org/show_bug.cgi?id=555626
<ubottu> Gnome bug 555626 in nm-applet "[enh] static IP but DNS via DHCP" [Enhancement,New]
<gp_will_be_back> mean while i have un -installed  it and using wicd
<directhex> dtchen, what would happen if an app disables pulse on startup, and tries to use alsa's "default" plug?
<Chipzz> gp_will_be_back: no it doesn't
<Chipzz> gp_will_be_back: state the comment in either the launchpad or gnome bug report which says it works in vanilla gnome
<Vittor> juego de boxeo online http://www.kobox.org/kobox-fande-Nourine.html
<Rocket2DMn> hey guys, bug 421221 affects the listing for Text Editor in ubuntu-docs, however there still seems to be some upstream discussion about it
<ubottu> Launchpad bug 421221 in gedit "menu entry says 'gedit' should say 'Text Editor'" [Low,Fix released] https://launchpad.net/bugs/421221
<Rocket2DMn> Is the plan to release with "gedit Text Editor" in Applications->Accessories, or is it going to be adjusted again before final Karmic release?
<Rocket2DMn> Is there another bug open for the issue that I'm just not seeing?
<freeflying> tested today's daily build, still found some acpi warning message when bootup
<SystemR32> Hello
<SystemR32> Please I need help
<SystemR32> anyone here?
<Aji-Dahaka> there is a fix on network-manager that has been committed via launchpad.  Are there any docs on how to build the stuff from launchpad?  I downloaded the patches via bzr and ran the rules file to get the source from git, but I'm kinda lost at that point
<Aji-Dahaka> it looks like something will have to apply the patch files and then the build process is probably about the same as "usual"
<Turl> hello, can anyone on a laptop confirm this? https://bugs.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/442378
<ubottu> Launchpad bug 442378 in gnome-power-manager "gnome-power-manager settings have no "on battery" tab" [Undecided,New]
<lucas> could someone "give-back" ruby1.9.1 on i386? it built everywhere else, so I'm pretty surprised it failed to build on i386.
<siretart> lucas: the package seems to have been built fine: https://edge.launchpad.net/ubuntu/+source/ruby1.9.1/1.9.1.243-2/+build/1275487
<siretart> lucas: btw, you should be able to retry builds by yourself (if you have upload priviledges for the package, that is)
<cjwatson> foxbuntu: upstart doesn't start xsplash, which might explain why you're having trouble finding where it does. :-) I think it's started by the GNOME session
<foxbuntu> cjwatson, thanks, I learned that last night :)
<lamont`>  /usr/sbin/invoke-rc.d: 274: /sbin/runlevel: not found <-- is maybe sysv-rc missing a Depends: upstart-compat-sysv ?
<cjwatson> lamont: upstart rather than upstart-compat-sysv. I'm going to upload a fix to a PPA first since I'm slightly wary of pre-depends cycles here
<lamont> ok
<lamont> cjwatson: fwiw, the new chroots differ from the old chroots in that rather than /etc/hostname having some random buildd host (wherever it was built), they now say 'INVALID' - there's a part of me that wants to add that host to /etc/hosts. :-(
<cjwatson> lamont: they also differ in that apparently the debconf frontend is borked ...
<cjwatson> (you have a bug about that)
<lamont> ah, thanks
<lamont> got a handy bug number?  if not, I'll go find it
<cjwatson> lamont: bug 442480
<ubottu> Launchpad bug 442480 in console-setup "Recent update to console-setup is causing packages to FTBFS" [Undecided,New] https://launchpad.net/bugs/442480
<james_w> what makes two people seemingly independently file bugs about being unable to eject CDs against D-Bus in two days?
#ubuntu-devel 2010-10-04
<RAOF> Hm.  Who was kees pointing at me?  I've got the ping, not the context from backscroll.
<ScottK> RAOF: http://paste.ubuntu.com/505382/
<RAOF> Ah, ok.  Yeah, we don't really use the video group anymore, and *something* needs to handle setting appropriate permissions on the DRI/whatever kernel device.  Sounds like a job for consolekit, to me - give the active seat access to the hardware.
<RAOF> I think the nvidia device is world-writable, for that matter, so having the arm drivers use a world-writable node won't be any worse than nvidia :)
<penguin42> yeuch
<kees> RAOF: the question was about how the graphics devices get their facl for the current user to use it. (e.g. getfacl /dev/dri/card0) for the case where ARM needs a 3d device for some special graphics driver it uses
<kees> RAOF: specifically, ogra was trying to sort it out
<RAOF> Ah.  I always assumed that it was consolekit that did the magic there; it seemed to be in-scope.
<RAOF> Also, I haven't noticed an example of that magic _failing_, so I haven't investigated too closely :)
<james_w> maxb: there are no others now I think. I retried all the others after adding the tags manually, as I believe I fixed the bug that was causing the tags to be missing a while ago.
<james_w> maxb: if there are more then we can file a new bug
<pitti> Good morning
<ion> that
<pitti> Riddell: current kubuntu desktops are 1 MB oversized; fixed in the seeds, next dailies will be ~ 696 MB
<sladen> pitti: when will the next dailies be?
<sladen> (I assume you're doing them manually)
<pitti> sladen: 0414 UTC every day
<pitti> sorry, 0314
<pitti> sladen: no, cron jobs are back on
<pitti> mr_pouit: is lp:~xubuntu-dev/ubuntu-seeds/xubuntu.maverick still the correct branch for xubuntu seeds? I added some langpacks on Friday, but current CD still doesn't have them
<pitti> cjwatson: ^
<pitti> (no error on livefs build logs)
<dholbach> good morning
<ari-tczew> hello
<cjwatson> pitti: that's the correct branch, yes
<cjwatson> pitti: the language packs seem to be on the Xubuntu alternate CD
<cjwatson> pitti: (you only changed ship)
<pitti> cjwatson: erk, silly me; thans
<pitti> thanks, too
<Wubbbi> Hey guys. I have an issue and this issue I have in the hole time of Ubuntu. But now it is realy getting on my nervs. Evolution is the word! I got a screen resolution of 1028x600 ... A Netbook. And Evolution is not going to fit on my screen. There are may parts of it which are going out of my screen thus I can click on some Icons or buttoms. Is it possible to fix it? Nothing helped yet. Even if I get on Fullscreen mode, it still not fits
<Wubbbi> . Anyone can confirm it or even help me. I realy have to work with evolution!
<micahg> Wubbbi: bug 645753
<ubottu> Launchpad bug 645753 in evolution (Ubuntu) "Evolution unusable on small 8" (1024 x 600) netbook screen's." [Undecided,New] https://launchpad.net/bugs/645753
<Wubbbi> micahg: ok thx. Will this be fixed in Ubuntu 10.10?
<micahg> Wubbbi: I can't say for sure, but highly unlikely at this point
<Wubbbi> micahg: This is bad. Thus I have to deinstall evolution now and I have to work with Thunderbird. This is not a personal atack but it realy sucks because I realy want to use this programm. Well ok. You cant do anything for it
<maxb> james_w: There appear to be 31 current NoSuchTag UDD failures, which is a lot more than mentioned in the latest update of bug 494481. I was thinking of going through some of the ones that don't appear to be caused by improper merging by humans, and listing the tags needing adding and a summary of where they appear to have got lost, if that would be useful?
<ubottu> Launchpad bug 494481 in Ubuntu Distributed Development "Too easy for people to not use merge-upstream" [High,Triaged] https://launchpad.net/bugs/494481
<Wubbbi> Ha! LoL! When I'm going to delete Evolution, it wants me to delete 50% of ubuntu ... -_-
<directhex> Wubbbi: deleting evolution-data-server will cause that
<directhex> Wubbbi: several evolution libraries are hard to remove independently, as they're sued for things like systemwide contacts, calendaring in the gnome clock, stuff like that
<Wubbbi> directhex: I know. But what does it bring for me when I cant use evolution. What do I need data-server for?
<directhex> Wubbbi: just the evolution client should be removable, though
<Wubbbi> hmmm ... ok data-server still exsist -.- ... Well still I'm not that happy ;)
<jibel> mvo, I don't understand bug 631426 . I can only think of an unsynced mirror or what else ? This is the last u-m dist-upgrade untriaged bug.
<ubottu> Launchpad bug 631426 in update-manager (Ubuntu) "Upgrade 10.04 -> 10.10 failed due to "the essential package 'ubuntu-minimal' can not be found anymore"" [Undecided,New] https://launchpad.net/bugs/631426
<cjwatson> ari-tczew: I uploaded palo to Debian with that patch the other day, BTW
<ari-tczew> cjwatson: yes I saw, thanks :)
<lucidfox> didrocks, re: "Just uninstall indicator-appmenu and the fallback for all applications indicator will be the systray."
<lucidfox> Shouldn't that be indicator-applet?
<didrocks> lucidfox: ooupsssss, you're right. Well, indicator-applet-appmenu to be exact
<didrocks> lucidfox: do you have the bug # handy?
<lucidfox> wait, isn't appmenu the global menu bar?
<lucidfox> Liferea uses the messaging indicator, which is removed (IIRC) by uninstalling indicator-messages
<lucidfox> bug #540490
<ubottu> Launchpad bug 540490 in liferea (Ubuntu) "liferea should be added to the indicator applet" [Undecided,Fix released] https://launchpad.net/bugs/540490
<didrocks> lucidfox: right, I'm not really awake today it seems, I was waiting for indicator-applet-application and relying on shell completion, but it's indicator-applet for whatever reasonâ¦ :)
<mvo> jibel:  thanks, let me have a look
<didrocks> lucidfox: added a comment. Thanks for the notice :)
<YokoZar> can I add a multiverse library to ia32-libs?
<cjwatson> no
<cjwatson> can the multiverse library be given a lib32xxx package instead?
<mvo> jibel: I updated the bugreport, I suspect there is something there that always servers zero files
<mvo> jibel: that is the only idea I have about this bug at this point
<cjwatson> mvo,jibel: do either of you happen to know what's going on with bug 597017 and its vast number of duplicates?  it looks as if some package management frontend is broken, but I don't know which
<ubottu> Launchpad bug 597017 in man-db (Ubuntu) "package man-db 2.5.7-2 failed to install/upgrade: debconf: DbDriver "config": /var/cache/debconf/config.dat is locked by another process: Resource temporarily unavailable while processing triggers for man-db" [Medium,Triaged] https://launchpad.net/bugs/597017
<cjwatson> perhaps jockey?  but it's hard to tell for sure whether that accounts for all of them
<cjwatson> and doesn't seem to account for the current master bug, if nothing else
<cjwatson> (in which the root user action appears to be "install chromium-browser-inspector"
<cjwatson> )
<jibel> cjwatson, no, I haven't been able to find a pattern, sometimes it happens while installing only one package.
<cjwatson> it's absolutely not a man-db bug, but I have no idea where to reassign it
<jibel> cjwatson, I thought of apt-daemon doing some weird async thing, but it seems to happen with apt too.
<cjwatson> man-db is just a canary for package management operations being called in some kind of invalid state
<mvo> I have to admit that my suspecion was aptdaemon debconf handling as well
<cjwatson> (because it's triggered by practically everything and it uses debconf)
<mvo> but if it happens with apt too, then â¦
<jibel> e.g reporter of bug  641023 was using apt-get update and simply upgraded dpkg.
<ubottu> Launchpad bug 641023 in man-db (Ubuntu) "package man-db 2.5.7-2 failed to install/upgrade: el subproceso script post-installation instalado devolviÃ³ el cÃ³digo de salida de error 1 (dup-of: 597017)" [Undecided,New] https://launchpad.net/bugs/641023
<ubottu> Launchpad bug 597017 in man-db (Ubuntu) "package man-db 2.5.7-2 failed to install/upgrade: debconf: DbDriver "config": /var/cache/debconf/config.dat is locked by another process: Resource temporarily unavailable while processing triggers for man-db" [Medium,Triaged] https://launchpad.net/bugs/597017
<cjwatson> 'apt-get update' won't upgrade any package ...
<cjwatson> the thing that did the upgrade wasn't apt-get, it was, as the reporter puts it, "the graphical agent"
<jibel> cjwatson, fair enough :)
<cjwatson> (whatever that is)
<cjwatson> presumably update-manager
<jibel> bug 578449, sudo aptitude update && sudo aptitude safe-upgrade -y
<ubottu> Launchpad bug 578449 in man-db (Ubuntu) "package man-db 2.5.7-2 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1 (dup-of: 597017)" [Undecided,New] https://launchpad.net/bugs/578449
<ubottu> Launchpad bug 597017 in man-db (Ubuntu) "package man-db 2.5.7-2 failed to install/upgrade: debconf: DbDriver "config": /var/cache/debconf/config.dat is locked by another process: Resource temporarily unavailable while processing triggers for man-db" [Medium,Triaged] https://launchpad.net/bugs/597017
<jibel> but maybe there was a software-center running in the background.
<cjwatson> the thing is that if another package management frontend is running then some other lock should clash
<cjwatson> except for the specialised use of debconf during initial OS installation, I can't see how the debconf lock should ever be the first one to clash; there should always be something outside it, like the dpkg lock
<jibel> cjwatson, right, I tried that scenario but the dpkg lock is preventing to install the package.
<cjwatson> though there doesn't seem to be an apt lock as such apart from the acquire lock, so I suppose races are possible, but I don't get the sense that that's what's going on here
<Riddell> mvo: could you comment on bug 653838 ?
<ubottu> Launchpad bug 653838 in update-manager (Ubuntu) "Lucid Maverick upgrade - kbluetooth is still installed" [Undecided,New] https://launchpad.net/bugs/653838
<shadeslayer> mvo: doesnt extras.ubuntu.com have a signing key?
<shadeslayer> W: A error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: http://extras.ubuntu.com maverick Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 16126D3A3E5C1192
<ion> shadeslayer: Upgrade.
<shadeslayer> hmm
<shadeslayer> ion: ok i see a upgrade for ubuntu-keyring, i guess it sorts out the issue
<shadeslayer> ion: also.. what does extras.ubuntu hold?
<\sh> the new opportunistic dev apps?
<cjwatson> shadeslayer: install ubuntu-extras-keyring, actually
<shadeslayer> \sh: and who has upload rights to that repo?
<cjwatson> you may have to reinstall it
<cjwatson> (there was a bug in live CD generation that meant that installations from the RC live CD didn't have the extras key properly installed)
<shadeslayer> yeah i think i have that ^
<\sh> shadeslayer: there was/is a long discussion on u-d about that topic...there is an application developer board which reviews those pkgs
<mvo> Riddell: looking
<shadeslayer> hmm.. im subscribed to that list.... i think
<doko> quadrispro: any update on xvidcap?
<kklimonda> shadeslayer: extras is for distributing applications that are not part of Ubuntu in any way - they can be dropped in outside of our development cycle, packaged by upstream developers and not as strictly checked
<Riddell> mvo: I seem to have broken the update-manager build anyway so I guess it needs another upload as it is.  but I don't know why kbluetooth wouldn't get removed for him since it's not in the archive any more (it gets removed when I've done upgrades)
<mvo> Riddell: we can force its removal
<mvo> Riddell: I did send you a mail about the build btw
<\sh> doko: thx for the sun-java  update :)
<shadeslayer> kklimonda: does that mean new KDE releases can go into this repo? like KDE 4.5.2 ?
<shadeslayer> Riddell: ^
<cjwatson> no
<\sh> shadeslayer: no
<shadeslayer> ok
<kklimonda> shadeslayer: no, it's only for things that are not in archive yet.
<\sh> shadeslayer: it's all about apps which are not in ubuntu, it's not allowed to update/upgrade already packaged software in ubuntu...
<shadeslayer> ohh....
<quadrispro> hi doko! back to work few hours ago, I've fixed some stuff on the Debian-side, now I'm about to have a deeper look at xvidcap
<kklimonda> shadeslayer: new KDE should probably be.. backported through -backports ;)
<shadeslayer> right...
<kklimonda> shadeslayer: I'm not sure if its feasible for such big projects
<quadrispro> doko, any idea about the reason it fails to build in the archive? I had success to build it in a cowbuilder chroot :-/
<\sh> kklimonda: was the workflow not like this: "upload to a special ppa and when ARB acked this pkg they copy it to the extras archive"?
<quadrispro> doko, maybe I miss something?
<shadeslayer> i agree ... i just thought that extras was for new stuff as well as stuff that cant be put into archives since they dont justify a SRU
<kklimonda> \sh: yes, last time I've heard about it that's how it is supposed to work.
<shadeslayer> but extras seems to be exclusively for new apps
<mvo> Riddell: I commited the fix for the kbluetooth issue
<Riddell> mvo: thanks, I'll fix the build and upload
<mvo> thanks Riddell
<ricotz> YokoZar, hello, what do you think about updating the packaging of ia32-libs for mesa-dri-experimental? like it is done in xorg-edgers ppa
<YokoZar> ricotz: do you mean adding libgl1-mesa-dri-experimental to ia32-libs?
<ricotz> YokoZar, like this https://launchpad.net/~xorg-edgers/+archive/ppa/+sourcepub/1310260/+listing-archive-extra
<ricotz> YokoZar, so creating a new package including the 32bit galliums files for optional install
<YokoZar> ricotz: what's in the new pacakge though?
<YokoZar> is it just 32 bit libgl1-mesa-dri-experimental?
<ricotz> YokoZar, yes
<YokoZar> Then why put it in a separate package and not just add it to the list of crap in ia32-libs?
<cjwatson> I'd much rather things be in a separate package when possible
<ricotz> YokoZar, so applications like googleearth could run with 3d acceleration on nouveau if the experimental packages are installed
<YokoZar> ricotz: it would work if it was part of the same package too, no?
<cjwatson> seb128: is anyone looking at bug 651254?
<ubottu> Launchpad bug 651254 in devhelp (Ubuntu Maverick) "devhelp fails to build from source in maverick" [High,Confirmed] https://launchpad.net/bugs/651254
<YokoZar> ricotz: looking at the package you linked, all it DOES do is add libgl1-mesa-dri-experimental to ia32-libs and then put it in a separate package
<seb128> cjwatson, wasn't that fixed with the update which got in after the rc freeze?
<ricotz> YokoZar, it is better to use a separate package which depends on lib-mesa-dri-experimental
<tumbleweed> cjwatson: bug 651255
<ubottu> Launchpad bug 651255 in devhelp (Ubuntu) "FTBFS: expected declaration specifiers or '...' before 'GtkNotebookPage'" [Undecided,Fix released] https://launchpad.net/bugs/651255
<ricotz> YokoZar, adding it directly to ia32-lib might mess up the driver search path of xserver
<YokoZar> ricotz: you mean if someone has ia32-libs but doesn't have lib-mesa-dri-experimental?
<ricotz> YokoZar, so add this would enable apps like googleearh to benefit of the 3d acceleration
<ricotz> YokoZar, yes
<YokoZar> why would that happen?
<ricotz> YokoZar, because it will search first for the gallium libs
<YokoZar> I mean, is X searching in /usr/lib32?
<ricotz> X is seaching for ../dri/gallium/. first then .../dri/.
<cjwatson> seb128: no idea, all I know is the bug's still open
<cjwatson> (and on the ubuntu-10.10 milestone list)
<seb128> cjwatson, it's fixed, let me close the bug
<YokoZar> ricotz: wouldn't it make sense to have ia32-libs-mesa-dri-experimental install by default when someone installs mesa-dri-experimental and one of these 32 bit packages?
<YokoZar> (eg wine/google earth?)
<YokoZar> I'm trying to figure out how to do that without pulling in ia32-libs on systems that don't have these 32 bit apps
<ricotz> YokoZar, this might be not possible
<YokoZar> Right.  But if both were always installed together and X was smart enough to only look for ia32-libs-mesa-dri-experimental when the 64 bit version was also installed, we wouldn't have a problem right?
<cjwatson> seb128: thanks
<ricotz> YokoZar, i think so
<ricotz> YokoZar, but since libmesa-dri-experimental is not supported or installed automatically i think users should also install the 32bit libs manually
<YokoZar> maybe libmesa-dri-experimental should recommend ia32-libs-mesa-dri-experimental (on 64 bit)
 * quadrispro has to leave
<ricotz> YokoZar, yes thins might a solution
<cjwatson> siretart: performous is failing to build on powerpc because (as far as I can see) libavcodec isn't built with -fPIC.  Would it be OK if I fixed that?
<ricotz> YokoZar, or suggest whatever is the lesser depend
<YokoZar> ricotz: recommend will get it pulled in by default
<YokoZar> ricotz: which is probably what we want here
<ricotz> YokoZar, ok
<YokoZar> cjwatson: ~multiverse that wants to be in ia32-libs: https://bugs.launchpad.net/ubuntu/+source/ia32-libs/+bug/643884
<ubottu> Launchpad bug 643884 in ia32-libs (Ubuntu) "Lucid: ia32-libs should include libmotif3 libs for ICAclient" [Medium,Triaged]
 * YokoZar wonders why libmotif3 is in multiverse
<cjwatson> YokoZar: no can do, sorry.  you'll need a separate package.
<cjwatson> universe source needs to be free
<YokoZar> cjwatson: right I agree
<YokoZar> cjwatson: but you had asked earlier if we could make a separate lib32 type package
<cjwatson> sure, that's the simplest fix
<cjwatson> assuming it works
<cjwatson> siretart: hmm, http://bugs.gentoo.org/show_bug.cgi?id=282390 suggests it's more complicated than that though ...
<ubottu> bugs.gentoo.org bug 282390 in Applications "shared libraries of media-video/ffmpeg fail to load on ppc with "R_PPC_REL24 relocation" errors due to no -fPIC" [Normal,Resolved: worksforme]
<cjwatson> think I might just remove performous on powerpc
<Kano> cjwatson: dont you think you should begin running isohybrid on the iso... it is really a very bad sign that u is not ready for hybrid just because of that - every other current distro handles it, do you think you had not enough time? it worked >1.5y ago...
<Kano> for fedora, kanotix and about 1 year ago for suse
<doko> siretart: ffmpeg powerpc ping
<cjwatson> doko: ... you're not debugging the same thing I was just debugging, are you?
<cjwatson> (see above)
<doko> ahh
<cjwatson> I removed performous on powerpc - fiddling around with -fPIC in ffmpeg six days before release didn't fill me with warm fuzzies
<doko> cjwatson: was looking at odin pn powerpc
<cjwatson> ah
<cjwatson> haven't looked at that
<doko> ok, should do the same with odin then
<cjwatson> similar complaint about an R_PPC_REL24 relocation being out of range?
<doko> yes
<doko> but but-imaging recommends it. should we remove it anyway?
<cjwatson> not sure.  it was an easy decision with performous because it was a leaf game package
<cjwatson> making things uninstallable is a harder one
<cjwatson> oh, just a recommends?
<doko> but [!powerpc] in recommends doesn't work?
<doko> yes
<doko> recommends
<cjwatson> actually I wouldn't even worry about a recommends
<cjwatson> package managers will just ignore those if they're missing
<doko> ok
<jibel> cjwatson, mvo, I can reproduce the man-db error. The problem is with apt-daemon.
<cjwatson> jibel: cool, do you know what the problem is?
<jibel> here is the recipe:
<jibel> launch s-c
<cjwatson> is the debconf proxy locking debconf maybe?
<jibel> select a package with a debconf prompt: I picked krb5-admin-server
<jibel> install but let the debconf dialog opened.
<cjwatson> (shouldn't, though, it uses a throwaway db)
<jibel> launch a terminal and install another app that trigger man-db
<jibel> I installed ntp with apt.
<cjwatson> hm, if you leave the debconf dialog opened, surely the dpkg lock should still be helf
<cjwatson> held
<cjwatson> it shouldn't be possible to proceed without closing the dialog
<mvo> *ick* indeed, the dpkg lock should still be held
<jibel> what make the problem more difficult to diagnose is that the package installed from s-c doesn't appear in the logs
<mvo> jibel: many thanks for the reproduce instruction, let me try to reproduce now
<mvo> jibel: hm, so I see packages installed in term.log, is that not the case for you?
<mvo> jibel: *cough* I think I got it - dpkg-preconfigure is the problem
<jibel> mvo, after you've finished the installation of the first package. It's not caught in the crash file.
<mvo> jibel: it does not lock it seems
 * pitti can't help but wondering about bug 652631
<ubottu> Bug 652631 on http://launchpad.net/bugs/652631 is private
<pitti> bug 642792, sorry
<ubottu> Launchpad bug 642792 in metacity (Ubuntu Maverick) "ALT+PrtSc not recognised: breaks built-in screenshot function" [High,Confirmed] https://launchpad.net/bugs/642792
<pitti> am I the only one on earth who thinks that a key labelled "printscr" should act as such without Alt?
<seb128> pitti, it does?
<seb128> the printscreen takes a screenshot of your screen where alt-printscreen should take one of the active dialog
<pitti> seb128: yes, and I never noticed it to behave differently
<pitti> seb128: erm, alt+printscr has been sysrq for the last two decades or so
<seb128> no
<seb128> start a lucid desktop and try it
<pitti> that sounds like a bug, though
<seb128> well it has been this way since warty
<pitti> a sysrq certainly shoudn't trigger a screenshot?
<pitti> presumably I didn't notice since in the cases where I need it the OS is too broken to do anything else than reboot..
<seb128> well we had that working and sysrq working
<pitti> seb128: that would mean that the key does two things?
<didrocks> yeah, since warty alt+printscr is to take the screenshot of the current window
<seb128> I think we had bugs say that sysrq opens the screenshot dialog yes
<pitti> wow; one never stops learning
<seb128> but from an user perspective you break an handy feature which worked since warty
<seb128> you want to take screenshots of dialog most of the time
<pitti> so, is that gnome-settings-daemon then?
<seb128> not sure which part handles that keybinding
<pitti> I don't get an input event on alt+printscr, so perhaps the kernel is intercepting it now
<pitti> sorry, xev doesn't show it; I do get an input event
<siretart> doko: hi
<doko> siretart: see above, some thing for powerpc libavcodec and ffmpeg
<didrocks> pitti: that is what is reported and we discussed on Friday. I think the guess of a kernel change comes from there
<siretart> from the bug: "As far as I understand it, the ppc problem is not because shared libs have to be pic but because relocations are too "big" when loaded from some libraries (ffplay/ffmpeg seems to work and load the same library)."
<siretart> from the gentoo bug
<siretart> a similar (toolchain) bug can be seen on ia64, btw
<mvo> jibel: I prepare a upload now, many thanks again
<siretart> see debian bug #598952
<ubottu> Debian bug 598952 in src:ffmpeg "ffmpeg: FTBFS on ia64: relocation truncated to fit: GPREL22 against `.bss'" [Serious,Open] http://bugs.debian.org/598952
<siretart> cjwatson: regarding re-compiling with pic: if you want to do that, I'd suggest to patch the configure script, it has a hardcoded list of architecture that require -fPIC.
<cjwatson> siretart: I saw, but I decided to take a different approach for the problem I was working on (performous)
<siretart> cjwatson: upstream strongly advises against that because of performace impact
<jibel> mvo, thanks to you, that was a quick fix.
<cjwatson> siretart: indeed, applications that do not start at all are much faster than ones that do
<siretart> cjwatson: does ffplay work for you?
<cjwatson> siretart: for me?  I'm not actually using powerpc, I'm hunting down NBS
<siretart> according to the gentoo bug, I understand that this doesn't affect all applications. in particular, ffplay/ffmpeg seem to work, but not gst-ffmpeg
<cjwatson> AFAIK doko is doing the same
<siretart> I see
<cjwatson> packages that fail to build tend to have something of an effect on archive consistency
<cjwatson> which is important as we approach release
<siretart> well, we have a fast workaround (enabling PIC) that has performance impact but unbreaks gst-ffmpeg but also causes performance issues. under these circumstanced, I'd tend to agree to go the quick fix
<tkamppeter> pitti, hi
<cjwatson> I think we're just removing the powerpc binaries for the packages that fail to build on powerpc, for now
<pitti> hello tkamppeter
<tkamppeter> pitti, can you have a look at bug 653470, bug 653515, and 653585, there seems to be an interference between the upstartification of CUPS and systems with CJK languages.
<ubottu> Launchpad bug 653470 in cups (Ubuntu) "package cups 1.4.4-6ubuntu1 failed to install/upgrade: è¯¥è½¯ä»¶åç°å¨çç¶ææä¸ºä¸å¦¥ - å»ºè®®æ¨ å¨å¸è½½å®ä¹ååéæ°å®è£ä¸æ¬¡ã" [Undecided,New] https://launchpad.net/bugs/653470
<ubottu> Launchpad bug 653515 in cups (Ubuntu) "package cups 1.4.4-6ubuntu1 failed to install/upgrade: è¯¥è½¯ä»¶åç°å¨çç¶ææä¸ºä¸å¦¥ - å»ºè®®æ¨ å¨å¸è½½å®ä¹ååéæ°å®è£ä¸æ¬¡ã (dup-of: 653470)" [Undecided,New] https://launchpad.net/bugs/653515
<tkamppeter> bug 653585
<ubottu> Launchpad bug 653585 in cups (Ubuntu) "package cups 1.4.4-6ubuntu1 failed to install/upgrade: å­è¿ç¨ å·²å®è£ post-installation èæ¬ è¿åäºéè¯¯å· 2" [Undecided,New] https://launchpad.net/bugs/653585
<james_w> maxb: oh, not in main, sorry for the confusion. That would be great.
<maxb> james_w: np, will do
<doko> bdrung: do you work on the audacious plugin build failures?
<doko> cjwatson: did you already remove performous-tools on powerpc?
<cjwatson> yes
<cjwatson> mvo: BTW, did you notice bug 653200?
<ubottu> Launchpad bug 653200 in update-manager (Ubuntu Maverick) "extras.ubuntu.com added to server installs" [High,Confirmed] https://launchpad.net/bugs/653200
<jibel> pitti, could you publish screen 4.0.3-14ubuntu1.2 (bug 574773) during your next round of sru. The bug number is not in the changelog and is not shown on the pending sru list.
<ubottu> Launchpad bug 574773 in screen (Ubuntu Lucid) "Cannot make directory '/var/run/screen': Permission denied (convert init to upstart)" [Medium,Fix committed] https://launchpad.net/bugs/574773
<pitti> jibel: ah, doing now; thanks!
<jibel> pitti, cool, thank you.
<raphink> Keybuk: could you have a look at the new patch on mountall (bug 654545) please?
<ubottu> Launchpad bug 654545 in mountall (Ubuntu) "mountall does not honor nobootwait flag on /var/* and /usr/* filesystems" [High,In progress] https://launchpad.net/bugs/654545
<tkamppeter> pitti, did you see my message?
<pitti> tkamppeter: yes, I'll have a look later on
<pitti> tkamppeter: I looked at the first dpkg log and didn't see an obvious error message related to cups, so I'll loko at the dups
<pitti> tkamppeter: replied with requests for further info
<jibel> cjwatson, I've updated bug 653134 with new info. If I replace the grub.cfg from the failed upgrade with the one from a maverick install on the exact same system then ubuntu in wubi boots fine.
<ubottu> Launchpad bug 653134 in Wubi "Can't boot Ubuntu after an upgrade from 10.04.1 to 10.10" [Undecided,New] https://launchpad.net/bugs/653134
<jibel> cjwatson, both cfg files are attached to the report.
<mvo> cjwatson: re 653200> I'm working on that now
<ricotz> siretart, hello, i think there is a problem with a dependency of libswscale-dev which depends on libswscale0 | libswscale-extra-1, libswscale-extra-1 is not available ffmpeg-extra creates libswscale-extra-0
<mvo> cjwatson: thanks for the reminder :)
<cjwatson> jibel: hm, I'd have said that the one from the install was the broken one
<cjwatson> if you had me look at those outside the context of this bug
<cjwatson> guess it has something to do with module loading not being available in wubildr
<jibel> well, I'm logged in now. I guess it's working
<cjwatson> jibel: did you comment out 'insmod gfxterm' by hand?
<jibel> cjwatson, yes
<cjwatson> oh, that was in the old file
<cjwatson> jibel: could you put the old configuration back, apply http://paste.ubuntu.com/505772/ to /usr/share/lupin-support/grub-mkimage, and run 'sudo grub-install /dev/sda' (the /dev/sda bit doesn't matter in the Wubi case)
<cjwatson> ?
<jibel> okay
<cjwatson> having trouble seeing why any of this would *crash* grub, but this is worth a shot ...
<cjwatson> (BTW, if that works, then as a control it would be good to unapply that patch and try grub-install again, to make sure that still breaks)
<jibel> cjwatson, I also noticed that when you upgrade the files c:\ubuntu\winboot\wubildr and wubildr-bootstrap.cfg are not there but they exist when performing a fresh install.
<siretart> ricotz: didn't I already fix that one? if not, yeah, you're totally right
<seb128> hum, bug #654395
<ubottu> Launchpad bug 654395 in gdm (Ubuntu) "random graphical boot failure with (process:275): Glib-WARNING **: getpwuid_r() failed due to unknown user id (0)" [Undecided,New] https://launchpad.net/bugs/654395
<seb128> does anybody has a clue if that's a plymouth or gdm issue?
<ricotz> siretart, seems not to be fixed then ;)
<cjwatson> jibel: wubildr-bootstrap.cfg is an artifact
<cjwatson> in the "temporary file" sense
<seb128> hum, seems similar to bug #532984
<ubottu> Launchpad bug 532984 in plymouth (Ubuntu) "Ubuntu 10.04 Alpha 3 won't boot on HP Compaq Pentium 4; displays an irrelevant Glib warning on the console" [Undecided,Invalid] https://launchpad.net/bugs/532984
<cjwatson> jibel: afaik c:\ubuntu\winboot\wubildr is not used after initial installation
<seiflotfy> hey guys
<seiflotfy> a question
<seiflotfy> my partition fials to mount to /home
<seiflotfy> its a btrfs
<seiflotfy> is there a way to fix t
<doko> azeem: opensync ping. you suggested to build barry without the opensync plugin, and to remove any other opensync plugin form maverick. is this still the way to go?
<jibel> cjwatson, grub rescue> I think I broke my main grub :/  booting from livecd
 * barry wonders who had the gall to name a package after him without a hefty royalty check... :)
<jibel> cjwatson, the system is back from the void.  Your patch is working.
<jibel> cjwatson, now breaking the system again to make sure that is still breaks.
<cjwatson> jibel: sounds promising ...
<jibel> cjwatson: \o/ my system is broken again. That works!
<cjwatson> hooray!
<cjwatson> guesswork for the win.
<Haegin> hi, who is the best person to talk to to request a patch being added to the kernel or does that have to happen upstream?
<cjwatson> #ubuntu-kernel
<cjwatson> (and in general, most patches should go upstream)
<Haegin> cjwatson: ta
<alex88__> hi, i'm trying netbook edition...i've removed firefox and installed chromium..how can i add it to the launchers on the left?
<alex88__> well..with unity
<alex88__> mmhh...i've read to run the app and right-click-> keep in launcher..but i haven't that option
<alex88__> !netbook
<cjwatson> siretart: so, just to confirm, since doko has uploaded a candidate change for this for maverick: are you OK with enabling PIC in ffmpeg on powerpc?
<mar> how do I report bug for stopped-clock
<mar> i mean clock in my gnome-panel is stuck at 21:38:30 now :)
<penguin42> mar: Did you wind it ?
<penguin42> mar: Not on this channel; use ubuntu-bug followed by the package name, discussion on #ubuntu-bugs
<siretart> cjwatson: well, I don't have powerpc hardware myself, so I need to rely on people that actually use that hardware
<siretart> cjwatson: if you say as powerpc user that enabling PIC has more worth than the performance it brings, then sure!
<YokoZar> why does apt-get source jasper give me jasper-initramfs but apt-get source libjasper1 give me jasper source package
<YokoZar> ah hah...because the jasper binary is in the jasper-initramfs package but not the jasper source package
<YokoZar> weird
<ScottK> YokoZar: I think that's got to be a bug.  I've seen it before.  I think if you feed it a source package name that's what it should get unless it doesn't exist.
<YokoZar> ScottK: at the moment it's preventing me from adding libjasper1 to ia32-libs
<ScottK> Interesting.
<YokoZar> ScottK: because it gets double parsed essentially
<YokoZar> so would we say this is a bug in apt-get or a bug in the binary package that's named for someone else's source package (seems like something we should have a policy about)
<ScottK> I think it's a bug in apt-get, or at best a use case that isn't considered by the current design.
<ScottK> Try apt-get source kdebase for similar fun.
<slangasek> pitti: do you have a standard rune for use of dpkg --path-exclude, --path-include somewhere?
<cjwatson> siretart: as I said earlier today, I'm not a powerpc user any more
<cjwatson> siretart: doko and I are trying to fix up the archive, in ways that don't necessarily in all cases require actually using the architectures that have problems
<cjwatson> YokoZar: use the --only-source option
<cjwatson> siretart: so I'm only a "user" in the sense that I care about the fact that some source packages don't build on powerpc due to this; I'm unable to evaluate the performance tradeoff
<YokoZar> cjwatson: brilliant, thanks.  (hooray for the switch not in the man page :) )
<cjwatson> it is in the man page
<cjwatson> http://paste.ubuntu.com/506034/
<hallyn> kees: jdstrand: jinkeys
<hallyn> kees: jdstrand: i didn't realize i'd be allowed to push to qa-regression-testing
<hallyn> uh, so.  yeah, feel free to revert.  i don't know how open it's intended to be
 * hallyn had hoped to push to his own branch, and request a merge to get some review...
<kees> heh
<kees> hallyn: no worries. you must be part of the qa group. :)
<SpamapS> hrm.. bzr-buildpackage is killing me at the moment..
<SpamapS> bzr: ERROR: [Errno 2] No such file or directory: '/home/clint/pkg/pipemeter/bzr/pipemeter/packaging/debian/emacsen-startup.ex'
<SpamapS> file exists
<SpamapS> so.. wtf?
<SpamapS> not to mention, bzr status does not mention it. :-P
<kees> hallyn: I would probably have used optparser instead of the manual argv stuff, but if it works, that's all good.
<kees> hallyn: nice to replace a TODO with real code :)
<hallyn> SpamapS: so it needs to be in the bzr manifest?
<hallyn> kees: yeah, i wanted to, but the python test framework steals my argvs!
<kees> hehe
<hallyn> kees: maybe my hack will offend jdstrand enough that he'll do it the right way :)
<kees> hahah
<SpamapS> weird
<SpamapS> had to re-add all the .ex files I manually rm'd
<hallyn> SpamapS: maybe it would've been happy if you'd "bzr remove"d them?
<SpamapS> hallyn: indeed, but usually bzr is just fine and dandy with added files disappearing
<hallyn> SpamapS: i've got a bzr bd q too  :)  i've got my own little package which only exists in bzr.  i want to build the package.  but it complains there is no .orig.tgz file.  help?
<SpamapS> hallyn: --native would be a sneaky way out of that
<hallyn> i'm fine with sneaky
<SpamapS> hallyn: its less sneaky if this is something that is only really useful on ubuntu/debian systems. ;)
<cjwatson> [BUILDDEB]\nnative = True
<cjwatson> in .bzr-builddeb/default.conf
<cjwatson> see /usr/share/doc/bzr-builddeb/README.gz
<hallyn> cjwatson: i've done that
<hallyn> SpamapS: --native doesn't help
<cjwatson> ask james_w then
<hallyn> maybe i want to use export-upstream
<hallyn> cjwatson: ok, thanks.  the README looks helpful1
<hallyn> !
<SpamapS> hallyn: what do you mean it doesn't help though?
<hallyn> whee, it's doin gsomething
<SpamapS> hallyn: --native and what cjwatson said are the same thing ;)
<SpamapS> except his is permanent
<hallyn> SpamapS: it still said make: *** No rule to make target `get-orig-source'.  Stop.
<hallyn> SpamapS: the export-upstream was what i needed.  now i'm down to my crap debian/control contents :)
<SpamapS> hallyn: yeah, get-orig-source should be skipped with --native tho.. or maybe I'm forgetting something else
<hallyn> that'd have been nice, since my export-upstream path is just my bzr pull path :)
<hallyn> SpamapS: and it even started out saying "Building using working tree
<SpamapS> hallyn: I have a package here that is native.. there's no orig source and it never asks for one.. hmm
#ubuntu-devel 2010-10-05
<SpamapS> hallyn: lp:~clint-fewbar/debigem/trunk
<SpamapS> hallyn: that one is native
<SpamapS> builds perfectly with bzr-buildpackage --native
<SpamapS> hallyn: do you have "3.0 (native)" in debian/source/format ?
<SpamapS> hallyn: if not, try that :)
<hallyn> SpamapS: oh, no i do not
<SpamapS> hallyn: did that help?
<hallyn> SpamapS: yes, it does, and it's a lot faster than using export-upstream :)
<hallyn> thx
<SpamapS> sweet
<james_w> SpamapS: please file a bug on the missing but there thing
<james_w> hallyn: please file a bug on the --native not working for you first time if possible
<james_w> hallyn: just the log from your attempts would probably help me diagnose.
<SpamapS> james_w: will do
<hallyn> james_w: well, i didn't have debian/source/format set.  is that then still a bug, or user error?
<james_w> hallyn: still a bug
<james_w> any confusion is worth examining to see if it can be alleviated
<hallyn> james_w: ok, will do, thanks
<ebroder> I'm trying to figure out how cryptsetup and mountall interact. I have a swap LV that's not configured as a potential resume partition (the key is regenerated at boot) and therefore isn't decrypted from the initrd. It *seems* like the cryptdisks-enable and mountall jobs will race, right?
<ebroder> Err, rather, they seem to be racing
<ebroder> Regardless of whether I set nobootwait or not, the boot seems to succeed without interference and the swap is enabled by the time boot completes
<ebroder> But I can't find any setting that will kill mountall's "unable to find device" plymouth message
<cwillu_at_work> ebroder, do not concern yourself with the secrets of scary people
<cwillu_at_work> ebroder, what does nobootwait do again?
<cwillu_at_work> I think I understand the process, but I want to hear your interpretation before I explain what happens
<cwillu_at_work> i.e., if I'm wrong, I'd like to find out before I start saying stuff :p
<ebroder> cwillu_at_work: Actually, I'm still trying to work it out. It looks like mountall has some sort of udev trigger or something? So when cryptdisks-enable runs, it'll trigger mountall to try mounting stuff again
<ebroder> Which I guess explains why the boot doesn't completely fail when I *don't* have nobootwait sent
<cwillu_at_work> ebroder, cryptdisks-enable isn't the relevant job here I don't believe
<cwillu_at_work> cryptdisks-udev is the magic
<ebroder> Eh. They're basically the same thing, right? One does initialization, and one responds to events after initialization?
<cwillu_at_work> it also handles mounting the contained devices
<ebroder> Wait, really?
<cwillu_at_work> i.e., it does a "mount /dev/unlocked_device"
<cwillu_at_work> which will only do anything if it's listed in fstab
<cwillu_at_work> yep, read /lib/cryptsetup/cryptdisks.functions
<cwillu_at_work> crypttab_start_one_disk calls mount_fs
<cwillu_at_work> and mount_fs does: mount "$point"
<ebroder> Huh. Will mount do a swapon?
 * cwillu_at_work giggles
<cwillu_at_work> hmm
<ebroder> cwillu_at_work: No, it won't. It'll complain about the mountpoint not existing
<cwillu_at_work> ebroder, oddly, there's nothing that does a swapon in my /etc/init*/*
<ebroder> cwillu_at_work: Yes there is - mountall
<cwillu_at_work> mountall emits all-swaps
<cwillu_at_work> it doesn't swapon
<ebroder> The init job doesn't, but the mountall daemon does
<cwillu_at_work> that's unfortunate: /
<cwillu_at_work> have you looked at its source yet?
 * cwillu_at_work dives in
<ebroder> I've tried to, but I haven't managed to grok Keybuk's style yet
<cwillu_at_work> heh
<cwillu_at_work> I love the nih_ prefix :p
<cwillu_at_work> ebroder, you're _only_ asking about swap devices?
<cwillu_at_work> or are you concerned about normal mounts too?
<ebroder> Nope, just swap
<cwillu_at_work> it doesn't ever wait on swap
<cwillu_at_work> at least, if I'm reading it right
<ebroder> Maybe I need to spend some more time figuring out what exactly the failure I'm seeing is
<cwillu_at_work> among other things:  (no)bootwait has no effect on swaps:  it checks whether something is swap in the same if tree as it later checks for that tag
<cwillu_at_work> in mount_policy, swaps never have anything added to their dependencies
<cwillu_at_work> ugh, I hate dpatch
 * cwillu_at_work threatens to sue if dpkg-buildpackage doesn't work from inside dpatch-editpatch's hackjob
<cwillu_at_work> ebroder, are you an ubuntu dev, or just another poser like me? :D
<cwillu_at_work> does anyone know if our bash has readline statically compiled in?
<cwillu_at_work> I'm trying to fix some broken history behaviour, but bash doesn't seem to be using any readline libs, let alone my modified ones
 * cwillu_at_work blinks, as he finally notices bash-static is installed
<cwillu_at_work> but... that's not what I'm running anyway
<cwillu_at_work> and yes, our bash has readline compiled in
<cwillu_at_work> drat
<dholbach> good morning
<pitti> Good morning
<dholbach> hi pitti :)
<pitti> hey dholbach, how are you?
<dholbach> great - how are you?
<pitti> I'm great, thanks!
<iulian> Morning dholbach.
<dholbach> thekorn, Happy Birthday! :)
<pitti> thekorn: ooh, alles Gute zum Geburtstag!
<thekorn> dholbach: pitti vielen Dank
<dholbach> :-)
<hyperair> ScottK: did you get around to checking out libgpod?
<Laney> he's away
<Laney> hyperair: you should just get it sponsored to the proposed queue and it will be reviewed there
<tkamppeter> pitti, I have a fix for bug 653814.
<ubottu> Launchpad bug 653814 in hplip (Ubuntu Maverick) "Wrong driver used because of incorrect device-ids" [High,In progress] https://launchpad.net/bugs/653814
<Laney> (assuming that's what you mean)
<tkamppeter> pitti, the bug was caused by changes done to make PPDs for Ricoh printers correctly selected depending on whether an optional PostScript module is installed or not, but for HP PostScript printers PCL PPDs got selected instead of PostScript PPDs.
<tkamppeter> pitti, as HP lasers are rather common I think this is very important for Maverick. should I upload the two packages containing the fix?
<hyperair> Laney: yeah, i asked him to sponsor it for me
<Laney> hyperair: didrocks might fancy it ;)
<shadeslayer> ion: i still have that archive signing bug
<shadeslayer> everything is updated and ubuntu-extras-keyring is installed
<shadeslayer> and when i tried to remove and reinstall that package i got gpg: key "3E5C1192" not found: eof
<fta> mvo, hi, any idea about bug 654782? corrupted deb file or bug in apt/dpkg?
<ubottu> Launchpad bug 654782 in chromium-browser (Ubuntu) "package chromium-browser 7.0.540.0~svn20100930r61020-0ubuntu1~ucd1~lucid failed to install/upgrade: lettura breve in buffer_copy (dpkg-deb backend su "./usr/share/doc/chromium-browser/copyright")" [Undecided,New] https://launchpad.net/bugs/654782
<shadeslayer> ion: ok fixed with sudo apt-get --reinstall install ubuntu-extras-keyring
<pitti> tkamppeter: if they have an unintrusive and precise patch, please go ahead
<tkamppeter> pitti, OK.
<tkamppeter> pitti, done.
<hyperair> didrocks: hey do you have upload access to main?
<didrocks> hyperair: yes
<didrocks> hyperair: need sponsoring?
<hyperair> didrocks: would you mind uploading libgpod to -proposed?
<hyperair> didrocks: yeah.
<hyperair> https://bugs.launchpad.net/ubuntu/+source/libgpod/+bug/652855
<ubottu> Launchpad bug 652855 in libgpod (Ubuntu) "Please fakesync libgpod 0.7.95-1 from Debian experimental to maverick-updates" [Undecided,New]
<hyperair> needs a fakesync
<didrocks> hyperair: ah, the libpod change :-) sure, as we discussed it with the desktop team :)
 * hyperair nods =)
<bdrung> doko: i did a quick look, but i have not enough time to work on them
<hyperair> you were there during the discussion?
<Laney> haha @ the last comment there
 * hyperair only recalls talking to seb128 about it
<doko> bdrung: looks like we have to disable these ...
<didrocks> hyperair: yeah, I read it :-)
<hyperair> aah
<didrocks> hyperair: I was around, I just don't speak when I don't have any valuable input from my point of view (at least, I try :p)
<bdrung> doko: yes
<doko> bdrung: let me know if you can help with the removal
<hyperair> didrocks: try, eh? =p
<bdrung> doko: this week probably not
<zul> pitting: ping the landscape-client SRUs have been verified as fixed can we move them into updates?
<seb128> tkamppeter, hey
<seb128> tkamppeter, do you know if somebody is working on porting system-config-printer to gtkbuilder?
<tkamppeter> seb128, no.
<tkamppeter> seb128, what is gtkbuilder
<soren> It's just like glade, only different.
<seb128> tkamppeter, https://bugs.edge.launchpad.net/ubuntu/+source/system-config-printer/+bug/403540
<ubottu> Launchpad bug 403540 in system-config-printer (Ubuntu) "Should use GtkBuilder rather than libglade" [Wishlist,New]
<tkamppeter> soren, seb128, is glade about to be deprecated in favor of gtkbuilder?
<soren> zul: pitting? pitti - next generation?
<seb128> tkamppeter, it's not 'about to', it has been a year ago
<pitti> zul: can do
<seb128> tkamppeter, but we want to drop libglade from the default installation next cycle
<seb128> tkamppeter, system-config-printer is one of the few software which has not been ported yet
<geser> soren: better than the current one? :)
<soren> geser: Impossible :)
<zul> pitti: thanks
<zul> soren: not enough caffine :)
<pitti> zul: ah, just 7 days today, so right on time
<zul> pitti: excelent
<tkamppeter> seb128, this would depend on Tim Waugh, the principal maintainer of system-config-printer.
<seb128> tkamppeter, could you ask him if he has any plan to work on that?
<seb128> I guess fedora will want that as well since they are porting everything to be GNOME3 compliant as well
<tkamppeter> seb128, I asked him in the bug report now.
<soren> seb128, tkamppeter: http://cyberelk.net/tim/2010/03/17/system-config-printer-1-2-0/ says it's already using GtkBuilder?
<seb128> tkamppeter, thank you
<seb128> soren, oh, nice
<seb128> we have 1.1. though
<soren> system-config-printer | 1.2.3+20100723-0ubuntu7 |      maverick | source
<soren> ?
<seb128> soren, hum, my mistake
<seb128> so maybe just somebody who forgot to clean the control depends?
<seb128> checking...
<soren> It's gui.py certainly uses GtkBuilder.
<soren> s/It's/Its/ darn it.
<seb128> ok, I got confused
<soren> The only mention of glade is a comment and the name of the xml file.
<seb128> they didn't rename their .glade to .ui and the depends didn't get updated
<soren> ...and debian/control, clearly.
<seb128> soren, thanks ;-)
<seb128> tkamppeter, ^ their ported the code, you need to drop the depends on python-glade2 in the next upload
<soren> seb128: Oh, thank *you*. I was desperately looking for an excuse to do something else for a few minutes. :)
<seb128> lol
<tkamppeter> seb128, I have done an upload to Maverick some minutes ago, to fix bug 653814, should I replace it to drop this dependency in Maverick or should I wait until Natty with that?
<ubottu> Launchpad bug 653814 in system-config-printer (Ubuntu Maverick) "Wrong driver used because of incorrect device-ids" [High,Fix committed] https://launchpad.net/bugs/653814
<seb128> tkamppeter, you can wait until next cycle
<seb128> tkamppeter, we still have some other packages in the default installation depending on it
<seb128> so it will not make a difference to drop it now
<tkamppeter> OK, so first Natty upload should drop this dependency to magically free ups some megs on the CD.
<seb128> tkamppeter, thanks
<seb128> it's probably some megs, the library is small, but it's less cruft in any case ;-)
<micahg> Riddell: do you have time to process 2 removals from the archive?
<Riddell> micahg: if they're reported as bugs and subscribed to ubuntu-archive I'm going to process them shortly
<micahg> Riddell: awesome, thank you
<jibel> pitti, I think that you can publish debian-installer 20081029ubuntu102.4 to lucid-updates, the kernel in updates is already 2.6.32-25 and dove is 2.6.32-209.25, there is no bug report attached.
<pitti> jibel: already done
<pitti> jibel: thanks
<jibel> pitti, thank you
<cjwatson> pitti: please note https://wiki.ubuntu.com/ArchiveAdministration#Special%20case:%20debian-installer%20updates
<cjwatson> I'm going to apply that now
<cjwatson> (done)
<pitti> ah, thanks
<philsf> pitti, about bug #642792, what about reverting the kernel patch? Could this be done in time for release?
<ubottu> Launchpad bug 642792 in metacity (Ubuntu Maverick) "ALT+PrtSc not recognised: breaks built-in screenshot function" [High,Confirmed] https://launchpad.net/bugs/642792
<pitti> philsf: no, the kernel is solidly frozen; there's not enough time to prepare, test, upload, build, and publish a new kernel until the release
<pitti> that's why I mentioned "needs to become an SRU now"
<philsf> pitti, I figured. thanks for the clarification
<tkamppeter> pitti, hi
<fta> pitti, hi, when there's a problem while unpacking a deb, does apport trigger the corresponding package hooks?
<fta> pitti, wrt bug 654782
<ubottu> Launchpad bug 654782 in chromium-browser (Ubuntu) "package chromium-browser 7.0.540.0~svn20100930r61020-0ubuntu1~ucd1~lucid failed to install/upgrade: lettura breve in buffer_copy (dpkg-deb backend su "./usr/share/doc/chromium-browser/copyright")" [Undecided,Incomplete] https://launchpad.net/bugs/654782
<pitti> fta: it sohuld, yes
<fta> pitti, so i guess i should tweak my hooks to prevent that error, right?
<seb128> fta, there quite some bugs similar to this one
<fta> seb128, oh, really? i should dupe this one then
<pitti> fta: looks like the apport hooks did run, why?
<pitti> fta: but yes, this seems like a common problem, not specific to chromium
<seb128> fta, could be due to disk running out of space
<seb128> bug #108837
<ubottu> Launchpad bug 108837 in dpkg (Ubuntu) "confusing messages when installation fails due to ENOSPC" [Wishlist,Won't fix] https://launchpad.net/bugs/108837
<fta> pitti, i meant, i should not try to export stuff from the user chromium profile in that case
<pitti> ah, right
<fta> seb128, it's not a disk full: http://launchpadlibrarian.net/57097434/Df.txt  (unless it's short of inodes)
<penguin42> fta: That's a buffer read error not write, so isn't that where it's coming from?
<cjwatson> usually means i/o error reading from disk or something like that
<cjwatson> (reading the .deb, specifically)
<didrocks> pitti: just back on bug #642792, the drawback is that now my SysReq key (which is Fn + printscreen) on my laptop is no longer working. I was asking myself when I had to use it why I cDouldn'tâ¦
<ubottu> Launchpad bug 642792 in metacity (Ubuntu Maverick) "ALT+PrtSc not recognised: breaks built-in screenshot function" [High,Confirmed] https://launchpad.net/bugs/642792
<wathek> jello all
<wathek> hello all
<wathek> is it possible to make xorg work with my multitouch table using TUIO ? like in this http://www.tuio.org/images/diagram.png ?
<vish> cjwatson: hi, could you have a look at Bug #653259 ?  it causes problems in a few apps, is there a reason ubiquity does not append the .utf8 ?
<ubottu> Launchpad bug 653259 in ubiquity (Ubuntu) "Choosing India as location sets locale as en_IN and not en_IN.utf8" [Undecided,New] https://launchpad.net/bugs/653259
<cjwatson> $ grep en_IN /usr/share/i18n/SUPPORTED
<cjwatson> en_IN UTF-8
<cjwatson> ubiquity is correct, the apps are wrong
<cjwatson> compare:
<cjwatson> $ grep en_GB /usr/share/i18n/SUPPORTED
<cjwatson> en_GB.UTF-8 UTF-8
<vish> cjwatson: i'm not sure which is right.. but it was causing problems in gwibber which was fixed.. but likely there maybe other apps not factoring this
<cjwatson> the apps are wrong and need to be fixed.  there are interfaces available for this
<cjwatson> sorry, it's that simple I'm afraid
<vish> cjwatson: nah, np. if it is intended then could you close the bug with a comment?
<cjwatson> already done
<vish> thx.
<cjwatson> vish: BTW, I have experience implementing this on the application side and am happy to advise anyone who is confused about it
<vish> cjwatson: cool! will direct any /confused/ folks to you, if i notice similar bugs.
<cjwatson> the background is that .UTF-8 was added to locale names purely in order to distinguish them from legacy non-Unicode locales
<cjwatson> the POSIX specification is absolutely clear that locale names are opaque and applications aren't allowed to try to interpret them
 * vish nods..
<cjwatson> now, in some cases you actually have to - OS installers certainly need to know a certain amount about the OS, sometimes you need to try to work out the language as well rather than leaving it to gettext, etc.
<cjwatson> but if you're doing anything like that then you're skating along the edges of what's allowed and you need to make sure that it works with all valid locales
<vish> k
<kenvandine> cjwatson, makes sense, i wasn't sure where the bug really was and the code in gwibber that it caused a problem for was actually useless :)
<cjwatson> sometimes the way :)
<kenvandine> cjwatson, the thing that really complained was python, locale.setlocale wouldn't set the locale back to what it was previously set at
<kenvandine> error was the encoding was wrong
<kenvandine> that useless code hitting the exception in setlocale, was preventing messages from getting parsed... nasty bug
<cjwatson> that sounds like a different bug.  locale.setlocale works fine with en_IN
<kenvandine> it does, sort of
<kenvandine> if you do loc = locale.getlocale(locale.LC_TIME)
<kenvandine> and then locale.setlocale(locale.LC_TIME, loc)
<kenvandine> it blows up
<kenvandine> something like that, typing from memory
<cjwatson> oh wow, that's totally a python bug
<cjwatson> >>> loc
<cjwatson> ('en_IN', 'ISO8859-1')
<kenvandine> i think the exception was that the encoding wasn't valid for the locale
<kenvandine> something along those lines
 * kenvandine doesn't know enough about locales
<cjwatson> the locale module is just wrong
 * kenvandine moves the bug there
<kenvandine> if i choose en_IN from gdm, it works fine
<cjwatson> the odd bit is that it actually does use nl_langinfo
<kenvandine> but it sets the encoding to UTF-8
<cjwatson> just not in the right place
<cjwatson> (it uses it in getpreferredencoding)
<cjwatson> still buggy in python3
<kenvandine> cjwatson, since you clearly know WAY more about this than I, care to comment on the bug?
<cjwatson> subscribe me to whichever bug it is and I'll have a look tomorrow
<kenvandine> thx
<maxb> james_w: Could you requeue_package deja-dup? It just unexpectedly succeeded locally
<YokoZar> Someone approve my ia32-libs upload so I can do a ritualistic dance
<ari-tczew> SpamapS: ping
<SpamapS> ari-tczew: pong? wassup
<ari-tczew> SpamapS: I've commented your patch for drupal (@bzr). What do you think about apply patch to older releases?
<SpamapS> ari-tczew: I think it would be worthy of a Lucid SRU.. maybe Hardy.
<ari-tczew> SpamapS: why just that?
<SpamapS> ari-tczew: Oh, it could probably be SRU'd to all the others, true. ;)
<ari-tczew> SpamapS: cool! do you planning prepare patches for SRUs?
<SpamapS> ari-tczew: I usually wait until the fix makes it into the current dev release before nominating for SRU's
<ari-tczew> SpamapS: good point, true. :)
<kees> slangasek: my /etc/pam.d/sudo lists pam_limits.so as "required", but doesn't seem to work. i.e. when I sudo, I lose all the settings from limits.conf. have you run into anything like that?
<slangasek> kees: sudo'ing to root?  '*' limits don't apply to root
<kees> oh. heh
<kees> dur
<ogra_ac> crimsun, you around ?
<ogra_ac> crimsun, i'm looking for info where and how /usr/share/alsa/init/00main is used in the initalization process, it appears that only alsactl init seems to actually use it (see LP: #637947)
<myrkraverk> pitti% Are you there by any chance?
<\sh> myrkraverk: hopefully is went to bed ;)
<\sh> s/is/he/
<myrkraverk> \sh% Ah.
<ajmitch> \sh: aren't you in the same timezone? :)
<\sh> ajmitch: yes...but I just finished with an SSL update rollout during the evening hours
 * ajmitch hopes it went well
<\sh> ajmitch: yes..and it went fast..it took only 20 minutes for 50 servers ;)
<\sh> 5 mins for the linux machines with puppet + terminator , and 15 mins for the windows crap
<SpamapS> wow.. this maintainer script is doing all these crazy things with conffiles and has one comment "Prepare to move a conffile without triggering a dpkg question"
#ubuntu-devel 2010-10-06
<SpamapS> ScottK: around?
<ScottK> SpamapS: Sort of
<ScottK> hyperair: No.
<hyperair> ScottK: nevermind, didrocks has uploaded it already =)
<hyperair> thanks anyway
<Rotund> can someone help me with packaging?  I want to build an updated package, but I don't understand all of this
<Rotund> my debian folder has some .debdiff files in it
<SpamapS> ScottK: I was looking for some clarification on the prerm script in mail-stack-delivery
<ScottK> SpamapS: You realize I did that month's ago, right?
<ScottK> It's nearly 1AM here, so I'm not likely to be very useful.
<ScottK> I'm happy to take a shot at it, but ivoks-afk is probably a more likely victim.
<SpamapS> ScottK: hah, understood. ;)
<SpamapS> ScottK: among other things, I'm trying to figure out why it moves just one file from /var/backups/dovecot-postfix and then rmdir's that dir without checking to see if it is empty.
<SpamapS> ScottK: there's definitely something going wrong out there..  https://bugs.launchpad.net/ubuntu/+source/dovecot/+bug/653362
<ubottu> Launchpad bug 653362 in dovecot (Ubuntu Maverick) "package mail-stack-delivery 1:1.2.12-1ubuntu7 failed to install/upgrade: subprocess new pre-installation script returned error exit status 1" [High,Confirmed]
<ScottK> I vaguely recall believing that no other content in there mattered.  It may be though that I messed up and thought I'd removed it all and was wrong.
<ScottK> Of course rmdir on a non-empty directory won't be very satisfying.
<SpamapS> ScottK: I think, but I'm not sure, that people are only having problems if they started on an older version of dovecot-postfix
<ScottK> If you don't get better information, I'd make sure all the contents are moved.
<SpamapS> I'm doing a release upgrade from karmic -> lucid -> maverick to test this theory
<SpamapS> as yet none of the people reporting have provided any listings of /etc/dovecot that might help me understand why they'd get permission denied errors. :-P
<SpamapS> ScottK: it goes deeper than the backups dir.. but that particular bit was rather confusing.
<SpamapS> ScottK: with all due respect, the lack of comments is maddening. ;)
<pitti> Good morning
<pitti> myrkraverk: hello
<SpamapS> hmm.. how does dpkg determine that a conffile has changed? It seems to be broken in the dovecot-postfix/mail-stack-delivery packages .. they always thing things changed...
<SpamapS> s/thing /think /
<SpamapS> This should really be uploaded before maverick's isos are spun, if at all possible. Anybody care to sponsor it?  -- https://code.launchpad.net/~clint-fewbar/ubuntu/maverick/dovecot/karmic2lucid2maverick-upgrade-fix/+merge/37707
<dholbach> good morning
<mvo> SpamapS: let me have a look
<SpamapS> mvo: thanks! :)
<SpamapS> I can't believe I stared at that code all day and didn't notice the lack of []'s
<mvo> SpamapS: shell can do this to people ;)
<mvo> SpamapS: looks good, uploading now
<SpamapS> mvo: syntax checking is for wusses right? ;)
<SpamapS> mvo: very much appreciated!
<mvo> SpamapS: yw :)
<SpamapS> woot, the last in the server-mrs tag.. https://bugs.launchpad.net/ubuntu/+source/dovecot/+bugs?field.tag=server-mrs
<SpamapS> oh wait, thats just for dovecot.. darn.. still 3 others.
<smb> cjwatson,  PCI: allocate space top-down, not bottom-up
<robbiew> pitti: I see you are working on bug 648414 :)
<ubottu> Launchpad bug 648414 in upower (Ubuntu Maverick) "upowerd assert failure: *** glibc detected *** /usr/lib/upower/upowerd: double free or corruption (out): 0x00d13ec0 ***" [Critical,In progress] https://launchpad.net/bugs/648414
<pitti> robbiew: I just started to look at it
<pitti> robbiew: it was marked oem-priority yesterday, and krafty asked about it
<robbiew> I'm thinking maverick-updates given the crash isn't catastrophic
<smb> https://bugzilla.kernel.org/show_bug.cgi?id=16228
<ubottu> Error: Could not parse XML returned by bugzilla.kernel.org: HTTP Error 500: Internal Server Error (http://bugzilla.kernel.org/xml.cgi?id=16228)
<smb> cjwatson, ^
<pitti> robbiew: yes, it only crashes when there's a policykit error, but this should usually work
<pitti> robbiew: and it auto-respawns at the next request
<pitti> but from the stack trace it's relatively clear what happened
 * pitti hugs apport
<robbiew> :)
<robbiew> cool
<robbiew> pitti: is it actually a "Critical" bug?
<robbiew> seems more like a High
<pitti> I agree
 * pitti updates
<pitti> done
<robbiew> pitti: thank you sir!
<mvo> pitti: I remember we talked about b43-fwcutter and jockey, it appears its suggesting it for chips that don't work and then the ostinst fails (e.g. bug #655485). I would rather make this a message instead of a error
<ubottu> Launchpad bug 655485 in b43-fwcutter (Ubuntu) "package firmware-b43legacy-installer 4.178.10.4-4 failed to install/upgrade: el subproceso script post-installation instalado devolviÃ³ el cÃ³digo de salida de error 1" [Undecided,New] https://launchpad.net/bugs/655485
<pitti> mvo: yes, it's evil that the package fails completely
<tkamppeter> pitti, hi
<pitti> hello tkamppeter, how are you?
<tkamppeter> pitti, fine, it is about bug 160092.
<ubottu> Launchpad bug 160092 in cups (Ubuntu) "apparmor rules break filters in /usr/local" [Undecided,New] https://launchpad.net/bugs/160092
<tkamppeter> pitti, /etc/apparmor.d/usr.sbin.cupsd has only
<tkamppeter> /usr/local/share/** r
<tkamppeter> for /usr/local. Should it not have
<tkamppeter> /usr/local/** rix
<tkamppeter> as it has for /opt? This way arbitrary third-party drivers will work, as they do now when they are in /opt.
<pitti> tkamppeter: that would mean that it could run arbitrary code in /usr/local/bin, too, though
<myrkraverk> pitti% I wanted to ask, can I instuall and run the your PG9 packages along with my current 8.4?
<pitti> myrkraverk: yes, that'll work fine
<pitti> myrkraverk: see /usr/share/doc/postgresql-8.4/README.Debian.gz (or doc/postgresql-common/...)
<myrkraverk> pitti% No extra configuration overhead, just "plug&play" ? ;)
<pitti> myrkraverk: you can run both in parallel
<myrkraverk> Great.
<tkamppeter> pitti, OK, but in /opt also arbitrary code can be executed.
<pitti> tkamppeter: right, we can't assume anything about the structure there
<pitti> tkamppeter: /usr/local/lib/cups/** rix should get us a long way, though?
<pitti> tkamppeter: ah, I remember that one; I was waiting for kern.log for ages, now we've got one
<tkamppeter> pitti, yes this would already help.
<pitti> tkamppeter: I'll commit that to trunk.
<tkamppeter> pitti, at least CUPS-Raster style filters work then and most third-party filters are of that style. Perhaps one could open the rest of /usr/local at least for reading, so that the filter works if it has auxiliary files, libraries, ...
<pitti> tkamppeter: committed that, too
<tkamppeter> pitti, OK, thanks.
<artnay> how does one reopen a bug on launchpad? I just witnessed something marked as "Fix released" making my computer unusable with up-to-date Maverick. see https://bugs.launchpad.net/ubuntu/+source/apt-xapian-index/+bug/363695
<ubottu> Launchpad bug 363695 in apt-xapian-index (Ubuntu) "update-apt-xapian-index uses too much CPU" [Undecided,Fix released]
<artnay> well, #64 makes it pretty clear
<cjwatson> artnay: it's generally best to file a new bug, IME as a developer responding to them
<cjwatson> artnay: all too often people think it's a reopening of a previous bug, and it's actually a new cause with similar symptoms - it's a lot less confusing when you have a new bug to work with
<cjwatson> plus it's easier to mark bugs as duplicates than to split them up
<kklimonda> jcastro: ping
<Goodi> Ehlo, I did the 10.04 -> 10.10 upgrade and it went fairly well, except for the deskbar-applet & libdeskbar-tracker  (Bug #654392 )
<ubottu> Launchpad bug 654392 in deskbar-applet (Ubuntu) "package deskbar-applet 2.30.0-0ubuntu1 failed to install/upgrade: trying to overwrite directory '/usr/lib/deskbar-applet/deskbar-applet' in package libdeskbar-tracker 0.6.95-1ubuntu6 with nondirectory" [Undecided,New] https://launchpad.net/bugs/654392
<Goodi> Some other oddities were mainly on the way the update-manager prompted for the "configuration file changes"
<Goodi> On terminal you can see the "Y/n/D(iff)/.." questions but the popup won't still offer anything else but keep/replace
<Goodi> except on Samba... Why is samba-configuration handled differently (?)
<Goodi> Anyway.. so far it's looking pretty good. (Except for the deskbar-applet, which I hope gets fixed before the release)
<robbiew> mvo: are you the "guy" who can disable kernel-oops before we release?
<pitti> robbiew: we already did
<pitti> robbiew: https://edge.launchpad.net/ubuntu/+source/kerneloops/0.12+git20090217-1ubuntu9
<robbiew> pitti: cool...I thought so, but wanted to be sure ;)
<jibel> Goodi, I can reproduce during an upgrade from Lucid, thank you.
<Goodi> ok.
<Goodi> Btw. when installing a new system the installer (or OEM-configurator) prompts for a new user. Is there any way to set the UID for the user? (hidden parameters, preseed-magick, etc)?
<mvo> jibel: are you on it already or should I fix it? it appears that libdeskbar-tracker was removed from maverick, so the fix is simple (just conflict)
<jibel> mvo, seb128 is trying to find a volunteer
<seb128> bilalakhtar claimed it
<seb128> bilalakhtar, ^ what mvo said
<bilalakhtar> ah
<bilalakhtar> mvo: yes I am doing it
<mvo> excellent
<mvo> bilalakhtar: just ping me when its ready, I'm happy to sponsor
<bilalakhtar> mvo: I have upload rights :)
<slashbeast> can anyone, please, help me found source for linux-alsa-driver-modules-2.6.35 from ubuntu audio dev team?
<mvo> bilalakhtar: cool, even better \o/
<cjwatson> Goodi: passwd/user-uid=1002 (or whatever)
<cjwatson> (or 'd-i passwd/user-uid string 1002')
<seb128> cjwatson, ev: bug #651064, who would be likely to work on that issue?
<ubottu> Launchpad bug 651064 in ubiquity (Ubuntu) "Missing pixmap for Australia/Eucla timezone" [Undecided,New] https://launchpad.net/bugs/651064
<seb128> cjwatson, ev: design team?
<seb128> cjwatson, ev: it's not a maverick target bug now but I would make the right people know about it
<ev> seb128: traditionally this work was done by kwwii
<ev> seb128: probably best to send to Iain and CC me in on it.
<seb128> ok, so design, thanks
<ev> indeed
<ev> thanks
<brettalton> I've been trying to get some numbers on what the most popular programming languages are in Ubuntu.
<brettalton> GTK, Linux and some GNOME apps are written in C
<brettalton> A lot of others use C++ and Python
<brettalton> But some also use Mono/C#
<brettalton> Are there any numbers on which are the most widely used?
<jdstrand> cjwatson: hi! when you have a moment, would you mind accepting the email to the TB from fta regarding chromium? (sorry to bother you but iirc, kees couldn't moderate it for me last time)
<cjwatson> brettalton: I'm not aware of any numbers
<cjwatson> jdstrand: done
<jdstrand> cjwatson: thanks :)
<brettalton> cjwatson: figured, but if I'm to start a new application, which potentially could be a pretty large project, I'd like to have a talk around what language to use and why
<cjwatson> brettalton: sloccount might be able to do it though you'd need a local mirror
<cjwatson> brettalton: I think I'd be inclined to look for the right tool for the job rather than pure popularity (maybe excluding really obscure ones)
<cjwatson> you might be influenced by library availability
<brettalton> cjwatson: exactly, but I'd like to know what most programmers are using, and then find out why
<brettalton> Most are using Python due to it's binding with GTK no?
<cjwatson> I think that's jumping to conclusions
<cjwatson> it may be true for a good chunk of the code written directly for Ubuntu, but there's plenty of code that uses Python and never goes near the desktop (or that uses Qt)
<OdyX> brettalton: you should maybe consider the language you are most comfortable with
<brettalton> cjwatson: very true again. But if I'm looking to develop a GTK-based app, what choices do I have in terms of languages? I have a few right? GTK as bindings for a lot of languages, such as C, C++, Python, Haskell, etc.
<brettalton> But I have a web background and know JavaScript very well, so why not Seed?
<brettalton> What I'm getting at is that I'm overwhelmed with the choices I have and am having a hard time narrowing them down
<brettalton> OdyX: what I'm most comfortable with is PHP and JavaScript, but also know some C# and C but I have no experience with GTK
<cjwatson> brettalton: I think it is fair to say that (a) many languages are indeed in use, and the GTK community in general is mostly divided between C C++ Python Vala Mono, or something like that; (b) Ubuntu generally recommends Python to application developers
<brettalton> cjwatson: okay thank you, that was my assumption
<brettalton> I'm really interested in that SLOCCount program. I think that'd be interesting if Launchpad released some statistics using that program
<brettalton> cjwatson: so thank you
<OdyX> brettalton: Ohloh has some stats if you want.
<cjwatson> I don't know how well sloccount is maintained; I heard of it a while back
<brettalton> OdyX: on the entire Ubuntu project though?
<OdyX> brettalton: on the complete FLOSS ecosystem. :->
<brettalton> OdyX: do you have a link? I can't find it
<OdyX> brettalton: did you Google it ?
<OdyX> http://www.ohloh.net/languages/compare <-
<jibel> cjwatson, did you saw my update on bug 653134  ?
<brettalton> I was looking at: http://www.ohloh.net/p/ubuntu/analyses/latest
<ubottu> Launchpad bug 653134 in lupin (Ubuntu Maverick) "Can't boot Ubuntu after an upgrade from 10.04.1 to 10.10" [High,Triaged] https://launchpad.net/bugs/653134
<cjwatson> jibel: I doubt there is anything else I can do now
<cjwatson> loopback loop0 /ubuntu/disks/root.disk <- don't see how it could boot at all without that
<cjwatson> lang=fr/lang=en> hmm
<cjwatson> I guess I could try a non-English installation, since that sounds like a serious contributor to the problem
 * cjwatson hates life
<jibel> cjwatson, I must admit that I don't understand either, I commented the lines one by one until I've found the one that's blocking the boot.
<cjwatson> wubi upgrades have never worked right before.  it would have been nice to say that they worked this time, but I have a hard time considering it a blocker
<cjwatson> (this is not to say I don't appreciate efforts to get them to boot ...)
<cjwatson> er, to work
<cjwatson> wubi really needs a maintainer who isn't me.  Agostino has been mostly lacking in time
<cjwatson> I'm only doing it by default
<Goodi> wubi 10.04 -> 10.10beta worked fine. Something broke my wubi install  on rc
<cjwatson> Goodi: *blink* for nearly everyone else it was broken to beta
<cjwatson> bug 581760 hosed lots of people
<ubottu> Launchpad bug 581760 in grub2 (Ubuntu Lucid) "[Wubi] when updating it advices to install grub on all partitions" [High,Fix committed] https://launchpad.net/bugs/581760
<cjwatson> also bug 617715 and bug 653134
<ubottu> Launchpad bug 617715 in lupin (Ubuntu Maverick) "10.10 Upgrade goes to Grub Prompt" [High,Fix released] https://launchpad.net/bugs/617715
<ubottu> Launchpad bug 653134 in lupin (Ubuntu Maverick) "Can't boot Ubuntu after an upgrade from 10.04.1 to 10.10" [High,Triaged] https://launchpad.net/bugs/653134
<cjwatson> in fact, without the fix for 617715 which wasn't in beta, I can't see how an upgrade to beta could possibly have worked
<cjwatson> I think you must have upgraded to slightly post-beta
<Goodi> cjwatson-  True.. I was bit worried on upgrading wubi to beta, but then I noticed all the warnings *after* I started the upgrade :)
<Goodi> Anyway the beta upgrade went nicely and I was able to use it for a while.. Last weekend I noticed that it didn't boot anymore
<Goodi> cjwatson-  that yes, that was quite late in beta. Probably something like week before rc
<tkamppeter> apachelogger, hi
<brettalton> cjwatson: is there a branch for the entire Ubuntu project? something like: https://code.launchpad.net/~ubuntu-branches/ubuntu/maverick
<beuno> brettalton, there is not
<brettalton> beuno: okay, I was just trying to get ohloh to do a code analysis of Ubuntu
<brettalton> and trying to write a new enlistment: https://www.ohloh.net/p/ubuntu/enlistments
<tumbleweed> brettalton: ohloh's bzr support isn't great, I've given up on them scanning my bzr branches
<brettalton> tumbleweed: ahh okay, ya I heard such instances, I was just curious
<tumbleweed> brettalton: it just stops working every now and then andyou have to get an admin to re-enable it
<mvo> tseliot: do you mind if I make patch a real dependency of dkms instead of a recommends? it used in the script and e.g. #653899 is caused by it missing
<tseliot> mvo: in what package?
<mvo> tseliot: dkms itself
<mvo> tseliot: the failure is in bcmwl
<tseliot> mvo: sorry, I misread your message. I think it should be fine. You might want to ask superm1 too though
<mvo> superm1: hello, do you mind if I make patch a real dependency for dkms instead of a recommends? dkms builds with patch may fail otherwise
<mvo> superm1: hm, the "make|build-essential|dpkg-dev" is also a little bit odd, makebe "make, build-essential|dpkg-dev" instead?
<mvo> superm1: hm, the last comment is not that important, it looks like the issue I was looking at is really just caused by a missing "patch"
<superm1> mvo, i've been previously saying individual packages using dkms that use the functionality of patch should depend on 'patch', but this keeps cropping up every so often
<superm1> so if it's gonna clean up this problem from happening from time to time, it's fine by me
<mvo> superm1: great, thanks. I will do a upload then
<dpm> hey all, could someone give me a hand? I'm trying to calculate translation stats for unity. I'd do it the same way as in Ubuntu: considering only the source packages from the default installation from the seeds. Could someone tell me which seeds I'd need to consider for unity?
<pitti> dpm: presumably http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/netbook.maverick/ ?
<pitti> dpm: (that's the entire netbook, which is what you need, I suppose?)
<dpm> pitti, yeah
<dpm> pitti, I usually take them from the germinate output. For Ubuntu I use ('boot', 'required', 'minimal', 'standard', 'desktop-common', 'desktop'), but I'm not sure which ones to use from http://people.canonical.com/~ubuntu-archive/germinate-output/netbook.maverick/
<pitti> dpm: should be http://people.canonical.com/~ubuntu-archive/germinate-output/netbook.maverick/netbook
<dpm> pitti, ah, cool, so that would represent all packages installed on a unity default installation?
<pitti> dpm: right
<pitti> dpm: hm, seems not quite -- there's a lot of stuff missing, such as xorg
<cjwatson> you'll still need desktop-common
<cjwatson> and all the stuff below
<cjwatson> dpm's original list is correct, just substitute 'netbook' for 'desktop'
<dpm> ok awesome, thanks cjwatson and pitti!
<apachelogger> tkamppeter: ahoy ahoy
<tseliot> superm1: any opinions on bug 655275 ? The patch seems to help here
<ubottu> Launchpad bug 655275 in dkms (Ubuntu) "allow 32-bit module build on 64-bit host" [Undecided,New] https://launchpad.net/bugs/655275
<mvo> pitti: re bug https://bugs.edge.launchpad.net/ubuntu/+bug/655111 - do you mind if I add code to jockeys b43 handler to check pci ids and select the right package?
<ubottu> Launchpad bug 655111 in jockey (Ubuntu) ""Additional drivers" proposes b43, fails w/o useful message, "Not supported low-power chip"" [High,Confirmed]
<pitti> mvo: no, that'd be great of course
<pitti> mvo: alternatively we could just disable it entirely; wl should work much better
<pitti> for me, b43 just freezes the computer
<mvo> pitti: disabling is fine with me
<mvo> pitti: is https://code.edge.launchpad.net/~mvo/jockey/b43-disabled sufficient or would you prefer that the entire file goes away?
<ogra_ac> hmpf, where is Keybuk when i need him
<superm1> tseliot, i think the patch is actually not correct though, it certainly would break rhel
<superm1> which can support i386 and i686
<tseliot> superm1: are you referring to the kernel?
<superm1> yeah
<tseliot> superm1: oh. Do you have better ideas?
<tseliot> superm1: or maybe we can check the distro
<tseliot> as we do in the template
<superm1> well if it's passed in as argument to dkms already from dkms_common.postinst, that should be carried through the code i think
<tseliot> superm1: the point is that dkms_common.postinst does pass it to dkms build
<superm1> right, so that value that dkms_common.postinst passed is what should be sed'ed into place, not a case statement hardcoding to i386
<tseliot> superm1: aah, so you're saying that we should pass i386 when we call the template. Good point
<pitti> mvo: (just a quick drive-by) yes, that's fine; that, or don't install the file at all
<pitti> mvo: but please fix the changelog to "UNRELEASED" and dch -r/debcommit -r separately when you merge into the ubuntu branch
<pitti> mvo: thanks!
 * pitti waves good night, Taekwondo time
<achiang> superm1: please see my latest update to that bug. we definitely do *not* break RHEL
<achiang> superm1: and your other suggestion of passing along whatever dkms_common.postinst detects won't work. the kernel Makefile doesn't understand "i686" as a valid argument for ARCH
<lep-work> hello, I'm trying to find out where I can get the configure strings used to build the software in the repos ... ie, what compile time options the package maintainer passed when he built a particular package
<smoser> anyone know why http://changelogs.ubuntu.com/changelogs/pool//main/l/lazr.restfulclient/lazr.restfulclient_0.9.11-1ubuntu1/ does not have a changelog ?
<ari-tczew> smoser: https://launchpad.net/ubuntu/+source/lazr.restfulclient/0.9.11-1ubuntu1
<smoser> ari-tczew, what are you telling me?
<ari-tczew> smoser: I gave you changelog
<smoser> well, unless i'm missing something, the i only see a diff that contains of a changelog versus the previous version
<smoser> i'm sort of SOL in the case that i need more than that (well, without a lot more work)
<smoser> but in general, i was trying to understand why some packages dont have changelogs on changelogs.ubuntu.com
<lep-work> could anyone point me in the right direction...I'm looking for the compile time options passed to bins in the ubuntu repositores...ie, the ./configure lines used to build the packages
<smoser> i think the answer my above question is that those releases were in -security
<smoser> lep-work, well, nothing magical/terribly standardized. but its all controlled via debian/rules in the source package.
<jcastro> other-kernel-n-misc is winning for best UDS session title so far.
<lep-work> smoser, thank you...that's exactly what I was looking for
<lep-work> :}
<coz_> hey guys.. I was just reading the mailing list where it is suggested that png and svg files along with gz files be rencoded to save space... what is the possiblitly of just creating  a "minimal live cd"  any files needed diring live session can be quickly downloaded an cached  and of course during install pricedure ,, they would be downloaded and installed/
<coz_> during not diring
<cwillu> what's the generic tool to create a new patch for any given unpacked source package?
<lep-work> diff?
<lep-work> is that what you mean?
<lep-work> diff creates patches
<penguin42> debdiff?
<penguin42> hmm no, that's just summary?
<cwillu> I'm remembering a tool that uses dpatch or quilt or whatever as needed
<cwillu> can't remember the name
<micahg> cwillu: edit-patch
<cwillu> that's the one
<cwillu> thanks
<ebroder_> In one of his e-mails, pitti mentioned bypassing GDM and running a user session directly on single-user machines. Anybody know how I would do that?
<TheMuso> ebroder_: Turn on auto login?
<ebroder_> TheMuso: Right, that's what I'm doing now. But gdm has disk/memory/boot time/etc overhead
<TheMuso> No idea then.
#ubuntu-devel 2010-10-07
<RAOF> ebroder_: You can manually start X and run gnome-session in it?
<penguin42> what happens to all the session stuff if you do that?
<RAOF> Oh, yeah.  That's right.
<RAOF> You want to run /etc/X11/Xsession or somesuch.
 * freeflying 
<RAOF> Oh, oh!  Can someone else reproduce bug #656037?  If so, this should be a release blocker.
<ubottu> Launchpad bug 656037 in ubiquity (Ubuntu) "Software sources not selected" [High,Confirmed] https://launchpad.net/bugs/656037
<bladernr> RAOF:  I can try in a few... gotta build a usb key for netbook first
<bladernr> I really should stop soon... I've been at this since 0900 :/
<RAOF> That needs to be qualified with a timezone to mean anything; I've been at this since 0830 :)
<bladernr> EDT
<bladernr> heh
<bladernr> so... roughly 15 hours
<bladernr> well about 12 hours (dinner and lunch break)
<bladernr> FWIW, I've got a 32bit Kubuntu install done w/ network and it looks like all the repos are present (main, universe and multivers + restricted)
<ogra_ac> -7join #ubuntu-release
<ogra_ac> hmpf
<RAOF> Heh.
<cdbs> How long after the release will natty open?
<micahg> cdbs: usually one to 2 weeks
<cdbs> micahg: ah, thanks
<RAOF> cdbs: Depends on how many electric shocks you apply to the foundations team! :)
<NCommander> pitti: ping, I need some help with apport-retracer when you have some time
<bladernr> RAOF:  I confirm... sources.list on netbook is hosed.  Though only on netbook images, it seems
<RAOF> bladernr: Yeah.  I think I've identified the problem, and I've brought it to the attention of ubuntu-release and the ubiquity guys.
<bladernr> excellent...
<bladernr> now I shall pass out for a few hours...
<bladernr> cheers
<dholbach> Good Morning!
<soren> Mr. Holbach!
 * soren hugs dholbach 
 * dholbach hugs soren back
<dholbach> man! how are you doing?
<soren> Great, but busy :)
<dholbach> :-)
<soren> Trying to get a release out the door and celebrating my daughter's two-year birthday at the same time.
<dholbach> woohoooo!
<soren> On that note, I have to go wake her up. She's celebrating by sleeping in, apparently.
<dholbach> have a great party :)
<soren> Ta ;)
<pitti> Good morning
<pitti> RAOF: doesn't startx do that?
<RAOF> pitti: Not last time I tried.
<RAOF> Or, at least, not to my rememberance :)
<pitti> ebroder: gdm doesn't have that much overhead, but if you want to start it directly, then something like "ck-launch-session startx" ought to do
<pitti> NCommander: what's  up?
<RAOF> Hm.  Why doesn't this live session have a shutdown option?
<jibel> mvo, Hi, could you have a look at bug 639933, it seems to affect only kubuntu upgrades.
<ubottu> Launchpad bug 639933 in x11-xkb-utils (Ubuntu) "10.04 -> 10.10beta: could not install the upgrades - Couldn't configure pre-depend x11-common for x11-xkb-utils, probably a dependency cycle." [High,Triaged] https://launchpad.net/bugs/639933
<mvo> jibel: sure
<jibel> mvo, thanks
<planetcall|web> does ubuntu need dotnet skills?
<Laney> some applications are based on mono, if that is what you are asking
<Laney> These tend to be written in C#
<Tm_T> Laney: he is gone already (:
<Laney> oh
<Laney> oh well
<NCommander> pitti: reinstalled apport-retracer on kakadu, I try running crash digger but it just hanged when it starts retracing, and doesn't seem to be calling apport-retrace
<pitti> NCommander: I suppose it needs some firewall rules
<pitti> NCommander: there were some network adjustments necessary on ronne, for working around bug 620458
<ubottu> Launchpad bug 620458 in Launchpad Bugs "cannot access attachments of private bugs any more" [High,Triaged] https://launchpad.net/bugs/620458
<pitti> NCommander: but I don't know about the details unfortunately (I was on holiday)
<NCommander> pitti: shouldn't that just error out and not hang?
<NCommander> Or is that a bug in the retracer?
<pitti> NCommander: TCP timeouts somewhere?
<NCommander> pitti: 10/07/10 04:12:27: retracing #625408
<NCommander> That was about 5 hours ago ...
<NCommander> Something should have timed out by now :-)
<pitti> ok, then it seems somethign deep in launchpadlib/lazr/etc. should time out
<pitti> but anyway, I think the reason are the firewall settings
<pitti> NCommander: you could attach strace to it and see what it's hanging on?
<NCommander> pitti: I posted IS, and will wait to see if that just magically resolves it (and may just throw the retracer up on 127.0.0.1 to see if its actually firewall related)
<NCommander> pitti: will do, though probably not tonight.
<seb128> you can try retracing a public bug to see if it works
<seb128> without the firewall tweak the retracers were crashing on timeout after minute or so
<wgrant> FWIW, we have a proper private attachment which is awaiting testing.
<ScottK-droid> seb128: Would you please review cairo-dock/plugins in the queue? Go ahead and accept them if you think they are OK.
<seb128> ScottK-droid, ok
<ScottK-droid> Thanks.
<seb128> yw
<chrisccoulson> lamont, is there any way i can debug processes which hang in the buildd's?
<chrisccoulson> i had a firefox build hang last night: http://tinyurl.com/3yz6gen
<chrisccoulson> and i'm not sure what to do, it's not reproducible locally
<lamont> chrisccoulson: I don't even have any way to reach into a ppa builder and see what it's doing, other than via the web UI on launchpad
<chrisccoulson> hmmm, that's a bit of a pain
<lamont> if it's hanging on the archive buildds, poke someone to look at it during that 2.5 hour window is about the best answer
<lamont> chrisccoulson: definitely a pain
<chrisccoulson> i was hoping that i could resolve these issues before i upload to the main archive next cycle :/
<chrisccoulson> lamont, there's not anything running on port 8888 in the PPA builders is there?
<lamont> prolly not
<smb> Who would be currently in charge for network manager again?
<pitti> smb: Mathieu (https://launchpad.net/~mathieu-tl)
<smb> pitti, Ok, thanks
<pitti> mdeslaur: so, postgresql-8.4/maverick couldn't be synced (too late); want me to provide a maverick-security upload, or do you already have one in the pipe? (it's just the Debian sid package with an adapted version number, and perhaps a bug ref in the changelog)
<mdeslaur> pitti: I'm actually publishing the dapper-lucid ones as we speak :(
<mdeslaur> pitti: could you create a maverick-security package, and I'll release it next week?
<pitti> mdeslaur: ah, so we'll do a followup USN for maverick?
<mdeslaur> pitti: yeah, I'll release a -2
<pitti> mdeslaur: yep, can do
<mdeslaur> pitti: cool, thanks
<pitti> mdeslaur: I guess I don't need to do it "right now", then, and "by tomorrow" is enough?
<mdeslaur> pitti: I won't publish it before tuesday anyway, so no rush
<pitti> mdeslaur: btw, should I include the orig.tar.gz into the .changes? it's the same orig.tar.gz as for karmic/lucid
<pitti> mdeslaur: but if you upload it to a PPA first, you might need it
<pitti> (uploading without one for now)
<mdeslaur> pitti: That's okay, I'll grab it from the other releases. thanks
<pitti> URL sent to the bug
<pitti> (you wouldn't have guessed it :) )
<mdeslaur> hehe
<ari-tczew> when natty will be open?
<micahg> ari-tczew: 1-2 weeks after release generally
<mdeslaur> pitti: have you run the postgresql test suite on maverick?
<dpm> hi mvo, a translator had been doing some work on the ddtp templates, and some of his translations are now gone. He's asking if the strings are now stable or if he should wait for a bit...
<mdeslaur> pitti: it's asking me for a password, which it doesn't do on previous releases...
<mdeslaur> pitti: never mind, seems I had cruft in my /var/lib/postgresql directory
<sabdfl> do we really have a 0-day ssl issue? aieeee :-)
<highvoltage> hmm, if what sabdfl say is true, then we'll probably have another rebuild
<highvoltage> and testers should probably be given some kind of heads-up that there will be a rebuild
<mdeslaur> highvoltage: no, it's been published in -security
<mdeslaur> highvoltage: no need to rebuild
<highvoltage> mdeslaur: ok
<ScottK> mdeslaur: From reading the USN, it wasn't clear to me if both issues were risk of code execution with privileges of the calling application or potentially something worse?
<mdeslaur> ScottK: only the second issue applied to Maverick, and while it's marked as a code execution, our hardening features turns it most likely into a simple denial of service
<hallyn> slangasek: cjwatson: so regarding bug #622762, does it sound like something worth having in release notes?  (about backward compatibility of cryptsetup from lucid to maverick)
<ubottu> Launchpad bug 622762 in cryptsetup "encrypted partition works in lucid, not maverick" [Undecided,Invalid] https://launchpad.net/bugs/622762
 * ScottK goes to re-read the USN.
<ebroder> Who am I supposed to talk to to get a room at UDS? Do I just book it with the hotel directly?
<ScottK> mdeslaur: Thanks.
<slangasek> hallyn: yes
<hallyn> slangasek: is there something i should do, like add a tag to the bug?
<slangasek> hallyn: open a task against the ubuntu-release-notes project
<highvoltage> https://wiki.ubuntu.com/TechnicalBoardAgenda needs an update on next meeting time.
<hallyn> slangasek: ok thx
<kees> highvoltage: I've updated the date.
<highvoltage> kees: thanks!
<kees> highvoltage: np :)
<mvo> dpm: some are gone .( why that?
<mvo> dpm: vanished packages?
<mvo> dpm: they should be stable now
<dpm> mvo, I don't know which ones exactly vanished. I'll ask the translator tomorrow. Thanks, I'll tell him now that they should be stable
<Dev^Null> Hey all I have a disk image of ubuntu 9.10 that I replicate to about 500 different machines. I am having an issue with the 70-persistent-net.rules becuaes it wants to name the nic based of the mac address while this changes with each machine. I would like to set it up to look if ATTR{operstate}=="up" then  call that car eth1 I have 2 nic's in each box and only one is ever used. how would I do this.
<kibibyte> hi
<kibibyte> why nobody fixed bug with icons disappering fom right top menu? this bug exists since 1 or more years. Only solution to it is rm -rf .gconf*  and then set desktop from scratch!#
<rmrfslash> How/where is networking started on boot in Ubuntu?
<rmrfslash> I don't see any init scripts in runlevels other than 0,6
<rmrfslash> clearly is must be started from somewhere else, I'd just like to know the best place to put an iptables-restore
<kklimonda> rmrfslash: check /etc/init/
<rmrfslash> /etc/init.d?
<kklimonda> no, /etc/init/
<kklimonda> see for example how is ufw started
<rmrfslash> woops
<rmrfslash> so I should probably put rules in user.rules
<kklimonda> if you decide to use ufw it's pretty well documented
<kklimonda> see man ufw-framework
<kklimonda> user.rules are, afair, added by the ufw itself
<kklimonda> you should edit before.rules and after.rules
<kklimonda> rmrfslash: *
<kklimonda> ech, missed ^
<rmrfslash> i c
<rmrfslash> thanks
<ScottK> barry: Would you be able to take a look at https://bugs.launchpad.net/bugs/656541 and see if the proposed patch is correct?
<ubottu> Launchpad bug 656541 in wxwidgets2.8 (Ubuntu) "cubecolordialog.py regression with patch" [Undecided,New]
<cwillu> while trying to build compiz form source, dpkg-buildpackage dies with "gtk-window-decorator.c:50: fatal error: libwnck/libwnck.h: No such file or directory"
<cwillu> this is odd, given that cwillu@dominubuntu:~/work/compiz/compiz-0.8.6$ ls -lh /usr/include/libwnck-1.0/libwnck/libwnck.h
<cwillu> -rw-r--r-- 1 root root 1.3K 2010-05-31 01:44 /usr/include/libwnck-1.0/libwnck/libwnck.h
<poolie> in that case i guess autoconf/pkg-config isn't finding the right path
<cwillu> poolie, thanks.
 * cwillu starts reading potentially relevant man pages
<cwillu> poolie, pkg-config --list-all has an entry for libwnck-1.0, which would seem correct
<cwillu> ugh, stray copy in /usr/local/ from before I knew how of dpkg-buildpackage's existence
<poolie> that'd be it
<poolie> cwillu: you might like to use sbuild or pdebuild to do your package builds isolated from your regular system
<cwillu> poolie, I use similar for my arm packages;  for my desktop stuff (incidently, how do I go about getting some of these fixes actually applied?), them breaking in this fashion is a sign that I did something wrong, and I'd rather have the symptom
<cwillu> for instance, current compiz with snapping is unusable on slower systems, as it warps the mouse pointer back to the last window move location faster than you can move it
<poolie> how do you mean getting them applied?
<poolie> best thing is to create a merge proposal on lp
<cwillu> so, first step is to actually set up a ppa or such?
<poolie> cwillu: no, you don't have to
<poolie> just put them in a bzr branch, push that to launchpad, then propose a merge
#ubuntu-devel 2010-10-08
 * away_Sgiomlairea is now away - Reason : dinner
<ion> Gee, thanks a lot for the information!
<micahg> !away | away_Sgiomlairea
<ubottu> away_Sgiomlairea: You should avoid noisy away messages and -nicks in a busy channel like #ubuntu, or other Ubuntu channels; it causes excessive scrolling which is unfair to new users. Use the command "/away <reason>" to set your client away silently.  See also Â«/msg ubottu GuidelinesÂ»
 * Sgiomlaireachd is no longer away : Gone for 2 hours 34 minutes 41 seconds
<TheMuso> !away | Sgiomlaireachd
<ubottu> Sgiomlaireachd: You should avoid noisy away messages and -nicks in a busy channel like #ubuntu, or other Ubuntu channels; it causes excessive scrolling which is unfair to new users. Use the command "/away <reason>" to set your client away silently.  See also Â«/msg ubottu GuidelinesÂ»
<poolie> TheMuso: that's at least twice today
<pitti> Good morning
<pitti> mdeslaur: yes, I did run the tests on maverick, they all succeeded
<pitti> mdeslaur: ah, good
<[newbie]> hello
<Crissi> how the graphical installer is named?
<Crissi> i found a bug into it
<pitti> ubiquity
<Crissi> ah
<Crissi> i tested the rc of maverik and install fails
<Crissi> because i cant install to the iscsi hdd
<Crissi> its not selectable
<\sh> pitti: any clue how to change the order of sys.path ? I would like to have /usr/local/lib/python<VER>/dist-packages included before /usr/lib/python...
<\sh> good morning btw
<\sh> ok, sys.path shows me that $HOME/.local/lib/python<VER>/site-packages comes before /usr/lib/python2.6, but it still imports the old version of a lib which is installed in $HOME/.local/... and /usr/lib/python2.6/... argl
<YokoZar> Is a final ia32-libs update possible (to sync it with the other libraries) ?
<pitti> \sh: hey
<pitti> YokoZar: that depends on whether that's shipped on any of the images
<pitti> i. e. xubuntu or edubuntu; probably not, but we need to check
<YokoZar> pitti: it's larger than the size of a CD, so I imagine it isn't
<pitti> YokoZar: ? ia32-libs is not that bad
<pitti> 33 MB or so
<YokoZar> err nm I'm thinking source pacakge
<pitti> the source is a hog, sure
<pitti> \sh: hm, some old .pyc files perhaps?
<pitti> \sh: did you try python -v -c 'import mymod' to see what it's doing?
<amitk> morning
<\sh> pitti: http://paste.ubuntu.com/508583/ <- this looks wrong
<\sh> it's using the pyOpenSSL version from the /usr/lib path, but not from the .local path
<dholbach> good morning!
<pitti> \sh: perhaps add a "print sys.path"?
<\sh> pitti: http://paste.ubuntu.com/508586/ <- this is wrong...$HOME/.local comes after /usr/lib/python2.6 ...
<\sh> but all easy_install.pth eggs are before...(btw...even installing under /usr/local/lib/python<ver>/dist-packages doesn't help
<\sh> hey dholbach
<dholbach> heya \sh
<\sh> pitti: I wonder if this is actually right, to set /usr/local after /usr in sys.path, while all setuptools installed modules are coming before /usr... there is (IMHO!) a mistake in setting this path
<\sh> normally someone wants to overlay the system libs in /usr/local/lib or $HOME/.local/lib/
<jibel> mvo, hey, how are things ?
<jibel> mvo, We received bug 639933 this morning again. This is affecting kubuntu users trying to upgrade to 10.10
<ubottu> Launchpad bug 639933 in x11-xkb-utils (Ubuntu) "10.04 -> 10.10beta: could not install the upgrades - Couldn't configure pre-depend x11-common for x11-xkb-utils, probably a dependency cycle." [High,Triaged] https://launchpad.net/bugs/639933
<mvo> jibel: I tried to reproduce this yesterday without success, were you be able to reproduce?
<mvo> jibel: I try again today
<jibel> mvo, no I didn't. I haven't tested hard tough. I finish some wubi testing this morning and I'll try again.
<mvo> jibel: thanks
<\sh> pitti: sys.path.insert(0,"/home/shermann/.local/lib/python2.6/site-packages/") helps to overcome the bugger now...but I think we need to fix this sys.path problem somehow
<\sh> doko: you are my python man ;) do you eventually know why $HOME/.local/lib/python<VER>/site-packages and /usr/local/lib/python<VER>/dist-packages are included in sys.path after /usr/lib/pymodules/* , while I expected that those paths are before the system paths (for overlaying python system libs with newer version)?
<doko> \sh: I didn't change anything with this. I hope /usr/lib/pymodules/* will be gone in 2.7. ask barry about it
<\sh> barry: ^^ :)
<YokoZar> pitti: I'm going to bed, but if you could please check the seeds for any use of ia32-libs and if it comes up clean just do a ./fetch-and-build and reupload it would be great
<YokoZar> or I suppose I could do that right now and you can accept/reject as you wish
<kklimonda> slangasek: hmm, have you synced python-django 1.2.3-1 or did you manage to stop it? :)
<kklimonda> slangasek: i.e should I prepare a 1.2.3-1ubuntu1 or even 1.2.3-1ubuntu0.1 or is 1.2.3-0ubuntu1 still valid
<cjwatson> Crissi: ubiquity isn't expected to support iSCSI - missing feature rather than bug
<persia> kklimonda, rmadison (from devscripts) suggests 1.2.1-1 is current (you may find this tool generally useful)
<Crissi> no
<Crissi> its a bug
<kklimonda> persia: oh, it works in the real time? :)
<Crissi> it should be possible to install on it
<cjwatson> call it what you like.  but it won't be, in 10.10
<Crissi> it can be the only one system hd
<cjwatson> sorry
<Crissi> it should
<Crissi> in 10.10
<cjwatson> it will not.  period
<persia> kklimonda, My understanding is that it hits a CGI that queries current status: might be old by a publisher run or so.
<cjwatson> far too late to be adding that kind of thing to ubiquity
<Crissi> hrrr
<Crissi> no
<cjwatson> you're welcome to file a bug report and we can consider it for later releases
<Crissi> thats bug was in 10.04 and 09.10 too
<cjwatson> sure, that feature has never been available in ubiquity
<Crissi> still done
<Crissi> why?
<Crissi> its important
<cjwatson> ubiquity is a desktop installer.  you're literally the first person I'm aware of to care about it having iSCSI support
<Crissi> if i install a opensuse i can select in graphical installer...
 * wgrant hasn't seen an iSCSI desktop before.
<Crissi> iscsi has nothing to do if desktop or not
<cjwatson> we have a different installer for servers, which supports iSCSI
<persia> YokoZar, ia32-libs -> wine1.2 -> lmms-vst -> ubuntustudio-audio -> Ubuntu Studio images
<cjwatson> that's as may be, but you are the first person to ask for it on desktop
<Crissi> its an media like scsi, ide, flash, ...
<cjwatson> you can use the alternate CD to install a desktop on iSCSI
<cjwatson> you just can't use the desktop CD
<Crissi> huh? that cant  be true.
<cjwatson> it is true.
<YokoZar> persia: is that spun yet?
<Crissi> :(
<Crissi> that a pity.
<cjwatson> use the alternate CD and be happy. :-)
<Crissi> i usedd the server cd which provides it in text installer
<cjwatson> the alternate and server CDs use the same installer, yes
<Crissi> but it really should be available in graphical installer
<cjwatson> the alternate CD will install desktop packages
<persia> YokoZar, http://iso.qa.ubuntu.com/qatracker/build/ubuntustudio/all is present, but I admit I'm not sure if there's currently a concern that would result in a respin.
<YokoZar> persia: how about a new ia32-libs ;)
<persia> YokoZar, You'd have to ask ScottL : it depends on tester availablility more than anything, I think.
<Crissi> just a hint: download a opensuse cd/dvd and install in a virtual machine (like virtualbox) and see how easy it can be. dont understand me wrong, i like ubuntu/debian but opensuse is has a nice way to install graphically for end users
<YokoZar> ScottL: well hopefully he'll see the backscroll and this gets handled (or not) while I'm asleep
<persia> He's in a timezone not fara removed from your usual, so unlikely to see it for a few hours, at best.
<Crissi> then you will got some useful ideas for the graphical debian installer :)
<Crissi> btw: the graphical installer hangs after selecting german and click next if run in kvm :(
<Crissi> vbox works
<cjwatson> testing that
<cjwatson> seems to work fine for me in kvm
<cjwatson> remember that kvm's default memory is set to 128M which is unlikely to be enough
<lifeless> sladen: ping
<lifeless> https://edge.launchpad.net/~contributor-agreement-canonical/+invitation/uff-contributors - why?
<doko> cjwatson: maybe not the best time, did see the thread about CD space and wanted to point at the fdupes output, but couldn't find any. is fdupes installed on the CD build host?
<doko> mvo suggested that ...
<cjwatson> doko: livefs build logs
<cjwatson> doko: e.g. http://people.canonical.com/~ubuntu-archive/livefs-build-logs/maverick/ubuntu/latest/livecd-20101007-i386.out
<sladen> lifeless: so that @canonical.com employees can commit
<doko> cjwatson: thanks, was looking at the wrong logs ...
<sladen> lifeless: is there a better way of doing that?
<sladen> lifeless: or should I just add anyone who needs to (eg. Mark) individually
<cjwatson> sladen: if you do that, aren't we all going to get even more mail about stuff we don't care about?
<lifeless> sladen: give me some context
<lifeless> sladen: the group you've invited is the list of folk that have *signed the contrib agreement*, which is a necessary but not sufficient condition for community contributors to canonical projects
<lifeless> sladen: if you're using this for ACL's, its misguided.
<lifeless> sladen: that list is a useful hint, its a) not the authoritative list (legal hold that) and b) not appropriate for subscribing (directly or indirectly) to objects in LP.
<sladen> lifeless: okay, fair enough.  So the answer is eg. to check against that list if somebody makes a request, and then to add them individually
<lifeless> yes
<sladen> lifeless: awesome, can you DENY that invitation (I can't seem to cancel it, even with hand-hacking +member URLs
<lifeless> done
<poolie> sladen, lifeless, uh if you're happy to grant access to anyone who's signed the agreement, you can use that team
<poolie> having signed the agreement does not necessarily guarantee they know what they're doing
<poolie> s/use/grant access to
<poolie> excess mail  being sent to that group could be more or a problem
<kklimonda> lifeless: btw, should I be added to the ~c-a-c group if I've been asked to sign the agreement? Or should I care about it only when I get asked again to sign it? ;)
<poolie> kklimonda: normally you will be added when the project lead receives your assent
<dpm> hi pitti, re: the e-mail I sent you some days ago about a language pack update schedule, is it ok if I subscribe you to the blueprint to participate in the session at UDS?
<pitti> dpm: sure, please do; right, I still need to get to this mail
<dpm> pitti, cool, thanks. Don't worry too much about the e-mail, as I said it's not urgent, and I know you've probably got enough on your plate right now
<ScottL> persia, YokoZar : i'm not sure what is being asked, the RC image was tested and now two more images were released, are we asking for a another respin?
<persia> ScottL, There's been a refresh of ia32-libs, which differs from that on the 20101007 images currently at iso.qa.ubuntu.com.  Since that falls in your image, your input to the release team on whether to accept it or push to a post-release update is likely of considerable interest.  If you request a respin, any tests done to 20101007 would need to be repeated.
<ari-tczew> slangasek: plymouth in Ubuntu maverick not looks good. I have a photo, I'll file a bug.
<ScottL> persia, it appears that on image 20101007 no amd64 test have been completed but 2/3 i386 test have been done
<ScottL> persia, however, i can cover all the i386 test tonight if there is a respin today
<ScottL> persia, and if we can still get a few days to test the image i imagine we could find someone to test amd64 fully
<persia> ScottL, Tell the release team: I can't do anything other than give warning that a package does affect an image :)  -release is probably an excellent forum.
<soren> Litterman?
<soren> Ah, and entirely different Scott. :) Sorry :)
<soren> s/and/an/
<pitti> kirkland: http://blog.dustinkirkland.com/2010/10/try-ubuntu-server-in-cloud-on-our-dime.html is a great idea!
<kklimonda> pitti: does apport save crash in /var/crash even if package isn't genuine (and don't remove it) ?
<pitti> kklimonda: yes
<kklimonda> thanks
<Riddell> mvo: wibble bug 656876
<ubottu> Launchpad bug 656876 in Ubuntu "distupgrade crashed during conf file change review" [Undecided,New] https://launchpad.net/bugs/656876
<jibel> pitti, we are receiving lots of upgrade failures for postgresql since the latest security update.
<jibel> pitti, the error is FATAL:  could not create shared memory segment: Invalid argument
<jibel> pitti, do you think they are all misconfigured installations or there is something with the update
<jibel> pitti, ?
<pitti> jibel: it's bug 264336
<ubottu> Launchpad bug 264336 in postgresql-8.3 (Ubuntu) "pgsql fails to start due to shared buffer setting greater than kernel allows" [High,Confirmed] https://launchpad.net/bugs/264336
<pitti> it's been around for ages, but so far there hasn't been a satisfying solution yet, except for locally changing the size limits :(
<ScottK> Would that be worth mentioning in a revised USN?
<pitti> it's not specific to that update really
<pitti> it's been around for ages
<mvo> Riddell: looking
<mvo> Riddell: hm, no backtrace :( ?
<Riddell> mvo: nothing in the logs no, the DistUpgrade process is still running but the UI is frozen
<mvo> Riddell: this is the kde frontend, right?
<mvo> Riddell: can you type into the terminal?
<Riddell> mvo: I can
<Riddell> well not into the DistUpgrade terminal
<Riddell> that window is just a grey box now
<jibel> pitti, are you okay for a bugpattern then ?
<pitti> jibel: that'd be great
<jibel> pitti, great, will do, thank you
<pitti> thanks to you!
<mvo> Riddell: meh, ok, I try to reproduce now
<mvo> Riddell: I get a window with the conffile prompt, do you get that as well?
<mvo> Riddell: can you give me a ps afx output?
<Riddell> mvo: I got the window with the conffile prompt, then when I clicked on "show more" it crashed
<Riddell> only interesting thing in ps was the DistUpgrade process
<Riddell> but I'm starting a new install now I'm afraid
<mvo> Riddell: hm, hm, let me try to reproduce
<Riddell> mvo: it was started from kpackagekit is that would change anything
<scott-work> YokoZar, persia:  Scott.K and c.jwaston have agreed to respin ubuntu studio images for ia32lib
<mvo> Riddell: so the empty diff can be explained by dpkg lying on its status-fd, it sends "file-old", "file-new", but "fild-old" does not actually point to the right file *sigh*
<mvo> Riddell: I fix that now (well, workarond)
<jcastro> hey mvo, aquarius thinks he can fix apt.ubuntu.com to work with other browsers with a little bit of javascript
<mvo> jcastro: oh, cool
<jcastro> ok so he can fix it, and then it's just filing an RT ticket, but of course we'd like to run it past you
<jcastro> mvo: ok so are there any concerns you are worried about or should we Just Do It and see what you think?
<mvo> jcastro: that is fine with me
<mvo> Riddell: what is the thing that looks for restart required messages in kubuntu? the process name of that?
<Riddell> mvo: it's a kded module
<Riddell> qdbus org.kde.kded /modules/notificationhelper
<Riddell> qdbus org.kde.kded /kded org.kde.kded.unloadModule notificationhelper   would be how to stop it
<mvo> Riddell: will that work as root?
<mvo> Riddell: when the upgrade starts, this needs to be unloaded
<mvo> Riddell: or killed
<kirkland> pitti: thanks :-)
<Riddell> mvo: hmm no, needs to be user
<mvo> Riddell: can you add it to your code then please? bug #650481 fyi
<ubottu> Launchpad bug 650481 in update-manager (Ubuntu) "System restart notification while upgrade is in-progress" [Undecided,New] https://launchpad.net/bugs/650481
<mvo> Riddell: I will reassign to kpackagekit
<mvo> Riddell: (assuming that is the right package?)
<Riddell> mvo: kpackagekit starts DistUpgrade, kubuntu-notifications-helper is the notifier.  You want kpackagekit to kill kubuntu-notifications-helper before starting DistUpgrade?
<mvo> Riddell: if its kubuntu-notifications-helper then I can kill it when the upgrade starts in u-m (after the point of no-return)
<mvo> Riddell: otherwise it needs to be done by whatever starts the upgrade
<Riddell> mvo: kubuntu-notifications-helper is the kded module which needs the dbus bit run as user
<mvo> Riddell: ok, so after kpackagekit started the release upgrader, it should disable that and re-enable it if the user cancels, I will add that info to the bugreport
<Riddell> mvo: right
<mvo> Riddell: I fixed the empty conffile prompt now, but I can reproduce the hang (yet?)
<Riddell> mvo: can or can't?
<mvo> Riddell: sorry, I can't
<mvo> Riddell: but I try some more
<Riddell> mvo: I'm trying it again too
<mvo> I have issues with kvm in maverick unfortunately, that makes it less streamlined than it used to be (this kind of testing)
<Riddell> mvo: what was the empty conffile prompt?
<mvo> Riddell: dpkg did send a incorrect filename over its status fd
<Riddell> mvo: but you think that's unrelated?
<mvo> Riddell: yeah, I don't think its causing the crash
<penguin42> mvo: Which particular kvm issues?
<mvo> penguin42: when I do a test upgade from lucid->maverick on a maverick host (amd64) it hangs at some point. but only when running in gui mode, not when I run headless (vnc)
<penguin42> mvo: Can you just explain what you mean by gui mode?
<mvo> penguin42: when I run "kvm -m 768 lucid-desktop.qcow2" (the sdl window). when I run my automatic tests, the use -nographics and that seems to be working fine
<penguin42> mvo: sdl on kvm on maverick is just dead as far as I can tell, there's a bug against it
<penguin42> mvo: bug 615077
<ubottu> Launchpad bug 615077 in virtinst (Ubuntu Maverick) "[Maverick] SDL local window broken in last update" [Medium,Confirmed] https://launchpad.net/bugs/615077
<mvo> penguin42: thanks, that is rather unfortunate, if its a known problem at least its known
<penguin42> mvo: Yeh it's a pain; it seems to be related toa ccess to .Xauthority but IMHO it can fail really badly and try and do framebuffer which kills X
<mvo> penguin42: thanks, I will try to bring it into the broken state again and report a bug
<mvo> penguin42: or add info on it at least
<tseliot> cjwatson: is this patch for grub still relevant in maverick's grub? I'm asking as grub_memset has changed in maverick: http://pastebin.ubuntu.com/508850/
<tseliot> cjwatson: note: I'm not asking whether it applies cleanly ;)
<cjwatson> tseliot: it's not - a different version was applied upstream
<tseliot> cjwatson: ah, is it already in maverick or only upstream?
<cjwatson> the vast majority of the speed benefit was in doing wordwise writes rather than bytewise writes, and that can be done in plain C, so we did that
<mvo> Riddell: upgrade test is running, let see how it goes
<cjwatson> maverick too
<tseliot> cjwatson: ah, great. Thanks
<cjwatson> using rep stos* in assembly was a tiny additional improvement, but not worth maintaining the more delicate code - I think that's true even in OEM, it was milliseconds at most
<cjwatson> and I think not even that with the MTRR patch on top
<tseliot> oh, ok
<cjwatson> tseliot: see http://lists.gnu.org/archive/html/grub-devel/2010-06/msg00128.html and thread for the history if you care
<cjwatson> oh, and http://lists.gnu.org/archive/html/grub-devel/2010-07/msg00162.html
<tseliot> cjwatson: thanks. BTW I've also ported your MTRR patch
<GPenguin> hi guys. where did /etc/inittab go?
<GPenguin> i wanted to change the default runlevel
<Riddell> mvo: mine went fine that time but I didn't click "show more", going to try again on amd64
<cjwatson> tseliot: *nod* that should have been a simple forward-port
<cjwatson> GPenguin: replaced by upstart
<GPenguin> will read up on upstart then, thanks
<cjwatson> GPenguin: you can edit /etc/init/rc-sysinit.conf if for some reason you still care about the default runlevel
<GPenguin> ah, nice
<cjwatson> or put DEFAULT_RUNLEVEL=3 (or whatever) on the kernel command line, as mentioned in that file
<cjwatson> er, sorry, just 3
<tseliot> cjwatson: yes, that was easy
<GPenguin> thats even nicer
<cjwatson> tseliot: we may still integrate something like that upstream in future, but it will need to be more configurable ... it's not straightforward
<tseliot> cjwatson: right, I read that in the mailing list
<YokoZar> is -proposed opened?
<cjwatson> technically, it's been open since April ;-)
<cjwatson> you can upload to it, when it gets accepted is a different question
<cjwatson> we probably won't start accepting until tomorrow at the earliest
<YokoZar> ok, then I can be a bit lazy about Wine 1.2.1
<kees> YokoZar: so, what's the deal with the ptrace fix for wine1.2? you reverted it?
<slangasek> kklimonda: it didn't get synced
<mvo> Riddell: when click on show diff I get the issue you described now too
<jbarnes> I'm seeing a failure with mountall which prevents pretty much everything from starting
<jbarnes> I have a sw raid setup, two disks striped to create /dev/md0
<jbarnes> but they came from a previous hw raid config; I saw some bugs related to that
<jbarnes> was just curious how to correct things
<penguin42> jbarnes: Is that a case of kicking dmraid down?
<jbarnes> penguin42: no it's an mdadm setup
<jbarnes> oh it could be dmraid related, I think that's used for the so-called "hardware" raid configs?
<penguin42> jbarnes: So why did you point out they had come from a previous hw raid config?
<jbarnes> some of the bugs indicated that could be an issue
<jbarnes> thanks for reminding me about dmraid
<penguin42> no prob
<penguin42> jbarnes: Are you the intel_ips person?
<jbarnes> yes
<penguin42> jbarnes: That bug apw posted the patch for where the i915 symbols aren't found and it oopses; I was wondering why the symbols weren't found
<jbarnes> probably because i915 hadn't loaded yet
<jbarnes> or failed to load for some reason
<penguin42> jbarnes: Yeh so if it's a loading ordering issue then it might need a different fix; although at least one of the reporters that had the problem had an i5 or the like but with an external graphics chip which makes me wonder if the built in graphics was disabled
<jbarnes> yeah could be
<penguin42> one to watch out for I guess
<jbarnes> yeah if they load out of order, you won't get gfx turbo, which would be sad
<Sarvatt> especially on ULV parts, ugh
<jbarnes> yeah
<penguin42> jbarnes: Yeh hence I'm not sure that fix was the only fix needed, I don't think you can force the ordering since if they are using an extrenlal graphics chip you can't be sure it will load
<jbarnes> yeah
<penguin42> not sure what the right fix is though
<jbarnes> damn no luck with dmraid
<jbarnes> it can't find any metadata about my old raid config, so I guess that's not the issue
<jbarnes> [root@jbarnes-vaio ~]$ service mountall start
<jbarnes> mountall stop/waiting
<jbarnes> that seems wrong
<jbarnes> UUID="40e6fb47-8d67-4210-858a-64b14ca3025c"       /               ext3    errors=remount-ro 0       1
<jbarnes> that's the only entry in /etc/fstab
<achiang> jbarnes: maybe #linuxfs? or are you thinking this is a distro issue?
<jbarnes> achiang: distro issue is my guess right now
<jbarnes> mountall isn't starting
<achiang> hasn't mountall be upstart'ified?
<achiang> s/be/been/
<achiang> jbarnes: what if you just say: mountall --daemon ?
<jbarnes> achiang: nothing happens
<achiang> jbarnes: btw, for upstart jobs, the syntax is start <jobname>, although i guess service <jobname> might still work for compat reasons
<achiang> jbarnes: how far are you getting in boot?
<jbarnes> system boots up to a prompt
<jbarnes> but dbus doesn't start, no gdm, etc
<jbarnes> and I think it's because local-filesystems is never emitted
<jbarnes> mountall -v doesn't report errors
<achiang> jbarnes: if you pass --debug as a kopt, upstart should write a logfile in /var/log somewhere
<achiang> well, technically it's not a kopt, but you do pass it on the kernel command line
<jbarnes> ok trying that
<Chipzz> achiang: I think there never was a non-startup-ified mountall in the first place
<Chipzz> mountall was written specifically for startup iirc
<jbarnes> not sure if this log has anything interesting or not
<jbarnes> init: mountall main process (396) became new process (397)^M
<jbarnes> init: job_process_handler: Ignored event 20 (19) for process 398^M
<jbarnes> init: job_process_handler: Ignored event 1 (0) for process 396^M
<jbarnes> init: job_process_handler: Ignored event 40 (1) for process 397^M
<jbarnes> init: mountall main process (397) became new process (398)^M
<jbarnes> init: mountall state changed from spawned to post-start^M
<jbarnes> init: mountall state changed from post-start to running^M
<jbarnes> init: event_new: Pending started event^M
<jbarnes> init: Handling started event^M
<jbarnes> init: event_finished: Finished started event^M
<jbarnes> init: job_process_handler: Ignored event 1 (0) for process 397^M
<jbarnes> init: event_new: Pending mounted event^M
<jbarnes> init: Handling mounted event^M
<jbarnes> so it's emitting mount events
<jbarnes> but I never see local-filesystems get emitted
<micahg> !pastebin | jbarnes
<ubottu> jbarnes: For posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://tinyurl.com/imagebin | !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic.
<jbarnes> sorry
<achiang> jbarnes: but the raid actually works i guess? that is, your filesystem isn't hosed?
<jbarnes> yeah system is working fine other than most stuff not starting up :)
<jbarnes> I think it's a mountall problem
<achiang> nod
<achiang> jbarnes: i gotta run some errands, but i'll be back in an hour or so
<jbarnes> cool
 * jbarnes needs Keybuk, he could probably solve this in a minute
<jcastro> hi jbarnes
<jcastro> are you coming to uds?
<jbarnes> jcastro: oh sorry the invite got buried in my inbox
<jbarnes> jcastro: I'm not planning on it, I have too much travel around that time
<jcastro> no worries
<jcastro> maybe next time!
<jbarnes> yeah hopefully! :)
<YokoZar> kees: it didn't apply but it's in wine 1.2.1
<YokoZar> kees: which I'm putting in -proposed today
<kees> YokoZar: oh, heh. I just uploaded a backport that works, but your 1.2.1 will be even better. :)
<kees> YokoZar: so, feel free to have them reject mine once yours is ready
<DocMAX> can someone help me with cross compiling samba? i make a ./configure --host=arm-linux (also also tried --host=i686 --target=arm-linux)
<DocMAX> but i still get an i686 executable
<DocMAX> can someone help me with cross compiling samba? i make a ./configure --host=arm-linux (also also tried --host=i686 --target=arm-linux)
<ArtArfon> Possibly important...
<ArtArfon> http://mange.dynalias.org/linux/misc/Fedora12_GVFS_Crash_2010_10_08_Crash_GUI_Didnt_Let_Me_Type_In_Password_Twice/ccpp-1286569191-7930_GVFS_CRASH_2010_10_08/
<ArtArfon> PÃ¤rskans! :)
<dawning_> Sorry for the support question - how do I get everything a meta package references nuked?
<ArtArfon> dawning_ Que?.. :)
<dawning_> ArtArfon: I want to remove everything from ubuntu-desktop, but if I go apt-get remove ubuntu-desktop, it only removes the meta package and not all the stuff it defines
<ArtArfon> dawning_: Ah, to remove the entire desktop. Easy enough for someone perhaps.
<ArtArfon> dawning_: Remove its first dependency can be a qualified guess.
<ArtArfon> dawning_: kde* :)
<dawning_> Thanks
<ArtArfon> np
<ArtArfon> Walk the line - Ministry of sound... awesome! :)
<dawning_> This solved it for me:
<dawning_> http://www.psychocats.net/ubuntu/purekdekarmic
<ArtArfon> Haha, catmonkies :)
<ArtArfon> Tiger valigns
<ArtArfon> Tiger haligns / Feisty :)
<penguin42> removing libgtk should remove most of ubuntu-desktop - I hate to think what else it takes with it :-)
<ArtArfon> yes, kde people really reaks.
<ScottK> ArtArfon: If you want to be insulting, do it elsewhere.
#ubuntu-devel 2010-10-09
<ArtArfon> ScottK: Perhaps you should say this to the people destroying gnu/mc.
<ScottK> ArtArfon: I've no idea what you're talking about, but I'm reasonably confident it's not closely related to Ubuntu development (which is the topic of this channel).
<ArtArfon> ScottK: If you dont know anything, then why adress me at all ?
<ScottK> ArtArfon: Unless you have something to say relevant to Ubuntu development, please don't say anything at all (if a certain class of people have body odor problems doesn't qualify).
<ArtArfon> ScottK: I note youre dressed for the occation :P
<kees> pitti: I'm curious what you think of apport upstream commit 1792 -- I was trying to find a way to handle key clobbering without doing a "raise"
<Hobbsee> hmmm. how would i track down why my mouse is bouncing across the screen, rather than moving fluidly after rebotin gteh second time to maverick?
<Hobbsee> google is not being helpful
<cody-somerville> Hobbsee, wireless mouse?
<Hobbsee> cody-somerville: yes, and the keyborad seems tob e gting some elters in th ewrong sequence, or dropping them
<Hobbsee> i keep getin gwrong password, and the irc is speaking or itself
<cody-somerville> Hobbsee, anything useful in dmesg?
<Hobbsee> cody-somerville: nothing obvious to me, but i'm not fluid in it.  i'l pastebin
<Hobbsee> cody-somerville: http://www.pastebin.ca/1957945
<Hobbsee> i upgraded last night, rebooted, and all was fine, keyboard wroked, etc, installed the enwer virtualbox and wine from their ppas, booted this morning, and sudenly there's major mice and keyboard problems
<Hobbsee> Bus 006 Device 002: ID 046d:c517 Logitech, Inc. LX710 Cordless Desktop Laser  <-- and i'm fairly sur ethat's notmy mouse, eiter
<cody-somerville> Hobbsee, is it logitech at least? lol
<Hobbsee> cody-somerville: yeah, mx30
<Hobbsee> * mk300
<cody-somerville> Hobbsee, This might be a stupid question but have you tried unplugging and then plugging it back in?
<Hobbsee> cody-somerville: have now, no dice
<cody-somerville> Hobbsee, does it still register it as LX710 Cordless Desktop Laser?
<Hobbsee> cody-somerville: yes
<cody-somerville> Hobbsee, lines 749 - 770 look relevant
<Hobbsee> good ponit
<Hobbsee> cody-somerville: the windows solution worked.  go figure
<cody-somerville> The windows solution? whats that?
<ebroder> Keep rebooting until the problem goes away?
<Hobbsee> that's the one
<Hobbsee> "if in doubt, reboot"
<Hobbsee> doesn't seem to be a common problem - i couldn't find any other references to it with maverick
<cody-somerville> ah, yea I figured that would probably fix it
<Hobbsee> and it still detects wrong, incidently
<ebroder> That seems like it's likely to be the device mis-identifying to make it easier for Logitech to put the drivers together, but what do I know
<Hobbsee> probably
<cody-somerville> Hobbsee, It looks like it was probably caused by your nvidia driver hanging on an interrupt
<Hobbsee> cody-somerville: i see.  which i assume means i should'nt file a bug
<Hobbsee> (and my typing fails now are actualyl me, not the keyboard.  i think)
<cody-somerville> Hobbsee, If it happens often you could rewrite your DSDT so that at least the graphics driver didn't screw up USB. Just download and decompile the DSDT, locate the USB devices, and change the permitted interrupt lines, recompile and put in your initramfs.
<Hobbsee> cody-somerville: noted
<nigelb> Hobbsee: I've seen the keyboard thing with lucid, but I thought that was my hardware being finiky
<nigelb> some of the keys would not work on a boot making logging in a pain because the password just wouldn't work
<Hobbsee> nigelb: ouch, tha tsucks
<nigelb> Hobbsee: yeah.  I just wait it out and it starts working :)
<nigelb> (or the windows solution: thou shall reboot until it works)
<Hobbsee> hehe
<nigelb> hrm, if this is something kernel I should log a bug, but the problem goes away by the time I log in :/
<cody-somerville> nigelb, It happens every time you boot?
<nigelb> cody-somerville: nope, once in a while
<nigelb> cody-somerville: ah, mine's nvidia too.  sigh.
<nigelb> I'm hitting the same problem as Hobbsee perhaps.
<Hobbsee> nigelb: that was happening all the way into x
<Hobbsee> nigelb: so i'm guessing not
<nigelb> Hobbsee: 'all the way in x' means?
<Hobbsee> nigelb: as in, happens in gdm, happens after everything is loaded.  happened until i shut the machine down again
<nigelb> Hobbsee: similar here.
<nigelb> my password doesn't have all characters
<nigelb> somtimes I can get it, but some keys are still not working.
<cody-somerville> I wouldn't be so quick to assume the problem is the same.
<cody-somerville> lots of things could cause the symptoms you're describing.
<nigelb> hrm, what logs would be the best to get too the bottom of this?
<nigelb> if I can get in and get logs maybe I can try something.
<cody-somerville> nigelb, I recommend that if you decide to do that then you use ubuntu-bug - it'll collect the logs for you automatically.
<nigelb> okay, ubuntu-bug linux next time.  I just hope those keys woork
<nigelb> :D
<wgrant> maco: Is gally meant to have an explicit 0: epoch? That's a little strange.
<maco> wgrant: i got so used to seeing kde packages that start with 4: that i forgot they were optional
<wgrant> Haha.
<wgrant> See, KDE does bad things to your mind.
<pitti> kees: looks fine; if you could add an appropriate stanza to NEWS, too?
 * Claudinux help
<DocMAX> hi, when compiling programs, they get very big
<DocMAX> static dropbear for example
<DocMAX> is 900k
<DocMAX> pre compiled are only 150k
<DocMAX> any ideas?
<kees> pitti: thanks, done.
<pitti> kees: cheers
<LLStarks> hi
<prodigy> lol
<shadeslayer> wth was that
<LLStarks> pitti, you there?
<penguin42> bug 657489 may be a nasty one to look out for
<ubottu> Launchpad bug 657489 in grub2 (Ubuntu) "grub package update may crash when used with PnP wireless modems" [Undecided,New] https://launchpad.net/bugs/657489
<penguin42> really none obvious to find and breaks a grub update
<DocMAX> hi, whats "stripe" in compiling terms?
<penguin42> more context?
<DocMAX> i think i read something about a stripe flag
<DocMAX> it should make the binary much smaller
<penguin42> ah!
<penguin42> strip
<DocMAX> ah strip! =)
<DocMAX> where do i set this flag, and was does strip actually do?
<penguin42> DocMAX: It removes symbols from object files - makes it really really hard to debug and if you select some options cause linking problems; but mostly just about debugging
<DocMAX> where do i set this flag?
<DocMAX> make CFLAGS="-strip" ?
<penguin42> I'd normally just use the strip command on the binary; I think Debian package builds tend to do it automatically in the packages
<DocMAX> want to compile samba
<DocMAX> so i do a "strip smbd" ?
<DocMAX> on the binary?
<penguin42> yeh - why are you doing that?
<DocMAX> smbd is about 10 MB!
<wgrant> Why are you building it yourself?
<DocMAX> i found other pre-compiled binarys with only 2 MB, i dont know how they do it
#ubuntu-devel 2010-10-10
<pitti> YokoZar: dropping older wine1.2 upload, since the patch also seems to be present in the newer one
<pitti> doko__: rejecting libapache2-mod-python, it doesn't have a bug reference
<sabdfl> hello hello
<wgrant> Morning.
<pitti> hey sabdfl
 * pitti pats the Meerkat
<ion> o hai
<sabdfl> he
<sabdfl> magic maverick turned out nicely
<pitti> sabdfl: magic maverick?
<pitti> OMG!
<pitti> we are doing the wrong release!
<sabdfl> :)
<pitti> "Mark Shuttleworth stops the 10.10 presses due to major misunderstanding"
<sabdfl> file it under "Headlines we do not want"
<Riddell> someone may want to update the topic :)
<Riddell> congratulations all the sleepy ubuntu devs
<pitti> skaet: may you have the honor?
* sladen changed the topic of #ubuntu-devel to: Archive: FINAL Freeze in effect! | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper-lucid | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<pitti> what did you change?
* sladen changed the topic of #ubuntu-devel to: Archive: {{Kate to make major update in this space!}} | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper-lucid | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<ogra_ac> heh
<fagan> pitti: you have a meerkat I got to get the plane to germany so I can see it :)
<yofel> pitti: about apports --save - it only fails if you use --save=~/... and expanduser shouldn't mess with the path if home is already expanded
<pitti> yofel: aah, good point
<pitti> yofel: can you please follow up to the bug with that, for the record? I'm about to go offline now
<yofel> sure, I'll change it back to triaged then too
<persia> So, when does natty open?
<fagan> persia: I thought it was open a few days ago
<nigelb> no, it takes a few days
<wgrant> It can't be initialised until after release.
<wgrant> ... and after we sacrifice some goats to Soyuz.
<persia> https://launchpad.net/ubuntu/natty/+queue doesn't seem to show it open (and it is usually initialised frozen for toolchain folks)
<persia> wgrant, Haven't you managed to downgrade the sacrifices to chickens yet?
<nigelb> wgrant: ah, at least you got it down from the bulls.
<fagan> and the whales before that
<persia> But it's been goats for at least since karmic.
<persia> (unless cprov was issuing forward looking statements at the time)
<wgrant> fagan: Maybe we should try whales again this time. They are more relevant to the release.
<fagan> hah
<fagan> and the gods would find them more pleasing since they are bigger
<nigelb> LOL
<nigelb> unicorns?
<fagan> nigelb: if you can find them and feed them to the whales the gods would be very pleased
<nigelb> fagan: at the risk of all the little girls cursing me.
<fagan> hehe it would be worth it
<persia> The larger-creatures-developed-by-several-subcreatures-eating-each-other hypothesis has been deprecated for a couple millenia now: let's not revive it.
<nigelb> Heh.
<nigelb> oh, sabdfl tweeted.  It is indeed an auspicious day :p
<nigelb> and stack exchnage looks gorgeous today
<fagan> nigelb: yeah I was supprised too
<fagan> about sabdfl tweeting
<fagan> and yeah the stackexchange looks great
<sabdfl> stack exchange looks fantastic
<fagan> it would be nice now to have answers.launchpad.net/ubuntu to redirect to there
<nigelb> lol
<nigelb> haha, this rocks: http://design.canonical.com/wp-content/themes/canonical-design/42day/
<nigelb> design team ftw
<fagan> that banner on there is awesome
<nigelb> whoa => < rickspencer3> elmo just opened Natty :)
<nigelb> persia, fagan, and wgrant ^^
<wgrant> Well, FSVO opened.
<wgrant> It exists.
<nigelb> looks like they had the goats ready
<wgrant> But none of the Soyuz sacrifice is done yet.
<nigelb> Ah
<fagan> someone must have found a cat
<persia> a cat just isn't sufficient
<fagan> cats are magical creatures they are worth 2 goats
<highvoltage> when does natty open!? it feels weird and uncomfortable being on a stable release!!!
<persia> highvoltage, Next week, likely.
<Riddell> 11:35 < rickspencer3> elmo just opened Natty :)
<nigelb> highvoltage: when we offer a few sacrificial goats to soyez; see discussion above :)
<Riddell> but presumably we should wait for the toolchain first
<fagan> highvoltage: I agree being on a stable release is annoying /me quickly installs debian unstable
<persia> We can dist-upgrade whilst waiting for the toolchain, just can't upload anything.  Mind you, this may result in a need to reinstall, but ...
<fagan> (kidding)
<highvoltage> Riddell: :)
<nigelb> \p/ spiffy new fridge http://ubuntu-news.org/
<persia> nigelb, So, for folks subscribed to the RSS feed, are you doing something nifty to inform the readers of the new feed subscription?
<nigelb> persia: I think there will be an announcement on the old feed (fi there isn't one already)
<nigelb> persia: there is one already: http://fridge.ubuntu.com/node/2141
<fagan> all we need is a new planet.ubuntu.com and we have the set of updated sites
<persia> nigelb, Sure, but no automation to help clients resubscribe.  One has to open a browser, investigate the website, select the new feed, etc.
<persia> highvoltage, "flavours" :p
<highvoltage> persia: I'm just being consistant with how it's being called everywhere else atm :)
<persia> Where else?  Who else do I have to complain at?
 * persia sees a *huge* difference between flavours, participating as part of Ubuntu, and derivatives, who use the results of a release to build something else.
<highvoltage> persia: http://www.ubuntu.com/project/derivatives
<persia> Ugh.  That wasn't there before.
<highvoltage> persia: https://wiki.ubuntu.com/DerivativeTeam/Derivatives
 * persia files yet another website bug
<persia> That one is hard to change for annoying historical reasons, sadly
<highvoltage> persia: the top results for searching ubuntu flavours results in pages that refer to what you would call derivatives as flavours:
<highvoltage> http://www.lczajkowski.com/2010/01/23/new-flavours-of-ubuntu-being-developed-in-ireland/
<highvoltage> http://ubuntulinuxhelp.com/ubuntu-based-linux-32-flavours-and-then-some/
<highvoltage> persia: It would be nice to have it defined properly somewhere and have that definition updated everywhere so that there could be better consensus and better use of these terms
<persia> highvoltage, I know.  I've been hunting for slibs cogent distinction between "remix" and "flavour" for a while, and can't find it (which annoys me).  I fear that page may have been a victim of the "Ubuntu Netbook Remix" nomenclature discussions, and then the wiki history was lost in a site update.
<persia> The nice guide to when one had to use "remix" to be within the trademark guidelines has also gone missing (and finding good language for these is currently blocking me from some tasks).
<persia> But I think there is a vast difference in each class of Flavour (e.g. Edubuntu), Remix (e.g. Ubuntu Japanese Remix), and Derivative (e.g. gNewSense)
<highvoltage> persia: *nod*
<persia> Anyway, thanks for being the target of my rant about this :)  Please help rant at folk in the future to preserve the useful semantic distinctions, and maintain our reputation for quality for all flavours.
<highvoltage> persia: will do
<persia> Thanks :)
<real_ate> hi all... I'm having a bit of trouble working out to build someting I get from apt-get source
<real_ate> I want to find the right way, so I can build a package and install it instead of just using make install
<persia> real_ate, You're looking to fix a bug in Ubuntu, or package something separately?
<real_ate> persia: fix a bug
<persia> Excellent.  Just wanted to make sure we'd be on-topic :)
<real_ate> cool cool
<real_ate> I know there was some command to run in the same folder as you run apt-get source... i did it before but I can't remember
<real_ate> It packaged up the deb and applied any patches if there were any
<persia> Maybe `debuild -S -us -uc -i -I`?
<real_ate> ooo... that sounds familliar!
 * real_ate goes googling
<persia> That should convert an unpacked source, post modification, into a new source package.
<persia> It's a good idea to make sure you've used `dch -i` to get a new changelog entry, so you can be sure you end up with the right newer version when you make the new source.
<real_ate> hmm interesting... these are all part of the devscripts package then?
 * real_ate is not used to working like this
<persia> I think so.
<persia> Yep.
<persia> Now, to convert the now updated source package with the patch to fix the bug into a binary package there are three common techniques.
<persia> Most of us use pbuilder or sbuild
<persia> You can also use `debuild -b` but this may not result in the same thing as you'd get if your patch was uploaded, so isn't the best test.
<persia> https://wiki.ubuntu.com/Bugs/HowToFix#The%20traditional%20process is a sensible place to start digging around on the wiki
<shadeslayer> pitti: regarding bug 654236, i dont think a backport would be possible, since alot of work had to be done to port choqok to OAuth, ill contact upstream and see if its realistically possible tho
<ubottu> Launchpad bug 654236 in choqok (Ubuntu Lucid) "SRU : Please release choqok 0.9.85 for lucid" [Undecided,Confirmed] https://launchpad.net/bugs/654236
<real_ate> persia: thanks for all the help! that page is exactly what I was looking for but wansn't quite able to find :)
<real_ate> persia: hopefully you've helped me fix a rather annoying bug! cheers!
<persia> real_ate, Which bug?
<real_ate> i'm working on KDE gdm integration
<shadeslayer> oooh ^
<persia> Oh my :)  If you get it sorted, please remember to try to get it into Ubuntu, so we all have it fixed.  I think three are links to the sponsoring processes from that page.
<real_ate> persia: i'm usually an upstream developer but I want to see if I can do this the right way and get a patch into LTS
<real_ate> persia: thats the plan
<real_ate> :)
<persia> Excellent.
<Riddell> real_ate: what needs done with KDE gdm integration?
<real_ate> Riddell: it wasn't updated since the gdm protocol was updated
<real_ate> so things like... you can't shutdown in KDE when you have gdm enabled
<real_ate> selecting "switch user" actually just locks the screen
<real_ate> etc.
<mindentropy> Hi. When I am trying to upload my ssh key to launchpad it says invalid key. Do I need to upload everything in the id_rsa.pub file i.e. the last username@hostname too?
<persia> mindentropy, I'd recommend asking in #launchpad: they likely know better than us.
<wgrant> mindentropy: Yes.
<Riddell> real_ate: ah right, would be good to have that fixed, sounds like a patch for kdebase-workspace somewhere
<wgrant> I believe you need the comment too.
<real_ate> Riddell: well i've got a fedora patch to use as a starting point
<Riddell> real_ate: ah hah, so worth checking if the patch is in upstream KDE or not
<real_ate> first point of call is to try that and see if it works, then get out my bug investigation hat!
<real_ate> Riddell: its not
<real_ate> Riddell: that is why i'm doing this... i'm trying to get this done
<real_ate> persia: that page you sent me is suggesting that i work off the bzr repo... should i do it that way or can I just work off the apt-get source ?
<persia> I just work off apt-get source myself.  Saves fussing with bzr.  There's all sorts of fancy infrastructure that handles commiting my uploads into bzr without me needing to think about it at all.
<BUGabundo> tsimpson: pong :P
<BUGabundo> topic needs to be updated for karmic :)
* tsimpson changed the topic of #ubuntu-devel to: Archive: {{Kate to make major update in this space!}} | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper-maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<Jarvis> BTW, according to do-release-upgrade maverick is still classed as a development release, is that correct?
<Jarvis> or are you waiting for the servers to calm down a bit first :p
 * real_ate imagines the servers seeing red and going a little bit green and "hulky"
<Jarvis> hehe :p
<BUGabundo> Jarvis: it should work
<BUGabundo> but -d will take care of it
<Jarvis> yea thats what i've had to do, unfortunately if your using karmic, it only offers lucid , unless you do -d ... and if your on lucid, you get 'No new release found' unless you use -d
<Jarvis> upgrade-manager (not sure if that uses do-release-upgrade or not) is the same . it doesn't see maverick
<BUGabundo> Jarvis: are you set to long term (aka LTS) or normal releases?
<Jarvis> i've not set anything, neither has my friend
<Jarvis> so its whatever the defaults are
<BUGabundo> please check the release target
<Jarvis> BUGabundo: its set to lts .. and it seems thats the default :(
<BUGabundo> yes
<BUGabundo> so change to normal
<Jarvis> cheers BUGabundo
<BUGabundo> np
<real_ate> wow! this debuild stuff is COOL! :D
<real_ate> one question though... first i ran debuild -S and it generated the source package but it said that it was building too
<real_ate> does it build a binary package with debuild -S ?
<real_ate> grr... and now i've run debuild -S -us -uc but where does it build the deb package? :/
<persia> real_ate, To convert a source package to a binary package, you likely want sbuild or pbuilder.  You can use `debuild -b` but it's not recommended.
<persia> !sbuild
<ubottu> sbuild is a system to easily build packages in a clean schroot environment.  To get started with SBuild, see https://help.ubuntu.com/community/SbuildLVMHowto
<persia> !pbuilder
<ubottu> pbuilder is a system to easily build packages in a clean chroot environment. To get started with PBuilder, see http://wiki.ubuntu.com/PbuilderHowto
<persia> `mk-sbuild` or `pbuilder-dist` from the ubuntu-dev-tools package will likely make it much easier to set up either one.
<real_ate> i take it that those convienience scripts are detailed on those how-to pages?
<nigelb> is Lubuntu an official derivative yet (I think no, but I'd like to confirm)?
<gilir> nigelb, no, it's not on the Ubuntu release announcement
<padhu> Not yet
<nigelb> Thank you :)
<persia> lubuntu *is* a fine derivative.  it's 99% of the way to being a flavour (but not there yet)
<Tm_T> it needs a bit more sugar to have correctt flavour (:)
<persia> No.  Needs someone (me) to publish clear documentation on how to become a flavour, and someone (else) to stamp it as the official procedure.
<real_ate> wow! pbuilder is even cooler than debuild! :D he he he
<persia> Sugar is a different proto-flavour
<persia> And I hear that there may be discussion of spice at UDS, although I'm not yet convinced I understand it entirely.
<penguin42> the remote video thing?
<persia> No, nor the circuit simulator thing.  something related to flavours, but I'm waiting for a spec to be drafted.
<real_ate> grrr! damn you release! pbulder can't rectrieve its packages cos I assume the servers are busy! oh what a world! ;)
<pitti> shadeslayer: fair enough
<persia> real_ate, The couple days after release are the least convenient for doing Ubuntu development (unless you happen to live near a mirror that doesn't have many users).
<padhu> real_ate: +1
<real_ate> persia: :D what is the process of mirroring? lol
<persia> real_ate, You don't want to start now :)  https://wiki.ubuntu.com/Mirrors
<real_ate> lol
<real_ate> it would be done in 2 days time and by then i could just develop normally :D
<persia> real_ate, I doubt that.  When there's no current release, setting up a mirror usually takes a week or two (for sites with lots of bandwidth).
<real_ate> well things are starting to pick up now! I just wonder what it will do when it comes to the end... "sorry all that time is wasted 'cos we couldn't get these packages: {blah}" ;)
<real_ate> interestingly they were only warnings and not errors :s
<persia> I think it retries until it succeeds.  I don't use pbuilder, but for sbuild I always pass debootstrap-mirror= to point at a local mirror.
<persia> I seem to remember pbuilder-dist having some code that tried to automate that, but I'm unsure how well it works.
<real_ate> persia: well i was having trouble with the UK mirror so I changed my sources to the main server... but this pbuilder is still using the local mirror
<real_ate> so it must be doing something intilligent!
<real_ate> nope!
<real_ate> it just died
<real_ate> have to start from the begining again ! :(
<diogorcorreia> hey guys, what i might to do to become a ubuntu tester?
<BUGabundo_movies> diogorcorreia: you join #ubuntu+1 once it opens again
<BUGabundo_movies> after tool chain opens
<asac> congrats for release!
<BUGabundo_movies> and you run a disposable system or VM
<BUGabundo_movies> ehy asac
<asac> hell BUGabundo_movies
<asac> hello ;)
<asac> funny typo
<BUGabundo_movies> diogorcorreia: reporting bugs to launchpad, following devel and devel-discuss MLs
 * BUGabundo_movies slaps asac
<asac> hehe
<diogorcorreia> BUGabundo_movies: once it opens again?
<diogorcorreia> BUGabundo_movies: is it closed for now?
<BUGabundo_movies> yes
<BUGabundo_movies> till tool chain
<diogorcorreia> ok, so i must download some tools before start?
<BUGabundo_movies> not really
<BUGabundo_movies> set up a vm, and install maverick, ready to upgrade to 11.04 devel
<yofel> diogorcorreia: see https://wiki.ubuntu.com/UbuntuDevelopment/UsingDevelopmentReleases for this, also see http://qa.ubuntu.com/testing/
<diogorcorreia> Ok, Thanks for the support!
<diogorcorreia> btw, anyone from Portugal here?
<BUGabundo_movies> diogorcorreia: #ubuntu-pt
<jackyalcine> hello?
<micahg> !ask | jackyalcine
<ubottu> jackyalcine: Please don't ask to ask a question, simply ask the question (all on ONE line and in the channel, so that others can read and follow it easily). If anyone knows the answer they will most likely reply. :-)
<jackyalcine> okay
<jackyalcine> soo ive been looking at IDEs
<jackyalcine> and im accustomed to Visual Studio.
<jackyalcine> of course this doesnt work on Ubuntu
<jackyalcine> but i want to use GTK
<jackyalcine> soo ?
<jackyalcine> good ideas?
<jackyalcine> ?
<huntz0r> jackyalcine, try mono-develop
<jackyalcine> i have.
<jackyalcine> it wasn't to my taste, though.
<jackyalcine> not a fully extensible system.
<huntz0r> what language do you wnt to use?  Yeah, wasn't to mine either tbh, but its as good as it gets AFAIK for .net dev under linux
<jackyalcine> C++
<jackyalcine> or C
<jackyalcine> so far, the Qt framework's awesome.
<jackyalcine> i'm working on making a more efficient GUI for the AirCrack software.
<huntz0r> jackyalcine, sounds cool!  I'm not a c/cpp programmer so I don't think I'll be of too much use, have you tried out ajanta?  I mean if you use that in conjunction with glade, you might be onto a winner
<huntz0r> other than that, eclipse or netbeans might be a better option, I've only used those for java development, but they do support c/c++
<huntz0r> jackyalcine, just tried out anjuta, seems to do what you need it to do.  In my opinion, the gui builder is not quite as simple to use as the visual studio one, but may be good enough for what you need.
<jackyalcine> ajunta was okayy!
<jackyalcine> but i need a GUI with forms intergration.. saves time.
<jackyalcine> and eclipse has a plugin for Qt, it's okay, but Eclipse feels bloated.
<jackyalcine> and Netbeans... >_< not a fan of Oracle.
<kklimonda> have you tried QtCreator?
<kklimonda> oh, you want to use Gtk+
<huntz0r> jackyalcine, if you double click the .ui file in the src folder of your new gtk+ project it comes up with a form builder thing, is that what you're after?
<jackyalcine> yess, huntz0r
<jackyalcine> im in for RAD for C/C++
<penguin42> valac seems an interesting approach
<jackyalcine> valac?
<penguin42> http://live.gnome.org/Vala
<penguin42> jackyalcine: It's an object based C varient where gobject's are 1st class parts of the language
<penguin42> shotwell is written in it
<jackyalcine> interesting.
<YokoZar> pitti: Yes although my hope is that wine 1.2.1 can go through like today
<sladen> keybuk: there's a question about yer MoM on the end of https://bugs.launchpad.net/indicator-application/+bug/625793
<ubottu> Launchpad bug 625793 in Application Indicators "Regression: Multiple Keyboard Layouts unusable: continuously changes layout + 100% CPU usage [updated]" [Undecided,In progress]
<sladen> keybuk: wondering how to extract just a portion of a patch
<shadeslayer> pitti: 1) Upstream says its not possible to backport and 2) upstream says we need to ship choqok 0.9.90 and qoauth 1.01
<shadeslayer> um
<shadeslayer> 1.0.1
<Chipzz> sladen: the thing that popped to mind when I read that was: queue the "Yo Momma" jokes ;P
<slangasek> pitti: ping
<ari-tczew> slangasek: did you know this bug? bug 653274
<ubottu> Launchpad bug 653274 in linux (Ubuntu) "Plymouth doesn't show Kubuntu or Ubuntu logo with Nvidia proprietary driver" [Undecided,Confirmed] https://launchpad.net/bugs/653274
<persia> ari-tczew, Do you know if it is fixable?  I thought that required KMS support for the relevant DRI.
<ari-tczew> persia: I don't know. I think that I'm also affected by this bug and now I'm attaching a photo to this bug.
<persia> ari-tczew, I'd encourage you not to highlight folk about bugs unless you happen to have some ideas about them to help fix them.  Especially not in this channel.
<ari-tczew> persia: I don;t mind.
<persia> Sure, but the folk you highlight might :)
<ari-tczew> persia: I saw that slangasek is involved in plymouth, so I wanted ask him whether he knows this bug. that's all.
<ari-tczew> and making too much policy in communicator making me upset (and I think that not only me)
<ari-tczew> we are not robot to talking in procedures
<persia> I'm not trying to set policy.  I just think that this channel works better when people use it to collaborate to solve issues, rather than asking about the many bugs.
<persia> Entirely my opinion, really.
<ari-tczew> persia: it's just release day, I think it doesn't matter which channel is excellent. natty is not open yet.
<persia> So?  Here's a list of a good bundle of issues probably not in the bug tracker that are probably release-critical and need immediate SRU: http://qa.ubuntuwire.com/bugs/rcbugs/
<ari-tczew> persia: OK, I won't investigate in bugs.
<ari-tczew> you did this one. I'm discouraged.
<persia> Feel free to investigate anything you like.
<ari-tczew> persia: take your policy communication and destroy ubuntu contribution. ban me if I couldn't ask here for bugs in fresh release.
<owen1> is this the final/offical xubuntu - http://cdimage.ubuntu.com/xubuntu/releases/10.10/release/
<persia> Like I said before, I'm only expressing my opinion.  I am not telling you about policy.  I'm not currently someone who even could ban from this channel.
<owen1> why it's not part of xubuntu's site?
<persia> owen1, yes.  Dunno.  Maybe the xubuntu guys didn't update their site yet.
<ari-tczew> persia: I think that we can close this discussion at this moment.
<owen1> persia: do they have an irc channel? we should tell them there is a new release...
<persia> owen1, I suspect they know, but you might try #xubuntu or #xubuntu-devel
<persia> The trick is that there might be a gap between the folk who know about the release and the folk who know how to update the website to talk about the release.
<spy6> hi there
<spy6> anybody seen problems on upgrading from 10.04 to 10.10 via "do-release-upgrade -d" like http://pastebin.ca/1958814
<spy6> without glibc systems are not so comfortable :)
<persia> spy6, That's definitely unexpected.  Please file a bug.  I suspect it's specific to your system (but have no idea why)
<spy6> persia: any suggestions which package?
<spy6> anyways .. even debugging is not so easy without glibc
<persia> I'd file against update-manager to start.
<spy6> any ideas if that problem maybe recoverable? i guess without glibc i need to reinstall
<persia> If you can get to IRC, you can probably grab the .deb from somewhere, adn dpkg -i install it.
<persia> Reinstallation might be easier.
<persia> But if you reinstall, you'll havea  hard time recreating the environment that exposes the bug.
<spy6> persia: dpkg -i /var/cache/apt/archives/libc6_2.12.1-0ubuntu6_i386.deb
<spy6> dpkg: /lib/tls/libc.so.6: version `GLIBC_2.4' not found (required by dpkg)
<persia> Oh, heh.
<spy6> persia: i'm online from a different system
<spy6> even dpkg needs glibc
<persia> Yeah, recovery from that might be highly awkward.
<ebroder> It...seems wrong that dpkg will let you remove dependencies of essential packages without extensive whining and screaming
<ion> Boot with a live CD and unpack the deb to the root partition manually
<spy6> ebroder: yeah, thought so
<persia> ebroder, libc6-i686 oughtn't be essential, because there's libc6 (but something is odd)
<spy6> ion: eh! nice idea ;)
<spy6> will try that tomorrow, when i have physical access to the system
<slangasek> ari-tczew: I've not been involved in plymouth maintenance this cycle; and I don't have any hardware that uses the proprietary drivers, so it's hard for me to debug such things
<GPenguin> whats a good alternative for #ubuntu?
<slangasek> what do you mean, "alternative"?
<GPenguin> slangasek: a smaller and more lively place maybe, where people discuss Ubuntu related topics
<micahg> GPenguin: #ubuntuforums?
<GPenguin> micahg: ah, thats a good one. i keep forgetting about it
<highvoltage> sabdfl: ubuntu is 6 years old with this release right? if you add the numbers of 42 (4+2) you get 6.
<ion> Iâm sure there are about a million ways to get a random number related to Ubuntu from another set of numbers related to Ubuntu. ;-)
<GPenguin> highvoltage: the real magic number for (german) hackers is 23 tho
<GPenguin> cause Robert A. Wilson said so
<GPenguin> and i am not saying sabdfl is involved in that conspiracy :-P
<GPenguin> 23, 2+3 - 5, Ubuntu 5 was the first release. RIGHT?!
<ari-tczew> GPenguin: The first release of Ubuntu was 4.10 Warty Warthog.
<GPenguin> oh, bummer
<ari-tczew> when natty will be open?
<micahg> ari-tczew: asking multiple times won't help, the answer is when it's ready :)
<ari-tczew> micahg: I know, but the sooner is the better
<stgraber> ari-tczew: anyway, you want to have the toolchain uploaded and some of the most common packages to be updated before uploading anything to a new release.
<stgraber> ari-tczew: also, it's usually a good idea to wait for UDS so at least you know what's the focus for the next release and what you should be focusing on.
<ari-tczew> stgraber: ok I understand and I remember, that it's related to gcc updates.
<ari-tczew> stgraber: heh, I work there where I want to work.
<GPenguin> !
<GPenguin> ari-tczew: but what if the entire team works against you then?
<GPenguin> knowing what the team plans to do can really help
<stgraber> ari-tczew: yes, gcc is one of the packages that's part of the toolchain indeed. So is binutils and the libc. Any major change of these might require rebuild of everything else that was uploaded.
<ari-tczew> GPenguin: there are a lot of things to do - merges, security updates, rc bugs, ftbfs, SRUs. I'm not a Canonical employee and I won't work with UDS objectives. I could, but I don't need.
<GPenguin> speaking of security updates, i am wondering what the status is regarding apparmor. it seems to disappear from novell/suse sites since quite a while. and the ubuntu community does not really reflect on it either
<GPenguin> is a proper selinux integration maybe more desireable?
<micahg> GPenguin: apparmor is actively used in Ubuntu and has been accepted as part of the linux mainline kernel
<GPenguin> micahg: how do you know its actively used when i may ask so directly?
<micahg> GPenguin: it's installed by default
<GPenguin> tomoyo e.g. is also accepted upstream btw
<micahg> GPenguin: https://launchpad.net/apparmor
<GPenguin> yeah, its installed by default like many other things. but it does not mean many people make use of it
<micahg> GPenguin: it works behind the scenes in most cases to enhance security
<ari-tczew> GPenguin: advanced questions about security are welcome on #ubuntu-hardened
<GPenguin> i am asking cause ... the only documentation is the release notes. the ubuntu wiki points to a suse wiki that does not exist, etc.
<GPenguin> that leaves a lot of mystery to the average users
<jdstrand> GPenguin: what page has the link to suse?
<jdstrand> GPenguin: apparmor is primarily maintained by Canonical these days
<GPenguin> https://help.ubuntu.com/community/AppArmor
<GPenguin> in the resources section
<jdstrand> ok. I'll adjust
<GPenguin> thats where it _would_ get interesting actually. there it stops :-)))
<jdstrand> GPenguin: there is also https://wiki.ubuntu.com/AppArmor
<GPenguin> checking it out, thanks
<GPenguin> ah, and there is a *-doc package which i missed
<GPenguin> lets see
<GPenguin> thats it, exactly what i was looking for: /usr/share/doc/apparmor-docs/techdoc.pdf
<jdstrand> GPenguin: ok, the community page has been edited. you might also be interested in https://apparmor.wiki.kernel.org/index.php/Documentation
<jdstrand> (I also added that to the wiki)
 * jdstrand wanders off
<GPenguin> hang on, why does that page look a lot different from the other kernel.org resource, hmmm
<jdstrand> GPenguin: it is a wiki page. projects in the kernel can ask for a wiki and they can do with it what they want
<GPenguin> yeah, somebody should re-work https://apparmor.wiki.kernel.org/index.php/Main_Page maybe
<jdstrand> GPenguin: it isn't 'official kernel documentation' -- but AppArmor is in the kernel so it is eligible to have a wiki hosted in the kernel.org namespace
<GPenguin> problem is, that i dont understand enough yet to be of any help
<jdstrand> GPenguin: the apparmor wiki is a work in progress
<jdstrand> there is a lot to do...
<GPenguin> but its good to know that Canonical took over from Novell
<GPenguin> so its no dead investment to learn more about it
<jdstrand> GPenguin: hardly! it is now in the official upstream kernel :)
<GPenguin> :-)
<jdstrand> GPenguin: we (Canonical and AppArmor upstream) are actively working on it for maintenance and features. you can expect more distributions besides Ubuntu and Suse (et al) to have it now that it is official (eg Debian)
<GPenguin> while redhat is more into expanding selinux support so it feels
 * jdstrand nods
<jdstrand> Ubuntu also has selinux available too, but it isn't the best fit for Ubuntu
<jdstrand> that is oversimplified
<jdstrand> AppArmor is a better default choice for Ubuntu
<GPenguin> for a desktop that changes often it requires too much work
 * jdstrand notes that Ubuntu is much, much more than a desktop OS
<GPenguin> e.g. with browsers like chromium
<jdstrand> than 'just' a desktop OS :)
<GPenguin> well! :-)
<spy6> okay ... i recovered vrom brocken libc
<GPenguin> the whole cloud computing stuff has yet to be defined
<jdstrand> (we've had a server install for years)
<jdstrand> and it is quite good, imnsho
<spy6> anybody a guess, why upgrading to 10.10 result into http://pastebin.ca/1958827?
<spy6> why is removing libc6-i686 so bad?
<spy6> there is no install candidat for it in 10.10
 * jdstrand really leaves
<micahg> spy6: you might want to try #ubuntu
<jibel> spy6, can you file a bug against update-manager, describe what you did and attach the files in /var/log/dist-upgrade/ . Thanks.
<spy6> jussi: thanks, I'll do
<BUGabundo> just made such a nice /etc/grub.d/40_custom that it should be default :P
<BUGabundo> boots from desktop livecd, netboot (that doesn't work cause of GPU driver), netboot.me and mini.iso
<BUGabundo> had to hack a bit of netboot, cause my grub2 is on 64bits, and netboot is 32
<BUGabundo> linux16 to the rescue
<persia> Why ought that be default?  I'd think it would confuse lots of folks.
<BUGabundo> $ pastebinit /etc/grub.d/40_custom   http://paste.ubuntu.com/510426/
<BUGabundo> persia: great rescue system :D
<GPenguin> a rescue system that depends on a working grub2 :-)
<BUGabundo> eheh
<BUGabundo> true
<BUGabundo> its also great to test daily isos
<GPenguin> for that its great, yeah
<superm1> BUGabundo, curious, when the system is mounted like that, does that partition containing the ISO still get a mount point by default?
<BUGabundo> superm1: I have /boot on a partition
<BUGabundo> cause my / is on btrfs
<superm1> ah
<BUGabundo> but yeah, on a non mounted system, you would need to adapt it
<BUGabundo> and change the hdroot
<superm1> BUGabundo, well if it can be adapted well to work with casper, it could make for a nice solution for usb-creator installs when switching to grub. usb-creator would just need to copy the .iso to the stick rather than extracting it
<BUGabundo> yeah, thinking about it
<BUGabundo> let me get you a stock set
<BUGabundo> superm1: http://www.panticz.de/MultiBootUSB
<BUGabundo> there's a stock boot from usb containing an ISO
<BUGabundo> my guess, have casper look for iso on mounte usb devices
<persia> BUGabundo, The tricky bit is that casper is inside a squashfs on the ISO
<persia> So the nifty config would be something that would work on the ISO, but when copied to USB/MMC/etc. would also work from that.
<persia> (one assumes a first-stage bootloader capable of device selection for this purpose)
<superm1> usb-creator can always write a custom config out too
<superm1> think something that just loop mounts the iso, and chainloads into the grub on the ISO already
<BUGabundo> persia: but casper _is_ capable of reading the ISO... that's what I did on 3 of those entries
<BUGabundo> cause its mounted loop
<persia> BUGabundo, Right.  I'm imagining that I have an Ubuntu install (which doesn't have casper) and I want to make a target to install for another device that has no optical drive.
<BUGabundo> well, put grub on the usb :P
<persia> superm1, I'm not a huge fan of usb-creator writing out configs, because it makes it harder to make it "just work" for armel/ppc (mind you, grub2/ppc needs more testing, and grub2/armel needs porting, so these aren't really first-class targets yet)
<BUGabundo> isn't that what usb-creator fakes?
<persia> Right.  Idea is to not fake it, but to have a configuration that allows one to just copy files from ISO to USB without anything else.
<persia> That means one can more easily write USB creator for Windows/OS X/Android/etc.
<BUGabundo> persia: then you need grub2 installed on a pendrive, and BIOS boot from it
<BUGabundo> then, having usb-creator just create a grub.cfg to boot from an ISO, just like I did mine
<persia> Precisely, and you have to do this in a way that lets you just copy the ISO rather than processing it.
<BUGabundo> I'm lost
<BUGabundo> what's hard about that?
<BUGabundo> copy, install, create cfg
<persia> Yep.  Not terribly difficult, but needs a bit of documentation, cleanup, and integration into existing systems.
<BUGabundo> I know nothing about usb creator, so I may be wrong
<persia> Oh, what's hard?  hard is making it just work for people who have never heard of "grub2" :)
<BUGabundo> grub2 has pretty neat support for all of that
<BUGabundo> ahhh
<BUGabundo> LOL
<BUGabundo> but all major distros are using grub2 for.... one or two cycles!
<BUGabundo> even debian has it on testing
<persia> Sure, but that means, given the market share numbers I'm making up right now, 95% of folks have never used it, and 99% of folks don't know they used it.
<persia> Or maybe I made a mistake in math: the idea being that 80% of grub2 users don't know they use grub2
<persia> And 95% of folks don't use any major distro (or any minor one, etc.)
<BUGabundo> ok, lets back up a little here
<BUGabundo> we are talking of improving usb-creator to boot from ISO instead of processing its content
<BUGabundo> OR
<BUGabundo> are we speaking of making a failsafe entrie in GRUB2 to allow remote/iso boot
<BUGabundo> ?
<persia> The former: so that the ISO can just be copied onto the USB stick, rather than needing to be unpacked, processed, etc.
<persia> Should reduce usb-creator code size significantly, and, ideally, more closely align the install experience.
<superm1> there would still need to be some processing done though to install grub to the stick
<BUGabundo> I agree
<superm1> which wouldn't necessarily making it any easier to implement on !linux systems
<BUGabundo> superm1: yes, that would be one part of it
<persia> Oh well.
<BUGabundo> we have usb creator on NON linux systems?
<superm1> well that was something persia mentioned above as being desirable
<BUGabundo> ahh
<persia> non-linux is definitely worth extra points.
<BUGabundo> grub2dos ?
<BUGabundo> the pen drive is already in fat32
 * persia had a 48-hour sprint for jaunty release to end up with a Windows tool to turn .img files on releases.ubuntu.com into bootable USB drives.
<superm1> the current way that usb-creator has grub code in place, when the ISOs are switched to booting with grub, dd is used to put the stages of grub in place
<superm1> so that can be easily adapted on other OS's
#ubuntu-devel 2011-10-03
<bookpage> how to make $display be set on a virt?
<RAOF> bookpage: export DISPLAY=:0 (or whatever)
<didrocks> good morning
<diwic> tjaalton, here we go again...the Nvidia kernel module refuses to load :-(
<diwic> tjaalton, that is, according to Xorg.0.log
<diwic> after latest days update
<tjaalton> nouveau loaded?
<diwic> tjaalton, seems not to, but I don't remember exactly how to check
<tjaalton> lsmod
<tjaalton> :)
<tjaalton> there should be a blaclist file in /etc/modprobe.d
<diwic> tjaalton, according to lsmod, "nvidida" is loaded
<tjaalton> installed by nvidia-current
<tjaalton> ok, so that's not it
<tjaalton> pastebin the log
<diwic> of xorg.0.log?
<tjaalton> yes
<diwic> hmm, how do I easiest do that without X
<tjaalton> pastebinit foo
<tjaalton> install it first if not
<diwic> http://paste.ubuntu.com/701490
<hrw> I am going to hate LP build failures. my packages (armel-cross-toolchain-base and armhf-cross-toolchain-base) both ftfbs on launchpad. but when I built them locally in pbuilder or in LP chroot they got built fine. arghhhhhh
<tjaalton> diwic: so if you 'stop lightdm; start lightdm' it works ok?
<diwic> let me try
<tjaalton> the logfile complains about the kernel module, but you said it was loaded
<tjaalton> maybe lightdm is too fast
<tjaalton> though the x driver should do the loading
<diwic> tjaalton, ah, that did it (had to do that in sudo though)
<tjaalton> sure
<diwic> maybe file a bug against lightdm? Or nvidia-current?
<tjaalton> put dmesg on pastebin too, i'll check what it says there
<hrw> any ideas how such build failure happens?
<infinity> dpkg-source: error: syntax error in eglibc-2.13/debian/control at line 114: duplicate field Multi-Arch found ?
<infinity> That's hardly buildd-specific.
<diwic> tjaalton, paste.ubuntu.com/701496
<hrw> infinity: yes
<hrw> infinity: I do not have it in pbuilder or in chroot fetched from LP build farm
<hrw> infinity: with exactly same dsc used
<tjaalton> diwic: ok, so it start's loading the module at 3.9s, X barfs at 4.4s, and then at 5.1s the loading is complete
<tjaalton> an interesting race condition.. maybe a bug in the xserver
<infinity> hrw: There's nothing fancy about how we call sbuild in lp-buildd.  Are you sure you're using a clean copy of the chroot from launchpad, and nothing but the build-deps?
<tjaalton> diwic: or in the nvidia driver ratherr
<tjaalton> -r
<infinity> hrw: (You can copy the list of installed packages that sbuild shows in the log, rather than using apt-get source, to be sure)
<hrw> infinity: clean it was
<hrw> infinity: anyway I will unpack this chroot again, do a step-by-step build and check at failed moment
<infinity> hrw: To be honest, I'd rather not have an armhf cross-compiler in oneiric anyway, unless it includes the new loader location, which I'm assuming it doesn't.
<hrw> infinity: armel cross fails same way
<hrw> infinity: as they share source package source
<diwic> tjaalton, ok, let me know if I should file a bug about it and if so against what component
<infinity> hrw: Sure, I know.  I'm not saying it's failing on purpose because I don't want it in the archive, just saying I'm not sure I care if it gets fixed (and I'm not sure it should have even been accepted, but it wasn't me who did it).
<tjaalton> diwic: ubuntu-bug nvidia-graphics-drivers
<tjaalton> diwic: and mention that the x driver is too impatient waiting for the kernel module to load
<hrw> infinity: it needs to be fixed cause cross toolchain is not installable now
<hrw> infinity: so... ;(
<infinity> They were new packages...
<infinity> Like, 2 days ago.
<infinity> It's just as easy to remove them as to fix them. :P
<hrw> infinity: nope - gcc-*-armel-cross ones got built in meantime
<diwic> tjaalton, bug 865111
<ubottu> Launchpad bug 865111 in nvidia-graphics-drivers (Ubuntu) "X quits, instead of waiting for kernel module to load" [Undecided,New] https://launchpad.net/bugs/865111
<infinity> hrw: Let me reproduce it here.
<tjaalton> diwic: thanks, tseliot will take it from there
<diwic> tjaalton, ok, thanks for the workaround in the mean time :-)
<infinity> hrw: Still, I wish we hadn't accepted this whole lot.  It enabled biarch too, didn't it?  Which we'll probably have to turn off again. :P
<infinity> hrw: Oh well.
<hrw> infinity: I got multilib toolchain buildable - but need to fix issues while using it
<infinity> "Issues" like "the loader for both arches is in the same filesystem location, and ABI-incompatible"?
<hrw> infinity: report bug?
<infinity> Or like "gcc on ARM is completely missing run-time biarch detection".
<infinity> hrw: We have a fix for the former (the loader issue), as discussed and agreed upon at LPC, but it means disabling biarch builds until we fix the latter.
<hrw> infinity: link to notes/bugs?
<infinity> cross-distro for the LPC notes.
<hrw> ok
<infinity> I have no bug filed for the broken biarch business.
<infinity> But if you'd like to make gcc on ARM work the same as it does on x86, be my guest.
<infinity> Right now, while we can do "biarch builds", it's complete BS, cause they don't actually work, at all.
<infinity> And I'm not even convinced we need them, but that's a different discussion.
<infinity> Cross-compiling soft from hard and hard from soft sounds like an odd corner-case to me, rather than just treating them as completely seperate arches.
<infinity> (Usually we want biarch to be able to cross-compile kernels when the kernel arch != host arch, but for ARM, that doesn't matter..)
<hrw> so ubuntu/armel is not able to build ubuntu/armhf packages now?
<hrw> natively? (I did not checked)
<infinity> No.
<infinity> Not with multilib, that is.  Obviously, a chroot that's fully-native armhf will work fine (though still has the wrong loader path).
<infinity> But, like I said, to fix the loader path, it's either a rewrite of multilib for ARM (which is beyond broken), or disabling it.
<infinity> Disabling it is the path of least resistance for now, if we want to actually have an hf port in the next 6 months.
<infinity> Unless someone really wants to fix multilib this week.
<infinity> (feel free to volunteer)
<infinity> hrw: You should probably be in #linaro-armhf ...
<hrw> infinity: shit. forgot to add this to autojoinlist
<hrw> I am on 16 irc channels ;(
<infinity> That's all?
<hrw> on 5 networks
<hrw> infinity: for 16 years of doing irc I used <10 for all years before canonical/linaro
<infinity> Heh.
<infinity> IRC channels are cheap, it's a nice way to keep topics focussed.
<infinity> Especially in massive communities like Debian and Ubuntu.
<infinity> Maemo had similar partioning, and the main channels were just completely silent.  It was a bit creepy.
<infinity> partitioning*
<infinity> I should probably sleep.  It's 2am.
<infinity> hrw: Poke me about your build failure tomorrow if you haven't figured it out.  I'll throw some spare cycles at it.
<hrw> infinity: I hope to get it solved today by myself but thanks for offer
<infinity> hrw: But we should talk multilib more, if you're interested enough to consider looking at it, and have the resources to allocate.
<hrw> infinity: would be nice if multilib bugs would be reported
<infinity> hrw: In talking with doko, I thought the "multilib doesn't work on ARM" thing was well-known upstream.
<hrw> infinity: arm multilib was done by doko and it's really fishy
<infinity> hrw: Hence didn't report anything.
<hrw> infinity: upstream did not had multilib for arm iirc
<hrw> infinity: only CSL had
<infinity> hrw: Well, upstream being Linaro, or whatever.  Not me. :P
<hrw> ok
<infinity> hrw: Either way, it's completely broken, and would love to actually discuss it sometime, rather than just file a bug and forget about it.  But we can file bugs while we discuss too. :)
<infinity> To be fair, it would have "worked" if we'd gone with the crazy "loader auto-detecting HF binaries" route, but that way just looks like madness to me.
<infinity> But for the seperate loaders case, it can't work, cause it doesn't select at compiler run-time like x86 does, it's all hardcoded.
<infinity> Some serious cargo-culting of x86 multilib would probably work.
<ubuntu-baltix> hi all
<ubuntu-baltix> ev: hi, are you online?
<ev> ubuntu-baltix: yes, hi
<ubuntu-baltix> ev: it seems you forgot to update ubiquity-slideshow-ubuntu translations from launchpad after translation freeze :(
<ev> I updated them on the 28th of September
<ubuntu-baltix> ev: but translation freeze was on 29th :)
<ev> ubuntu-baltix: I'll stick an upload in the queue, but it's up to the release team to decide if they want to accept it.
<ubuntu-baltix> ev: please update ubiquity-slideshow-ubuntu, because at 28th september Lithuanian translation was half complete (about 50%), but at 29th - fully translated (100%) :)
<ubuntu-baltix> I think it's very important to have fully translated slideshow in release candidate
<ev> ubuntu-baltix: I just said I would put an upload of the translations in the queue, but it's not my call as to whether or not it goes in.
<ubuntu-baltix> ev: thanks, could you tell me who should decide if accept or not? Maybe pitti ?
<ev> ubuntu-baltix: I already did. The release team.
<ubuntu-baltix> ev: Where I can talk with release team? ;)
<ev>  #ubuntu-release
<ubuntu-baltix> ev: thans again :)
<ev> sure thing
<soren> Did I miss it, or do we not know what 12.04 will be called yet?
 * cjwatson has not yet seen a name
<cjwatson> sabdfl: ^- getting kind of urgent :)
<azeem_> I thought it was going to be the pink panther?
<Laney> now that would make a good login sound
<seb128> Laney, no login sound is a good login sound ;-)
<azeem_> you could just have the first two notes, then the desktop should be there
<azeem_> would also remove IP-issues
<janimo> seb128, you mean broken pulseaudio :) ?
<diwic> janimo, a broken login sound is hardly pulseaudio's fault
<diwic> janimo, more likely to have to do with libcanberra or other upper layer
<janimo> diwic, is not every sound going through pulse?
<seb128> janimo, ;-)
<diwic> janimo, usually, yes
<diwic> janimo, but playing the login sound involves other components of the audio stack as well and my point is that PulseAudio is every now and then blamed for things incorrectly.
<seb128> diwic, speaking of that do you know what would be the right way to have no login sound by default?
<seb128> we want to do that next cycle
<diwic> seb128, hmm, good question - I assume some kind of override to the gnome sound theme
<diwic> seb128, who are "we", btw?
<diwic> seb128, I haven't heard that request before.
<artfwo> hi
<artfwo> do I have to request an FFE in order to sync the package from debian at this stage of development?
<sgnb> I hope so
<tumbleweed> artfwo: if there are only RC bug fixes, no new features, and it's not seeded, then you can just upload it
<artfwo> tumbleweed, i don't have upload rights, but a sync fixes uninstallable package in my case, take a look at bug 865334
<ubottu> Launchpad bug 865334 in p7zip-rar (Ubuntu) "Sync p7zip-rar 9.20.1~ds.1-3 (multiverse) from Debian unstable (non-free)" [Undecided,Confirmed] https://launchpad.net/bugs/865334
<om26er> patch pilot is missing :p
<tumbleweed> artfwo: LGTM
<seb128> om26er, bryceh and micahg are pilots today
<seb128> om26er, chrisccoulson is on holidays this week
<seb128> om26er, but it's a bit early for bryceh to be up still I guess
<tumbleweed> meh, this marking bugs confirmed because they affect multiple uses messes with sync requests...
<om26er> seb128, robert_ancell seems to be current thats an error?
<seb128> om26er, he probably forgot to sign off
<om26er> i'll wait for bryceh to get something re-SRUed
<tumbleweed> artfwo: oh, you only mentioned the most recent changelog entry, not the intermediate ones. That would require an FFe
<seb128> om26er, https://www.google.com/calendar/embed?src=6k1e5rq45m1bdqq0n1ge3oqaok@group.calendar.google.com&ctz=Europe/Berlin&gsessionid=OK
<artfwo> tumbleweed, but the current version in oneiric isn't installable anyway, does that qualify for an FFE as well?
<tumbleweed> artfwo: it means I'm very likely to give you a FFe. But you still need to apply for it
<om26er> seb128, thx :)
<om26er> I have a question related to uploads to archive.. if a release 3.8.16-0ubuntu1~natty3 is rejected for some reason after fixing my branch will the same version upload again work fine? or would it automatically get rejected?
<artfwo> tumbleweed, could you take a look at bug 865334 - is there enough data for an exception?
<ubottu> Launchpad bug 865334 in p7zip-rar (Ubuntu) "[ffe] Sync p7zip-rar 9.20.1~ds.1-3 (multiverse) from Debian unstable (non-free)" [Undecided,Confirmed] https://launchpad.net/bugs/865334
<geser> om26er: if the source got rejected you can keep the version number
<gtec> hello everyone: I am unclear on the difference between a pxelinux.0 image and a nbi.img. Is it required that etherboot boots a pxelinux.0 image as oppose to a nbi.img?
<tumbleweed> artfwo: yes, thanks
<tgardner> does anyone know whats up with armel-cross-toolchain-base in Oneiric? You can't install gcc-4.6-arm-linux-gnueabi because of dependency issues. Launchpad thinks armel-cross-toolchain-base was published 2 hours ago.
<hrw> tgardner: I know
<hrw> tgardner: wait two more days ;(
<tgardner> hrw, thats pretty inconvenient at this point in Oneiric development. 2 days ?
<apw> hrw what is it doing which takes 2 days?
<cjwatson> how long it'll take hrw's fix to build, presumably
<cjwatson> "published 2 hours ago" means the source package
<hrw> moment
<tgardner> Launchpad appears to think the build is done
<cjwatson> actually it says pending publication now, so maybe s/2 days/an hour/
<hrw> one more source to build - armhf-cross-toolchain-base (got uploaded just moment ago, need to be accepted), then rebuild of gcc-4.[56]-armel-cross (ftfbs-ed because of armel-cross-toolchain-base failure)
<cjwatson> oh, it's in NEW
<hrw> I had some linaro tasks to do which had higher priority.
<cjwatson> processed now, so next publisher run I suppose
<hrw> thank you
<tgardner> cjwatson, thanks, will give it a go in an hour or so
<bdmurray> Could somebody look at bug 859188?  Its not clear to me what might be going on here.
<ubottu> Launchpad bug 859188 in apt (Ubuntu) "E: Internal Error, No file name for libgl1-mesa-glx" [Low,Confirmed] https://launchpad.net/bugs/859188
<hrw> for p-cycle I will move to 'publish to ppa first' method - as LP builds are not reproductible even with chroots from LP
<slangasek> bdmurray: confusing error message; to apt-get install --reinstall a multiarch: same package that you have more than one version of installed, you have to do "apt-get install --reinstall $pkg $pkg:$otherarch", or else you get that error
<hrw> or I am doing something wrong
<bdmurray> slangasek: so they have installed for i386 and amd64?
<slangasek> bdmurray: yes
<cjwatson> hrw: well - I do have to say, most people with this problem are doing something wrong, or very few of us would ever get anything done!
<cjwatson> mind you if your build is *that* sensitive to details of the chroot then there's probably something wrong there too
<cjwatson> occasionally there's something that depends on the running kernel, which in the case of LP builds is rather older than the distribution it's building for
<hrw> cjwatson: I fetched chroot from LP and got it built in it.
<hrw> cjwatson: I will try to find time in p-cycle to check some issues
<didrocks> can someone bump the unity build in the ubuntu-destkop ppa (to prepare some testing for an eventual tomorrow upload with those fixes + few additional ones): https://launchpad.net/~ubuntu-desktop/+archive/ppa
<SpamapS> barry: is there any progress on porting dh_python2 to lucid?
<didrocks> barry: thanks for the Quickly fix btw :)
<barry> SpamapS: doko_ is working on that
<SpamapS> barry: ahh cool thanks
<SpamapS> doko_: and I ask you, how is the dh_python2 port to lucid coming along? :)
<bdmurray> slangasek: Do you have any thoughts on bug 813065?
<ubottu> Launchpad bug 813065 in ubiquity (Ubuntu) "Live session switches to VT console briefly" [High,Confirmed] https://launchpad.net/bugs/813065
<bryceh> !pilot in
<bryceh> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Beta 2 Released | Archive: Final Freeze | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: robert_ancell, bryceh
<om26er> bryceh, can you please sponsor https://code.launchpad.net/~om26er/ubuntu/natty/unity/unity-fix-761409 :)
* micahg changed the topic of #ubuntu-devel to: Beta 2 Released | Archive: Final Freeze | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: bryceh
<om26er> bryceh,  you sponsored it last time but seems there was an issue at your end last time so the upload got rejected :/
<om26er> here is the changelog of the rejected upload http://launchpadlibrarian.net/79155358/unity_3.8.16-0ubuntu1~natty2_3.8.16-0ubuntu1~natty3.diff.gz
<bryceh> om26er, what was the issue at my end?
<om26er> bryceh, the changelog also have --- unity-3.8.16.orig/.bzrignore.THIS
<om26er> +++ unity-3.8.16/.bzrignore.THIS
<om26er> the one that was uploaded to the archives my branch did not have it
<om26er> though i am not sure how things work
<bryceh> ok
<bryceh> om26er, done
<om26er> bryceh, thank you :-)
<infinity> jamespage: Your nova changelog doesn't even remotely match the diff.
<jamespage> infinity: how so?
<infinity> jamespage: http://launchpadlibrarian.net/81802657/nova_2011.3-0ubuntu4_2011.3-0ubuntu5.diff.gz
 * jamespage re-reads his changelog entry
<infinity> jamespage: I see the permission bits in postinst... And then a ton of other stuff.
<jamespage> infinity: I see - looks like the packaging branch was probably not up-to-date
<infinity> Right, well.  I'm going to reject this, if you'd like to re-upload with just the postinst fix. ;)
<jamespage> infinity, absolutely
<jamespage> infinity: somethings not right - it looks like older patches where included in the upload to the archive
<jamespage> can't find zul at the moment but it needs verification/unpicking
<infinity> jamespage: You can just make your postinst change to the archive version?
<jamespage> infinity: well I could but I'm concerned that we have an incorrect backported patch - I'd like to get that resolved/verified as OK as well
<infinity> jamespage: Fair enough.
<dobey> is anyone else having booting/network issues with current oneiric?
<dobey> because i have two laptops that are now pretty much entirely useless after updating them within the last 24 hours :(
<dobey> SpamapS: did you break my laptops?
<SpamapS> dobey: probably ;)
<SpamapS> dobey: whats the issue?
<SpamapS> dobey: do they say waiting for network configuration?
<seb128> <dobey> in normal boot the splash works fine, it just says "Waiting for network..."
<seb128> SpamapS, ^
<seb128> SpamapS, he said that it never finishes waiting
<bdmurray> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Beta 2 Released | Archive: Final Freeze | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: bdmurray, bryceh
<SpamapS> I may have created a huge red herring with that message...
<dobey> SpamapS: yes
<SpamapS> the problem is I can't *hide* it when its completed.
<dobey> SpamapS: my dell duo doesn't boot now
<dobey> it stays waiting for network
<SpamapS> dobey: can you boot with noquiet and --verbose ?
<dobey> my u820 boots but has other issues
<SpamapS> dobey: it never says Waiting at least 60 more seconds ?
<dobey> SpamapS: i don't know. can you be more verbose about where to add them?
<dobey> SpamapS: it does say that
<dobey> SpamapS: it just doesn't ever finish waiting
<SpamapS> dobey: does it ever say that its booting with an incomplete configuration?
<SpamapS> dobey: the process that is used for those messages is really failsafe.. unless /bin/sleep segfaults or something.
<dobey> SpamapS: i'll let you know in a couple minutes
<SpamapS> dobey: so if you see the first two, but not the third, then something is breaking *after* those messages are long dead and gone.
<dobey> oh ffs; now it's doing fsck
<dobey> SpamapS: seems like it is breaking long before, since i shouldn't ever see those messages
 * SpamapS ponders adding a post-start to clear the messages
<SpamapS> dobey: you'll see them if your loopback adapter isn't up for some reason, or if you have interfaces configured in /etc/network/interfaces
<dobey> waiting up to 60 moar now
<dobey> SpamapS: and neither of those should be true unless an update broke something
<dobey> and well, i think it's obvious an update broke something
<SpamapS> dobey: as far as the noquiet/--verbose .. edit the grub kernel command line and remove 'quiet' , and add '--verbose'
<dobey> booting without full config
<dobey> except it is a message wrought with lies
<dobey> as evidenced by the lack of actual booting
<SpamapS> dobey: ok, so it should boot now.. unless lightdm or plymouth is broken
<SpamapS> dobey: ctrl-alt-f1 should also get you a tty to login to
<dobey> SpamapS: what should i see with noquiet --verbose ?
<dobey> SpamapS: nope, it just had the textual output of the init scripts
<SpamapS> dobey: kernel messages, services starting..
<SpamapS> dobey: what was the last thing shown?
<SpamapS> alt-f2 might actually be better, it starts on runlevel [23] ..
<dobey> it's still waiting for the network
<SpamapS> dobey: before those messages that you already saw in plymouth.. anything else?
<dobey> stopping failsafe boot delay was the last thing
<dobey> lo is the only thing in /etc/network/interfaces
<SpamapS> Interesting
<dobey> and i have no network connection
<SpamapS> ls -l /run/network
<SpamapS> should be a dir, 'static-network-up-emitted'
<dobey> that exists
<SpamapS> I'm most intrigued why your system hasn't "booted" at this point, because you are clearly in runlevel 2 if you have a login on tty2
<SpamapS> can you look for clues in /var/log/syslog? Maybe the display manager failed to start
<SpamapS> dobey: at the point that dir exists, and when your filesystems are up, thats when runlevel 2 should have started and the messages should have stopped.
<SpamapS> hmm I wonder though.. /etc/network/if-up.d/upstart creates that dir, and then runs initctl emit
<dobey> well running /etc/init.d/lightdm restart got me a login screen and i can log into unity now
<dobey> but no network or bluetooth
<SpamapS> btw, /etc/init.d/<anything> is deprecated in Ubuntu
<SpamapS> use service
<dobey> i did use service, and it didn't work
<SpamapS> because?
<kenvandine> restart lightdm
<kenvandine> is all you need
<SpamapS> kenvandine: and is very dangerous
<kenvandine> oh?
<dobey> it said "not found" or something like that
<SpamapS> kenvandine: it doesn't reload the upstart job.. and does not properly run pre-stop's
<bdmurray> SpamapS: speaking of service how do you know what services names are avaiable?  I get confused about samba vs smbd ...
<SpamapS> use service. :)
<kenvandine> oh... i thought it was an upstart command
<dobey> SpamapS: the deprecated message says to use restart
<dobey> not service
<dobey> maybe you should fix that :)
<seb128> sudo restart lightdm often fails there
<seb128> it says there is no lightdm runnin
<SpamapS> bdmurray: unfortunately, that one is still unresolved in a single tool. 'initctl list' for upstart jobs, find /etc/init.d -type f  works for sysvinit
<seb128> where it's running ;-)
<SpamapS> yeah the deprecated message should be fixed
<dobey> anyway
<dobey> my laptops are broken
<bdmurray> SpamapS: thanks initctl was what I was missing
<hallyn_> Daviey: jdstrand: bug 842845 , final debdiff pulls a bunch of patches from upstream git.  Pls take a look.  It appears to solve the issue, and I think it should go into oneiric.
<ubottu> Launchpad bug 842845 in libvirt (Ubuntu Oneiric) "problems starting multiple lxc instances concurrently" [High,In progress] https://launchpad.net/bugs/842845
<hallyn_> running out, biack in a bit
<SpamapS> dobey: indeed, trying to determine why lightdm didn't start
<SpamapS> dobey: --verbose would give us a clue. can you boot with that?
<dobey> "unknown instance"
<dobey> i did boot with that
<dobey> where is it supposed to give a clue at? i didn't see any
<SpamapS> right, restart doesn't work when it was never started, thats another annoyance.
<SpamapS> dobey: /var/log/syslog would have any errors about lightdm
<SpamapS> its possible that it didn't exit with any "errors" it just decided not to start.
<SpamapS> but that would be odd
<dobey> i think i need to reboot
<SpamapS> dobey: anything in /var/log/syslog ?
<dobey> some stuff but i can't tell if it's from me doing restart or from booting
<SpamapS> dobey: you can match up the timestamps with the switch to runlevel 2
<dobey> SpamapS: it appears something is stopping it, and then killing it with SIGTERM
<dobey> last lightdm related message is "lightdm state changed from post-stop to waiting"
<slangasek> bdmurray: 813065> I think I'll try to reproduce that; it might be an easy win for release
<bdmurray> slangasek: okay, I was able to see it in a virtual machine fwiw
<SpamapS> dobey: brb, need to go move laundry from washer to dryer..
<SpamapS> dobey: have you tried rebooting w/ --verbose yet?
<slangasek> bdmurray: does "VT console" mean a login prompt, a blinking cursor, or a black screen?
<slangasek> (just to be sure I know what I'm looking for)
<bdmurray> slangasek: none of the above - I saw boot log messages
<dobey> SpamapS: yes, but i can't see anything useful. something is telling lightdm to start, then stop, then it kills lightdm
<slangasek> bdmurray: aha
<slangasek> bdmurray: oh; this bug is for lucid, not for oneiric?
<bdmurray> slangasek: its tagged oneiric too and thats what I tested
<slangasek> ok
<SpamapS> dobey: very intersting. I don't see any direct reasons that lightdm would be sent SIGTERM by upstart... it only stops on runlevel [016] .. none of those are happenign surely.
<dobey> isn't that "poweroff" ?
<SpamapS> 0 is halt/poweroff
<SpamapS> 6 is reboot
<SpamapS> dobey: something could be doing a 'stop lightdm' tho
<SpamapS> it does a stop in its own script..but then exit 0 right after that.
<SpamapS> dobey: does this return 0:
<SpamapS> [ ! -f /etc/X11/default-display-manager -o "$(cat /etc/X11/default-display-manager 2>/dev/null)" = "/usr/bin/lightdm" -o "$(cat /etc/X11/default-display-manager 2>/dev/null)" = "/usr/sbin/lightdm" ]
<dobey> right
<dobey> wtf
<SpamapS> actually hmmmmmmmmmm
<dobey> that's a lot of typing :(
<SpamapS> if [ "$RUNLEVEL" = S
<SpamapS> I think that may be a misuse of the RUNLEVEL variable
<dobey> in lightdm's init script?
<SpamapS> yeah
<SpamapS> the script was recently changed to simplify with less ()'s.. I wonder..
<dobey> waoh
<dobey> woah even
<dobey> somehow i got network
<dobey> </magic>
<SpamapS> dobey: I think this may be it.. if one of the other events comes *after* runlevel 2 ... RUNLEVEL is still "S"
<dobey> meh, update/reconfigure didn't help
<SpamapS> dobey: no I think you have found a bonified, majorly crap race condition
<infinity> jamespage: Err, did you re-upload the same broken one again?
<dobey> SpamapS: how can we fix?
<SpamapS> we need to check with the actual runlevel command, I think
<SpamapS> I have a working test case which shows the problem
<SpamapS> dobey: if I give you a replacement lightdm.conf, can you try it out?
<SpamapS> I'm trying it in a VM now
<dobey> SpamapS: give me a diff
<dobey> SpamapS: then i can just change it, since i can't easily just copy stuff over
<slangasek> SpamapS: I don't understand where the race condition is, can you explain?
<SpamapS> slangasek: sure, RUNLEVEL is set only when the 'runlevel' event arrives
<SpamapS> slangasek: but it may have been set by some other event that arrived before 'runlevel'
<slangasek> really?
<slangasek> which event would set it?
<SpamapS> slangasek: Yeah, thats my hypothesis
<SpamapS> I'm testing it out now :-P
<slangasek> ok :)
<SpamapS> slangasek: no idea!
<SpamapS> slangasek: nothing exports it except /etc/init/rc.conf
 * slangasek nods
<SpamapS> slangasek: one theory I also have is that there's a bug in upstart which copies it in even when it doesn't match
<SpamapS> slangasek: either way, it seems the most likely cause for dobey's problems that RUNLEVEL is coming up as "S" instead of "2" during lightdm's script
<SpamapS> tho.. there's another problem with that, which is that he's seeing the failsafe messages.. hrm
<dobey> this is but one of the many problems i am currently facing with oneiric :-/
<slangasek> SpamapS: seems strange that only dobey would be affected
<dobey> that's what i said
<slangasek> SpamapS, dobey: you've already ruled out /etc/X11/default-display-manager as the cause?
<slangasek> oh
<jamespage> infinity: no
<dobey> i haven't ruled anything out as the cause. but i really have no idea what is going on at this point
<slangasek> runlevel [!06]
<slangasek> SpamapS: why is that not runlevel [!06S]?
<slangasek> or even [!016S]
<slangasek> apparently we're using lightdm to handle stopping of plymouth in runlevels 1,S ? that doesn't make sense...
<slangasek> (what if you don't have lightdm installed, after all?)
<SpamapS> slangasek: oo I didn't realize.. [!06] is *wrong*
<infinity> jamespage: Well, it came back to the queue 28 minutes ago. :P
<dobey> where is that?
<SpamapS> slangasek: is 'runlevel S' emitted at bootup?
 * infinity rejects harder.
 * SpamapS tests that
<jamespage> zul and I are like ships in the night this evening
<slangasek> SpamapS: well, it's deliberate... I'm not sure that changing it in the obvious way is *right* either
<slangasek> SpamapS: no, only 'telinit S' gets you runlevel S, by design
<slangasek> otherwise /etc/init/rcS.conf would fire on every boot
<slangasek> dobey: could you post the log from booting with --verbose?
<dobey> i suspect not easily
<SpamapS> slangasek: I thought rcS.d *was* executed every time the system booted. :-P
<slangasek> SpamapS: running sulogin? :)
<slangasek> dobey: if you have networking up, perhaps pastebinit is of use?
<dobey> well i'm guessing the log doesn't rotate on every boot
<dobey> what block would be most useful?
<SpamapS> dobey: I'd be interested to compare the output of 'last' with 'grep init: /var/log/syslog'
<slangasek> dobey: I'd want everything logged by init since boot
<SpamapS> dobey: also the long line in /etc/init/lightdm.conf right after 'if [ -n "$UPSTART_EVENTS" ]'
<SpamapS> dobey: actually just cat /etc/X11/default-display-manager would be helpful
 * SpamapS goes afk again for 5 min
<dobey> default-display-manager just says "lightdm"
<slangasek> dobey: and just to be sure, what does 'debsums -s -e lightdm' show?
<dobey> what provides debsums?
<slangasek> the debsums package :)
<dobey> good thing network decided to actually start working
<dobey> too bad it doesn't on my other laptop
<dobey> changed file /etc/lightdm/lightdm.conf
<bigon> mmmh I hava valac (0.12) that segfault when building https://edge.launchpad.net/~gnome3-team/+archive/gnome3/+build/2820433
<bigon> with debian version it build perfectly
<slangasek> dobey: "changed file" - did you change it as part of the debugging, or was it already broken and that's what's causing your failures?
<slangasek> dobey: you should have an /etc/init/lightdm.conf.dpkg-dist that you can compare with... and in theory replace with to get the system working again...
<dobey> slangasek: that file was already changed, and doesn't seem like it would be related
<dobey> slangasek: wrong lightdm.conf
<slangasek> oh, right
<slangasek> sorry
<dobey> and i actually have no idea why it's different from the packaged version
<slangasek> I think that one might get dynamically modified by lightdm itself
<slangasek> (means conffiles are the wrong tool for it, but anyway - not relevant here)
<dobey> right
<dobey> where should i put this log?
<slangasek> dobey: in a bug report / pastebin / people.c.c?
<dobey> slangasek: https://chinstrap.canonical.com/~dobey/syslog.verbose
<slangasek> <yoink>
<SpamapS> slangasek: it strikes me that calling 'stop' in the script section may not be a good idea
<SpamapS> slangasek: exit 0 should suffice...
<slangasek> SpamapS: 'stop' is preferred
<SpamapS> slangasek: in this case, stop would cause upstart to send SIGTERM.. would it not?
<slangasek> maybe it's triggering a bug here, but it's a bug to be fixed if so
<dobey> well i need to go for now; thanks for helping debug
<slangasek> SpamapS: SIGsomething, sure; but the event's already received and processed by that point, so it shouldn't hurt?
<dobey> let me know if i need to test anything, my awaylog will catch it
<SpamapS> slangasek: it shouldn't, no.
<slangasek> dobey: does this system have hybrid graphics?
<SpamapS> wait
<SpamapS> 14:39 < dobey> default-display-manager just says "lightdm"
<SpamapS> dobey: not /usr/bin/lightdm or /usr/sbin/lightdm ?
<slangasek> ah, heh
<SpamapS> that *would* do it
<bdmurray> I'm looking at a pytrainer bug regarding communicating with gpsbabel and gpsbabel uses a 'usb:' parameter to communicate with the gps.  Anyway what device is 'usb:' so I can change permissions on it?
<slangasek> bdmurray: probably something under /dev/bus/usb
<bdmurray> slangasek: yes, a way to check occurred to me
<slangasek> depending on how the device name is being constructed, there's probably something under /sys/bus/usb/devices that lets you query the mapping I guess
<cjwatson> bdmurray: how do you know which services are available> 'service ' <tab> <tab>
<SpamapS> slangasek: my laptop is affected too
<SpamapS> lightdm is waiting for 'plymouth deactivate'
<SpamapS> also the stop signal is being ignored in the pre-start for failsafe...
<slangasek> SpamapS: "too"?  isn't that an entirely different issue?
<SpamapS> slangasek: my symptoms are identical to dobey
<SpamapS> I almost never reboot.. so when I did just now.. no lightdm
<slangasek> SpamapS: stop signal> ah yes, did you not see the bug I reported about that/
<SpamapS> slangasek: no I didn't see that bug.
<SpamapS> slangasek: do we need to set some handler to die quicker?
<slangasek> SpamapS: one sec, I'll assign it to you ;)
<slangasek> SpamapS: bug #863864
<ubottu> Launchpad bug 863864 in upstart (Ubuntu) "/etc/init/failsafe.conf doesn't actually stop on runlevel" [Medium,Triaged] https://launchpad.net/bugs/863864
<SpamapS> anyway, lightdm is waiting on plymouth deactivate.. which is polling an "anon_inode"
<slangasek> strange...
<slangasek> I haven't seen this in any of my testing
<slangasek> can you file a plymouth bug?
<slangasek> also, please boot with plymouth:debug=file:/var/log/plymouth-debug.log and attach
<SpamapS> slangasek: sure.. anything I can do to debug immediately?
<slangasek> debug or unstick?
<slangasek> debugging, I think you need to boot with plymouth debugging on
<slangasek> unstick, I'd try stop lightdm ; plymouth quit; start lightdm
<slangasek> (from tty2, say)
<SpamapS> is it possible failsafe's plymouth tickling is causing plymouth deactivate to not work?
<slangasek> I don't believe so
<slangasek> ok - it's *possible*
<slangasek> but that's a plymouth bug if so
<SpamapS> hrm.. does stop not actually tell pre-start's to exit?
<slangasek> correct
<SpamapS> Garhhh.. ok.. poor assumption there.
<slangasek> it changes the goal for the job, but does not kill a running process
<slangasek> not a running pre-start, that is
<slangasek> it waits for that to end on its own
<SpamapS> ok, so does that mean I need to change it to a task and change the rc-sysinit to 'stopped failsafe' ? thats kind of the mechanics I was looking for, but its not as clear in rc-sysinit
<SpamapS> that or I have to check runlevel before every plymouth message
<SpamapS> oh wait I can check my status with status
<slangasek> SpamapS: that's my suggestion in the bug report - completely untested though
<slangasek> checking with status - yuck :)
<SpamapS> I suppose I should switch back to X from console and read your suggestion
<SpamapS> slangasek: so I think 'stopped failsafe' should be fine, rather than an explicit event... is this acceptible as a fix for 11.10 ?
<slangasek> SpamapS: 'stopped failsafe' would cause /etc/init/rc-sysinit.conf to fire *twice*, unless you somehow made it a conditional 'stopped'
<SpamapS> slangasek: twice?
<SpamapS> slangasek: failsafe would only start at boot, no?
<slangasek> SpamapS: the failsafe job is always going to stop, the question is whether it stops due to timeout or because it's killed.  so rc-sysinit is "start on (filesystem and static-network-up) or started failsafe"; if you change "started" to "stopped" at the same time you move the bulk of its functionality into 'script', on a successful startup you will *always* match both parts of that 'or'
<SpamapS> slangasek: ahh right
<slangasek> hence, needing an explicit event instead of 'stopped'
<SpamapS> slangasek: ok, simple diff, and it fixes the problem with lightdm waiting on plymouth deactivate too
<slangasek> wait, what?  how does it fix that?
<SpamapS> ????
<SpamapS> I had it happen 3 times in a row before this fix
<SpamapS> slangasek: my guess.. plymouth waits for some socket to be closed which is held open by 'plymouth message' ?
<slangasek> 'plymouth message' is one shot, should return immediately
<slangasek> I mean, the execution of that script wouldn't work correctly if it didn't
<SpamapS> slangasek: I think this is more important than "Medium" .. I noticed on my other more pure oneiric laptop that I saw Waiting for network configuration ... once just before lightdm popped up...
<slangasek> yeah, I was going to raise the severity but hadn't gotten 'roundtuit yet
<slangasek> (after realizing the implications on boot, not just shutdown)
<SpamapS> ok, how about I raise it, and upload this diff which is relatively small, but probably needs serious scruitiny
<slangasek> SpamapS: sounds good to me
<bdmurray> What's the right status for a merge that shouldn't happen? A typo fix in the debian control file of a package we sync.
<SpamapS> Needs Fixing in the comment, and Work in Progress for the MP
<bdmurray> Work in Progress seems like a bad fit
<slangasek> well, the right way is 'rejected'
<slangasek> but I think there might still be a bug where only the TB can reject merge proposals for ubuntu-branches?
<SpamapS> I always feel like if its fixable easily, then Work in Progress is appropriate.. it means its the owner's problem
<slangasek> (whereas it should be "anyone who can upload")
<slangasek> SpamapS: this is "this should not be merged because it should be done in Debian instead"
<slangasek> so "rejected" is correct... if you can get to it
<bdmurray> which I can't
<SpamapS> Oh I misread the point of the question
<TheMuso> 3~/c
<hallyn_> Daviey: hey are you there?
<hallyn_> Daviey: d'oh, you never pushed http://people.canonical.com/~serge/ipxe-bin.debdiff . (I forgot about it and forgot to check and prod :)
<hallyn_> Daviey: it's needed in o
<SpamapS> slangasek: uploaded
<SpamapS> whoa and just as I hit enter on emit, one of my tests fails .. second upload pending.. damnit
 * SpamapS vows to starve his fingers till they lose another ring size
<SpamapS> slangasek: want to reject that upload?
<SpamapS> actually I rejected it
<slangasek> SpamapS: hum, as long as we're uploading upstart, I think I'd like to fix up the various manpage bugs at the same time
<slangasek> (undocumented events)
<SpamapS> slangasek: ok, I'll backout my debcommit --release..
<SpamapS> slangasek: ok my change is in there as r1331
<slangasek> SpamapS: cheers
#ubuntu-devel 2011-10-04
<bdmurray> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Beta 2 Released | Archive: Final Freeze | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: bryceh
<bryceh> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Beta 2 Released | Archive: Final Freeze | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<Daviey> hallyn_: o/
<Daviey> hallyn_: So i thought that debdiff was only required if we jumped to qemu 0.15, and the current version worked great with 0.14.. was i wrong?
<bookpage> does anyone know if it is common for d3d programs to read from $DISPLAY?
<hallyn_> Daviey: you were backward :)
<hallyn_> Daviey: the ipxe that's in the archive right now will work with 0.15.  But our qemu is still 0.14.2 and it needs the old names
<hallyn_> i don't know how i originally messed that up (but i did)
<hallyn_> Daviey: i only realized that it was still wrong bc the libvirt qa-regression-testing from jdstrand failed :)
<Daviey> hallyn_: Okay, if nobody beats me - i will upload it tommorrow morning.
<Daviey> too tired to review it right now.
<nigelb> s/tired/drunk/g
<nigelb> :P
<Daviey> hah
<slangasek> bdmurray: I haven't been able to reproduce bug #813065 with USB boot; I get a brief black screen, but no text. what boot log messages did you see?
<ubottu> Launchpad bug 813065 in casper (Ubuntu) "Live session switches to VT console briefly" [High,Confirmed] https://launchpad.net/bugs/813065
<slangasek> bdmurray: fwiw, architecturally we're always going to flash to black between the ubiquity menu and the "try ubuntu" session because there's no good way to hand off the X server between the two; but anything writing text to that console at boot probably needs to be fixed
<pitti> Good morning
<pitti> slangasek: can you please reupload your upower lucid SRU with a fixed bug ref in the changelog? (missing '#')
<bdmurray> slangasek: probably stuff like starting bluetooth, pulseaudio is configured for per user seesions etc...
<didrocks> good morning
<infinity> mvo: I haz a question for you.
<lifeless> mvo: and I (conflict checker is whining :P)
<infinity> mvo: Me first, me first!
<infinity> (It's bedtime for me, lifeless can suck it :P)
<infinity> (That came out dirtier than I meant it)
<lifeless> indeed
<infinity> I think he joined IRC just to tease us.
<infinity> And then ran off.
<didrocks> infinity: yeah, it's the 1st part of the show right now, he'll be back in 30 minutes for the 2nd :-)
<mvo> lifeless: conflictchecker just needs a new dpkg-dev I think with xz support
<mvo> infinity: s'up?
<mvo> infinity: (think of this as with my best german accent)
<infinity> mvo: Oh dear.
<infinity> mvo: So.  I've been looking at update-apt-xapian-index and its angry effect on ARM.  And then I read a manpage (crazy, I know), and found -u...
<infinity> mvo: Is there any reason why we're not using '-u' in cron.daily/apt?
<infinity> mvo: It brings run time down from 6 minutes to 30 seconds, and very limited I/O.
<mvo> infinity: we used to do that, but it modifies the DB in-place and we had some (corruption) issues with software-center that looked releated to this. so we disabled it again, but I tihnk for P we should give it a try again as we found the db corruption bug in another spot
<infinity> mvo: If you found the bug, can we flip it back? :/
<infinity> mvo: This (literally) kills ARM desktops.
<micahg> that might have saved lubuntu from dropping it as well
<infinity> mvo: Like, we become completely unusable for those 6 minutes.
<infinity> mvo: Which is extra special when it's one of the very first things a user sees (thanks to anacron kicking off cron.daily 5 minutes from first boot)
<mvo> infinity: it runs with nice/ionice, it makes it unusable?!?
<infinity> mvo: No amount of nicing or ionicing can help you when your storage is SD/MMC.
<infinity> mvo: It brings the system to a halt.  DBUS connections time out.  Nothing can start.  Etc, etc.
<infinity> mvo: '-u', on the other hand, seems very well-behaved.
<mvo> infinity: *urgh* thats definitely bad. I really don't want to change this globally at this point and bring in potential regressions for i386/amd64, bt I understand that this is a big problem
<infinity> mvo: We'd talked about it before, and you never mentioned -u, you just mentioned that it needed profiling.
<infinity> mvo: So, I was a bit shocked to discover that it can play nicely. :P
<infinity> mvo: Honestly, while I'm saying this with my ARM hat on, it's a big problem for any system that's "not fast".
<infinity> mvo: My crappy Atom netbook does the same "grind to a halt" thing, just for slightly less time.
<lifeless> mvo: any chance you can arrange that ? I'm swamped with new baby :)
<infinity> mvo: is that a DC machine?
<infinity> Err.
<infinity> s/mvo/lifeless/
<lifeless> infinity: yes
<infinity> Then just file an RT ticket, they have dpkg with xz support, it's running on cocoplum.
<mvo> infinity: it was me who actually added -u, its not my mission to make everything slow ;)
<mvo> lifeless: yeah, I will file a rt
<infinity> lifeless: 1.15.5.6ubuntu4.5.0.ISPATCHED.10.04
<lifeless> mvo: awesome, thank you!
<infinity> mvo: ^
<mvo> lifeless: sorry, I would have done it earlier but the release (you know how it is)
<infinity> mvo: I assumed it was you who added the flag, I just figured maybe you'd forgotten to get around to turning it (back) on.
<lifeless> mvo: totally
<infinity> mvo: And, again, if the DB corruption thing seemed to be a red herring (or, rather, a software-center bug), I'm all for bringing -u back. ;)
<mvo> infinity: well, its not 100% clear that it was a red herring or actually a real bug. its possible there were two bugs, a) the in-place modification b) a threading bug that got later fixed
<infinity> mvo: I'd also be willing to take the blame for doing something like "if [ "$(dpkg --print-architecture)" = "armel" ]; then $extra_args = '-u'; fi", if you're super scared about it breaking our primary arches.
<mvo> infinity: that sounds good to me
<mvo> infinity: I can add that now
<infinity> mvo: That would be lovely.
<infinity> mvo: *hug*
<mvo> infinity: or feel free to just upload it yourself :)
<infinity> mvo: Well, if I upload it myself, I'd have to not mix language syntax, as above.
<infinity> But I think I can manage that. :P
<infinity> mvo: You don't have any other apt stuff planned or lined up?
<mvo> infinity: maybe pending, but its not clear yet if that should hit final or not (could be -updates too)
<mvo> infinity: so I think a upload is fine
<mvo> lifeless: rt filed
<infinity> mvo: If you have -updatesish stuff pending and it's sane, I'd just as soon see it now.
<infinity> (note the "if it's sane")
<infinity> mvo: lp:apt the right branch?
<infinity> Oh, the Sources file claims lp:~ubuntu-core-dev/apt/ubuntu
<infinity> mvo: Is your pending stuff on the packaging branch?  If so, I'll have a look at it.
<infinity> mvo: If not, give me a pointer to it, and I'll put on some other hats for a bit.
<mvo> infinity: the only thing pending is a fix for 857472 but the best approach is not yet clear for this one
<mvo> infinity: and yeah, lp:~ubuntu-core-dev/apt/ubuntu
<infinity> mvo: Oh, the thing we "fixed" in stable release by just commenting it out? :P
<mvo> infinity: *cough*
<mvo> yes
<infinity> mvo: Don't you just want check-sigs instead of list-sigs?
<infinity> mvo: Ahh, I see, collision concerns when using the CLI.
<mvo> infinity: yeah, thats the core of the problem, that there is no guard against collisions in gpg
<infinity> mvo: vorlon's suggestion seems workable, though.
<infinity> mvo: As long as you export and verify each new key individually, you can't collide.
<infinity> mvo: (if you take the new keyring as a bundle, you have a weird vector as described by mdeslaur)
<infinity> mvo: But keys are already signed, I think your wanting to sign the keyring is overengineering. :p
<infinity> mvo: You just need to validate each one as an isolated entity.
<infinity> mvo: (signing a keyring file that contains a bunch of signed keys is sort of like gzipping a level-9 compressed jpeg, as far as how useless both are)
<mvo> infinity: right. overengineering> probably :) and yet the approach is pretty simple and bullet proof. but yeah, I think the individual export/verify is equally good
<infinity> mvo: And you still want to switch --list-sigs to --check-sigs in add_keys_with_verify_against_master_keyring(), I suspect.
<mvo> indeed
<mvo> infinity: hrm, now you made me work on this and I'm not even finished with reading my mail this morning ;)
<infinity> *cough*
<infinity> I'm a bad man.
<infinity> Is it worse if I tell you I'm going to bed now?
<mvo> infinity: heh :) it must be like 3am or so for you now?
<dholbach> good morning
<seb128> hey dholbach
<dholbach> salut seb128
<maniyadav> hi i'm making an application with quickly. how can i add application in games section with icon. this is my first deb application. please help
<maniyadav> Hi all. How to add application to global menu from python code
<maniyadav> please help
<cjwatson> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Beta 2 Released | Archive: Final Freeze | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: cjwatson
 * dholbach hugs cjwatson
<seb128> cjwatson, hey
<seb128> cjwatson, robert_ancell was looking for you, I think he got the infos he needed from talking with pitti but it would be nice if you could check if http://bazaar.launchpad.net/~lightdm-team/lightdm/1.0/revision/1232 address the locale issue you are having
<cjwatson> seb128: I doubt it, it'll find en_GB.iso88591 first
<cjwatson> "an encoding" isn't good enough.  it needs to actually check locale aliases properly
<seb128> pitti, ^
<pitti> seb128: yes, that's what I said in #u-desktop
<pitti> it should prefer an .utf8, and only fall back to "first match" if there isn't one
<cjwatson> why can't it just try the locale that PAM gives it?
<pitti> all this is just a rather horrible hack anyway, for a corner case
<cjwatson> I can't imagine what possible benefit it gets from rummaging through 'locale -a' output when PAM has already given it a usable locale
<pitti> cjwatson: it first tries pam, then falls back to accountsservice/.dmrc, and then to ~/.profile
<cjwatson> it should only do this stuff if the locale it gets back from PAM isn't usable
<pitti> yes, absolutely
<cjwatson> pitti: that's not working
<zarlino> I'm trying to package a Qt app. I'd like to depend on Qt>=4.5. I used shlibs:Depends and it automatically adds Qt4.7 to the dependencies. Should I remove completely shlibs:Depends? Should I set the dependencies by hand?
<cjwatson> I can see plainly in my log that it gets a locale from PAM and then ignores it
<pitti> all this heuristics stuff should only be done if there is no pam locale
<cjwatson> well, except for chopping off the codeset and then poking around in 'locale -a' for something that looks similar
<pitti> cjwatson: so that seems to be another bug then
<cjwatson> pitti: that is this bug, IMO
<seb128> ok, shame that robert_ancell left before you joined
<cjwatson> I have a perfectly good preconfigured locale that it isn't using any more
<cjwatson> [+8.46s] DEBUG: PAM returns environment 'GNOME_KEYRING_CONTROL=/tmp/keyring-JAW17p GNOME_KEYRING_PID=2592 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games LANG=en_GB.UTF-8 LANGUAGE=en_GB.UTF-8:en'
<cjwatson> [+8.47s] DEBUG: Using locale en_GB for language en_GB
<pitti> cjwatson: presumably you have some language setting in your ~/.dmrc?
<cjwatson> pitti: http://paste.ubuntu.com/702159/
<pitti> (I'm just guessing here, based on the checks that robert mentioned)
<sivang> sladen: around?
<sivang> (hi all)
<seb128> cjwatson, can you check in d-feet, org.freedesktop.Accounts, on your user account, the Language property?
<seb128> pitti, ^ I think it uses user account first nowadays
<cjwatson> seb128: en_GB
<cjwatson> and in "User Accounts" it says "English (United Kingdom) [ISO-8859-1]" - I absolutely never set that
<seb128> that seems to be the issue
<cjwatson> and there is no option in that combo box for English (United Kingdom) [UTF-8]!
<cjwatson> or even just "English (United Kingdom)"
<seb128> weird
<pitti> not that users should even be concerned about the encoding
<cjwatson> sure, but it's given me the _wrong one_
<pitti> I noticed that these days we generate the non-UTF8 locales as well
<seb128> seems like an accountsservice issue then
<cjwatson> pitti: even if we didn't, it would be wrong to assume they weren't there
<pitti> in earlier releases we only generated the UTF-8 ones from /usr/share/i18n/SUPPORTED
<cjwatson> I've probably generated these ones by hand
<cjwatson> because it's useful for me for man-db testing
<pitti> cjwatson: yes, true; just mentinoing that this could have uncovered a bug there
<pitti> cjwatson: no, I have them as well, and it's a fairly clean install
<cjwatson> (or, I mean, I probably would have generated them by hand if they weren't there by default)
<pitti> I just noticed it while looking at robert's request; not blaming it for that actual bug
<cjwatson> so why do we trust accountsservice over PAM?  it seems poorly-baked
<GunnarHj> cjwatson, pitti, seb128: Hi guys!
<pitti> I don't think we should
<pitti> we even fixed accountsservice to write ~/.profile
<sladen> sivang: dates.  Although I am not be in London.  I leave on ~Oct 15th and return on ~Novemeber 6th
<seb128> hey GunnarHj
<pitti> so there is little reason to not just use that
<pitti> it doesn't need to try and craft a locale from that accountsservice value
<cjwatson> all the other users on my system have the same broken value for Language
<pitti> hey GunnarHj, how are you?
<GunnarHj> Just noted that Robert disapproved a suggested fix of cjwatson's bug. I think he is missing something important.
<seb128> seems like the redhat guys who worked on accountsservice didn't test it much with non-utf8 locales on the system
<seb128> GunnarHj, that's what we are discussing
<seb128> GunnarHj,
<seb128> <seb128> cjwatson, can you check in d-feet, org.freedesktop.Accounts, on your user account, the Language property?
<seb128> <cjwatson> seb128: en_GB
<seb128> <cjwatson> and in "User Accounts" it says "English (United Kingdom) [ISO-8859-1]" - I absolutely never set that
<seb128>  
<seb128> so seems
<seb128> - there is a bug in accountsservice that makes it pick the wrong non-utf8 locale
<seb128> - there is a bug in lightdm that it prefers the accountsservice locale to the pam one
<pitti> ^ or that it uses acccountsservice's one in the first place
<pitti> <pitti> we even fixed accountsservice to write ~/.profile
<pitti> <pitti> so there is little reason to not just use that
<cjwatson> writing .profile is very irritating behaviour incidentally
<cjwatson> those are my dotfiles, leave them alone
<pitti> but unlike accountsservice language-selector has done that for ages
<GunnarHj> Yes, I understand. I think I'm to blame for this confusion. The thing is that the Ubuntu specific patch of accountsservice I wrote sets values like "de" or "es_ES" as the "Language" property, not complete locale names.
<pitti> we need to store the user language *somewhere*, and ~/.profile works reasonably well for that
<cjwatson> fortunately I have .bash_profile so junk in .profile is ignored
<cjwatson> automatically editing shell scripts is crazy
<pitti> yes, it is, we just don't have something better
<cjwatson> the user language should be set through PAM
<pitti> cjwatson: where does PAM take it from, if not from the environment?
<cjwatson> there has been a ~/.environment file for years
<cjwatson> I think, let me check that assertion
<pitti> GunnarHj: ^ interesting
<pitti> that indeed sounds a lot better then
<cjwatson> wait
<pitti> anyway, we won't touch the ~/.profile thing for oneiric
<pitti> it has worked reasonably for many years
<cjwatson> sorry, ~/.pam_environment
<pitti> and for P (gosh, name!) we want to drop language-selector anyway
<cjwatson> pam_env.c:#define DEFAULT_USER_ENVFILE    ".pam_environment"
<pitti> so in P we should change accountsservice to write to ~/.pam_environment instead of ~/.profile
<pitti> cjwatson: thanks
<cjwatson> and if you do that it will actually be consistent across PAM sessions
<pitti> cjwatson, GunnarHj: filed bug 866062
<ubottu> Launchpad bug 866062 in accountsservice (Ubuntu P-series) "SetLanguage(): Write ~/.pam_environment instead of ~/.profile" [Medium,Triaged] https://launchpad.net/bugs/866062
 * cjwatson goes back to being patch pilot as he's supposed to be :)
<pitti> but either way, lightdm shoudln't ask accountsservice
<pitti> at least not for oneiric yet
<GunnarHj> pitti: yes, it should, but there is still an urgent need for a change in lightdm.
<pitti> GunnarHj: right; above bug is a side issue, I targetted it to P
<seb128> pitti, I'm not sure why robert_ancell did it this way, could you drop a comment in the bug for him or sort it with him tomorrow morning if he's still online?
<pitti> GunnarHj: for oneiric's lightdm we should just drop the accountsservice query step IMHO
<pitti> seb128: sure
<seb128> danke
<pitti> seb128: which bug # was that again?
<seb128> 864618
<GunnarHj> pitti: I'm not sure what you mean, now.
<pitti> seb128, GunnarHj: I updated bug 864618
<ubottu> Launchpad bug 864618 in lightdm (Ubuntu Oneiric) "UTF-8 locale no longer set" [Critical,In progress] https://launchpad.net/bugs/864618
<seb128> pitti, thanks!
<GunnarHj> pitti: The set_language() function in src/session.c simply make a mess of the locale settings in Ubuntu.
<pitti> GunnarHj: but that part isn't the problem AFAICS
<pitti> GunnarHj: it seems lightdm checks the Language property of accountsservice and uses that to override what it got from PAM
<pitti> and it shouldn't do that IMHO
<seb128> cjwatson, GunnarHj, pitti: btw we should still have an accountsservice bug open about the encoding issue since that's buggy in the g-c-c account capplet
<seb128> i.e
<seb128>  <cjwatson> and in "User Accounts" it says "English (United Kingdom) [ISO-8859-1]" - I absolutely never set that
<GunnarHj> pitti: Maybe that's not the problem cjwatson encountered, but it's the problem I discovered thanks to cjwatson's bug.
<seb128> that's orthogonal to the lightdm issue
<pitti> so if the accountsservice property is wrong (due to whatever bug), it destroys the locale; and if it is correct, it will not actually change the resulting locale
<GunnarHj> pitti, seb128: Right now lightdm overrides LANG with a locale that represents the selected language. It breaks the settings as soon as LANG != LC_MESSAGES.
<GunnarHj> seb128: What's the problem you mentioned with the language setting in User Accounts?
<seb128> GunnarHj, it's listing an iso locale as being selected and not give the choice to pick an non iso one
<seb128> GunnarHj, i.e it's preferring the iso-8859-1 over the utf-8 one for cjwatson
<seb128> GunnarHj, where his .dmrc, config, etc are utf-8
<GunnarHj> But ... it does not set any locale directly, but lets accountsservice do it. And a-s certainly does not set any non-UTF-8 locale.
<seb128> GunnarHj, well it's not "setting", it's what is displayed in the user account ui
<GunnarHj> seb128: You don't see the locale name there, do you?
<seb128> <cjwatson> and in "User Accounts" it says "English (United Kingdom) [ISO-8859-1]" - I absolutely never set that
<seb128> <cjwatson> and there is no option in that combo box for English (United Kingdom) [UTF-8]!
<seb128>  or even just "English (United Kingdom)"
<seb128> GunnarHj, ^ that's what he wrote before
<seb128> cjwatson, sorry for the highlights
<GunnarHj> seb128: Weird. Have to take a look.
<GunnarHj> seb128: What I see in the User Accounts UI is the output from /usr/share/language-tools/language-options
<GunnarHj> i.e. as expected
<pitti> but that doesn't output locales
<pitti> at least not valid ones
<pitti> but language names
<pitti> (with country variants)
<GunnarHj> pitti, seb128: No, and that's intentional. UA sets language, not locale. :)
<pitti> lightdm tries to map that to a valid locale, using a rather hackish heuristics
<pitti> GunnarHj: right
<pitti> ligthdm iterates through `locale -a` to map that value to a locale, but doing that perfectly is nontrivial
<seb128> GunnarHj, not quite, /usr/share/language-tools/language-options doesn't list fr options for me but I've "franÃ§ais (France)" is the ua ui
<pitti> so my proposal was to drop that instead of trying to fix it
<seb128> and "franÃ§ais" in the list
<seb128> ok, sorry guys, I'm creating confusion there
<seb128> let's do one issue at the time
<seb128> I will let you sort the lightdm issue
<seb128> we can discuss the accountsservice,user-account one later
<GunnarHj> seb128, pitti: Yes, the lightdm issue is by far the most important right now.
<GunnarHj> pitti: How do we proceed? Can you take a look at the MP for bug 864618?
<ubottu> Launchpad bug 864618 in lightdm (Ubuntu Oneiric) "UTF-8 locale no longer set" [Critical,In progress] https://launchpad.net/bugs/864618
<pitti> GunnarHj: what does set_language() do?
<GunnarHj> pitti: It sets LANG with a locale that represents the language.
<pitti> GunnarHj: to what?
<pitti> from the "Language" property in accountsservice?
<GunnarHj> Yes, it's derived from there.
<GunnarHj> And it happens after ~/.profile is sourced.
<pitti> GunnarHj: followed up to MP, mostly directed towards Robert
<GunnarHj> pitti: Ok, that sounds like valid questions. I'll try to recall the details and get back to you.
<pitti> GunnarHj: cheers!
<tumbleweed> pitti: is there a known problem with the retracers? (I can't see any related bugs) I just got an aborted oneiric retrace that looks like it was using natty dbgsyms
<pitti> tumbleweed: the permanently known one is that dbgsyms keep vanishing, due to the very hackish way we retrieve and publish them
<pitti> there is no known acute breakage with them otherwise
<tumbleweed> err, yeah, that's it. Thanks
<siretart> could anyone please copy sun-java6-jdk from natty-partner to oneiric-partner, please?
<dholbach> Riddell, thanks muchly!
<jamespage> siretart: thats odd - it was there - I even have it installed
<siretart> jamespage: probably from natty-partner?
<jamespage> siretart: I don't think so - it have an oneiric version number
<siretart> jamespage: interesting
<jamespage> siretart: it may be related to the dlj changes that oracle have made - iamfuzz is the guy to ask but he's not around until later
<siretart> jamespage: in the mean time, it would be great to have at least the natty package available
<jdstrand> so, it seems that almost any time I do an apt-get upgrade, at the end of it all, evolution spouts errors about losing connection to dbus
<jdstrand> I have not pinpointed the issue yet
<seb128> dobey, SpamapS: is bug #856810 the issue you were discussing yesterday?
<ubottu> Launchpad bug 856810 in netcfg (Ubuntu) "Boot hangs at "Booting system without full network configuration..."" [Undecided,Confirmed] https://launchpad.net/bugs/856810
<seb128> bug #864174
<ubottu> Launchpad bug 864174 in lightdm (Ubuntu) "boot hangs waiting for lightdm after purging gdm" [Undecided,Confirmed] https://launchpad.net/bugs/864174
<hrw> is there snapshot.debian.org service for ubuntu? I need gcc-snapshot 20110813 (removed by mistake)
<Laney> you can get the old files from launchpad
<seb128> jdstrand, there is a gconf bug which has been forwarded upstream where they asked for somebody to add a dbus-monitor log from when having the issue
<seb128> jdstrand, if you want to get the info that could be useful
<Laney> â changelog â version â [arch] â files produced from this build
<Laney> hrw: ^
<hrw> thx
<jdstrand> seb128: looking for the bug.... can't seem to find it
<seb128> jdstrand, it's the first one in the gconf2 list iirc
<seb128> ups, gconf
<jdstrand> ah, was looking at evo
<seb128> bug #848198
<ubottu> Launchpad bug 848198 in gconf (Ubuntu) "Sporadic gconf error messages" [High,Triaged] https://launchpad.net/bugs/848198
<seb128> i.e https://bugzilla.gnome.org/show_bug.cgi?id=659835
<ubottu> Gnome bug 659835 in gconf "Configuration server couldn't be contacted: D-BUS error: Method "Set" with signature "s(ii)" on interface "org.gnome.GConf.Database" doesn't exist" [Normal,Unconfirmed]
<jdstrand> that's the one. thanks
<seb128> oh, upstream got some new comments
<Laney> ah
<Laney> that's the same bug we're having with banshee https://bugzilla.gnome.org/show_bug.cgi?id=659841
<ubottu> Gnome bug 659841 in general "Hang when GConf can't be called(?)" [Major,Unconfirmed]
 * Laney thought it was a problem there
<seb128> seems like ross just commented, maybe he will look at it ;-)
<Laney> it can cause banshee to go into a cpu death spiral which is pretty unfortunate
<jdstrand> ah, well, good then :)
<jdstrand> that has been an annoying bug :)
<seb128> it is indeed ;-)
<pitti> file binary/casper/filesystem.squashfs
<pitti> [...] created: Thu May 11 19:57:20 2084
<pitti> Welcome to the world of tomorrow!
<pitti> the officially built Chinese images are only from 2018, which clearly explains why they are bigger than they should be
<pitti> cjwatson: ah, I found out why http://china-images.ubuntu.com/oneiric/daily-live/20111001/ is oversized
<pitti> cjwatson: a local build is 690 MB, the official build is 714
<pitti> cjwatson: the amd64 squashfs has 98 MB (uncompressed) /var/lib/apt/lists/
<pitti> I didn't check the i386 on
<pitti> e
<pitti> hm, seems our official images have the apt indexes as well
<pitti> although both live-build and ubuntu-defaults-image make an effort to clean them
<pitti> cjwatson: does cdimage slide any hook into ubuntu-defaults-image which causes an apt-get update?
<pitti> cjwatson: ah, the difference is that our official CDs don't have universe _Packages (only main), while the daily Qin images also have universe; that's a gzip -9 delta of 21 MB
<dobey> seb128: yes that's an instance of the bug; i think slangasek and SpamapS got it fixed last night, but don't know if the upload got accepted yet
<seb128> dobey, ok
<pitti> cjwatson: I followed up to the Qin status mail now
<tkamppeter> pitti, how do I proceed with bug 867437, it is a CUPS package install failure but without terminal log.
<ubottu> Launchpad bug 867437 in cups (Ubuntu) "package cups 1.4.6-5ubuntu1.4 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Undecided,New] https://launchpad.net/bugs/867437
<cjwatson> pitti: cdimage does not and cannot do anything to the live filesystem build; you can look at livecd-rootfs
<pitti> cjwatson: right, that calls apt-get update; I just wonder where the difference between local and cdimage build is
<pitti> cjwatson: but anyway, at this point I suspect that the easiest solution would be to promote ubuntu-defaults-zh-cn to main and only build from main/restricted?
<mdeslaur> cjwatson: uhm...so openssl security updates won't get the reboot notification anymore?
<pitti> mdeslaur: the just accepted openssl update?
<pitti> mdeslaur: that removes the notifications for anything _but_ upgrades
<pitti> like first-time installs
<ogra_> the changelog says that it still is there for "important upgrades"
<ogra_> whatever that is :)
<pitti> it just moves the notification check into the if [ ! -z "$2" ]
<mdeslaur> pitti: let me check that for a sec, I though it was moving it into the major upgrade section ("if dpkg --compare-versions "$2" lt 0.9.8g-9 && dpkg --compare-versions "$2" gt 0.9.8c-4etch3; then")
<cjwatson> mdeslaur: I can't understand how it can possibly make sense to nag people with a reboot-required message when we're not taking the effort to restart services we know how to restart
<cjwatson> mdeslaur: at any rate it is certainly wrong to emit that message on fresh installs
<cjwatson> mdeslaur: if you want to adjust it further, perhaps you could follow up to the bug; the previous state was wrong though
<mdeslaur> cjwatson: because we don't want to automatically restart services when their security updates are being installed automatically, but we do want them to schedule their service restarts themselves, as it means they're running stuff with the insecure openssl
<cjwatson> pitti: it does move it into the major upgrade section
<cjwatson> mdeslaur: it would really, really, REALLY help if there were some COMMENTS about this
<cjwatson> it is inscrutable
<mdeslaur> cjwatson: agreed
<cjwatson> and finding previous wrong code did not fill me with confidence that anyone had actually known what they were doing
<cjwatson> so please do fix it up :-)
<highvoltage> sabdfl_: howdy! It's getting to that point in the release where people have to say "P" or "Oneiric+1" way too much :)
<SpamapS> dobey: have you updated your laptops yet? I think the change to upstart that Steve uploaded yesterday fixes your issues.
<dobey> SpamapS: is it accepted/in-archive yet?
<cjwatson> mdeslaur: so it sounds like moving it inside [ ! -z "$2" ] but not inside dpkg --compare-versions blah makes sense
<SpamapS> dobey: yes
<mdeslaur> cjwatson: yes, that's what I'll do, and I'll add some comments
<dobey> SpamapS: and only one laptop is hitting that issue; the other laptop is a different problem, and network doesn't seem to work at all on it
<cjwatson> thanks
<SpamapS> dobey: that may be related
<SpamapS> dobey: though I'd be curious to hear what the other issues
<SpamapS> s/issues/issue is/
<dobey> SpamapS: my other laptop boots up and i can log into gnome from lightdm and everything, but it just asays "Networking disabled" in the nm applet
<seb128> SpamapS, hey
<SpamapS> dobey: oh, that does sound different.
<seb128> SpamapS, is the the issue slangasek fixed similar to bug #864174
<ubottu> Launchpad bug 864174 in lightdm (Ubuntu Oneiric) "boot hangs waiting for lightdm after purging gdm (wrong default-display-manager)" [High,Confirmed] https://launchpad.net/bugs/864174
<seb128> dobey, could you check on that one if ck-list-sessions lists your session active or not?
<dobey> SpamapS: ifconfig shows all the interfaces though
<dobey> seb128: on the no-network one?
<seb128> dobey, yes
<dobey> ok, in a minute
<dobey> SpamapS: rebooting now with the upstart update
<superm1> infinity, is there an armel PPA that can be used for test builds to see if things will compile properly on armel?
<superm1> er a way to get a PPA activated for an account for that
<dobey> SpamapS: hrmm, well i don't seem to get the network messages now
<dobey> SpamapS: but alas, it just sits at the splash screen
<SpamapS> dobey: and on tty1/tty7 ?
<SpamapS> dobey: also try pgdn on the splash
<dobey> i could switch to tty[1-6] and log in, and sudo service lightdm start
<seb128> dobey, so the bugs I pointed before
<seb128> dobey, #864174 mentioned issues on wrong /etc/X11/default-display-manager  content
<seb128> dobey, what do you have in that file?
<seb128> dobey, otherwise the other one has a comment saying that "Manual symlink of /var/run->/run and /var/lock-/run/lock fixed my issues."
<dobey> it was "lightdm" last i looked
<seb128> dobey, change it to "/usr/sbin/lightdm"
<seb128> dobey, that seems the same issue
<seb128> "This is because /etc/X11/default-display-manager ends up saying "lightdm" whereas /etc/init/lightdm.conf accepts "/usr/bin/lightdm" or "/usr/sbin/lightdm". The user sees the splash screen messages "Waiting for up to 60 more seconds for network configuration" and "Booting system without full network configuration"."
<seb128> dobey, ^
<seb128> dobey, it started working when set to /usr/sbin/lightdm for that user
<dobey> what does having foo.dpkg-tmp mean?
<dobey> seb128: i have a default-display-manager.dpkg-tmp which has "/usr/sbin/lightdm" in it; so clearly something broke on apt-get upgrade to cause this
<cjwatson> dobey: sudo dpkg --configure -a
<dobey> cjwatson: didn't fix it
<cjwatson> that's usually a backup link from the previous version which hasn't been cleaned up yet because the new package hasn't been configured
<cjwatson> ... actually, no, it happens when *unpacking* the new version was interrupted
<cjwatson> so repeat the upgrade
<cjwatson> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Beta 2 Released | Archive: Final Freeze | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<dobey> hrmm, dpkg -S says nothing owns default-display-manager
<cjwatson> probably not, it's shared among multiple packages so I expect it's probably handled by maintainer scripts
<tjaalton> stgraber: ping, is there a way to prevent arkose from "crashing" when I hit ctrl-c?
<cjwatson> in that case I have no idea why there'd be a .dpkg-tmp version of it
<cjwatson> perhaps an old bug
<stgraber> tjaalton: ? it doesn't seem to crash here, what part of arkose are you using? arkose / arkose-gui / arkose-wrapper-gui? and with what parameters?
<tjaalton> stgraber: the snippet you blogged about, sudo arkose -n -h -c "cd $PWD; $SHELL"
<seb128> dobey, nothing owning it is normal, it's created by the maintainer scripts
<dobey> dpkg-reconfigure lightdm prints two warnings about missing env variables for dpkg-maintscript-helper
<tjaalton> stgraber: using zsh if it matters
<seb128> dobey, that's bug #706354
<ubottu> Launchpad bug 706354 in lightdm (Ubuntu) "dpkg-maintscript-helper: warning: environment variable DPKG_MAINTSCRIPT_PACKAGE missing" [Low,Triaged] https://launchpad.net/bugs/706354
<stgraber> tjaalton: can you try starting bash instead?
<tjaalton> stgraber: hum yeah, doesn't fail with bash
<tjaalton> i get "zsh: error on TTY read: I/O-error"
<dobey> seb128: hrmm
<dobey> and lightdm.postinst only mucks with default-display-manager if the file doesn't exist
<dobey> so i wonder how it got broken :(
<stgraber> tjaalton: reproduced it. I'll see how I can try to handle that without breaking anything else... Can you file a bug against arkose?
<tjaalton> stgraber: yep, will do
<dobey> seb128: i deleted the default-display-manager and .dpkg-tmp file, and reconfigured lightdm, and now it boots up into lightdm fine
<seb128> dobey, ok, so you got bug #706354
<ubottu> Launchpad bug 706354 in lightdm (Ubuntu) "dpkg-maintscript-helper: warning: environment variable DPKG_MAINTSCRIPT_PACKAGE missing" [Low,Triaged] https://launchpad.net/bugs/706354
<dobey> oh joy, no unity
<tjaalton> stgraber: and thanks, I'll use bash in the meantime :)
<dobey> seb128: yes i definitely got that bug
<dobey> oh lovely
<dobey> logged in, no unity; only a global menubar for nautilus; got a crash dialog about nautilus, clicked report; said the bug was already reported and would be in the browser; clicked ok, and i got a black screen with a mouse cursor i can't move
<dobey> fun times :(
<dobey> frozen solid system, but power button did the normal shutdown magic
<ScottK> Good thing we aren't close to release ...
<ScottK> :-(
<Galantus> yo yo yiggity yo
<Galantus> newb alert
<didrocks> dobey: if you still reproduce it, can you please check in tty1 if ~/.xsession-errors isn't owned by root?
<didrocks> dobey: that's one of the issue the lightdm upload was fixing
<dobey> didrocks: nope, they aren't
<didrocks> dobey: you have the compiz crash file then?
<didrocks> (nautilus crashing nowdays seem to be trigger by u1 btw)
<dobey> didrocks: i don't think compiz crashed. i think unity failed to load. there's no compiz crash file, and the apport dialog had window borders
<didrocks> dobey: hum, interesting, can you pastebin ~/.xsession-errors?
<didrocks> dobey: if a plugin fail to load, it normally makes compiz crash
<dobey> didrocks: "unity-panel-service: no process found" is probably the only interesting message in it that i can see
<didrocks> dobey: can you pastebin it?
<didrocks> still, better than I can get the full context
<dobey> and nautilus prints a billion criticals :-/
<dobey> didrocks: https://chinstrap.canonical.com/~dobey/xsession-errors
<didrocks> dobey: waow, that's really weird, unity started but you got nothing on screen?
<bdmurray> cjwatson: can you mark some merge proposals as rejected or so?
<dobey> didrocks: well my machine froze so i rebooted it and unity started fine now
<cjwatson> bdmurray: yes
<dobey> didrocks: but i have had it not come up a couple times
<bdmurray> https://code.launchpad.net/~paulbrianstewart/ubuntu/oneiric/blobby/833458-Spelling-Grammar-Fix/+merge/72817
<cjwatson> I wish LP would fix that bug
<bdmurray> https://code.launchpad.net/~paulbrianstewart/ubuntu/oneiric/btanks/834098-Spelling-Grammar-Fix/+merge/72957
<bdmurray> https://code.launchpad.net/~paulbrianstewart/ubuntu/oneiric/biniax2/834199-Spelling-Grammar-Fix/+merge/72971
<bdmurray> https://code.launchpad.net/~paulbrianstewart/ubuntu/oneiric/alien-arena/834369-Spelling-Grammar-Errors-Fix/+merge/72985
<didrocks> dobey: but your .xsession-errors is from the frozen ui launch, isn't it?
<bdmurray> https://code.launchpad.net/~paulbrianstewart/ubuntu/oneiric/extcalc/842339-Spelling-Error-Fix/+merge/74156
<bdmurray> cjwatson: those 5 please
<dobey> didrocks: it's both afaik
<dobey> didrocks: does it get overwritten every time i log in?
<didrocks> dobey: both?
<didrocks> dobey: yeah
<dobey> oh, then it's from a working session
<didrocks> ok, makes sense :)
<dobey> since i'm logged in now and it works
<didrocks> if you get a frozen session, then please tty1, and pastebin it
<cjwatson> bdmurray: done
<dobey> didrocks: well, i couldn't switch to tty, since keyboard was also frozen; but i'll get an errors file from the broken unity session next time
<dobey> huh
<dobey> the top panel bit on the unlock screen is gone now
<didrocks> dobey: thanks! (seems your issue is more serious than unity itself, I bet for a root .xsession-errors from lighttdm)
<didrocks> dobey: yeah, it was patch to not look "gnome-shell like" in august AFAIK
<dobey> â¦
<bdmurray> cjwatson: I think part of why he wanted to capitalize the description in the control file is because he was looking at packages in software center and it seems to be inconsistent there
<cjwatson> then that's a software-center bug
<cjwatson> if it's out of step with the recommended way to write the synopsis ...
<bdmurray> right of course
<cjwatson> if the presentation in s-c is such that it needs it in sentence-case, it should sentence-case it itself
<cjwatson> or rearrange so that that's not needed
<cjwatson> but, I want to stop Paul from making things worse :)
<bdmurray> mpt: is there a bug about inconsistent capitalization of software descriptions in software center?
<mpt> bdmurray, there are bug reports about the descriptions of various packages. <https://bugs.launchpad.net/ubuntu/+bugs?field.tag=metadata> I don't know that any of them are about capitalization specifically.
<bdmurray> mpt: it seems to me that the one-line description of packages sometimes starts with a capital letter and sometimes doesn't
<mpt> bdmurray, maybe lintian or something should nag people who start it with a word that doesn't contain an upper-case letter
<bdmurray> mpt: where does that come from?
<mpt> ah, good point
<mpt> It's the .desktop file for packages that have one, the synopsis (first line of the Description) for those that don't
<mpt> bdmurray, https://wiki.ubuntu.com/SoftwareCenter#software-summary
<bdmurray> mpt: cjwatson pointed out that the synopsis shouldn't have capitalization in it
<bdmurray> http://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.html#bpp-pkg-synopsis
<bdmurray> it'd seem to me that software center could title the synopsis if necessary
<mpt> huh
<mpt> I wonder why
<cjwatson> because not using sentence case there allows strictly more flexibility - you can use it in the middle of a phrase, and things that need it in sentence case can title() it
<cjwatson> it doesn't work the other way round
<maco> fancy
<mpt> cjwatson, is there software that uses it in the middle of a phrase?
<cjwatson> mpt: I don't know, but it would not surprise me
<cjwatson> mpt: anyway I'd counsel against trying to swim against the current here; it sounds like a lot of faff compared with a one-line software change
<mpt> ok, if Debian won't go to the mountain ...
<mpt> On the other hand, having an uncapitalized summary is a subtle hint that "this here is a geeky package"
<cjwatson> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=516436 is the source of the current wording, although the general sense of the advice predates that
<ubottu> Debian bug 516436 in developers-reference "6.2.2: talks nonsense about "appositive clauses"" [Normal,Fixed]
<mpt> But on the other other hand, fonts etc will never have .desktop files, and they should still have decent titles
<cr3> barry: quick python question for you: raise Exception("Foo: %s" % bar) returns an unprintable error unless I do bar.encode("utf-8"). I don't think I should have to encode unicode variables when raising exceptions though :(
<barry> cr3: is the exception getting caught or is it propagating to the eval loop?  the encoding error is probably happening when the exception is printed rather than when it's raised
<cr3> barry: it's probably getting caught and passed to logging.exception
<tkamppeter> pitti, hi
<barry> cr3: so then logging is raising the encoding exception when it tries to print it (probably to an ascii log file or something)
<cr3> barry: another solution would be to use %s instead of %r, but that looks pretty ugly in the output: u"foo\xa0bar"
<cr3> barry: what might be the right way to handle this?
<cr3> err, %r instead of %s, I mean
<cr3> barry: maybe I need to register a formatter with the logger to expect unicode strings
<barry> cr3: interestingly, i found this: http://stackoverflow.com/questions/1545263/utf-8-in-python-logging-how
<barry> cr3: which makes me think (without seeing your full code example) that you just need to get the encoding argument into the FileHandler
<barry> cr3: it does not look like logging.basicConfig() has an option for this
<slangasek> pitti: upower reuploaded, thanks
<mpt> bdmurray, cjwatson: I updated the spec <https://wiki.ubuntu.com/SoftwareCenter?action=diff&rev2=585&rev1=584> and reported bug 867588. Thanks for the suggestion.
<ubottu> Launchpad bug 867588 in software-center (Ubuntu) "Title and summary are capitalized if from .desktop but not if from package synopsis" [Undecided,New] https://launchpad.net/bugs/867588
<slangasek> bdmurray: ok, I'll see if I can work out how to keep this text from being written to the console then
<cjwatson> mpt: thanks
<cr3> barry: oddly, FileHandler has the argument but StreamHandler doesn't
<barry> cr3: indeed.  i wonder if there are any open bugs on that.  but it does sound like you will have to write your own handler
<barry> cr3: gotta run out now for lunch, but i'll be back later
<bdmurray> slangasek: I can test again if necessary
<slangasek> bdmurray: those messages are both from sysvinit-style init scripts, so it definitely gives me a place to start looking
<cr3> barry: I'm trying something like: codecs.getwriter("utf-8")(log_stream)... anyways, good to know it seems like a real problem
<lool> Would someone be so kind to reject logcheck in lucid-proposed?  (I have another patch to include)
<lool> (the one in hardy-proposed is fine)
<seb128> lool, https://launchpad.net/ubuntu/lucid/+queue?queue_state=1&queue_text=logcheck
<seb128> it's not there?
<ogra_> i think i saw it on -changes already
<slangasek> smoser: when the infrastructure was upgraded (bug #833783), did that mean any changes to the 'console=' arguments being passed?
<ubottu> Launchpad bug 833783 in udev (Ubuntu Oneiric) "boot failure: can't open /root/dev/console: no such file" [High,Confirmed] https://launchpad.net/bugs/833783
<lool> ogra_: the oneiric one went through
<lool> seb128: Hmm I wonder what happened
<ogra_> Betreff: 	[ubuntu/lucid-proposed] logcheck 1.3.7ubuntu2 (Accepted)
<ogra_> Datum: 	Tue, 04 Oct 2011 05:37:13 -0000 (04.10.2011 07:37:13)
<ogra_> lool, ^^^
<lool> ogra_: actually you're right
<lool> ogra_: I see it on lucid-changes too
<ogra_> else that would be a bad bug in evo :)
<ogra_> (secretly generating changes mails or so)
<lool> seb128: nevermind, it's already in -proposed, sorry about the noise  :-)
<lool> I missed the accepted email for some reason, must be sleeping
<cr3> pitti: quick apport question you probably know on top of your head: does apport tag bugs with regression-proposed automatically when running a proposed kernel?
<didrocks> slangasek: well, strictly speaking, the update-notifier upload isn't mandatory
<didrocks> slangasek: we have update-notifier icons showing in unity and unity-2d, without the big icon bug
<slangasek> didrocks: that depends on whose mandate we're following ;)
<didrocks> I don't see how having indicator is mandatory, in that case, we should mandate all applications that we whitelist by default :)
<slangasek> I don't want update-notifier to be setting a bad precedent for other software
<slangasek> the *only* other stuff currently in the whitelist is stuff we can't change
<didrocks> slangasek: scp-dbus-service ? (I don't really know this one)
<didrocks> slangasek: and for java, we can ask the dx team to provide indicator support/bindings for java apps
<didrocks> wine apps are exceptions though, agreed
<slangasek> I don't know what that scp-dbus-service is either
<slangasek> for java, providing the bindings doesn't ensure things will use it
<slangasek> and some of the java stuff is again closed-source
<didrocks> slangasek: well, same story for python, qt, Câ¦ :)
 * didrocks still doesn't like this whitelist idea, it's not in forcing people that we achieve this goal, it's by giving them extra bounties in using our API
<kees> 818177 is exciting
<seb128> lool, no worry ;-)
<slangasek> kees: 818177> are you able to reproduce it? :P
<kees> slangasek: I haven't tried, I'm afraid of it. :)
<kees> slangasek: when did the udev kill vs --exit thing change?
<slangasek> kees: no idea
<adam_g> kees: looks like it changed in udev 171-0ubuntu4 / Tue, 28 Jun 2011, to resolve http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=624469
<ubottu> Debian bug 624469 in udev "Fails to start: failed to bind control socket (address in use)" [Serious,Fixed]
<kees> adam_g: hmpf
<kees> slangasek, adam_g: ok, so I haven't been able to reproduce in the maybe 10 times I've rebooted since then.
 * adam_g just hit it
<adam_g> id be happy to poke at anything you think might of interest, tho the wifi here is bad.
<stgraber> slangasek: for bug 813065, do you think http://paste.ubuntu.com/702368/ would be enough? It seems to work here (when changing ubiquity-dm from break=bottom)
<ubottu> Launchpad bug 813065 in casper (Ubuntu Oneiric) "Live session switches to VT console briefly" [High,Confirmed] https://launchpad.net/bugs/813065
<soren> doko: Wrt user-mode-linux.. I'm having trouble getting it to build on i386. amd64 works great. I guess that's better than ftbfs'ing entirely. :-/
<slangasek> stgraber: don't we really want 'clear' rather than 'reset'?
<stgraber> slangasek: actually, clear should be enough, no need to do a full reset of the console
 * slangasek nods
<doko> there also is clear_console
 * slangasek digs into the code for context
<doko> soren, sure, better than nothing
<slangasek> doko: overkill, I think
<stgraber> doing another test run with "clear", if I don't see any upstart messages during the switch, I'll push that
<slangasek> stgraber: you seem to be clearing the screen after the X server has exited; we should do it before
<slangasek> (just in case the X server is slow to return after switching to text mode)
<stgraber> slangasek: hmm, I don't seem to be able to consistently reproduce that bug in a VM, so I'm not sure the fix actually works... I'll push it anyway as it doesn't seem to cause any harm and will ask for confirmation in the bug once uploaded.
<slangasek> stgraber: you can't reproduce it /at all/?  I would expect it to be racy, but not unreproducible
<stgraber> slangasek: I saw it once on around 20 tries, so can't really know if the fix works or if I'm just lucky
<slangasek> ah
<stgraber> I'll try with another virtual video card, maybe that'll make a difference
<niclas> Hi, if I need help to report a bug is this the place to ask? Or should I ask in a different room maybe? Don't know which package to file the bug against.
<slangasek> niclas: we can help with that, go ahead and ask
<niclas> Ok, I have a nfts drive connected with USB. I noticed that if a try to safely remove the disk when a program has a file on the disk open, the system freezes and a hard reboot is the only way to recover
<niclas> And i'n running oneric
<niclas> So, is it gvfs, ntfs-3g, kernel maybe?
<maco> does alt+sysrq+b reboot the machine? if so, then i think thatd knock kernel off the list
<maco> other bit to test would be mounting it with ntfs-3g manually (like on the command line) instead of through gnome, to try to rule out gvfs
<maco> niclas: ^ do those suggestions for testing make sense?
<niclas> Okay, well alt+sysrq+b does not help
<niclas> the num lock light does not react when I'm pressing num lock either if it is to any help
<niclas> yes it makes sence
<maco> is it in that state right now?
<maco> (if no and that sounded silly, its possible you have two computers)
<niclas> Frozen? No it runs just fine right now
<niclas> And yes, only one computer
<slangasek> maco: that doesn't eliminate it being a kernel problem.
<slangasek> but if it's locked up that hard, it clearly *is* a kernel problem
<maco> slangasek: not responding to magic sysrq does seem to implicate the kernel or an errant module, in my mind
<slangasek> yes
<slangasek> but being able to reboot with SysRq+b isn't proof that it's *not* a kernel bug :)
<maco> slangasek: fair enough
<slangasek> niclas: so, please file the bug against the kernel
<niclas> Okay, I will! Thanks
 * maco makes note that sometimes a stupid kernel will still sysrq
<slangasek> bryceh: hum, fortunately the application of the patch from bug #535172 seems to have been a no-op, because upstart already ships its own completion file...
<ubottu> Launchpad bug 535172 in bash-completion (Ubuntu) "Bash completion for upstart" [Wishlist,Fix released] https://launchpad.net/bugs/535172
<niclasl> slangasek, maco: Still there? I've done some testing now and I found that it has nothing to do with open files. If I let gvfs mount the disk and then tries to safely remove it, the system crashes even if it is the first thing I do after I log in. If I choose "unmount" instead of "safely remove", or if I manually mount and unmount the disk there is no crash
<infinity> siretart: Your logrotate patch makes no sense.
<niclasl> Is the kernel still the package I should file against?
<infinity> siretart: Exiting the cronjob if there's no status file means you never create a status file.
<infinity> siretart: So, ultimately, logrotate would never run.
<siretart> infinity: so the first run is *expected* to throw some error? - anyway, point taken, I'll change that to create an empty file if it doesn't exist. ok?
<infinity> siretart: A touch would work, perhaps, sure.  Just remove the status file (on a system you don't much care about logrotate consistency on) and actually test the cronjob a few times? :)
<siretart> on my way
<infinity> siretart: Actually, the status file MIGHT be created by logrotate.
<infinity> siretart: If that's the case, then just wrapping the whole cleanup thing in a [ -e status ] would work.
<infinity> siretart: But yeah.  Please investigate.  I'm not sure what the right solution is, I'm just positive that it's not "disable the cronjob entirely". ;)
<siretart> infinity: I've now implemented the 'touch' suggestion, and it does the right thing on my laptop
<maco> niclasl: if the kernel's wedging, id say yes
<siretart> infinity: thanks for the review, I'll upload in a minute
<maco> niclasl: someone from the kernel team will be able to sort out more particularly whats going wonky in the kernel
<niclasl> maco: okay, thanks
<bryceh> slangasek, done
<dobey> hrmm; is it not possible to have a -dbg package defined in control, and also avoid having an install file?
<slangasek> bryceh: the patch got added right back in via debian/patches/debian-changes-1:1.3-1ubuntu6 in this upload
<slangasek> (so, rejecting)
<slangasek> dobey: for a source package building only two binary packages (one of them the -dbg), I would expect that to work with dh_strip --dbg-package=foo-dbg
<dobey> slangasek: hrmm; so i'm using cdbs; would i need to add that to the rules file in some way to make it DTRT in this case?
<slangasek> dobey: you probably need to trick cdbs into doing that, but I don't know how
<bryceh> slangasek, crap one sec
<bryceh> bash-completion's packaging is annoying
<bryceh> slangasek, it automatically adds this debian-changes file during debuild; is there a way to stop it from doing that?
<slangasek> bryceh: run 'quilt unpatch' in the source package before removing the patch file from debian/patches
<slangasek> (dpkg source v3 says all patches are applied at source unpack time, and any changes found outside debian/ at source build time get shoved into a new patch file)
<infinity> siretart: Dude...
<infinity> siretart: Your changelog still claims the cronjob works the old way. :)
<bryceh> slangasek, hmm, 'quilt unpatch' just returns a usage message
 * bryceh quilt pops
<infinity> siretart: On the other hand, I'm having fun pressing the reject button, so that's pretty neat. ;)
<slangasek> bryceh: right, that's what I meant, sorry :)
<bryceh> slangasek, done
<dobey> slangasek: hmm, found some clue to use DEB_DH_STRIP_ARGS, but adding the --dbg-package=foo-dbg didn't seem to work :-/
<slangasek> dobey: pointer to the package?
<dobey> slangasek: lp:ubuntu/ubuntuone-client-gnome
<slangasek> dobey: ok.  why are the autogenerated .ddebs not sufficient for debugging, btw?
<slangasek> (you know that all packages in main have symbols split off automatically in the archive and dropped to ddebs.ubuntu.com?)
<dobey> slangasek: i think they are. i just want to get rid of the debian/install file
<slangasek> oh
<dobey> and i also want to do this for our nightlies packages, so we'd have to build the -dbg there anyway since we don't get auto-ddebs magic for being in main with those
<slangasek> right
<dobey> but if i just remove the debian/install file and rebuild, the package is empty :(
<slangasek> dobey: if I can replace your debian/rules with a shorter dh(1) rules file that does the right thing, would you take it? :-)
<dobey> slangasek: for ubuntu proper i don't care much in that regard, but i don't think we can do that for our nightlies builds
<slangasek> why not?
<slangasek> if nightly builds have a dependency on cdbs, then somebody's doing it wrong :P
<dobey> because using pure dh would mean making a much longer rules file than with cdbs, and i don't really feel like reimplementing a bunch of what cdbs does, just to use pure dh
<dobey> slangasek: for some other packages we could, but for things using autotools, it's not so easy :)
<slangasek> dobey: huh?
<micahg> dh_autoreconf?
<slangasek> what is cdbs doing here that dh isn't?
<dobey> micahg: no.
<dobey> slangasek: DEB_CONFIGURE_SCRIPT = $(CURDIR)/$(DEB_SRCDIR)/autogen.sh
<slangasek> dobey: oh - I don't see that in the branch you pointed me to, I guess that's only in the nightly build branch?
<dobey> slangasek: right, because we don't need to run autogen.sh for tarball releases; but we do for building from bzr trunk
 * slangasek nods
<slangasek> well, it might be longer then, but not *much* longer
<dobey> which is why i said i'm not fussed about the ubuntu branch, but the nightlies one i am :)
<slangasek> besides which, the reason we're having this conversation is that cdbs isn't working ;)
<dobey> and either way, dh_strip doesn't seem to be the solution to this problem
<slangasek> no, I think the problem is something particular to cdbs
<slangasek> dobey: DEB_DESTDIR = $(CURDIR)/debian/ubuntuone-client-gnome
<slangasek> dobey: not a cdbs-specific problem after all, it's deeper than that - debhelper in fact
 * infinity wonders idly why "apt-cache show libc6" gives long descriptions, but "apt-cache show libc6:i386" doesn't.
<slangasek> when debian/control lists one binary package, debhelper will do everything in debian/tmp and there's no need to use dh_install at all
<infinity> slangasek: Do you know enough about apt multiarch internals to grok why we're only getting long descriptions for the dpkg arch?
<slangasek> when debian/control lists more than one binary package, the install target still aims at debian/tmp by default, but dh_install with no arguments doesn't know what bits you want copied where - even when one of the packages is a -dbg package
<slangasek> dobey: so try as I might, I can't blame this one on cdbs ;)
<slangasek> infinity: not that part of it, no
<dobey> slangasek: thanks! that does seem to work. :)
<slangasek> stgraber: oh man, hilarious - when testing on nouveau, I *never* get a console switch to text between ubiquity-dm and lightdm; on intel, I *always* do...
<stgraber> slangasek: guess what I've been using for testing :)
<slangasek> nouveau, by chance? :)
<slangasek> never get a console switch> I know this because the X cursor stays on the screen the whole time
<stgraber> yeah, Lenovo R61 with nvidia quadro
<slangasek> we should still be clearing the console regardless
<stgraber> can you check that the call to "clear" does what it's supposed to?
<slangasek> but it means I'll have even more fun teasing keithp tonight
<slangasek> stgraber: still working on validating that
<slangasek> stgraber: btw, it's not "upstart messages" at issue here, but "boot-time messages" (these don't come from upstart at all)
<slangasek> I was going to fix the comment up, but maybe you'll beat me to it
<stgraber> slangasek: updated
<slangasek> cheers :)
<stgraber> slangasek: I'm ready for an ubiquity upload. Tested current trunk on ubuntu, xubuntu and kubuntu. Just let me know when you're done testing the ubiquity-dm change and if it works, I'll upload.
<slangasek> stgraber: ack
<Heimi> hi, does someone know howto create a (Python-based) Indicator, that directly reacts on a click on the icon (means that does not have menus)
<RAOF> Heimi: I believe the answer is: you don't, because that's a design anti-goal for indicators.
<Heimi> @RAOF: well, I think that I understand the goals somewhat - but to just have an Indicator  "Lock button" I think a menu is overkill
<udevbot_> Error: "RAOF:" is not a valid command.
<RAOF> Heimi: There's already a lock button under the power indicator - just above ?Log out?
<Heimi> yes, I know that (and would usually say that this is sufficient), but a client asked (unfortunately) for a separate button
<Heimi> I think that this can also be helpful for other scenarios - think about the old "force quit" Gnome2 bonobo applet ...
<ScottK> What an error message: "Something wicked happened resolving 'archive.ubuntu.com"
<stgraber> ScottK: what gave you that? :)
<ScottK> apt-get source.
<ScottK> The rest of the error was: http' (-5 - No address associated with hostname)
<RAOF> Heimi: Would a button on the launcher work?  It wouldn't be hard to whip up a .desktop file to lock the screen.
<Heimi> RAOF: yes, also thought about that - seems to be the only possible / workable solution ... and this is an easy one - just creating a .desktop file
<slangasek> stgraber: I have the distinct impression that interrupting the initramfs to make my changes to ubiquity-dm is permuting the boot in such a way that I get no messages on the console P
<slangasek> :P
<sladen> h
<bryceh> slangasek, hey do you know if there's a command line tool that'll retrieve the .dsc for a given source package name from Debian unstable
<slangasek> bryceh: apt-get source + chdist?
<ion> I just have deb-src for unstable and experimental in my sources.list. :-)
<micahg> bryceh: pull-debian-source
<slangasek> or that ^^
<Laney> pull-debian-
<Laney> yeah
<bryceh> ok will try (yeah I was poking at chdist)
<bryceh> micahg, perfect, thanks
<micahg> bryceh: you're welcome
 * micahg also happens to be able to do apt-get source -t unstable foo, but not everyone needs to deb-src entries
<slangasek> stgraber: ok, tested and this clear command is *not* sufficient
<slangasek> stgraber: I think we need to redirect clear's stdin/stdout to the X VT
#ubuntu-devel 2011-10-05
<stgraber> slangasek: I merged your change, then at cjwatson's suggestion, switched to .call() so we wait for the clear call to return and also moved it to a try/except IOError block just in case something goes wrong with /dev/ttyX
<psusi> cjwatson, I got a weird problem with grub on oneiric now... fails to install... grub-probe --target=fs /target fails to identify the fs... if I mount my lucid or natty logical volume in /target, it works fine..  nothing jumps out at me comparing the -vvv logs of the working lv with the failing lv... any ideas?
<psusi> --target=device works fine, as does abstraction ( lvm )
<psusi> cjwatson, everything is ext4 btw
<slangasek> stgraber: sweet, thanks :)
<ScottK> jbicha: I'm looking at your libmusicbrainz-2.1 sync.  Don't we already have hardening flags enabled via gcc in Ubuntu?  I think that sync is a no-op for us.
<ScottK> The wspanish changes don't look very RC either.
<micahg> ScottK: depends which flags
<ScottK> micahg: Would you look at the diff then, please?
<micahg> ScottK: can you point me to it?
<micahg> +queue doesn't show it
<ScottK> It won't.
<ScottK> I had to download and debdiff.
 * micahg uses LP
<ScottK> (yes, I've file the bug about that)
<micahg> https://launchpadlibrarian.net/81986735/libmusicbrainz-2.1_2.1.5-6_2.1.5-6.1.diff.gz
<ScottK> That's the one.
<micahg> yeah, that won't do anything for us this cycle
<ScottK> jbicha: ^^^ I'm going to reject them both.  If you really think they should go in, let's discuss.
<micahg> ScottK: you can make LP show a diff here: https://launchpad.net/ubuntu/oneiric/+localpackagediffs for syncs, select All packages
<ScottK> Right.  I tend to forget that's around now.
<ScottK> Except for syncs on +queue there's generally a diff on the page I'm looking at.
<micahg> right
<jbicha> ScottK: I thought those updates wouldn't hurt but it's not a big deal to me whether they get in or not
<ScottK> jbicha: Generally in the end game we prefer not to touch packages without a good reason.
<ScottK> I agree they were almost certainly harmless, but also provided no real benefit.  Stuff like that is better waiting.
<jbicha> ok, no problem then
<didrocks> good morning
<pitti> Good morning
<dholbach> good morning
<sladen> morgen
<jamespage> morning
<pitti> cjwatson: lightdm 1.0.1-0ubuntu2 should fix your locale bug
<cjwatson> pitti: yay, thanks
<cjwatson> I'll tell you in a bit ...
<zarlino> i all, I'd like to add my commercial software to the ubuntu software center. I read this http://developer.ubuntu.com/publish/my-apps-packages/, but cannot figure out how exactly I should package my app. Any suggestions?
<pitti> zarlino: I suppose you are not using quickly for your app then?
<zarlino> pitti: no it's a Qt app
<pitti> zarlino: above documentation assumes that, so if you don't use that, you might need to do the packaging manually
<zarlino> pitti: I already have a generic .deb for my app
<pitti> didrocks: ^ does quickly help with creating packaging if you don't use it for creating the source skeleton etc.?
<zarlino> pitti: I just don't know how to provide the "source package" format
<pitti> zarlino: oh, so much the better
<pitti> zarlino: well, how did you build your deb, if not with debuild or dpkg-buildpackage from a source package?
<didrocks> pitti: if the project is converted to the quickly format, yes
<didrocks> like library_name and such
<zarlino> pitti: yes I used dpkg-buildpackage
<zarlino> pitti: i used the "native" debian format, not the "quilt"
<pitti> zarlino: then whatever you ran it from is a source package tree; "dpkg-buildpackage -S" will build the source package, which consists of a .dsc, usually a .debian.tar.gz or .diff.gz, and a tarball with the upstream source
<pitti> zarlino: so you probably end up with a .tar.gz and a .dsc
<zarlino> pitti: ok but I'd prefer not to upload the sources
<zarlino> pitti: so how to package the binaries, icons and stuff in a source package format?
<pitti> zarlino: then you can't use Launchpad PPAs, but need to provide your own repository
<pitti> zarlino: you can also do that, of course
<zarlino> pitti: the software center developer site provides an upload form
<pitti> zarlino: it's called "source" package because usually it has the source, but technically the only requirement is that running dpkg-buildpackage in it builds .debs
<pitti> zarlino: e. g. the sun-java6 or nvidia driver packagages just ship the readily built blobs in the source and merely copy them into the debs
<pitti> zarlino: ah, for .debs or source pacakges?
<pitti> zarlino: if for .debs, it seems your problem is pretty much solved?
<zarlino> pitti: i think both
<zarlino> pitti: I'm talking about this: http://developer.ubuntu.com/publish/ to be clear
<ajmitch> the page does seem to state that it's a tarball of the source package
<pitti> zarlino: right, only source package
<ajmitch> it's also a bit too focused on commercial apps, which is fine in this case
<pitti> zarlino: for more details I think I defer to mvo, I don't know that process very well
<cjwatson> I think #ubuntu-app-devel might have more people who are focused on this kind of thing, BTW
<zarlino> cjwatson: thanks will also ask there
<cjwatson> (or maybe not, I confess I haven't been in there lately)
<ajmitch> it's been fairly quiet there lately
<zarlino> pitti: so your suggestion is I should look at nvidia or java debs and how they do it?
<pitti> zarlino: as I said, they just have the final binaries, and the debian/ bits are by and large nothing more than installing these binaries
<ajmitch> reading the info there, it looks like packaging commercial apps is something canonical offers help with
<pitti> zarlino: i. e. just having a debian/mypackage.install file and the standard 3-line debian/rules ought to be enough
<zarlino> pitti: It'll look easy to me too when I'll found about what those 3 lines are...
<pitti> see "man dh":
<pitti> #!/usr/bin/make -f
<pitti> %:
<pitti>         dh $@
<zarlino> pitti: reading that man, thanks for your help!
<Laney> congrats new TB :-)
<micahg> did I miss an e-mail?
<ajmitch> a blog post by sabdfl
<ajmitch> maybe an email as well, I haven't checked this evening :)
<Laney> just saw the blog
<micahg> ah, just saw it
<binarymutant> is there a way to search the archives for a particular license?
<binarymutant> * an easy way *
<Laney> erm, packages.u.c links to .copyright files that don't exist
<tkamppeter> I have an old 32-bit HP Compaq 12-inch laptop and it does not boot with the 3.0.0-12 kernel, but only with the last Natty kernel. How to report a bug/debug this?
<Laney> binarymutant: I cannot think of any place you can get the copyright file for an Ubuntu package other than from the binary package itself
<binarymutant> thanks I found a way :D
<Laney> hmm?
<binarymutant> google `site:packages.debian.org inurl:changelogs/pool/main filetype:copyright wtfpl`
<Laney> I found out that the links from packages.u.c are wrong but the copyright files are actually there
<Laney> so yes, s/debian.org/ubuntu.com and s/main// might work
<sabdfl> micahg, sorry for the impersonal approach! congrats and welcome
<nigelb> sabdfl: Hey! Dictionary alright? We still haven't got a name :D
<sabdfl> precisely
<ogra_> oh, awesome, stgraber made it !
<ogra_> stgraber, congrats !!!
<stikonas> dpm: Hello. Can I ask a question about launchpad translations? Something strange happens that I don't understand.
<dpm> hi stikonas, sure
<stikonas> dpm: according to https://translations.launchpad.net/ubuntu/oneiric/+source/kde4libs/+pots/libplasma/lt/+details there are no differences between upstream and Ubuntu
<stikonas> But in upstream  "%1 Settings" is translated as msgstr "Nustatymai: %1|/|$[get-case Kilmininkas %1] nustatymai", while in Launchpad the translation is "Nustatymai: %1"
<stikonas> it seems that Launchpad has older translation
<stikonas> and has not reimported translations after the change in upstream. But it still thinks that there are no differences
<dpm> stikonas, when you say upstream, where are you looking at? Could you point me to the string that differs in the upstream repo?
<stikonas> btw, I'm upstream translator who made that change.
<stikonas> ok
<stikonas> dpm: http://websvn.kde.org/*checkout*/branches/stable/l10n-kde4/lt/messages/kdelibs/libplasma.po
<stikonas> dpm: please search for msgid "%1 Settings"
<dpm> stikonas, I can see the string. Are you certain that the libplasma version this PO file belongs to has already been uploaded to Ubuntu?
<stikonas> dpm: it should be. I change the upstream translation in March or April, so it should have been imported with KDE 4.7.0
<stikonas> s/change/changed/
<stikonas> dpm: and Launchpad lists this new string as a suggestion
<dpm> stikonas, hm, I'll have to investigate further, then. In the meantime, if this is an important change, could you please updated in Launchpad, so that at least we ensure that the language packs will contain the correct translation?
<dpm> s/updated/update it/
<stikonas> dpm: OK, I'll fix it in Launchpad now.
<dpm> thanks stikonas
<stikonas> dpm: I a few strings in this file. I'll now look at some other file
<dpm> ok, thanks stikonas, let me know if you see any other inconsistencies
<tseliot> cjwatson, pitti: do you think it would be better to merge the package from debian or would a 2 lines fix be more appropriate, given the fact that we're in final freeze? bug #811016
<ubottu> Launchpad bug 811016 in pbuilder (Ubuntu) "Move to /run breaks pbuilder --execute" [High,Confirmed] https://launchpad.net/bugs/811016
<pitti> tseliot: without having looked at the merge delta, a cherry-pick is generally better at this time IMHO
<stikonas> dpm: I have found something similar in https://translations.launchpad.net/ubuntu/oneiric/+source/kde-workspace/+pots/powerdevilglobalconfig/lt/+details
<tseliot> pitti: I figured as much but I wanted to be sure
<tseliot> thanks
<stikonas> dpm: If you want, we can leave it as a testcase. It is not as important as the translations that we talked previously.
<stikonas> dpm: e.g. this string is not updated: https://translations.launchpad.net/ubuntu/oneiric/+source/kde-workspace/+pots/powerdevilglobalconfig/lt/34/+translate
<stikonas> dpm: corresponding upstream is http://websvn.kde.org/*checkout*/branches/stable/l10n-kde4/lt/messages/kdebase/powerdevilglobalconfig.po
<dpm> stikonas, thanks. Perhaps a good idea might be to collect those you notice in an e-mail and send it to the ubuntu-translators list. I cannot promise that we'll be able to look at them straight away or before release, but it will help to keep track of them
<tseliot> pitti: ok, I've just uploaded the fix for pbuilder
<larsu> tkamppeter, ping
<doko> dholbach, updated https://wiki.ubuntu.com/CompilerFlags
<tkamppeter> larsu, hi
<larsu> tkamppeter, did you get the direct messages I sent you?
<dholbach> thanks doko!
<jibel> mvo, I tried an upgrade to oneiric on i386 and bug 853688 is still there.
<ubottu> Launchpad bug 853688 in command-not-found (Ubuntu Oneiric) "Natty to Oneiric - failed to calculate the upgrade with gcj-4.4-jre installed" [Medium,Confirmed] https://launchpad.net/bugs/853688
<jibel> mvo, to reproduce I installed gcj-4.4-jre-headless on an up to date natty then upgraded to oneiric.
<mvo> jibel: thanks let me try to reproduce again
<stgraber> ogra_: thanks!
<ogra_> stgraber, time for LTSP wold domination then :)
<ogra_> *world :)
<ogra_> we can talk about it in SW harbor :)
 * ogra_ finally got the tickets sorted
<stgraber> hehe :)
<stgraber> ogra_: cool, when are you arriving in SW harbor?
<Chipzz> doko: there's a small "error" on the page you updated
<Chipzz> doko: the section about -Wl,--no-copy-dt-needed-entries has this sentence twice: "This option affects the treatment of dynamic libraries referred to by DT_NEEDED tags inside ELF dynamic libraries mentioned on the command line."
<ogra_> stgraber, 17:23 it says
<ogra_> on the 27th
<ogra_> i'll likely need a lift
<stgraber> ogra_: ok, I'm sure we'll find someone who can give you a lift. We'll be in SW Harbor at around 1-2pm to pick up pscheie but either someone driving a bit later than we are can pick you up or we'll just have someone drive from SW Harbor.
<ogra_> yeah, i know jim likes to do such stuff
<ogra_> i'm sure i can get him to pick me up
<ogra_> renting a car like i did last time somehow doesnt cut it since i dont really drive around much
<doko> Chipzz, thanks, fixed
<stgraber> ogra_: are you on the same flight to Orlando as alkisg, highvoltage and I?
<ogra_> not sure, let me check the flight '
<ogra_> #
<Chipzz> doko: yw :)
<ogra_> stgraber, US 835
<stgraber> ogra_: hmm, different than us. What time is this one leaving from Bangor?
<ogra_> leaves PHL at 6pm
<ogra_> no, through philly
<stgraber> ah, ok, and what time is your flight from Bangor to philly?
<rbasak> cyphermox: ping
<cyphermox> rbasak: pong
<ogra_> stgraber, 3:30 pm
<rbasak> cyphermox: got somewhere with bug 856209
<ubottu> Launchpad bug 856209 in network-manager (Ubuntu) "NM fails to set IPv6 default route when IPv6 details entered manually" [High,In progress] https://launchpad.net/bugs/856209
<rbasak> I think it's an issue in libnl3
<rbasak> I have a patch to libnl3 which makes your program work, but it's maybe a bit invasive
<rbasak> libnl3 sets routes using multipath destinations only, looks like it expects a single destination to be a special case of that
<rbasak> I tried changing it so that if there is only one destination specified, then rather than requesting a multipath route it requests a normal one
<rbasak> That worked
<rbasak> Also to fix the "::" vs. "default" thing, you have to set the prefixlen to 0.
<hallyn_> skaet: Daviey: bug 522710, does nothing but add manpage for libvirtd.  Is a trivial but wishlist fix like that doable during final freeze?  :)
<ubottu> Launchpad bug 522710 in libvirt (Ubuntu) "libvirtd does not have a man page" [Wishlist,In progress] https://launchpad.net/bugs/522710
<stgraber> ogra_: ah, ok. I see this one arrives quite a bit later in Orlando than ours do (Bangor => NYC => Orlando), my goal was to arrive at the hotel around 6pm.
<cyphermox> rbasak: yeah, the default part I knew about, just didn' t bother to touch it, since it didn' t work either way
<ogra_> stgraber, my goal was to get a payable flight at all ... since i'm late as usual :)
<cyphermox> but yeah, your thing does make sense
<rbasak> The catch is that AIUI because the libnl3 API doesn't distinguish between single and multipath, you must set an interface index
<rbasak> (since it doesn't have the option of not setting one)
<rbasak> So in my patch I ignore an interface index if set and only one destination is specified
<cyphermox> and you can' t set it outside multipath :)
<stgraber> ogra_: hehe, yeah, I guess there wasn't too many flights left when you booked ;)
<ogra_> right
<cyphermox> rbasak: you should still be able to set the index if it' s specified in the multipath parameters, as long as there' s only one multipath, set it directly as a destination?:
<rbasak> What I'm not sure about is whether there is any case where it does make sense to specify a single destination but with a device index, and if so I'm not sure how to implement that without changing the API
<rbasak> Yeah but at the stage where the netlink payload is generated, it's not possible to distinguish between the API user having set an interface and not having set one (AFAICT)
<rbasak> There is no sentinel or flag, AFAICT, because in the multipath-only case a per-destination interface is mandatory
<cyphermox> rbasak: isn't there already a check being done for whether an interface is set in the multipath struct?
<rbasak> This is assuming that the issue isn't something to do with the multipath handling - I fixed it by taking that out
<rbasak> No, I don't think so - the only check is to see if multipath is enabled, which happens automatically when you add a single nexthop
<rbasak> The reason is that in the wire protocol for multipath an interface isn't an option, it's part of the RTA_MULTIPATH struct
<rbasak> so in the add nexthop libnl3 function, I think you're supposed to set one in all cases - you can't leave it undefined
<larsu> tkamppeter, okay, I have a non-crashing verions of liblcms1. It does generate lots of "Error: Can't create transform" errors, though
<larsu> but that seems to be a deeper problem
<cyphermox> rbasak: you have a patch ready no? if you send me I have an idea I could send you back what I mean as a revision of your patch :)
<rbasak> Note that when I do "ip -6 route add default gw ..." without a device specified, the kernel nevertheless works one out and adds one - but that's done at kernel level, not in userspace
<cyphermox> rbasak: well, something is done by the ip util to send a netlink message, but I suspect it' s an "old"  message
<pitti> mterry: is there a bug for the lightdm upload? this change isn't straightforward and obviously regression free, so I'd like to know more details
<pitti> mterry: (will answer in a bit, need to run out for some errands)
<rbasak> cyphermox: the ip util follows a different path depending on whether you are using multipath or not
<rbasak> cyphermox: I tried doing a single destination specified in the multipath syntax and ip rejected it - this might be ipv6 only
<mterry> seb128, you said you hadn't seen a bug for the gdmflexiserver thing, that it came over IRC?  I'll search for one
<pitti> mterry: in particular, how does this prevent the utility path from appearing in the actual session?
<seb128> mterry, right, I had a look and didn't find one open
<mterry> pitti, we want it in the actual session.  the bug is that it's not
<mterry> pitti, this is how we've had lightdm override gdm's gdmflexiserver
<rbasak> cyphermox: patch: http://paste.ubuntu.com/702750/
<pitti> mterry: that's strange, though, and might still break with custom $PATH settings in ~/.profile, etc?
<pitti> mterry: don't we rather want to put those programs in to $PATH in the .deb?
<pitti> anyway, really off now
<pitti> (back in ~ 45 mins)
<mterry> pitti, only custom PATH settings that completely override PATH, which is bad behavior, no?
<mterry> pitti, well, putting it into PATH has its own set of problems.  GDM's executable is already in PATH.  There's another kdm package that adds a divert to it to add their own.  So we could add another divert, switch to an alternatives system, modify PATH, or maybe something else.  PATH was seen as least offensive, although seb128 continues to feel icky about it
<mterry> pitti, There is no bug associated with it, because we used to do things this way, then someone noticed that it was no longer being inserted into PATH and commented to seb128 about it on IRC.  I can file one?  To reproduce, uninstall gdm and lock your screen.  Normally, you should be able to switch users from that dialog, but since it can't find gdmflexiserver, you can't.
<seb128> mterry, yeah, it's chrisccoulson who asked if the "switch user" was missing in the lock screens for others earlier
<chrisccoulson> hi :)
<seb128> hey chrisccoulson
<chrisccoulson> it was actually jo who noticed it was missing ;)
<seb128> chrisccoulson, want to open the bug? ;-) mterry is fixing it
<rbasak> cyphermox: so "ip -6 route add default via 2001:db8::1" would be how I'd do it, but I think "ip -6 route add default nexthop via 2001:db8::1" is syntactically correct in that it defines a single entry multipath route. But the latter fails with "Error: an IP address is expected rather than "2001:db8::1"". I wonder if IPv4 single-entry multipath routes work but IPv6 doesn't?
<chrisccoulson> seb128, for lightdm or gnome-screensaver?
<seb128> chrisccoulson, lightdm
<seb128> well lightdm has a gdmflexiserver
<cyphermox> rbasak: it's very possible ipv6 doesn't, you' d have to look it up in the libnl or netlink kernel code
<seb128> it's just that it fails at injecting the directory in the path
<seb128> which mterry has a merge request for now
<seb128> that should fix the bug
<rbasak> cyphermox: well, that's what libnl3 is requesting from the kernel :-)
<rbasak> (without my patch)
<seb128> (why did we switch to #ubuntu-devel? ;-)
<cyphermox> that said, I want to make sure we don't only cover the default gateway, because if this fails now nothing says it wouldn't also fail for a "<net> dev <dev>" route
<seb128> (oh, pitti pinged there)
<rbasak> Ah
<cyphermox> rbasak: what about this: http://paste.ubuntu.com/702756/
<rbasak> Yeah, that's the kind of thing I was worried about, but I didn't think of that very common case!
<seb128> chrisccoulson, mterry, pitti: the other option is to patch gnome-screensaver to tech it about the lightdm gdmflexiserver path
<seb128> but we might have other things trying to use gdmflexisever
<seb128> that command is an hack to start, we should replace it with dbus interfaces next cycle ;-)
<rbasak> cyphermox: that's fine, but what if I didn't want to set an ifindex (in the default case)?
<seb128> or make gnome-screensaver use those interface if we already have them
<cyphermox> rbasak: right, I don' t think it's a common case, but since it is actually correct (e.g. p2p links)... and ifindex is set unconditionally in multipath, so why not set it unconditionally in the route
<cyphermox> rbasak: I'd test this first of course, but if you don' t want to set it I think it defaults to nothing
<rbasak> cyphermox: I'm concerned that it defaults to undefined
<mterry> seb128, it's also gnome-shell and I think one more package
<cyphermox> rbasak: isn't that fine?
<mterry> maybe gnome-session
<cyphermox> rbasak: we' re also always setting it up in NM when the route is being added :)
<rbasak> no, because it'll be whatever happened to be at that memory location previously
<chrisccoulson> seb128, mterry, pitti - bug 868363
<ubottu> Launchpad bug 868363 in lightdm (Ubuntu Oneiric) "Can't switch user from a locked screen (no gdmflexiserver binary in $PATH)" [High,Triaged] https://launchpad.net/bugs/868363
<seb128> chrisccoulson, thanks
<mterry> chrisccoulson, awesome
<rbasak> OK so if NM does set it then it'll be fine in that case
<cyphermox> I believe it just defaults to 0, but it would be nice to test it
<cyphermox> and doing so couldn' t be easier :)
<rbasak> But then the libnl3 API won't allow the "please kernel work it out yourself" case that I do with the ip tool
<rbasak> However, if the NM case will work, then I don't think we'll have broken anything and we'll have fixed the bug
<rbasak> and it'd be nice to see my ipv6 working in oneiric :)
<cyphermox> would be nice to have a second opinion from upstream; do you want to send it to the mailing list?
<rbasak> me? :)
<cyphermox> or actuially, would be best to give it a bit of testing first, but then I can send it :)
<rbasak> I did try writing an email for the list, but I had great difficulty in explaining the issue
<rbasak> Please remember to check that it doesn't break ipv4 - that would be embarrassing :-)
<cyphermox> hehe
<ScottK> RAOF: Is there any actual content in your dbus-sharp sync?  From debian/changelog it looks like a no-change upload.
<cyphermox> rbasak: who needs ipv4 now anyway?
<rbasak> cyphermox: those of us with a missing ipv6 default route :-P
<pitti> mterry: ah, I didn't see the discussion in #u-desktop, I just reviewed the upload
<pitti> thanks for the explanatino
<mterry> pitti, (it's understood that PATH mangling isn't optimal, but we haven't come up with an amazingly better way that doesn't involve GNOME switching to dbus for this)
<pitti> mterry: accepted and closed the bug, thanks!
<skaet> hallyn_,  its a reasonable SRU candidate.  If the fix is ready though, we haven't started spinning images, so if Daviey reviews and doesn't see side effects, I'm ok with it going in.
<hallyn_> skaet: thanks
<hallyn_> skaet: oneiric-proposed won't open until next month I assume?
<cjwatson> you can upload to oneiric-proposed right now, although that isn't to say anyone will look at it
<cjwatson> (and it's not necessarily a good idea unless you're certain the package in oneiric is at its final version there)
<cjwatson> we do sometimes use it just before release
<mvo> jibel: I can reproduce and I think I found the problem
<SpamapS> jamespage: hey are you familiar with the udevadm settle initramfs bug that adam_g has seen?
<mvo> jibel: I will have a word with doko about it, its really odd
<jibel> mvo, thanks for confirming, I reopen the report then.
<mvo> jibel: please open a task against gcc-4.4-base again
<mvo> jibel: the bug is in the breaks of the gcc-4.4-base package
<mvo> jibel: I will add details tehre
<frafu> Can anybody please tell me whether it is possible to extract the tooltip for translation from the following tag of an xml file?
<sladen> frafu: URL?  path?  example?
<frafu>                 <key group="bottomrow" id="showclick" image="show-click.svg" button='true' tooltip='Toggle click helpers'/>
<frafu> The corresponding program (named Onboard) is written in python.
<sladen> frafu: the ideal would be use an XML parser.  Failing that, some quick and dirty grep/awk would do it.
<frafu> Is intltool not able to extract the tooltips in order to put them into the pot file?
<cjwatson> I think that only works with files in a certain form; in particular (from a quick reading of the code) I think it would need to be _tooltip=
<kelemengabor> frafu: have you tried adding translatable="yes" ?
<kelemengabor> if this is from a glade file, it should do the trick
<cjwatson> that wouldn't help intltool-extract in this case
<cjwatson>     while ($input =~ /<(property|atkproperty|col)\s+[^>]*translatable\s*=\s*"yes"(?:\s+[^>]*context\s*=\s*"([^"]*)")?(?:\s+[^>]*comments\s*=\s*"([^"]*)")?[^>]*>([^<]+)<\/\1>/sg) {
<cjwatson> does not match <key ...>
<kelemengabor> oh
<cjwatson> that doesn't look like glade to me anyway?
<frafu> I think that  translatable="yes" works for tags that also have a closing tag. But the <key /> tag does not have a closing tag.
<frafu> Assuming that I change the xml file to use _tooltip instead of tooltip without underscore. Does it also remove the underscore from the tooltip tag in the xml file (it is not a glade file) before putting it into the source package when calling ./setup.py sdist?
<frafu> cjwatson: Here is where the file is hosted.  http://bazaar.launchpad.net/~onboard/onboard/main/view/head:/layouts/Compact.onboard
<Riddell> mdke: please add me "jr" to ~ubuntu-core-doc
<lamont> my wife is not happy with oneiric
<lamont> lpstat got a segv, she let apport report it, and now her display is hung up.
<frafu> cjwatson : What approach would you recommend? Manually extracting the tooltips into a separate file, which intltool can read? (We are doing it already for the some labels of the gui. )
<cjwatson> don't know sorry
<cjwatson> meeting now
<cjwatson> my instinct is that if you put things in a .in file in a way that intltool-extract can read then it should drop things like leading _ in the output file - but I cannot help in detail sorry
<frafu> cjwatson : I will first try the underscore method. Thanks anyway for the help you have given.
<jamespage> SpamapS, I'm familiar with it symptomatically and spent some of yesterday with jhunt trying to diagnose furthur
<kelemengabor> frafu: no, removing the _ markers is not automatic, you need to call intltool-merge -x on the files at build time
<adam_g> jamespage: were you guys able to gain any insight into Bug #818177 ?
<ubottu> Launchpad bug 818177 in udev (Ubuntu Oneiric) "boot failures caused by udev race" [High,Confirmed] https://launchpad.net/bugs/818177
<jamespage> adam_g, jhunt tried a few things on my reliable test case - but I don't think we move much further forwards
<hallyn_> jamespage: has anyone tried hacking udev to keep handling events until the queue is empty when asked to exit?
<hallyn_> I'm still unconvinced that we won't lose kernel netlink uevent msgs between shutdown and startup of the rootfs udev, but...
<hallyn_> (but i suppose the replay is supposed to fix that)
<adam_g> jamespage: im wondering if the 'udevadm control --exit' is blocking the subsequent move of /dev to ${rootmnt}/dev.
<adam_g> hallyn_: ^
<adam_g> remounting the udev devtmpfs again after a failed boot shows the directory populated
<hallyn_> adam_g: well the udevd does hang (bc there are unhandled events) so yes the move doesn't happen until after that...
<hallyn_> but i'm working from memory atm
<hallyn_> i never was able to reproduce it with udev instrumented to tell me the *contents* of the non-empty worker and/or event lists :)
<adam_g> hallyn_: did you modify udev to output that or were you depending on additional shell commands in the hook?
<hallyn_> udev
<adam_g> ah :(
<hallyn_> just added some code to walk the lsits and print the contents
<hallyn_> if i just had it say 'list empty' or 'list not empty' i coudl still reproduce,
<hallyn_> but adding looping over the list, that heisenberged on me
<bdmurray> jhunt:         - ProcEnviron: A subset of the process' environment (only some standard
<bdmurray>           variables that do not disclose potentially sensitive information, plus
<bdmurray>           the ones mentioned in extraenv)
<jhunt> bdmurray: maybe apport could be tweaked to include all environment variables *names* (but no values)?
<jhunt> bdmurray: ... we might get a few 'MY_DODGY_PICS_AND_VIDS_DIR' entries, but... :)
<bdmurray> jhunt: what's the value of doing all names?
<jhunt> bdmurray: atleast we could know if DISPLAY say has some value. If sensitive, we can then ask for a sample value from the user. Right now, we've only got a small handful of vars. Maybe we just add a few more like DISPLAY in full though.
<bdmurray> jhunt: /win last
<bdmurray> jhunt: http://bazaar.launchpad.net/~apport-hackers/apport/trunk/view/head:/apport/report.py#L392
<frafu> kelemengabor : Thanks for the tip about removing the underscore.
<kelemengabor> you are welcome :)
<jhunt> bdmurray: how about DISPLAY and TERM then? Re env names only, would be useful to just know that LD_LIBRARY_PATH was set to any value I think.
<jhunt> bdmurray: and LD_PRELOAD :)
<cjwatson> kelemengabor: FYI I corrected a Hungarian translation of gfxboot-theme-ubuntu (s/_/^/)
<cjwatson> https://translations.launchpad.net/ubuntu/oneiric/+source/gfxboot-theme-ubuntu/+pots/bootloader/hu/+translate?batch=10&show=all&search=Enlist
<kelemengabor> cjwatson: thanks! a bad reflex from me :(
<cjwatson> just noticed while merging into the package
<bdmurray> jhunt: bug 868501
<ubottu> Launchpad bug 868501 in apport (Ubuntu) "ProcEnviron should include DISPLAY among other things" [Undecided,New] https://launchpad.net/bugs/868501
<jhunt> bdmurray: thanks!
<Laibsch> Can somebody help me understand where the package alarm-clock-applet picked up the run-time dependency on gconf2 >= 2.28.1-2 although that package is not in the PPA or its dependencies?  The same package locally compiled has a dependency on gconf >= 2.10.1-2
<Laibsch> https://launchpad.net/~r0lf/+archive/stable/+packages
<jtaylor> is someone working on bug 851383? it would be a shame to release with a broken geany (and possible other gtk2 apps) :/
<ubottu> Launchpad bug 851383 in gtk+2.0 (Ubuntu) "geany crashed when trying to open a second file" [Medium,Triaged] https://launchpad.net/bugs/851383
<jtaylor> apparently caused by a libgtk2.0-0 2.24.6 regression
<tjaalton> isn't auth-client-config deprecated? still in main, no updates in over three years
<micahg> ok, so chromium failed to build on armel, I disabling --no-add-needed will fix it, I hate to do it, but we're close to release and I don't want to block armel images (if they exist for lubuntu/mythbuntu), opinions?
<slangasek> tjaalton: I don't believe there's anything else that implements the NSS side of things
<tjaalton> slangasek: but it conflicts with pam-auth-update? maybe it just needs some cleanup & love, and of course support for sssd :)
<tjaalton> conflicts as in functionality wise
<slangasek> didn't I neuter it to *not* conflict with p-a-u?
<slangasek> or maybe jdstrand did
<tjaalton> oh, the changelod does mention something about that
<tjaalton> nevermind then, haven't actually ran it myself, just heard that it exists
<jdstrand> I should probably remove it
<jdstrand> some people do still use it aiui, so I've been reluctant
<tjaalton> jdstrand: not so fast, it could still prove useful :)
<jdstrand> heh
<jdstrand> well, I'll take some time to look at it
<hallyn_> jamespage: fwiw http://people.canonical.com/~serge/udev-debug.debdiff is the simplest patch i'm trying to debug with
<infinity> micahg: There are no ARM images for lu/myth, but it would still be nice to not have it broken..
<ScottK> jtaylor: there's an upload in queue to address it.
<jtaylor> ah good
<jtaylor> hm only that one patch added?
<jtaylor> that did not fix it for me
<barry> ScottK: bzr merging sid's python3-defaults source branch into oneiric's is not conflict-free.  however, i think we can drop the one ubuntu delta in our branch, so i'm thinking a sync would be better, except for this: http://pastebin.ubuntu.com/702924/
<barry> ScottK: thoughts?
<jtaylor> maybe I screwed it up, building the apcakge
<ScottK> I think some of the versions need to be different in the maintainer scripts for when 3.2 became supported.
<ScottK> I may be wrong though.
<ScottK> It can't actually be a sync though due to the version differences.
<barry> ScottK: here are the diffs from doko's last change: http://paste.ubuntu.com/702928/
<barry> ScottK: so essentially, all those will be mirrored or overwritten in a "sync"
<ScottK> Right, but we need the 3.2~rc1/3.2.2 changes.
<barry> ScottK: yes, but after a merge debian/rules will have this:
<barry> PREVVER := 3.2.2~rc1
<barry>  
<ScottK> Right and it needs to be 3.2.2.
<superm1> jtaylor, i wasn't able to reproduce it in geany with that patch
<barry> probably 3.2.2-0ubuntu2. because of the version numbers, as you say we can't do a straight sync, so i'll try to smack bzr merge-package around some more
<superm1> jtaylor, you were just opening the 'file open' dialog several times right?
<jtaylor> superm1: weird, I'm almost done building
<barry> ScottK: ^^.  not sure why merge-package is puking all over the merge tho :/
<jtaylor> superm1: you have to open a file once first
<jtaylor> I'm also cloning git to see it there something else needed, but that will take a while with my connection ._.
<superm1> jtaylor, yeah i tried several different ways to open it, geany $ARGS followed by opening a file
<ScottK> barry: You and your fancy UDD stuff are on your own for that bit ...
<barry> ScottK: ;)
<superm1> and # geany, open a file and then try to open another
<superm1> wasn't getting any crashes with it applied
<jtaylor> k maybe I screwed something up while patching
<barry> ScottK: yeah, i'm just afraid that if i go old skool, the udd importer will choke on it, which will just make things more crappy.  /me wonders if james_w has any thoughts
<ScottK> barry: It won't make things crappier for the actual code in the archive, so I'd suggest short that out later when we aren't in a time crunch.
<hallyn_> Daviey: are you around?
<barry> ScottK: yeah, you have a point there
<james_w> barry, what does the puke look like in this case?
<barry> james_w: http://pastebin.ubuntu.com/702939/
<james_w> barry, urgh
<barry> james_w: i don't get the debian directory conflict
<james_w> barry, what's the diff -r ancestor:../sid look like?
<barry> james_w: http://paste.ubuntu.com/702940/
<james_w> barry, odd, it looks like it somehow has a different root file id or something
<james_w> I'm not sure how to deal with that exactly
<james_w> a merge and then returning all the contents of the files to what is desired (without using revert) would be one (perhaps painful) way of doing it
<barry> james_w: i can generate a diff in the sid branch and manually change the oneiric branch, so for immediate purposes, i can muddle through.  is it possible when p opens to just blow away the oneiric branch and overwrite it with the sid branch (i.e. just sync us back up with debian)?
<james_w> that wouldn't reflect reality though
<james_w> and likely the problem would continue with p
<barry> hmm
<james_w> applying the diff indeed works, but the same thing will occur next time you want to do a merge
<barry> james_w: my concern is that after the merge debian/ only has the conflict files, while debian.moved/ has all the good stuff in it, though i'm not sure their contents is what we ultimately want
<james_w> yeah
<james_w> barry, that would be the (perhaps painful) :-)
<barry> james_w: so i'm thinking: apply the patch and produce a source package for ScottK to approve for his time-constrained need.  then go through the painful merge to see if i can get some sanity.  that painful merge can even wait in a separate branch until p opens up
<james_w> that sounds good to me
<barry> cool, thanks
<adam_g> slangasek: i just hit the bug with udev event logging.
<slangasek> adam_g: yay!  Dump please :)
<adam_g> slangasek: http://paste.ubuntu.com/702960/
<adam_g> im still hung in manual recovery, if there is anything else you want me to poke at. i can dump a log of a successful boot if thats useful
<slangasek> a successful boot would be nice to compare with, yes
<slangasek> also, would be great if you can attach both to the bug so we don't lose them
<slangasek> adam_g: to be clear, this is bug #818177? or #862823?
<ubottu> Launchpad bug 818177 in udev (Ubuntu Oneiric) "boot failures caused by udev race" [High,Confirmed] https://launchpad.net/bugs/818177
<adam_g> slangasek: 818177
<slangasek> ok
<shadeslayer> jono: does half a pitcher of beer count as drunk? :P
<adam_g> slangasek: http://paste.ubuntu.com/702962 <- a good boot. both logged on the ticket
<Daviey> hallyn_: o/
<barry> ScottK: here's the diff.  i'm building it in my ppa for testing and if it looks good, i'll dput the package (unless you want to give the thumbs up now): http://paste.ubuntu.com/702967/
<ScottK> prevver shouldn't change.
<ScottK> Other than that, looks good.
<ScottK> Please upload when that's fixed and you're ready.
 * barry nods
<hallyn_> Daviey: is there a certain step in package creation that is supposed to substitute in the right values for '@sysconfdir@', or do we need to do that by hand in debian/rules?
<hallyn_> suppose i'll just do it by hand...
<mdke> I've uploaded a new ubuntu-docs with translations. If someone could approve this so that the translations will be included in the langpacks for the release, that would be much appreciated
<jono> shadeslayer, lol
<Daviey> hallyn_: Good question.  I believe that is DEB_CONFIGURE_SYSCONFDIR
<jtaylor> I supose updating gtk2 to git HEAD for oneiric is not possible at this stage or?
<jtaylor> the gtk2 24.6 filechoser mess cleanup is pretty much impossible to backport without making some mistake :/
<Daviey> hallyn_: if it is dh, you could do: override_dh_auto_configure: dh_auto_configure -- --sysconfig=/etc/
<micahg> jtaylor: superm1 updated gtk2 for a crash in the filechooser
<Daviey> (there is a linebreak and tab between :)
<jtaylor> yes but not correctly
<superm1> micahg, unfortunately it's sounding like there might be another codepath that was causing the crash too
<micahg> ah, ok
<superm1> it fixed it for me, but it's still happening to jtaylor
<jtaylor> no blame on him, its not easy to backport this 1000 line diff
<micahg> well, is it only on installed systems or live media as well?
<hallyn_> Daviey: sysconfdir is being set right for the code, it just isn't being expanded in the manpage
<hallyn_> Daviey: what you suggest is for if that isn't being set in configure right?
<bdmurray> slangasek: would moving bug 745501 to file-roller be the right thing?
<ubottu> Launchpad bug 745501 in Ubuntu "psrG4g" [Undecided,New] https://launchpad.net/bugs/745501
<RAOF> ScottK: I haven't requested a dbus-sharp sync?  If it's a sync of 0.7.0-4 then it will indeed be a no-op.  That might be Laney driving needless diff-from-debian down.
<TheMuso> ScottK: Oh thanks so much for pushing that fix for pulse. I was looking to do the same.
<TheMuso> ScottK: Do you have a bzr branch you used anywhere, so I can sync up the packaging branch?
<ScottK> TheMuso: Great.
<ScottK> TheMuso: No.  I dput it.  I figured the importer would handle it.
<TheMuso> Ok.
<ScottK> (I grabbed the other change that was pending in bzr, so the diff from what's there is what I added to the package)
<TheMuso> ScottK: we don't use the ubuntu branches for packaging. Never mind, I'll fix it up.
<ScottK> Oh.  Thanks.
<ScottK> I thought the Vcs-* field pointed there.
<TheMuso> No it doesn't, but never mind.
<slangasek> bdmurray: I suppose so :)
<slangasek> bdmurray: (as opposed to redirecting it to someone who speaks German?)
<bdmurray> slangasek: don't you? is the german about file-roller or something else?
<Daviey> halyno, that is for if it IS for ./configure
<Daviey> (DISLAIMER: i have been wrong before.)
<Daviey> hallyn_: ^^
<slangasek> bdmurray: it's about an "archive", and he reported it via file-roller... so that may be what he's referring to
<slangasek> he seems to be saying he can no longer create archive files through file-roller
<bdmurray> slangasek: got it thnaks
<jtaylor> success! f4814585 aa8f54b736 79d16aab need picking, maybe one of them can still be removed
<jtaylor> but that I'll do tomorow gn8
<slangasek> adam_g: it would probably be useful to see if some lvm-related scripts are still running at the time everything gives up
<broder> "Ubuntu precise" - that's going to take a while to get used to parsing
<cjwatson> indeed
<barry> stgraber: ping
<stgraber> barry: pong
<infinity> broder: Yeah, but we'll have the best post-release updates ever with precise-security and precise-updates.
<broder> ha!
 * ajmitch thinks that quickly should be renamed to precisely
<infinity> ajmitch: You've clearly not looked at what it does.
<ajmitch> wouldn't you want to 'precisely package'?
#ubuntu-devel 2011-10-06
<tomswartz07> I didnt get a chance to look, but does anyone know offhand if there is a bug filed about the screen lock timeout set to 'never' immediately blanking the screen?
<tomswartz07> specifically, after 0 seconds of inactivity, the screen fades to black (lock). Only happens when the timeout is set to 'never'.
<mdeslaur> tomswartz07: bug 863038
<ubottu> Launchpad bug 863038 in gnome-screensaver (Ubuntu) "If turnoff the screen setting set to 'never' screen turns off instantly" [High,In progress] https://launchpad.net/bugs/863038
<tomswartz07> splendid thanks mdeslaur
<tomswartz07> to avoid it, i switched to tty, and its too difficult to search launchpad using 'links'
<pitti> Good morning
<ajmitch> morning pitti
<pitti> ogasawara, apw: do we need a -meta bump for the -headers-lbm stuff on http://people.canonical.com/~ubuntu-archive/component-mismatches.txt ?
<tkamppeter> pitti, hi
<dholbach> good morning
<dholbach> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Beta 2 Released | Archive: Final Freeze | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: dholbach
<pitti> diwic: you can still upload a new pulse if necessary (for fixing patch application)
<dholbach> cjwatson, regarding https://bugs.launchpad.net/ubuntu/+source/python-meld3/+bug/749880 - should I unsubscribe sponsors for now as you're handling it?
<ubottu> Ubuntu bug 749880 in python-meld3 (Ubuntu Natty) "Current version incompatible with Python2.7" [Medium,Triaged]
<cjwatson> dholbach: as you like, it's actually just waiting for SRU review at this point
<dholbach> ah ok
<cjwatson> but if you'd prefer to get it out of the queue that's fine; I've subscribed directly now
<dholbach__> you're right - I could've just changed the natty queue :)
<dholbach> pitti, how do you feel about getting gnome-color-manager 3.2.0 in now? it's in universe, and while it's not 100% bugfixes only it looks like it fixes a whole bunch of bugs
<pitti> RAOF: ^ any opinion?
<dholbach> https://code.launchpad.net/~jbicha/ubuntu/oneiric/gnome-color-manager/3.2/+merge/77637
<pitti> dholbach: hm, so it seems nobody packaged the further 3.1.x releases :(
<dholbach> if you want, I can pastebin the news file
<pitti> dholbach: I'd say, upload it, and we'll review it from the queue; unless you already see that it has new unsatisfyable build deps or so
<dholbach> no no, it builds fine
<pitti> NEWS is in the MP
<dholbach> http://paste.ubuntu.com/703253/
<dholbach> ah ok
<dholbach> ok, will do
<pitti> meh, who changed devscripts to use "precise" by default
<pitti> shouldn't we only do that _in_ precise, not already in oneiric?
<diwic> pitti, yeah, I think we should upload a new pulseaudio (if it makes it to the RC, that'd be great!), my question was more about the workflow, kinda where to apply what
<pitti> diwic: you mean how to correctly apply the patches? I can have a look at the package, if you tell me what is wrong
<infinity> pitti:
<infinity> devscripts (2.11.1ubuntu2) oneiric; urgency=low
<infinity>   * debchange: Add precise, and make it the new default upload target.
<infinity>  -- Stefano Rivera <stefanor@ubuntu.com>  Thu, 06 Oct 2011 01:27:08 +0200
<pitti> a bit premature IMHO; if anything, this should have switched to oneiric-proposed :)
<pitti> anyway, not a biggie
<infinity> pitti: Heh.
<infinity> The default is wrong for me 99% of the time anyway.
<infinity> Chroots, Debian vs Ubuntu, etc, etc.
<diwic> pitti, my question is more about lp:~ubuntu-audio-dev/pulseaudio/ubuntu.oneiric - I mean, should I ignore it today and make a debdiff for you to sponsor, or should I try to import ScottK 's change to the tree, then apply my stuff on top of that?
<pitti> hm, I really don't know
<pitti> diwic: FYI, RC is around Monday, so still time
<pitti> today is a good day still for targetted patches which have a very low regression risk
<diwic> pitti, I just pushed ScottK's stuff and mine on top of that to lp:~ubuntu-audio-dev/pulseaudio/ubuntu.oneiric
<diwic> pitti, on dtchen's recommendation
<diwic> pitti, feel free to sponsor
<pitti> diwic: done; looks fine, thanks
<ev> mvo: I just had to help John Oxton recover a partial upgrade because X/compiz crashed while he was running through it.  Have you ever thought of running update-manager under xpra or some other screen-for-X like trick?
<ev> (xpra: http://code.google.com/p/partiwm/wiki/xpra)
<mvo> ev: that is a excellent idea
<mvo> ev: hrm, not packaged
<mvo> yet
<mvo> ;)
<mvo> ignore me, it is
<ev> I think I did *AGES* ago
<diwic> pitti, I don't know if you're Ã¼ber-busy with Oneiric today, but if you aren't, do you know https://launchpad.net/ubuntu/+source/pulseaudio/1:0.9.22~0.9.21+stable-queue-32-g8478-0ubuntu14.1 hasn't reached lucid?
<diwic> pitti, it's been sitting in lucid-proposed for months.
<dholbach> can somebody help me mark https://code.launchpad.net/~psusi/ubuntu/natty/gnome-power-manager/fix-duplicate-battery/+merge/67466 as merged (r188)?
<pitti> diwic: there's a lot of chatter on that bug 445849, but it seems nobody actually tested the proposed pacakge and gave feedback?
<ubottu> Launchpad bug 445849 in pulseaudio (Ubuntu Lucid) "Highpitched rattling like sound with 5.1 surround configuration" [Undecided,Fix committed] https://launchpad.net/bugs/445849
<diwic> pitti / dholbach, is it the verification-needed -> verification-done stuff that's needed here?
<pitti> diwic: less so the tag setting, but a report that someone actually tested teh -proposed package and confirms that it works
<pitti> (i. e. not a local build, and someone who is affected by the bug)
<dholbach> can somebody please reject https://code.launchpad.net/~bones/ubuntu/natty/radiotray/fix-for-722886/+merge/70107 (fixed in oneiric, sru rejected)
<diwic> pitti, to complicate matters further, the lucid-proposed actually only fixes the bug for *some* people (i e amd64). I have one more patch to fix it for i386.
<diwic> Would the right thing to do here, to make a new debdiff on top of the lucid-proposed one
<diwic> and upload/test that to lucid-proposed again?
<diwic> pitti, I think I could verify that one myself
<pitti> diwic: depends; if the current version helps some people and doesn't regress others, we can also move it to -updates and then do another SRU
<pitti> diwic: if it might regress for some people, better to do a new SRU on top of -proposed right away
<diwic> pitti, I'd prefer the latter
<pitti> ok, let's do that then
<diwic> ok, I'll prepare a debdiff for 14.1 -> 14.2 (?), just having lunch first.
<dholbach> pitti, regarding bug 722936 - could it be that the .pot file needs to be updated?
<ubottu> Launchpad bug 722936 in jockey (Ubuntu) "Missing a space in "toolsfor"" [Low,Fix committed] https://launchpad.net/bugs/722936
<dholbach> or is that going to be a 'precise' thing?
<pitti> dholbach: it should be auto-built during package build
<pitti> dholbach: it's only in trunk right now (string freeze)
<pitti> hm, wait
<dholbach> ah, I checked the source package and it seems that the string was only in the .po and .pot files
<pitti> right, but is still in ubuntu branch
<pitti> cjwatson: want me to seed ubuntu-defaults-zh-cn and ask for a MIR review, so that we can build the image from main only? (to fix oversizedness)
<cjwatson> if that's the only way
<pitti> cjwatson: in my mail I pointed out some alternatives, but I think at that point it's the safest way
<mvo> ev: I played with that a bit in lp:~mvo/update-manager/xpra-experiment but its not that encouraging, it seems to be a bit unstable
<ev> mvo: oh? I never had any trouble running Pidgin under it, but that was admittedly about two years ago.
<ev> very cool though - I'll have a look at the branch in a bit
<pitti> didrocks: do you have a minute today to look at bug 869058?
<ubottu> Launchpad bug 869058 in ubuntu-defaults-zh-cn (Ubuntu) "[MIR] ubuntu-defaults-zh-cn" [Undecided,New] https://launchpad.net/bugs/869058
<didrocks> pitti: sure, will look at it
<pitti> didrocks: merci
<didrocks> pitti: I have a gtk2 version of glade parallely installable now
<didrocks> pitti: will push it in the glade-3 source package soon
<pitti> didrocks: oh, nice!
<didrocks> will need BINNew and suchâ¦
<pitti> didrocks: why not a separate source?
<pitti> didrocks: or does hte current version still support gtk 2 with different configure options?
<didrocks> pitti: glade-3 is already 3.8 (for the old gtk2 library needed with pygtk)
<didrocks> glade is 3.10
<pitti> oh, glade vs. glade-3
<seb128> didrocks, pitti: why do we need glade-2 back?
<didrocks> yeah
<didrocks> seb128: because Quickly is using pygtk
<didrocks> seb128: and 3.10 is gtk3 only
<didrocks> like, it uses box and not hbox, vbox
<seb128> oh ok
<didrocks> and pygtk can't instantiate those
<didrocks> so yeah, we need it back :/
<didrocks> let me just readd a removed patch for expanding the treeview by default
<didrocks> oh dch -r "" set "precise" now :)
<didrocks> pitti: glade-3 pushed, will upload Quickly to dep and run the gtk2 flavor now
<jml> has someone asked LP to rename p-series?
<pitti> didrocks: thanks for the MIR
<pitti> cjwatson: it's in main now, so cdimage can drop the --components argument now
<didrocks> pitti: yw ;)
<cjwatson> pitti: cdimage doesn't have it, it's in BuildLiveC
<cjwatson> D
<cjwatson> actually, is it
<cjwatson> I can't find --components anywhere relevant; how did it work before?
<cjwatson>         COMMAND="ubuntu-defaults-image --locale ${UBUNTU_DEFAULTS_LOCALE} --arch ${ARCH} --release ${STE}"
<pitti> cjwatson: how are xubuntu/mythbuntu etc. built? Is there a lookup table somewhere mapping images to components?
<pitti> no, that wouldn't affect u-d-image
<cjwatson> pitti: that's in livecd-rootfs/live-build/auto/bconfig
<dholbach> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Beta 2 Released | Archive: Final Freeze | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<didrocks> pitti: just pushed the new lenses with the icon change and some other fixes
<didrocks> pitti: FYI, you will see in the diff:
<didrocks> -Icon=/usr/share/unity/4/lens-nav-app.svg
<didrocks> +Icon=/usr/local/share/unity/4/lens-nav-app.svg
<didrocks> this is fine, the config is rewritten during build
<pitti> didrocks: ok, thanks for the warning
<didrocks> pitti: yw, this thing pretty much depends on who make the tarball :)
<ScottK> diwic: Thanks for fixing the pulseaudio issue.
<pitti> didrocks: did you actually upload?
<pitti> still not in the queue
<pitti> didrocks: dch got changed to default to precise, maybe you stumbled over that?
<didrocks> pitti: ahah, nice catch!
<didrocks> probably :)
<ev> mvo: ah, mpt fairly points out that the correct solution here is to port update-manager to use aptdaemon and handle bringing the UI back up when the user logs in again
<ev> (on the xpra thing)
<diwic> ScottK, np
<diwic> ScottK, the same to you, btw. Was it phonon that depended on a three version string?
<ScottK> phonon and skype AFAIK.  Probably more.
<diwic> pitti, so for the old bug 445849, let's upload a new one to lucid-proposed: https://launchpadlibrarian.net/82117342/pulseaudio14.1.14.2.debdiff - and if noone really tests, I guess it's a wont fix for Lucid.
<ubottu> Launchpad bug 445849 in pulseaudio (Ubuntu Lucid) "Highpitched rattling like sound with 5.1 surround configuration" [Undecided,Fix committed] https://launchpad.net/bugs/445849
<mvo> ev: yeah, that is indeed the right solution, there is even a ancient branch in this spirit lp:~mvo/update-manager/gui-seperation but it never got anywhere :(
<mvo> ev: because of time/other stuff, but it would be really good to finish that
<ev> indeed! :)
<Riddell> kenvandine: do you use the UDD branches for the freeciv package?
<kenvandine> Riddell, i think i did for the one upload i did
<kenvandine> i can't remember for sure, i've only touched it once :)
<ogasawara> pitti: linux-meta is at 3.0.0.12.4 so it should be the correct abi to match lbm.
<pitti> ogasawara: maybe there is no metapackage for headers-lbm?
<pitti> at least I can't see one
<pitti> not sure how we handled that in the past
<pitti> ogasawara: also, do we support linux-image-extra-3.0.0-12-virtual ? that's also not covered by metapackages
 * pitti notes it is tremendously easier to have all binaries in main, otherwise SRUs will just make a mess out of components
<ogasawara> pitti: hrm, indeed it does look like we're missing an lbm meta package.  let me investigate.
<ogasawara> pitti: ah yes, the -extra package is new and supported.  I'll get that fixed up as well.
<pitti> ogasawara: thanks
<tkamppeter> pitti, am I right that if I have a source package in Main and one of its binaries is in Universe, if I want to promote this binary to Main I do NOT need a MIR?
<kenvandine> tkamppeter, no... something in main needs to depend on it or it needs to be seeded on the CD to get promoted
<pitti> tkamppeter: correct
<didrocks> pitti: thanks for the u-l-f and u-l-a, sorry for the false alarm. /me shouldn't use dch -r "" anymore ;)
<tkamppeter> pitti, kenvandine, thanks.
<jdstrand> pitti: hi! fyi bug #868695 (I didn't see you were subscribed, so just mentioning it here)
<ubottu> Launchpad bug 868695 in apport (Ubuntu Oneiric) "[oneiric] apport test suite failure" [Undecided,New] https://launchpad.net/bugs/868695
<pitti> jdstrand: will follow up on the bug later, thanks
<pitti> jdstrand: btw, do you need anything else from me for bug 866049?
<ubottu> Launchpad bug 866049 in postgresql-8.3 (Ubuntu Hardy) "New bug fix releases: 8.4.9, 8.3.16" [High,Fix committed] https://launchpad.net/bugs/866049
<jdstrand> pitti: nope, looks great, thanks :)
<jdstrand> pitti: as always, much appreciated
<bdmurray> pitti: Do you ever run into "'NoneType' object has no attribute 'makefile'" with the retracer?
<bdmurray> pitti: when using db.download in apport
<mneptok> is use of "whois" now discouraged in Ubuntu (i rarely keep up with the "groovy new tools/way" stuff)? been using Debian for the past 3 U releases or so. my Xubuntu 11.10 laptop does not have whois in the default install.
<stgraber> mneptok: whois simply isn't seeded by Xubuntu
<stgraber> mneptok: it's in Ubuntu and Edubuntu because gnome-nettool depends on it
<stgraber> and ubuntu-desktop depends on gnome-nettool
<mneptok> ach so.
<mneptok> i was afraid i had missed some "OMG YOU STILL USE WHOIS?!??! USE $something_hip INSTEAD!" thing. /me installs
<ev> mneptok: seriously dude, roll your own ;)
<jtaylor> any recommendations what to do with gtk2? bug 851383
<ubottu> Launchpad bug 851383 in gtk+2.0 (Ubuntu) "geany crashed when trying to open a second file" [Medium,Triaged] https://launchpad.net/bugs/851383
<jtaylor> I seem to have found the commits which fix the issue, but that probably introduces a bunch of other bugs as the code is strongly refactored in git
<jtaylor> this is what I extracted: http://paste.ubuntu.com/703493/
<jtaylor> I'd prefer to go back to .5 and hope upstream regains its sanity at some point
<jtaylor> superm1: ^
<jtaylor> or we do what debian did and add all 560 line changes
<superm1> jtaylor, i'd defer to #ubuntu-desktop folk in this scenario, they're the ones that maintain the package mostly
<superm1> can you check in there?
<cyphermox> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Beta 2 Released | Archive: Final Freeze | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: cyphermox
<slangasek> jhunt, hallyn_, apw: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/818177/comments/57 clearly points to udev being idiotic with its handling of 'udevadm exit' - the command has succeeded but all the workers are left running
<ubottu> Ubuntu bug 818177 in udev (Ubuntu Oneiric) "boot failures caused by udev race" [High,Confirmed]
<slangasek> this is a recent (oneiric) change to the initramfs -bottom script
<apw> slangasek, i concur they are clearly there ...
<apw> jhunt, i am up to 32 reboots without failure changing from move to bind, which would fit with those not being dead
<slangasek> we changed from using pkill to udevadm exit in response to bug #787610 / Debian bug #624469
<ubottu> Launchpad bug 787610 in udev (Ubuntu) "udevd fails to start: bind failed: Address already in use" [Undecided,Fix released] https://launchpad.net/bugs/787610
<ubottu> Debian bug 624469 in udev "Fails to start: failed to bind control socket (address in use)" [Serious,Fixed] http://bugs.debian.org/624469
<apw> slangasek, yep we swapped one fails to boot 1:10 for another
<slangasek> yes
<slangasek> so
<slangasek> there are two possible fixes that I see
<apw> slangasek, so when did we introduce the mount -o move for /dev, that is pretty new
<slangasek> 1) fix 'udevadm exit' to reap its children (but that may not be correct vis-Ã -vis upstream)
<apw> which i assume is what is exposing this new 1:10 boot failure
<slangasek> 2) call 'udevadm exit', and then *also* call pkill udevd to reap any remaining children
 * apw thinks 2 isn't a bad option
<slangasek> apw: the mount -omove dates back to 2009... :)
<apw> heh really? i thoought we only started doing that when dev became a devtmpfs
<apw> slangasek, i thnk you should put what yo just said in the bug, the link to the ps output is key evidence
<slangasek> yep
<apw> slangasek, i wonder if we could also do something like this as belt-and-braces
<apw> slangasek, mount -o move A B || mount -o bind A B
<infinity> slangasek: Say, with an amd64 adobe-flashplugin in partner (well, in unapproved right now), do we get to undo all the crazy multiarch and plagunwrapper business for flashplugin-nonfree? ;)
 * infinity wonders what a plagun is...
<pitti> bdmurray: that certainly rings a bell; not sure when I saw it the last time, though, it seems to be intermittent
<bdmurray> pitti: okay, I've hit it a few times but couldn't recreate it this morning
<mdeslaur> infinity: yes, that would be nice
<infinity> mdeslaur: Did you just volunteer?
<mdeslaur> infinity: uhm, no :)
<infinity> mdeslaur: We're in a hard freeze, I'm sure you're bored.
<mdeslaur> infinity: security is like the post office, CVEs never stop coming in
<mdeslaur> I'm not even sure how come I ended up holding the flash short straw in the first place
<jdstrand> mdeslaur: you know you love it :P
 * jdstrand dodges
 * mdeslaur puts flash short straw in jdstrand's pocket without him noticing
 * jdstrand notices something in his pocket and tosses it into the trash
<slangasek> apw: I'd rather not ignore the mount -o move failures... any processes blocking the move are liable to cause trouble down the line
<mdeslaur> jdstrand: is that a metaphor for you removing flash from the archive? \o/
<jdstrand> I admit I have an itchy trigger finger for that one :)
<slangasek> infinity: I don't intend to muck with that again for oneiric; but for p, sure
<slangasek> er, I mean for precise
<infinity> slangasek: Well, we at least need to muck enough to update the tarball bits, right?
<slangasek> yes, but that's all the mucking I endorse at this time :)
<slangasek> that and fixing the damn downloader to NOT CLAIM SUCCESS when it fails to install anything
<infinity> slangasek: At which point, you could just make -downloader arch:amd64 i386, and oops, it's done. :P
<infinity> (Well, and a couple other tweaks)
<maco> why is xterm installed by default?
<pitti> maco: mostly hysteric raisins, I figure; but it certainly makes a nice "if anything else goes wrong, this will still work" app?
<maco> i dont remember it being part of the default install
<maco> unity shows it when i search term though so i was surprised to suddenly see it
<mdeslaur> slangasek, infinity: FYI, I plan on SRUing flash 11 (including amd64) into stable releases, most likely after oneiric releases
<infinity> mdeslaur: You could just do it now. ;)
<mdeslaur> infinity: slangasek will unleash his wrath at me
<infinity> mdeslaur: He will?
<infinity> mdeslaur: It's uninstallable right now.
<mdeslaur> infinity: huh? how so? the old version should still be there
<infinity> mdeslaur: If you plan to SRU the amd64 change, we may as well do it pre-release, so people aren't starting with a multi-arch plugin and switching back.
<infinity> mdeslaur: The old version won't be there forever.  We download it from the orig in the parnet archive.
<infinity> mdeslaur: Once I accept Flash 11 into partner, the old one goes poof.
<infinity> mdeslaur: (And Flash 11 is in unaccepted right now)
<mdeslaur> infinity: not anymore, we have a hack to keep the old versions in partner for that specific reason
<infinity> unapproved, even.
<infinity> mdeslaur: Ahh.  Well, that's silly. ;)
<infinity> mdeslaur: But fine.  We should still do something about it.
<mdeslaur> infinity: you do know that the flashplugin package is actually part of the installer? if you remove the old versions, people can't install anymore until I fix it
<infinity> mdeslaur: Err, it is?
<infinity> mdeslaur: Which installer?
<mdeslaur> infinity: it gets installed as part of the "Install extra proprietary crap" checkbox
<mdeslaur> infinity: ubiquity
<mdeslaur> infinity: it's the only reason I don't get flashplugin-nonfree nuked from the archive this very minute
<superm1> mdeslaur, for precise you should push for that checkbox to enable partner instead and install flash from there
 * infinity is failing entirely to find this code in ubiquity.
<mdeslaur> infinity: it installs ubuntu-restricted-something and that pulls in flash
<mdeslaur> superm1: yes, except the partner archive isn't mirrored
<mdeslaur> superm1: but yes, foundations should do something about it in precise
<infinity> mdeslaur: Ah-ha.
<infinity> mdeslaur: Still, we don't install that stuff on the CD.
<superm1> mdeslaur, but flashplugin-nonfree pulls from partner indirectly anyway, so i think the mirroring concern is a non-starter
<infinity> mdeslaur: So, removing old versions isn't a concern.
<stgraber> infinity: if it's connectivity + non-free selected, it adds ubuntu-restricted-addons to the list of packages to download+install
<infinity> mdeslaur: Cause it's pulling the most recent from the archive.
<mdeslaur> infinity: yes, as soon as I release the new version, it works again...but I'm usually a day or two behind the partner archive
<mdeslaur> infinity: that's why we needed to keep the old versions there for a while
<infinity> mdeslaur: Oh, sure, I'm not saying partner shouldn't have a reaping delay (and all archives do), just that saying "it'll be there indefinitely, so we can wait" seems silly. :)
<mdeslaur> infinity: agreed
<infinity> mdeslaur: And every new Flash release is usually about 400 security fixes (and 200 new bugs, but whatever).
<jdstrand> infinity has cracked the short-straw code right there
<slangasek> mdeslaur: I'm happy for you to upload flashplugin-installer to oneiric before release, as long as you fix that darn exit 0 in the postinst along the way :)
<mdeslaur> slangasek: so...you want to prevent users from getting security updates if for some reason their flash tarball failed to download?
<jdstrand> oh, it's *on*
<mdeslaur> lol
<infinity> mdeslaur: It's general practice for postinsts to fail when they fail, yes. :P
<infinity> mdeslaur: And in the case where a postinst is THE WHOLE PACKAGE, that seems doubly-sane, no?
<mdeslaur> infinity: yes, I'm aware it's standard practice.
<mdeslaur> infinity: I just _hate_ the fact that a whole bunch of users stop getting updates at some point because a package is in a failed state and update manager stops working
<infinity> mdeslaur: Maybe our GUI tools need to learn to yell louder when that happens.
<infinity> mdeslaur: The command-line is pretty obvious about it.
<infinity> mdeslaur: Still, "fixing" every postinst to exit 0 unconditionally is the wrong answer.  Filing bugs on update-manager would be lovely.
<mdeslaur> infinity: yes...we should definitely fix the gui tools (if they haven't already been fixed)
<mdeslaur> infinity: I agree
<mdeslaur> slangasek, infinity: ok, you win, no more exit 0
<mdeslaur> jdstrand: I got a debian beatdown
<jdstrand> heh
<mdeslaur> infinity, slangasek: will apt upgrade from flashplugin-downloader:i386 to flashplugin-downloader:amd64?
<slangasek> mdeslaur: right, I'm with infinity on this one... we need update-manager to get better at recovering from package install failures in the middle of an upgrade, but honestly it's already a lot better than it used to be, and hiding errors is the devil's work :)
<slangasek> nope
<infinity> There's a fix for that.
<slangasek> if you drop the Multi-Arch: foreign from flashplugin-downloader, then the new flashplugin-installer will forcibly replace the i386 one with the amd64 one
<infinity> Want to hear it and cry?
<slangasek> infinity: no
<slangasek> :)
<infinity> Oh, that would work too.
<mdeslaur> slangasek: oh, cool. thanks
<infinity> (are you sure apt and dpkg will DTRT with MA bits going away again?)
<slangasek> infinity: yes.  It is possible that apt won't actually calculate the upgrade path we *want*, but it will know "flashplugin-downloader is out of date and the new version doesn't satisfy the dependency"
<slangasek> the question is whether it will *actually* upgrade, or if it will just try to remove stuff instead - should probably be tested in a ppa before upload :)
<slangasek> mdeslaur: ^^
<mdeslaur> slangasek: yeah, I'll test it
<infinity> slangasek: Yeah.  I was going to suggest something ickier to avoid that, but... It was icky. :P
<slangasek> I could tell ;)
<infinity> Though, mine's guaranteed to work. ;)
<infinity> (PS: Icky)
<mdeslaur> slangasek: is there something better than uname -m in a postinst to get the arch?
<infinity> mdeslaur: Eek.
<infinity> mdeslaur: dpkg --print-architecture
<mdeslaur> infinity: I assume that means yes :)
<infinity> mdeslaur: uname has nothing to do with dpkg arch.
<slangasek> uname -m is always the wrong tool
<infinity> mdeslaur: Think i386 base on an amd64 kernel.
<infinity> mdeslaur: For instance.
<mdeslaur> that's what happens when I cargo cult stuff from other packages I come across :P
<hallyn_> yeah i got that wrong with lxc-create too, stgraber set me straight :)
<stgraber> hehe :)
<infinity> mdeslaur: If you've found uname in another package, I'd like to know about it. :)
<slangasek> mdeslaur: so there are two relevant "what architecture" checks you might want.  One is "what is the primary architecture of this machine" (dpkg --print-architecture), the other is "what is the architecture of this package in multiarch land" (echo $DPKG_MAINTSCRIPT_ARCH)
<mdeslaur> infinity: I did, but I can't remember where
<mdeslaur> slangasek: oh, so $DPKG_MAINTSCRIPT_ARCH is the arch of the package itself? hmm, I'll use that
<slangasek> correct
<mdeslaur> slangasek: thanks
<slangasek> that way you don't have to munge the maintscript at build time to get that info
<superm1> mdeslaur, stgraber , if i'm not mistaken, it's just a one line diff to fetch flash from partner directly instead of multiverse via this ugly thing at install time. http://paste.ubuntu.com/703567/
<superm1> ubuntu-restricted-addons will already fetch adobe-flashplugin first if it's available
<mdeslaur> ooooh
<mdeslaur> slangasek, infinity: how about doing that and killing flashplugin-nonfree entirely?
<mdeslaur> ^
<slangasek> mdeslaur, superm1: blah, no
<slangasek> opting to install flash is not the same thing as opting to enable partner
<slangasek> if we wanted that, we should drop the package from multiarch entirely
<slangasek> also, this would lose all the nspluginwrapper integration, which AIUI adobe has rejected
<mdeslaur> slangasek: we don't need nspluginwrapper anymore
 * slangasek makes a sour face :)
<mdeslaur> slangasek: but, that's a good point, opting into that checkbox doesn't mean opting in to partner
<mdeslaur> slangasek: why the sour face?
<slangasek> regardless, I'm not ok with handling this via a policy change in ubiquity during final freeze
<slangasek> mdeslaur: because not all browsers have firefox's out-of-process plugin handling... the nspluginwrapper integration is IMHO still a feature :)
<slangasek> but yeah, technically we don't need it now
<mdeslaur> I'm not sure how the upgrade patch would have worked anyway
<mdeslaur> s/patch/path/
<slangasek> yeah
<hallyn_> doko: do you know why libnl-3 doesn't install /etc/classid?
<hallyn_> (Makefile still appears to generate it, and libvirt with netcf wants it.)
<cyphermox> hallyn_: I think it's an issue with whether makefile really tries to install it, or tries to install it in the right place
<cyphermox> and I fail, I should have tried to address this a few minutes ago
<cyphermox> hallyn_: I've seen a patch or commit on the mailing list or on git post libnl3 3.0
<hallyn_> cyphermox: ok, so it's not being droppedon purpose?
<hallyn_> ok, cool.
<cyphermox> hallyn_: no, I do think it's a bug. but I also don't see what it changes (not that I looked)
<hallyn_> cyphermox: thanks, I"ll work around it for now and file a bug later today
<cyphermox> aside from the message I saw no effect
<cyphermox> hallyn_: are you running into an actual bug with this?
<hallyn_> well libvirt tests are failing, i don't know if it's because of those or not
<hallyn_> cyphermox: yes, with the file installed the tests pass :)  so it will break libvirt build
<hallyn_> (when netcf is enabled, hopefully very soon)
<cyphermox> dah
<cyphermox> the tests pass?
<hallyn_> yes
<cyphermox> oh, sorry, I had missed reading one of the above lines :)
<hallyn_> np :)
<mdeslaur> slangasek: so a apt-get dist-upgrade is holding flashplugin-installer back
<hallyn_> now, the q, does this all actually *work* :)
<ricotz> slangasek, hi, this seems to be a multiarch related problem -- i am trying to compile this http://paste.debian.net/plain/134701 with the included command which results in a linker error, and it works using binutils-gold
<cyphermox> hallyn_: what's classid supposed to contain?
<hallyn_> "ClassID <-> Name Translation Table"
<mdeslaur> slangasek: but if I do "apt-get install flashplugin-installer", it wants to do the right thing
<hallyn_> cyphermox: it only has three, though.
<hallyn_> 0:0, ffff:ffff, and ffff:fff1
<slangasek> mdeslaur: yep, those were the two possible outcomes there, drat
<cyphermox> ah
<slangasek> ricotz: what does working using binutils-gold have to do with multiarch?
<ricotz> it might be a problem with the multiarched glib
<slangasek> I see nothing that suggests that
<ricotz> it seems the normal linker is missing a reference to -L/lib/x86_64-linux-gnu/
<ricotz> slangasek, can you confirm the error?
<slangasek> ricotz: I get an error; you didn't say what your original error was
<slangasek> abstract.c:(.text+0x10): undefined reference to `g_unix_socket_address_abstract_names_supported'
<slangasek> abstract.c:(.text+0x23): undefined reference to `g_print'
<slangasek> abstract.c:(.text+0x34): undefined reference to `g_print'
<slangasek> collect2: ld returned 1 exit status
<ricotz> yes, that one
<slangasek> nothing to do with multiarch
<slangasek> glib2.0 broke its .pc file
<ricotz> ok
<slangasek> Requires: gobject-2.0,gmodule-no-export-2.0,gio-2.0
<ricotz> so gold is adding some additional paths on its own then
<slangasek> I'm pretty sure that's the wrong syntax
<kees> slangasek: wow, neat. my system hung at boot waiting for my cryptswap to "be available"
<kees> I dropped to manual recovery, and everything looked fine (it was set up and available)
<slangasek> hmm
<kees> in a final bid to wonder if it got set up wrong, I ran blkid /dev/mapper/cryptswap1 and instantly the system finished booting
<sconklin> kees: have seen the same thing, exactly once, on a Natty system
<slangasek> kees: for the moment I assume this is a duplicate of one of the other two udev bugs
<slangasek> kees: is it random crypted swap?
<kees> slangasek: yeah
<Dean> nope
<slangasek> kees: so that should've been brought up in the initramfs.  racy-racy
<kees> slangasek: right, I assume it's the same bug too. I just hadn't seen blkid trigger udev happiness
<kees> slangasek: right, mountall told me it was waiting for it.
<slangasek> yeah, dunno about that
<slangasek> oh, if it's crypted random, I guess it wouldn't be registered as a RESUME target in the initramfs setup
<kees> slangasek: right, but it's listed in my fstab
<slangasek> kees: yes, I'm just working through why it wouldn't necessarily be brought up via initramfs
<slangasek> in fact, if it's not the rootfs or the RESUME target, I think cryptsetup explicitly does *not* try to bring it up in the initramfs
<kees> ah! right, yeah, this one isn't delayed, so it's effectively crossing the initramfs/real-root udev kill boundary
<slangasek> "isn't delayed"?
<slangasek> what's /conf/conf.d/cryptroot in the initramfs?
<kees> ... isn't waited for, is really what I meant.
<slangasek> right
<infinity> superm1: Dude, dpkg -l in your postinst?
<slangasek> and anything that isn't waited for, AFAIK isn't *attempted* at all
<superm1> infinity, not in the postinst, this is in a late script
<infinity> superm1: What are you trying to determine?  If a package is installed?
<infinity> superm1: Or, whever.
<kees> slangasek: should be empty, let me unpack it...
<superm1> infinity, yeah but just a quick check if it's installed to prevent badness from happening if so
<infinity> superm1: Either eay, that's not entirely guaranteed to work the way you think it will.  And you're much better off testing for a file on the filesystem from said package, IMO.
<superm1> infinity, really?  how can it break?
<infinity> superm1: If anything in dpkg -l matched 'fist', for starters?
<kees> slangasek: yeah, I don't have a /conf/conf.d/cryptroot at all
<infinity> superm1: (plus there's the part where packages can show in dpkg -l even when not installed, you're not actually checking the status, you're just checking to see if it's listed)
<broder> superm1: dpkg -l can also be really slow because it forces you to read the whole dpkg database off disk
<superm1> infinity, well that's a good point for futureproofing
<infinity> superm1: It's much saner to just test for a file that "fist" ships.
<superm1> want to axe the upload and i'll follow the recommendation?
<infinity> Rejecting.
<superm1> thansk
<slangasek> kees: ok, so it's not an initramfs issue.  There have been past reports of raciness between mountall and crypted swap; I think you'll find an open bug on mountall for this
<kees> slangasek: okay, cool.
<cyphermox> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Beta 2 Released | Archive: Final Freeze | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<cyphermox> I'll be back later; for now on the road / dinner and all :)
<cr3> is there a preferred package to get a utc timezone object in python on ubuntu? I've been using python-tz but it's not installed by default, so I'm hoping there's a recommended package more likely to be already installed
<cr3> aha, I believe it's python-dateutil!
#ubuntu-devel 2011-10-07
<micahg> slangasek: why was the aptitude multiarch issue marked won't fix?  are you sure the patch will be so scary it can't be SRUd?
<slangasek> micahg: ambiguity over the proper way to handle release-tracked bugs; I'll un-wont-fix it
<micahg> slangasek: thanks
<YokoZar> slangasek: Can I add depends:libllvm1 to ia32-libs-multiarch to make the nonproprietary drivers work?
<ScottK> YokoZar: Go for it.
<YokoZar> ScottK: What about adding /usr/lib32/dri to the library path in that package?
<YokoZar> err not that package
 * ScottK looks at slangasek.
<YokoZar> but somewhere
<YokoZar> since if it's not somewhere we'll have to have environment variables on launching any 32 bit 3d program :/
<slangasek> you have to do that anyway
<slangasek> you should not add any of the 32-bit libGL to the system path
<slangasek> because it's a halfway measure that's going to break the other cases harder
<slangasek> YokoZar: libllvm1 doesn't seem to exist as a package?
<Sarvatt> can't believe 11.10 is shipping without libgl1-mesa-dri:i386 being installable, darn libpciaccess :(
<Sarvatt> multiarch libpciaccess is in ppa:ubuntu-x-swat/x-updates at least
<slangasek> Sarvatt: fwiw, with only 6 reverse-build-deps, it would've been doable for somebody-who-isn't-me to prove that we wouldn't regress and get an FFe for the sync... but now it's too late :/
<YokoZar> slangasek: *libllvm2.9
<slangasek> YokoZar: ah yes
<Sarvatt> slangasek: argh, I've been using it for 2 months and bringing it up for weeks and have been told it was too crazy to do past final freeze when it finally got uploaded to debian
<slangasek> Sarvatt: hmm
<YokoZar> Are we worried about breaking the rdeps?
<YokoZar> because they'd have to be some pretty serious rdeps for their breakage to be worse than libgl1-mesa-dri not being installable...
<Sarvatt> no accelerated GL on open source drivers is insane to ship with
<Sarvatt> (for 32 bit apps on amd64, sorry)
<slangasek> we care about not breaking *any* reverse-deps when doing freeze exceptions
<Sarvatt> not to mention flash is one of the things that uses libgl1-mesa-dri:i386 if its available
<Sarvatt> well not anymore with 64 bit flash
<slangasek> Sarvatt: have you verified that all the reverse-depends of libpciaccess build against the multiarched version?
<slangasek> if that's confirmed, we might still talk skaet into it if there's a window
<YokoZar> slangasek: Sarvatt: quick way to test that is to upload them all to a PPA
<YokoZar> (this also helps you prove it ;) )
<Sarvatt> seriously? no I haven't but thats definitely something worth the time and effort vs. shipping 11.10 without wine/google-earth/32 bit flash working properly on open source drivers
<slangasek> FWIW, it's news to me that flash wants libgl1-mesa-dri... there's nothing in the depends/recommends to indicate this, and it's been working here forever
<slangasek> Sarvatt: anyway, how quickly do you think you could test the revdeps and get bug #864123 turned into an FFe?
<ubottu> Launchpad bug 864123 in libpciaccess (Ubuntu) "libpciaccess0:386 is uninstallable on amd64 " [Undecided,Confirmed] https://launchpad.net/bugs/864123
<slangasek> (and a local build is probably faster than a ppa if you're set up for it, since you don't have to wait for libpciaccess to be published in your ppa before building against it...)
<YokoZar> I'll get on the PPA
<YokoZar> If you can point me to the libpciaccess0 package to sync
<YokoZar> err
<YokoZar> is the package in ppa:ubuntu-x-swat/x-updates  just synced from debian?
<Sarvatt> flash uses GL if its available for rendering, libgl1-mesa-dri has the accelerated drivers in it that makes it work fast, its not required or anything and uses software if not. libgl1-mesa-glx just has libGL in it but not DRI drivers that are required to actually use the GPU
<slangasek> Sarvatt: yes, there's no mention of libgl1 in the flashplugin-downloader package's recommends - and there ought to be
<Sarvatt> libpciaccess 0.12.1-2 is in debian testing
<Sarvatt> (and multiarched)
<Sarvatt> libgl1-mesa-dri depends on libdrm-intel1 which depends on libpciaccess0 (which isn't multiarched in oneiric making libgl1-mesa-dri uninstallable)
<YokoZar> PPA builds are in progress btw
<skyblaster> there seems to be a regression between beta1 and beta2 on the tg3 driver. I'm getting "eth0: link is not ready" when trying to bring up the interface (BCM57785). Link LED is on after issuing "ifconfig eth0 down" and extinguishes when trying to bring it back up. Anyone here able to help diagnose. I don't see any open tickets on this issue
<RAOF> YokoZar: If you need a hand with pciaccess I can help / take over if you run out of time.
<YokoZar> RAOF: slangasek: Sarvatt: half way done, PPA here: https://launchpad.net/~scottritchie/+archive/build-tests/+packages?field.name_filter=&field.status_filter=&field.series_filter=oneiric
<lamont> infinity: is the bbg3/beagle3xm manualness your doing?
<slangasek> YokoZar: I am confused by the set of packages I see in that ppa
<infinity> lamont: Yes.
<lamont> cool
<infinity> lamont: If we have an emergency built for release, I want it to hit a panda.
<lamont> yep
<infinity> s/built/build/
<YokoZar> slangasek: are you looking at the 2 deleted ones?
<slangasek> YokoZar: the relevant set of reverse-deps is intel-gpu-tools, libdrm, libvirt, radeontool, xorg-server, and xserver-xorg-video-intel
<YokoZar> slangasek: yes those are in progress uploading atm
<slangasek> YokoZar: ah, ok
<slangasek> also, libhbalinux
<YokoZar> libhbalinux?
<slangasek> YokoZar: nah, ignore that one, it's FTBFS in universe anyway
<skyblaster> Forget my earlier question, there is a bug, but not with tg3. As soon as Additional Drivers scanned for new hardware, eth0 came up :-)
<slangasek> skyblaster: glad to hear you got it sorted
<skyblaster> slangasek: You're telling me. Just got this new Acer AS5750-9851 yesterday. Broadcom wireless and Broadcom GigE <barf>. Thought I was in quite the predicament with neither working.
<slangasek> YokoZar: xserver-xorg-video-ati built before libpciaccess was published; please re-test that build
<YokoZar> slangasek: Yeah I just noticed that, reuploaded
<slangasek> thanks
<YokoZar> all packages are uploaded, ball is in launchpad'
<YokoZar> launchpad's court now ;)
<slangasek> yep
<slangasek> Sarvatt, RAOF: we have RM approval for this to go in today/tomorrow, provided the diff stands up to my scrutiny and the rebuild test clears it
<RAOF> slangasek: Ok, thanks.  I don't expect there to be any rebuild problems, and obviously because I did the multiarching the diff will be perfect ?.
<slangasek> :)
<slangasek> there are other changes in that upload though
<YokoZar> Assuming this works as planned, can I then put libgl1-mesa-dri  into ia32-libs-multiarch's list?
 * YokoZar wonders what the implications of removing it from ia32-libs entirely would be since everything using it seems to be broken...
<RAOF> Yes, that would be right.  Although you shouldn't need to, because libgl1-mesa-glx:i386 Recommends libgl1-mesa-dri:i386
<YokoZar> RAOF: true, but will apt install it on update if it was previously uninstallable when its status as recommends is unchanged?
<RAOF> ?I don't think so, actually, no.
<RAOF> So it'd work for upgrades from Natty, but not people who updated from, say, Beta 2.  Which isn't particularly welcoming :)
<YokoZar> I'll sneak it in then, as we'll need a final ia32-libs upload anyway to make sure every package is fresh
<YokoZar> slangasek: all builds complete in PPA
<RAOF> yokozar, slangasek: Anything I can do to help this along?  It seems like the next step is to hit the button and get the diff reviewed, right?
<slangasek> RAOF: I'm a-reviewin'
<YokoZar> This is probably the bug to post in: https://bugs.launchpad.net/ubuntu/+source/libpciaccess/+bug/864123
<ubottu> Ubuntu bug 864123 in libpciaccess (Ubuntu) "libpciaccess0:386 is uninstallable on amd64 " [Undecided,Confirmed]
<pitti> Good morning
 * slangasek waves
<YokoZar> Ahh good morning to the European crew.  Still working on multiarch/ia32-libs issues :/
<slangasek> RAOF, YokoZar: libpciaccess accepted
<RAOF> slangasek: Rocking.  Thanks muchly. +1 beer for UDS.
<slangasek> RAOF: I assume that beer is transferrable in the case something blows up from this and I owe a beer to skaet ;)
<RAOF> Of course! :)
<slangasek> hallyn_: ping
<YokoZar> If beer is transferable, then I should forward all those beers I got offered over the window controls blog post a year ago...
 * Sarvatt owes infinite beers, thank you guys so much for that
<Sarvatt> wasn't going to be fun explaning to my ubuntu convert friends that they needed to use a PPA to use wine in 11.10 otherwise :)
<YokoZar> funny you mention that
<YokoZar> the version in oneiric is one before the complete sound rework :D
<ajmitch> Sarvatt: what game were you wanting to play? ;)
<pitti> apw, ogasawara:
<pitti> The following packages have unmet dependencies:
<pitti>  linux-image-extra-3.0.0-12-virtual : Depends: linux-image-3.0.0-12-virtual (= 3.0.0) but 3.0.0-12.19 is to be installed
<pitti> seems something went wrong with the dependency generation?
<pitti> "= 3.0.0" looks very wrong
<ScottK> So I'm assuming the PPA versioning on the udev upload wasn't on purpose ...
 * ScottK eyballs slangasek.
<slangasek> nope
<slangasek> rather, the versioning was and the upload wasn't
<slangasek> apparently the order of the arguments to 'dput' is significant!
<slangasek> who knew?
<slangasek> self-rejected now
<ScottK> OK.
<pitti> slangasek: do you mind to commit to the Vcs-Bzr: branch, too?
<slangasek> pitti: for something that's not supposed to have been uploaded? yes, I do mind :)
<pitti> ah, ok :)
<pitti> I misunderstood the error the other way round
<pitti> slangasek: FYI, https://github.com/kaysievers/udev is the current tree (temporary location)
<pitti> but I didn't see anything related to --exit
<slangasek> pitti: ah, good to know
<dholbach> good morning
<micahg> pitti: can you set https://code.launchpad.net/~rye/ubuntu/natty/bindwood/update-firefox-6-compat-fix/+merge/76055 to rejected please?
<pitti> micahg: I can't, sorry
<didrocks> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Beta 2 Released | Archive: Final Freeze | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: didrocks
<pitti> I'm not currently a member of ~techboard
<pitti> sabdfl needs to put us all back in
<micahg> pitti: oh, I thought the TB could...
<micahg> ah, right
<pitti> we timed out
<pitti> sabdfl: oh, you're online
<pitti> sabdfl: how are you?
<pitti> sabdfl: any chance that you can re-populate https://launchpad.net/~techboard ?
<lifeless> pitti: a sysadmin could fix it too
<pitti> ah, I guess so
 * lifeless speculates should ~techboard be owned by ~council or something (or whatever the team is)
<Galantus> hello world
<Galantus> am i in the cave of developers
<apw> Galantus, yes, if you have a question on ubuntu development this is the place
<Galantus> uhh awesome:P
<Galantus> ill start with a bold one
<Galantus> where do i start?
<apw> https://wiki.ubuntu.com/UbuntuDevelopment
<Galantus> yes ive already been referred there on ubuntu-il
<Galantus> but im not very experienced you know?
<Galantus> where would you advice me to start coding?
<apw> with something that interests you i guess
<RAOF> It's also important to note that we don't do a huge amount of *coding*.
<Galantus> you dont?
<RAOF> At least, not in Ubuntu.  When we code, it generally goes to the upstream project.
<RAOF> Sometimes the upstream project is driven by Canonical; Unity, for example.  Mostly it's not, like the kernel or the GNOME apps, or KDE, etc.
<Galantus> ohh
<Galantus> so where do you guys code?
<Galantus> like where should i hahaha
<RAOF> Like apw said: wherever you're interested in.  Most open source developers start by scratching their own itch.
<Galantus> i heard other devels fire that line before
<Galantus> but what if i dont have an itch lol
<diwic> I have never used harvest myself, but maybe that would be interesting if you want to find bugs to fix
<diwic> Galantus, http://harvest.ubuntu.com/
<Galantus> thanks man ill start looking around:)
<Galantus> so what other projects do you guys code for?
<Galantus> just curiosity haha:P
<diwic> Galantus, I'm doing audio stuff, so mostly in the kernel drivers and PulseAudio. But a lot of time is also communicating, triaging bugs etc.
<Galantus> shit that sounds really interesting
<Galantus> in what language do you work?
<diwic> Galantus, mostly C
<OdyX> .oO(English)
<diwic> (kernel and PulseAudio are both written in C)
<Galantus> cool ill check that out:)
<didrocks> jhunt: I think you are in charge of mountall as well, isn't it? In that case can you look at some typo fixes: https://code.launchpad.net/~cldunlap1/ubuntu/natty/mountall/fix2-for-805509/+merge/78135 ?
<jhunt> didrocks: looking...
<jhunt> didrocks: I've now commented.
<didrocks> jhunt: thanks a lot!
<damg> what should I do with https://bugs.launchpad.net/ubuntu/+source/gnome-system-monitor/+bug/725248 ? the user reported that in 11.04 the problem got fixed. Simply put on fix commited w/o verification?
<ubottu> Ubuntu bug 725248 in gnome-system-monitor (Ubuntu) "System Monitor no longer reports all cpus" [Low,Incomplete]
<seb128> damg, set it fix released
<damg> ok, thanks
<seb128> damg, thank you for triaging ;-)
<damg> as of  11.10, it looks like I'll return to launchpad :)
<brendand> i've got a weird issue with an application i'm maintaining - basically it uses a GtkWindow for a dialog to indicate that a script is running, but what seems to happen is that if too many of them are instantiated in a short period of time then the whole application gets hidden to the launcher
<brendand> if i introduce a small delay into the code the problem stops occuring
<brendand> could be something to do with hide() being called to many times actually, because if i never hide the dialog then the problem doesn't occur
<damg> dou your windows get a focus? maybe it is a matter of timing and the window manager executes hide on the wrong object.
<damg> s/dou/do
<pitti> jdstrand: there are two remaining WIs on https://blueprints.launchpad.net/ubuntu/+spec/desktop-o-lightdm which sound related to your team: "Check two-factor works well", and "Perform security review"; right now they are owned by Robert, but especially the latter would make more sense for security?
<pitti> jdstrand: I reassigned the second one to you, please feel free to delegate further; not sure who would be able to test two-factor?
<didrocks> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Beta 2 Released | Archive: Final Freeze | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<brendand> damg - that's what i'm thinking. should i check if they have focus before hiding them?
<damg> I would take a look at that
<brendand> damg - though i just tried checking if they were mapped, which should be as good - but it didn't help
<damg> hm
<damg> brendand, are those windows hidding from different threads?
<damg> s/hidding/being hidden/  I should talk more English and put oni my glasses :)
<brendand> damg - i don't think so. pretty sure this application is single threaded
<brendand> damg - well, seems like it is multi-threaded
<brendand> damg - problems with calling hide from different threads?
<damg> possible. for example if the pointer to the window is static.
<brendand> damg - btw, app is python based
<damg> you could put a mutex around those critical sections and see whether it works
<damg> hm, ok
<damg> is it an opensource one? I could take a look, too
<brendand> damg - lp:checkbox
<brendand> damg - the hide is happening in checkbox_gtk/gtk_interface.py:242
<damg> okay, I'll take a look in a few minutes (this VM is not the fastest :) )
<artfwo> hi
<artfwo> a main package (libffado) is suffering a severe regression, which renders the package unusable: debian bug 643024
<ubottu> Debian bug 643024 in libffado2 "libffado2: jackd can't start with libffado version 2.0.99+svn1995-1" [Grave,Fixed] http://bugs.debian.org/643024
<artfwo> debian has a fix - can the fix be synced/merged into ubuntu at this development stage? (ubuntu version has changes)
<damg> brendand, which tests produce such a fault?
<mdeslaur> pitti: there's a small two factor test pam module I've wrote here: http://bazaar.launchpad.net/~ubuntu-security/ubuntu-security-tools/trunk/files/head:/utilities/pam_twofraktor/
<mdeslaur> (If someone wants to run it against lightdm)
<brendand> damg - oh, that's a tricky one. run it using 'bin/checkbox-gtk -W data/whitelists/default.whitelist' and follow the prompts. you can skip tests, when you get to the one about USB audio, then pressing Next should make it happen
<damg> brendand, hm, interesting, I can't reproduce it in a virtual machine. You could try to send call to show_progress_pulse() directly after show_progress_start() in checkbox/user_interface.py:84 as it does some gtk event processing in gtk's pulse method
<jdstrand> pitti: re security review> ack. I was unaware of that work item, but it was on my todo list. I can't guarantee it will happen in time for release
<pitti> jdstrand: thanks
 * jdstrand is not really here today btw
<hallyn_> slangasek: I'm here if you still wanted to chat
<smoser> bug 863629
<ubottu> Launchpad bug 863629 in libvirt (Ubuntu) "libvirt-lxc: virFileOpenTtyAt can't be called on /some/other/dev/pts" [High,Confirmed] https://launchpad.net/bugs/863629
<kenvandine> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Beta 2 Released | Archive: Final Freeze | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: kenvandine
<jamespage> jhunt: hows udev feeling today?
<sabdfl_> pitti,  i made the CC the owner of TB, so others can admin it too
<sabdfl_> will update it now
 * dholbach hugs kenvandine
 * kenvandine hugs dholbach
<kenvandine> dholbach, todays list has quite a few old things with open questions still
<pitti> sabdfl_: splendid, thank you!
<dholbach> kenvandine, I noticed that the bug bot resubscribed the sponsors team in a couple of cases
<dholbach> is that it?
<lamont> so if I can't use ctl-X, HTF do I get nano to exit?
<kenvandine> maybe...
<kenvandine> but things like the ubuntustudio lightdm theme, you had asked if it needed a dep
<kenvandine> but it is still in confirmed
<kenvandine> i am going through the list looking :)
 * lamont figures out his path to happiness
<artfwo> i don't want to spam the channel, but i'm still not sure about what can be done with libffado regression, related to debian bug 643024
<ubottu> Debian bug 643024 in libffado2 "libffado2: jackd can't start with libffado version 2.0.99+svn1995-1" [Grave,Fixed] http://bugs.debian.org/643024
<artfwo> should i request a merge or a sync? debian version seems to have similar changes
<artfwo> also, would a merge be acceptable at this stage of development?
<diwic> artfwo, it seems definitely SRUable at least
<diwic> artfwo, have you verified it is a problem, in what Ubuntu versions?
<cjwatson> it probably ought to be a cherry-pick rather than a merge though
<diwic> cjwatson, agreed
<artfwo> diwic, cjwatson, yes, libffado worked in oneiric for me, but the latest upload broke it - i cannot start jackd anymore, symptoms are the same as in debian bug above
<artfwo> diwic, cjwatson, i built the latest debian version locally and the problem is gone
<diwic> artfwo, latest upload of libffado2 or jackd?
<artfwo> diwic, libffado - jackd has a linked ffado backend
<artfwo> there is also bug 855438, which is fixed both upstream and in debian, so a merge may be of double benefit, but i'm not sure
<doko> diwic, can you handle the libffado issue?
<diwic> doko, as an SRU or earlier than that?
<doko> diwic, either. it was just a rebuild. I assume libffado makes some bad assumptions about constructors/destructors
<diwic> doko, hmm, if a rebuild is all what's needed, and I don't have upload rights, there's not much I can do...?
<doko> diwic, no, apparently the rebuild did introduce the regression. what is needed is a sync, or just applying the fix
<diwic> doko, rebuild of libffado 2.0.99+svn1985-2 => libffado 2.0.99+svn1985-2ubuntu1 ?
<cjwatson> it wasn't a no-changes rebuild, but there were no changes relevant to x86
<doko> barry, ScottK:
<doko> Setting up python3 (3.2.2-0ubuntu2) ...
<doko> running python rtupdate hooks for python3.2...
<doko> running python post-rtupdate hooks for python3.2...
<doko> why? mixed up version numbers?
<barry> doko: ScottK needed an urgent merge for python3-defaults a few days ago
<doko> barry, but why run the rtupdate hooks?
<barry> doko: afaict from python3.postinst.in, they always run
<barry> (on configure)
<doko> barry, they only should when a new runtime is added, removed, or the default changes
<barry> doko: i'm just reading the file.  i guess POX would be able to answer definitively
<Daviey> wow, devscripts already targets P-Series.
<pitti> Daviey: s/wow/eww/
<pitti> cjwatson: does that look ok to you? http://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk/revision/529
<Daviey> pitti: yeah, kinda suprised me.
<Daviey> Anyone happen to know what sets, apt-config shell UpdateInterval APT::Periodic::Update-Package-Lists <-- in livebuild?
<cjwatson> pitti: yes, that looks fine; you need an RT ticket to land the change though
<cjwatson> pitti: they prefer you to attach the modified script to the ticket IME
<pitti> cjwatson: ok, thanks; uploaded, filing RT now
<cjwatson> pitti: bah, and the reason I couldn't find it in my tree was that I had staged the same change locally but not committed it :-/
<pitti> well, I'll file it once it's through unapproved
<slangasek> hallyn_: I guess when you say "/run is still mounted" you mean it's *not* mounted?
<pitti> cjwatson: heh
<hallyn_> slangasek: uh, no, disregard that comment :)  I thought /run/initramfs was supposed to get moved to /dev/.initramfs, but i ssee (on my laptop) it persists
<YokoZar> Any library updates currently in the queue for oneiric?  I'm about to roll the final ia32-libs package
<slangasek> hallyn_: ah; the intended behavior is 'mount -n -o move /run ${rootmnt}/run'
<slangasek> YokoZar: any library updates in the queue will be shot on sight
<YokoZar> slangasek: I suppose things like dependency changes wouldn't matter in this case
<pitti> ogasawara: http://people.canonical.com/~ubuntu-archive/component-mismatches.txt still has some linuxy stuff that wants to to go universe; I suppose we just seed the extra metapackages?
<pitti> ogasawara: it would tremendously ease our countless SRUs if all binaries are in main
<pitti> ogasawara: oh, our oneiric seeds still say "-natty", fixing
<pitti> ogasawara: http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/platform.oneiric/revision/1654
<pitti> will check c-m again tomorrow morning to verify
<pitti> I took care of nova-compute-xen and openoffice.org-gcj
<Daviey> mvo: Are you still running the upgrade testing?
<Daviey> pitti: did you, i thought i did?
<ogasawara> pitti: looks good to me
<pitti> Daviey: removed NBS openoffice.org-gcj, demoted nova-compute-xen
<Daviey> ah, thanks
<kenvandine> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Beta 2 Released | Archive: Final Freeze | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<kenvandine> but i'll be back :)
<Daviey> lynxman: Was the udev issue you had solved with adam_g's sleep patch?
<Daviey> (and that was the same hardware Trellis was using?)
<herton> pitti: around?
<kenvandine> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Beta 2 Released | Archive: Final Freeze | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: kenvandine
<Daviey> Does anyone have an oneiric fresh install handy?
<Daviey> fresh-ish.
<mvo> Daviey: yeah, the auto-upgrade tester is still running
<YokoZar> Ok, making final ia32-libs-upload.  Hopefully it's the last one ever.
<Daviey> Hi, can a few people please give me the output of: $ apt-config shell AutoAptEnable APT::Periodic::Enable && echo $?
<ScottK> barry and doko: Did you get python3-defaults sorted?  I was AFK.
<jamespage> Daviey: 0
<Daviey> jamespage: What is your system, and it's history?
<jamespage> Daviey: oneiric desktop; upgraded from natty about 1 month ago - natty was a fresh install
<Daviey> interesting.
<stgraber> Daviey: 0 here too on a fairly recent clean Oneiric installed from netinstall
<jamespage> Daviey: 0 on a fresh oneiric server install from this morning
<Daviey> jamespage / stgraber: apt-config shell AutoAptEnable APT::Periodic::Update-Package-Lists , rather
<stgraber> AutoAptEnable='1'
<jamespage> Daviey: 0 on the server
<barry> ScottK: i think was left hanging (and i got distracted with other stuff)
<jamespage> Daviey: AutoAptEnable='1'
<jamespage> 0
<jamespage> on the desktop
<Daviey> jamespage: So I have a natty server here which shows AutoAptEnable='1'
<jamespage> Daviey: double checked on the server - just a 0 - no  AutoAptEnable='1'
<jamespage> Daviey: ah - but that was off preseed with - d-i pkgsel/update-policy select none
<jamespage> that might make a difference
<Daviey> heh
<jamespage> Daviey: hmm can't get my natty iscsi root install to boot - lots of io errors
 * jamespage thinks this seems familiar
<Daviey> *awesome*
<Daviey> This day started so well.
<jamespage> lol
<Daviey> jamespage: can you throw that in a bug and link it on the tracker?
<jamespage> Daviey: the natty iscsi root install?
<jamespage> it looks like the same issue that we had in oneiric
<Daviey> Oh, you are seeing this on natty still?
<jamespage> stgraber: I can't remember - did you see the iscsi root issue that you fixed this release in natty?
<jamespage> then one where the open-iscsi daemon post initrd tramples the one that started first
<jamespage> Daviey: yes - thats what is confusing me
<stgraber> jamespage: nope, it's limited to Oneiric as a bug in upstart in Natty makes open-iscsi start before network is up
<stgraber> jamespage: so in Natty open-iscsi either does nothing or just exists
<stgraber> *exits
<jamespage> stgraber: then I'm not sure what I'm seeing then
<jamespage> it looks symptomatically like the oneiric issue
<stgraber> jamespage: that part of the boot may be racy or someone "fixed" natty and so introduced the bug there too ;)
<jamespage> I hacked the open-iscsi init script to just exit 0 rather than do anything and it boots just fine
<Daviey> for giggles, lets blame udev.
<stgraber> jamespage: my test system was a stock natty without updates IIRC
<jamespage> OK - this is a stock with updates
<stgraber> can you check if someone backported some of the upstart fixes that broke it in Oneiric?
<Daviey> stgraber: is there a bug on this?
<jamespage> Daviey; however I was able to confirm that when open-iscsi is not breaking stuff I don't get a long boot - but I do get a manual eth0 entry
<jamespage> Daviey: so technically I am seeing a regression
<stgraber> Daviey: the "hangs at boot time" bug was marked Fix released with the upload in Oneiric and I filed another one to track the "open-iscsi disconnects everything when we have / already on iscsi"
<stgraber> bug 850960 is the new bug and bug 838809 is the one I "fixed"
<ubottu> Launchpad bug 850960 in open-iscsi (Ubuntu) "iscsid tries to reconnect existing session at startup, failing to do so and hanging the system" [Undecided,New] https://launchpad.net/bugs/850960
<ubottu> Launchpad bug 838809 in open-iscsi (Ubuntu Oneiric) "authenticated and unauthenicated iscsi clients fails to complete boot" [High,Fix released] https://launchpad.net/bugs/838809
<stgraber> jamespage tracked it down to a change that happened in upstart 1.3-0ubuntu6 in Oneiric
 * Daviey formally invites stgraber to the Ubuntu Server Teams weekly meeting.
 * Daviey nees to go awol for a bit.
<ScottK> barry: I've got no time today to even think about it, so please work it out.
<barry> ScottK: maybe doko should file a bug
<falktx> hey there
<falktx_> I saw the latest kernel released went into -proposed
<bkerensa> k
<bkerensa> No RC?
<bkerensa> https://wiki.ubuntu.com/OneiricReleaseSchedule
<ScottK> RC isn't a formal milestone.
<ScottK> RC means we have images we think we might want to release.
<ScottK> We're starting to work on those, but there's a bit more to do.
<falktx_> hm, it was due to yesterday
<ScottK> No.  There is nothing due.
<ScottK> That's when you start working on potential release candidates.
<falktx_> oh, got it
<ScottK> You don't KNOW you have one until you release.
<bkerensa> kk
<ScottK> What we used to call RC is now called beta2 because it seems wrong to call something an RC that we know wasn't what we were going to release.
<slangasek> hallyn_: still around?
<hallyn_> slangasek: yes
<kenvandine> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Beta 2 Released | Archive: Final Freeze | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<slangasek> hallyn_: sorry - how about now :)
<hallyn_> a bit distracted, but here
<slangasek> hallyn_: wondering about getting combined logs from a failed boot... a ps at the end of init-bottom/udev, plus udevadm monitor -e output from the whole run
<slangasek> hallyn_: should I prepare a package that includes these mods?
<hallyn_> slangasek: that would be best, so we can have reliable reproducible results from
<hallyn_>  more than just me
<hallyn_> but again, a ps aat end of init-bottom/udev was not getting done
<hallyn_> well, that or fs tree was funky, and i should do it into kmsg
<slangasek> I noticed that the earlier outputting to kmsg showed things a bit scrambled
<slangasek> I think it's probably best to dump to stdout and capture the console output
<slangasek> anyway, I'll do up a test package then
<hallyn_> slangasek: great, thanks
<slangasek> hallyn_: btw, "is the scripts/init-bottom/udev file itself being killed?" - absolutely - the script is set -e!
<slangasek> so anything you try to do after the mount call will fail :)
<slangasek> or not be called, I mean
<Tecuhtli> I'm not sure if this is the correct place to ask but here it goes: is there any usage documentation for python-ftdi package?
<Tecuhtli> I have only found one page but its information refers to libftdi API
<slangasek> Tecuhtli: I don't think anyone here is likely to be familiar with it; the package is inherited without changes from Debian
<hallyn_> slangasek: d'oh.  of course
<Tecuhtli> thanks slangasek
<Tecuhtli> I will search there then
<hallyn_> slangasek: (I intend to test with your ppa later tonight)
<slangasek> hallyn_: cheers
<slangasek> hallyn_: hey, how do I use vm-new?  I get an error message about wanting a non-existent config file (~/.uqt-vm-tools.conf)
<slangasek> this seems contrary to the goal of having an easy-to-use wrapper for creating vms :)
<hallyn_> slangasek: yeah...  there's some initial setup involved.  see https://wiki.ubuntu.com/SecurityTeam/TestingEnvironment
<hallyn_> it looks worse than it is :)
<hallyn_> once it's set up, you can trivially create a set of new vms with 'vm-clone -c o1 o2'
<hallyn_> i noticed this afternoon, trying to create a lucid one from scratch, there seem to be trouble with some of the lucid archives or installers...
<hallyn_> at least the mini lucid iso installer fails
<hallyn_> will have to pursue that
 * hallyn_ curses the new alt-tab behavior one more time
<slangasek> hallyn_: ok; so these are the same steps you followed?  I'm trying to make sure the vm I wind up with matches yours
<hallyn_> slangasek: I followed those steps, but then used http://people.canonical.com/~serge/vm-new in place of that vm-new
<slangasek> ok
<hallyn_> (much smaller download).  and using apt-cacher-ng locally, though that shouldn't matter
<krutoileshii> Need help compiling rocket raid 2640 divider under Ubuntu 11.10. Fails to compile saying only supports 2.4 2.6 $ series
<krutoileshii> Does not compile under 3.0
<bdrung> Laney: you are haskell hacker?
<krutoileshii> (krutoileshii) (krutoileshii) Need help compiling rocket raid 2640 divider under Ubuntu 11.10. Fails to compile saying only supports 2.4 2.6 series
<cjwatson> I guess you'll have to find where it complains about that and fix it to handle 3.x
<cjwatson> and preferably to do a proper version check, or these days to drop the check altogether
<krutoileshii> Makefile.def
<krutoileshii> There are differences between the way 2.4 and.2.6 and up are compiled so there needs to be a check for that.
<cjwatson> well, if anyone cares about 2.4 any more ...
<krutoileshii> Not me, i'm in Mt phone right now, but I'd loved some help with modifying it.
<cjwatson> I mean, 2.6.0 was released almost eight years ago
<krutoileshii> I know the section approximately but not sure How to fix it
<krutoileshii> I know.
<cjwatson> really the maintainer of this out-of-tree driver should be fixing it
<directhex> it's closed.
<directhex> highpoint rocketraid ships a binary .o, which it munges into the C parts which are built against the target kernel
<krutoileshii> Maintainer is highpoint, i've contacted them, but haven't heard anything yet.
<directhex> it's as prone to breakage as you think
<cjwatson> right.  we really can't in general help with that kind of thing.
<krutoileshii> That part is not what's broken actually
<cjwatson> sounds like if you bypass the version check (which is probably straightforward, just hack it out) it may just explode your kernel later.
<krutoileshii> I've gotten it to compile and and run before under 2.8
<cjwatson> there has never been a 2.8 kernel
<directhex> highpoint aren't shipping a usable driver, and i'd be dubious about claims that the device is a real raid card, too
<krutoileshii> I'll take a look at that. Thanks. I meant 2.6.28 (it didn't originally)
<directhex> if there's magic they feel is worth protecting, then there's magic in the .o - and if there's amgic in the .o, it's doing things on your CPU rather than on your raid controller's io processor
<krutoileshii> Its not a real raid card. I use it for extra sata
<cjwatson> mm, 2.6.28 was quite a long time ago in kernel terms though
<cjwatson> who knows what kernel interfaces it's using that may or may not have changed ...
<krutoileshii> I'll post back on the progress.
<directhex> probably describes itself as GPL in the c wrapper, to avoid the limited exported symbols issue
<directhex> which was around 2.6.30something iirc
<krutoileshii> I had it working in 11.04
<directhex> 2.6.38 iirc
<directhex> should be close enough to 3.whatever
#ubuntu-devel 2011-10-08
<krutoileshii> Yep, I tried replacing the parts that check for 2.6 to 3 and it compiled, but it failed to install
<krutoileshii> Not sure what I missed yet, I'll do some investigating tomorrow. Thanks for the help.
<slangasek> hallyn_: heh; vm-new tries to bring the VM up with virtio networking, which fails with 'failed to find romfile "pxe-virtio.bin"'.  are there some other options I'm supposed to be using?
<jfi> Hello, I would like to know if a fix to bug #811003 is acceptable for Oneiric, or this kind of "bug" (more a feature) is generally delayed to the next release. I just want to know whether is usefull that I provide a debdiff or just wait the next sync from debian.
<ubottu> Launchpad bug 811003 in psensor (Ubuntu) "Psensor application indicator should use a mono-color icon" [Undecided,In progress] https://launchpad.net/bugs/811003
<hallyn_> slangasek: oh?  that should spit an error, but not fail
<hallyn_> slangasek: pxe-virtio is only for pxeboot over virtio
<slangasek> hallyn_: ah.  well, I'm looking at logs because what I'm experiencing is that the VM never comes up after reboot
<hallyn_> virsh list doesn't show it running?
<slangasek> no, it *does* show it running
<hallyn_> oh just ssh to it or gvncviewer :0
<slangasek> but it's not meaningfully "up"
<hallyn_> drat
<slangasek> oh, it does seem to respond to ssh, hmm
<slangasek> but vm-new doesn't finish because vm-ping fails?
<hallyn_> yeah the reporting isn't perfect at vm-new.  but the big win with vm-tools is the vm-clone command
<hallyn_> i don't use vm-new all that much
<hallyn_> but clone every day
<slangasek> well, I'm not sure if I should ^C this vm-new command...?
<hallyn_> yes
<hallyn_> look in / in the guest,
<hallyn_> if there is still a post-install.sh, run it as root, otherwise you're done
<hallyn_> so, your initramfs has 'udev.bak', will it run that?
<cjwatson> jfi: it's too late for UI adjustments at this point, so we're probably best just taking the next sync from Debian in precise
<cjwatson> jfi: although thank you for caring
<jfi> cjwatson, thanks for the response
<hallyn_> slangasek: scripts/init-bottom/udev is still not getting to the ps -ef (even when I add '|| /bin/true' after the pkill)
<hallyn_> oops, missed the other line, lemme try a || true after udevadm control --exit
<slangasek> hallyn_: Eduard points out on the bug that udevadm control --exit also exits non-zero if it hits the timeout... so you need a || true after that as well, sorry
<slangasek> right
<slangasek> hallyn_: udev.bak?
<hallyn_> yes, init-bottom/udev.bak existed in the initramfs.
<slangasek> uh
<slangasek> shouldn't be from anything I did
<hallyn_> don't nkow how that happened
<slangasek> but if it's executable, it'd try to run that as well
<hallyn_> it was
<hallyn_> probably i messed it up before
<hallyn_> haha no /bin/true in initrd
<slangasek> right, should just be called as 'true'
<slangasek> (shell builtin)
<slangasek> hallyn_: and what's the right way to attach to the console?
<slangasek> 'virsh console' doesn't give me anything useful
<slangasek> ah, of course, there's a separate 'vm-view' command for that - sigh, why is all this separate from virt-manager
<slangasek> hallyn_: vm-view doesn't provide much console scrollback... recommendations?
<hallyn_> slangasek: i usually just use gvncviewer and store logs to scp off later.  But https://wiki.ubuntu.com/SergeHallyn_libvirtserial   should work
<hallyn_> I used to do that for early boot kernel debugging...  Of course your vm then needs to define ttyS0 as a serial port in boot cmdline
<slangasek> hallyn_: got it, thanks
<slangasek> hallyn_: this hang-on-tty-event thing is just weirding me out.  what's /proc/cmdline for these boots?
<slangasek> i.e., do you have a serial console configured when this happens?
<slangasek> (because, once again, a tty is the last event processed)
<hallyn_> slangasek: no, i don't change cmdline at all
<hallyn_> slangasek: BOOT_IMAGE=/boot/vmlinuz-3.0.0-12-server root=UUID=442917ed-fe24-4f00-858a-152dbae9db58 ro quiet
<hallyn_> yeah no idea why those are always there
<slangasek> hallyn_: huzzah, I've reproduced it here - just took me a bit to realize I'd done so, since the initramfs script is fixed here to not die on udevadm timeout :)
<slangasek> (which means /dev actually gets mounted properly)
<bbigras__> It seems someone edited the main page of the wiki to create his own page. I reverted it and emailed him about it. I hope I did it right because I drank a bit.
<slangasek> bbigras__: looks good now, thanks
<slangasek> history also shows someone attaching their apt debugging logs to the page, heh
<bbigras__> slangasek: Oh that's why I wasn't able to revert to those revisions.
<slangasek> yeah, they aren't content changes to the page :)
<SanbarComputing> I need to prototype an app for a client that implements peer-to-peer messaging over the internet.  Is there a specific channel for networking and internet oriented development on IRC anywhere?
<SanbarComputing> this messaging is not intended for chat or social networking type application, but to enable the application to do peer-to-peer message passing for the purposes of the application functionality unrelated to internet messaging or whatever - just uses the messaging mechanism to communicate between peers
<SanbarComputing> indeed ...
<slangasek> hggdh, Daviey, hallyn_, adam_g: udev accepted into oneiric with a fix for at least *one* bug.  Please retest at your convenience so we can see what's left that needs stomping...
<Laney> doko_: what happened to the maintainer of gdc-4.6 in debian?
<doko_> Laney, ?
<Laney> http://packages.qa.debian.org/g/gdc-4.6.html
<doko_> oops ...
<Laney> motu just got mailed about the ftbfs
<fishor_> hallo all, please can any one point me to some instruction, how to add patches to debin/patches. and is it possible to use git formated patches? I know i can edit every thing manually, but may be there is some script to do it
<penguin42> fishor_: Most of them use quilt I think, so searching for stuff on quilt and debian often finds it
<frafu> Hi, In order to test whether a python program is running under GDM, I used the following command:
<frafu> if os.environ.has_key('RUNNING_UNDER_GDM'):
<frafu> Can anybody please tell me whether there is a similar command for lightdm?
<frafu> Maybe:
<frafu> if os.environ.has_key('RUNNING_UNDER_LIGHTDM')
<frafu> ?
<fishor_> penguin42, thank you. i found this manual https://wiki.ubuntu.com/PackagingGuide/PatchSystems
<hggdh> slangasek: will do
<hggdh> slangasek: will a new ISO be generated, or is it a 0-day?
<infinity> hggdh: There will be new ISOs spun on Sunday.
<hggdh> infinity: thank you
<rhettnaxel> so...
<bdrung> tumbleweed: around?
<tumbleweed> bdrung: sort of
<tumbleweed> (around, but up to my ears in pypy)
<bdrung> tumbleweed: i pushed distro-info rearrangement
<bdrung> tumbleweed: can you prepare the perl library for distro-info?
<binarymutant> does xutils-dev provide xorg-macros?
<tumbleweed> bdrung: pushed it, but haven't got to tests yet
<bdrung> tumbleweed: now we have to split distro-info into three parts
<tumbleweed> yeah
<bdrung> tumbleweed: what's with the remove me item?
<tumbleweed> oops, that was from debugging, sorry still have my head in pypy
<bdrung> tumbleweed: do you want to update your ubuntu email address?
<tumbleweed> bdrung: eh?
<bdrung> tumbleweed: ubu VS deb mail
<tumbleweed> aah, in copyright.
<bdrung> tumbleweed: git grep it
<bdrung> there are more places
#ubuntu-devel 2011-10-09
<bdrung> tumbleweed: the haskell rewrite needs polish now
<bdrung> tumbleweed: but it is nearly done for ubuntu
<bdrung> tumbleweed: https://bugs.launchpad.net/ubuntu/+source/distro-info/+bug/807644/comments/5
<ubottu> Ubuntu bug 807644 in distro-info (Ubuntu) "ubuntu-distro-info displays codenames" [Wishlist,Triaged]
<bdrung> tumbleweed: current output of the rewritten tool
<tumbleweed> looks good. /me -> bed
<Laney> bdrung: sorry I forgot to reply to your ping
<Laney> but this sounds exciting!
<damg> what was that link in the wiki containing all those standard replies for launchpad? Like "thank you for your bug ..."
<damg> found it
<Q-FUNK> I know we're already frozen, but it seems that some bugs were found in three ispell/myspell/aspell packages over the last few days:   bugs #871231,  #871232, # 871231
<ubottu> Launchpad bug 871231 in ispell-et (Ubuntu) "Sync ispell-et 1:20030606-16 (main) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/871231
<ubottu> Launchpad bug 871232 in rus-ispell (Ubuntu) "Sync rus-ispell 0.99g5-11 (main) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/871232
<Q-FUNK> Ã¶Ã¶..   871233
<Q-FUNK> bug  #871233
<ubottu> Launchpad bug 871233 in myspell-lv (Ubuntu) "Sync myspell-lv 0.9.4-3 (main) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/871233
<Q-FUNK> As to whether those issues are considered serious enough to warrant a freeze exception, I'll leave it up to the release team.
<rickspencer3_> hi pitti
<pitti> hey rickspencer3_
<rickspencer3_> hi pitti
<rickspencer3_> so, I got a new kernel tonight!
<rickspencer3_> I presume that's with the kernel oops off, so ....
<rickspencer3_> this is it :)
<pitti> rickspencer3: no, that was kerneloops
<pitti> rickspencer3: the new kernel just fixed a bad depenency to make the -virtual image installable
<DoctorPepper> hi guys!!!
<dupondje> somebody has any idea how to choose the correct locale in gnome3? always sets nl_NL :(
<DoctorPepper> agateau: are u here ?
#ubuntu-devel 2012-10-01
<Kano> where is the shim package?
<pitti> Good morning
<pitti> infinity, RAOF: Can we release bug 1055944 now?
<ubottu> Launchpad bug 1055944 in postgresql-9.1 (Ubuntu Precise) "New bug fix releases: 9.1.6, 8.4.14, 8.3.21" [Undecided,Fix committed] https://launchpad.net/bugs/1055944
<pitti> RAOF: I'm happy to do the package copies myself, but wanted to coordinate with an SRU team member first
<pitti> RAOF, infinity: I'd appreciate if postgresql-8.4/precise could also be accepted (bug 1058218) as this breaks lucid->precise upgrades
<ubottu> Launchpad bug 1058218 in postgresql-8.4 (Ubuntu Precise) "do-release-upgrade (lucid->precise) leaves postgres 8.4 in bad state" [High,In progress] https://launchpad.net/bugs/1058218
<dholbach> good morning
 * pitti hugs dholbach, guten Morgen
 * dholbach hugs pitti back :)
<infinity> pitti: It's on my hitlist first thing in the morning if no one beats me to it.
<pitti> infinity: cheers
<xnox> Guten Morget!
<xnox> Guten Morgen!
 * xnox fail
<astraljava> fails*
<gema> x)
<xnox> =(
 * xnox needs more coffee =)
<geser> any idea how to resolve the current situation around "ntfsprogs"? it's currently build by ntfs-3g (main) and linux-ntfs (universe). "ntfsprogs" from ntfs-3g is a transitional package but dropped in the latest upload in Debian (not merged yet) and "ntfsprogs" from linux-ntfs has a lower version.
<geser> drop "ntfsprogs" in ntfs-3g and add an epoch to linux-ntfs or wait till the r-series? or something else?
<xnox> geser: and ntfsprogs from linux-ntfs does not have an epoch?
<geser> xnox: no
<xnox> =(
 * xnox is inclined to wait for r-series
<geser> I found this when I uploaded a FTBFS fix for linux-ntfs which is now "Failed to upload" due to this
<cjwatson> geser: I'll fix it up shortly.
<cjwatson> xnox: I'm not.  This is a +1 maintenance issue.
<xnox> ok.
<cjwatson> We should possibly just remove linux-ntfs.
<cjwatson> Though I'll need to check whether ntfs-3g really supersedes all of it.
<geser> partclone and testdisk depend/build-depend on libntfs10/libntfs-dev from linux-ntfs
<cjwatson> ntfs-3g provides the tools, but not the library.
<cjwatson> So maybe we should drop the ntfsprogs/ntfsprogs-udeb binaries.
<geser> ntfs-3g has also a library. perhaps check if testdisk/partclone can be build against them? (or build them without libntfs)
<cjwatson> I'll check, but I'm doubtful.  I suspect the APIs are quite different.
<Laney> "The disk drive for / is not ready yet or not present" but it is mounted when I drop to a shell?
 * xnox has the same with /tmp for some reason.... and I am confused how can /tmp be missing....
<xnox> on my machine /tmp is not a separate mount point =/
<Laney> heh
<Laney> I don't know how to get it to boot given this
<cjwatson> testdisk appears to have ntfs-3g support
<geser> partclone too, I'll test-build both with ntfs-3g
<cjwatson> I'm test-building testdisk at the moment
<cjwatson> Go ahead with partclone :-)
<cjwatson> Laney: You might want to alert slangasek given his recent mountall work.
<Laney> cjwatson: ah, good clue
<Laney> I'll try downgrading that
<cjwatson> geser: testdisk uploaded
<geser> partclone builds too, will upload it soon
<geser> partclone uploaded, feel free to kill linux-ntfs :)
<pitti> cking: are you okay with my followup in https://code.launchpad.net/~colin-king/apport/acpi-tables-remove/+merge/127206 ?
<pitti> cking: or do you want to remove the code for other reasons, e. g. it's not working well, etc.?
<Laney> indeed, mountall 3.40 boots fine
<Laney> xnox: ^ try that?
<xnox> Laney: ok. I will. (well I'll downgrade now, and reboot when X will lock up next time ;-) )
<mzanetti> hey. anyone here using a Nokia N9 with the HOTP auth?
<xnox> mzanetti: mzanetti if this is related to launchpad/ubuntu-one SSO authentication try #launchpad. As your question doesn't seem to lead to developing ubuntu....
<mzanetti> xnox: ok. thanks
<Laney> doko_: do you want to look over qt4-x11 in canonical-arm-dev and copy to Q if it looks OK to you?
<Laney> built on all except PPC, but I believe that will get the correct build record when copied
<Laney> also I'll upload make-dfsg and webkit to the queue shortly (after restoring the symbols to -c4) for you to review
<cjwatson> You know we're getting a workaround for the timeout issue ASAP, right?  (Not that I can see these uploads.)
<Laney> oh, well that might help for qt
<Laney> but not for webkit
<Laney> try giving it back when the deployment happens
<cjwatson> Yeah, will do
 * cjwatson glares at the botched merge of libav-extra
<tkamppeter> Anyone knows how to debug avahi-daemon?
<pitti> tkamppeter: like any other plumbing daemon you should be able to run it in a terminal with avhi-daemon --debug; it also has a -k for killing an existing one
<ogra_> hrm
 * ogra_ struggles with a linker problem ... 
<ogra_> so i havea non multiarch package (nvidia-tegra) ... that drops a confi into /etc/ld.so.conf.d/ ... runnin ldconfig -v i can see the path and the libs listed ... but running an app that makes use of a lib from there i see the app not parsing the path from the linker config when looking for the lib
<ogra_> infinity, doko_ ^^^ any hint ?
<ogra_> the postinst has: update-laternatives --force --install /etc/ld.so.conf.d/arm-linux-gnueabihf_EGL.conf arm-linux-gnueabihf_egl_conf /usr/lib/nvidia-tegra/ld.so.conf 9000
<ogra_>  /usr/lib/nvidia-tegra/ld.so.conf points to  /usr/lib/nvidia-tegra
<ogra_> so i'm a bit lost why the app doesnt find the lib
<cjwatson> doko_: Please pay attention to reverse-dependencies when removing packages from quantal.
<ogra_> (it worked with exactly the same setup in precise btw)
<cjwatson> doko_: ldc <- libtango - what do you suggest?
<doko_> cjwatson, removed ldc from the blacklist. will remove libtango from q as well. mentioning it in bug #935267
<ubottu> Launchpad bug 935267 in libtango (Ubuntu Precise) "libtango version 0.99.9.dfsg-1 FTBFS on i386 in precise" [High,Confirmed] https://launchpad.net/bugs/935267
<doko_> ohh, it's October, +1-maint over ;-)
<cjwatson> Hence most of my uploads today :-)
<doko_> you forgot mksh, fixing a ftbfs ;)
<doko_> ogra_, does the app rely on the dynamic loader, or does it just use dlopen?
<ogra_> doko_, i see it opening ld.so-cache at the top and then there are just open() calls apparently
<ogra_> pointing to the usual places (/lib/$triplet and /usr/lib/$triplet)
<cjwatson> doko_: Thanks for leaving things in a state where I could basically go straight to fixing build failures, though ;-)
<wookey> doko_: have you done any work on updating the gcc packaging for aarch64/arm64?
<wookey> (and eglibc and binutils)
<doko_> wookey, no, a bit early, as long as the eglibc bits are missing
<wookey> If not I'll have a go this week
<doko_> binutils should be ready, maybe omitting arm64 in the -multilib build
<wookey> ready in the quantal package, or debian unstable or some repo somewhere?
<doko> quantal
<wookey> OK ideal.
<doko> wookey, are the eglibc bits released?
<wookey> I understand so yes
<wookey> I need to check exact status of what's released where to whom and in what versions
<wookey> ah no, apparently it's not out in the real world yet - in a few days
<doko> wookey, heh, first patches on glibc-alpha this morning
<doko> wookey, are you at this arm64 sprint?
<wookey> yes I am
<wookey> and If I could get a packaged toolchain working it would make my life a lot easier, so thought I'd see where we were at
<wookey> and I'll have people to hassle when it breaks :-)
<doko> so, the glibc changes look safe to apply, even in quantal, and gcc-4.7 has the patch already included, but not applied.
<wookey> OK, sounds promising.
<doko> for gcc, it's probably only updating the packaging, disabling Go, etc
<wookey> the glibc changes are for trunk presumably, not 2.16 - but you reckon they are reasonably compatible?
<doko> the first patch just adds aarch64 files, the second patch defines some aarch64 constants. if this is all, it doesn't touch other archs
<wookey> (for relases types:) I also have 25 patches for core packages that need simple config.guess,sub updates. Is it too late to stick thos in quantal?
<cjwatson> Do you have a list?  It would be interesting if it overlapped with the set that could use rebuilding for armel/armv5
<doko> not from my point of view, need to address the armel build too. could you paste this list?
<cjwatson> heh, snap
<wookey> sure hold on a mo
<ogra_> wow, not even preloading the lib directly with LD_PRELOAD works
<wookey> http://paste.ubuntu.com/1253817/
<ogra_> aha, but setting LD:LIBRARY_PATH works
<wookey> cjwatson: ^
<ogra_> *LD_LIBRARY_PATH
 * ogra_ doesnt get that
<wookey> hmm db5.1 wqould be more use wouldn't it :-)
<doko> hrw, could you have a look at the gcc-4.5 cross packages ftbfs in the q test rebuild, fix or remove?
<cjwatson> We can certainly have a look; feel free to put the patch set somewhere downloadable
<wookey> He's (hrw) probably on a train right now. Due here about 3:30pm (i.e 1.6hrs)
<doko> wookey, for make please get in touch with Laney. he has another patch pending
<wookey> who is laney?
<Laney> erm
<doko> another *ey
<ogra_> grmbl, the setup is even identical on the panda for pvr-omap4 ...
<doko> wookey, you want to update libffi too
<wookey> yes, got that.
<wookey> again not sure if there are backporting issues
<ogra_> ldconfig -p shows the lib is in the chache :/
<doko> cjwatson, I hope you didn't find any in main =)
<cjwatson> doko: Any what?
<doko> ogra_, is this arm?
<doko> cjwatson, build failures
<cjwatson> Oh, right.  Well, there were several left from the test rebuild
<ogra_> doko, tegra, yes
<cjwatson> But I've been mostly attacking them random-access based on whatever looks easiest :-)
<doko> too many :-/
<wookey> cjwatson: patches at http://wookware.org/software/patches/quantal/
<cjwatson> wookey: OK, I'll look at those as time permits
<ogra_> :q
<cjwatson> wookey: The first one I happened to look at appears to be unnecessary, because the build process automatically links in current config.guess/sub
<cjwatson> wookey: So I suspect your search is too broad
<cjwatson> wookey: Ah, hmm, actually debian/rules was linking new versions to the wrong place.  I'll fix that instead.  (findutils)
<doko> cjwatson, wookey: the overlap with the armel rebuild is findutils libnih module-init-tools nano patch
<cjwatson> Yeah, I was looking at those first
<pitti> cjwatson: ok if I move psql to -updates? (bug 1055944)
<ubottu> Launchpad bug 1055944 in postgresql-9.1 (Ubuntu Precise) "New bug fix releases: 9.1.6, 8.4.14, 8.3.21" [Undecided,Fix committed] https://launchpad.net/bugs/1055944
<pitti> more and more people are pinging me about this
<cjwatson> pitti: Yes, I think we were agreed on that the other da
<cjwatson> y
<pitti> it's been 7 days now anyway
<pitti> ok, copying then
<cjwatson> doko: Your armel rebuild list is rather out of date though - I'm using a fresh ist
<cjwatson> *list
<cjwatson> Just in case you were going to do any uploads based on yours
<doko> cjwatson, known. could you paste your new one?
<cjwatson> doko: http://people.canonical.com/~cjwatson/armel-rebuild updated hourly.  By binary package, sorry, was a lot easier to avoid false positives that way
<cjwatson> doko: That's for main
<cjwatson> Hmm, maybe I should filter by libc6 dependencies
<cjwatson> That's a bit better
<cjwatson> doko: That's basically just "not rebuilt since precise", BTW - lillypilly:~cjwatson/bin/armel-rebuild
<hrw> re
<hrw> doko: ok, let me look
<hrw> doko: url to ftfbs?
<ogra_> doko, do you know if anything changed wrt link handling for libs in the linker ?
<ogra_> seems ldconfig gets me something like: libGLESv2.so -> libGLESv2.so.2
<ogra_> while it shoudl eb the other way round
<ogra_> (teh link in the dir is actually the other way round)
<ogra_> i.e. libGLESv2.so.2 -> libGLESv2.so
<ogra_> (though i dont get why LD_LIBRARY_PATH works )
<ogra_> and no matter how i manually fiddle with links of that lib, it always ends up as libGLESv2.so in ldconfig
<debfx> kenvandine: why have you uploaded qt4-x11 to -proposed?
<kenvandine> to fix that medium font issue
<kenvandine> let a few folks test it out
<kenvandine> debfx, that bug was on the release teams list and wanted some more testing
<debfx> right, but proposed isn't really for testing
<ogra_> it is simple easier to reject it from -proposed in case issues are found
<kenvandine> right
<kenvandine> and we were in a freeze as well
<kenvandine> it already had some PPA testing
<ogra_> and it will cause archive skew if you uploads directly to main
<xnox> ogra_: true but the version number is taken, such that you can't really reupload again with the same version number if it got accepted.
<ogra_> xnox, if it got accepted all should be fine
<tkamppeter> pitti, thanks. I tried this and the debug info is not much. It gives some (normal) output at startup and does not log anything more while running. When I start CUPS and it takes up all CPU it does not do any further logging.
<cjwatson> kenvandine: please note that the release team will move things from -proposed to release when they're fully built, and won't wait for testing
<xnox> ogra_: upload to -proposed -> accept -> purged -> new upload needs to be version++ which is ok, but confusing sometimes =)
<pitti> tkamppeter: I guess you could run it under strace and see what happens?
<cjwatson> (well, as long as they're installable)
<ogra_> xnox, oh, i thought accepted into release :)
<xnox> ogra_: ah =)
<kenvandine> cjwatson, yeah, i know
 * ogra_ starts to really get annoyed by that ldconfig issue 
<kenvandine> it wouldn't have been at that point in the freeze last week, so if it wasn't NACK'd by the time b2 released, it should be good to promote
<ogra_> package update work of 10 minutes now causes hours of debugging and i dont get anywhere :(
<kenvandine> it had successful testing in the PPA and upstream approved the patch
<kenvandine> but they only plan to merge it in qt5
<tkamppeter> pitti, I am trying but under strace avahi's timimg seems to change and avahi gets immune. It never reaches 100% and normalizes within some seconds.
<cjwatson> doko: http://people.canonical.com/~cjwatson/armel-rebuild is by source package now, if I didn't screw it up
 * pitti chuckles on LP saying "Estimated finish 46 seconds ago"
<ev> pitti: heads up in case you run into this one on the Launchpad retracers as well: https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1059621
<ubottu> Launchpad bug 1059621 in apport (Ubuntu) "Sandbox option breaks on extraction of precise gnat-gps and gnat-gps-common" [Undecided,New]
<ev> confusing, since gnat-gps-common is a dependency of gnat-gps, so it presumably should be okay that it gets extracted first
<pitti> ev: ah, thanks; I don't currently use those in the distro retracers, though
<ev> ah, noted
<smoser> this appears to be a fairly serious issue:
<smoser> https://bugs.launchpad.net/ubuntu/+bug/1058517
<ubottu> Launchpad bug 1058517 in Ubuntu "Upon Restart after Upgrading Apt Packages SSH Keyfiles Rejected" [Undecided,Confirmed]
<smoser> basically unclean unmount of / on reboot after upgrade
<smoser> (the bug summary is the original bug reporters)
<smoser> anyone have thoughts there?
<ev> pitti: actually, the bug is incorrectly titled. It should happen even without the --sandbox option, as it seems to be the result of using dpkg -x
<mpt> ev, any chance of a rollout this week?
<ogra_> doko, so i see a massive discrepancy here, if i copy the libs to /usr/lib or /lib or set LD_LIBRARY_PATH all is fine, even with the broken soname in the lib ... if i use a dir like /usr/lib/nvidia-tegra nothing works ...
<ogra_> (ldconfig forces the broken soname which doesnt contain a version)
<ev> mpt: yes - I'll sort one tomorrow
<mpt> splendid
<smoser> jodh, SpamapS either of you have thoughts on what could have gone wrong in bug https://bugs.launchpad.net/ubuntu/+bug/1058517
<ubottu> Launchpad bug 1058517 in Ubuntu "Upon Restart after Upgrading Apt Packages SSH Keyfiles Rejected" [High,Confirmed]
<smoser> something is causing unclean mount of /
<bryceh> could an archive or SRU admin accept nvidia-common and jockey from the upload queue?  These are needed for the Valve Steam release that happens in a few days.
<SpamapS> cjwatson: have you already seen bug reports about upgrading grub-pc in an lxc container?
<SpamapS> /usr/sbin/grub-probe: error: cannot find a device for / (is /dev mounted?).
<SpamapS> seems like we should probably decline to configure grub in lxc
<cjwatson> No
<cjwatson> Feel free to fix, I probably don't have bandwidth
<cjwatson> (Well, suggest a patch to me anyway)
<SpamapS> I'm trying to imagine a situation where grub needs to be configured inside a container
<cjwatson> Building an image for booting elsewhere, perhaps
<stgraber> I have grub installed in all my upgrade containers as those are running a full desktop system
<stgraber> obviously grub can't actually do anything as it doesn't have write access to the block device (and shouldn't have) but it's still installed
<utlemming> any unity dev's here? apt-get dist-upgrade on 12.10 B2 completely foobar'd me.
<utlemming> no dash, launcher, or title-bar at the top of the screen. Just a lovely little compiz session.
<xnox> utlemming: bug 1053288 or something like that?
<ubottu> Launchpad bug 1053288 in unity (Ubuntu Quantal) "Broken UI and no window management" [Critical,Confirmed] https://launchpad.net/bugs/1053288
<utlemming> xnox: nope. I don't have a launcher either. alt-tab doesn't work, but that is likely because unity doesn't appear to even be running.
<utlemming> xnox: the only unity component running is the unity-webapps-service
<utlemming> I filed Bug #1059725
 * xnox is not unity dev so it was just a guess.
<ubottu> Launchpad bug 1059725 in xorg (Ubuntu) "dist-upgrade on 12.10-beta2 results in no dash, no titlebar" [Undecided,New] https://launchpad.net/bugs/1059725
<cjwatson> utlemming: do you have quantal-proposed enabled, perchance?
<utlemming> cjwatson: yup
<cjwatson> utlemming: Yeah, you do.  Don't do that.
<cjwatson> utlemming: Its purpose is to guard you against this kind of skew.
<utlemming> cjwatson: I think that happened when I upgraded from precise :(
<utlemming> cjwatson: is there any easy way to downgrade?
<cjwatson> apt-get install compiz/quantal probably
<cjwatson> Have to rescue crying baby.  Maybe somebody else can help if you can't figure it out
<utlemming> interesting...it looks like the core problem is that unity isn't even installed
<zyga> barry: ping
<zyga> barry: where is pysetup in python3.3?
<utlemming> xnox, cjwatson: looks like the problem was a downstream depedency on compiz uninstalled unity
<utlemming> its fixed now
<xnox> utlemming: don't use quantal-proposed. or $dev-proposed ever. we use it to prevent these sort of problems.
<utlemming> xnox: I don't think that was intentional. I upgraded from precise, where I had proposed enabled. I might have re-enabled it, by accident, but I don't think that was intentional at all.
<xnox> utlemming: did you upgrade by-hand or with upgrade-manager?
<utlemming> upgrade-manager
<xnox> Hmm....
<xnox> ok, thanks.
<geser> could someone reject my first switchsh upload from the unapproved queue? I forgot to mention the LP bug number in the first upload :(
<cjwatson> utlemming: Yeah, that's what I said in my comment on the bug
<cjwatson> geser: linux-ntfs removed now
<stgraber> geser: I may have accepted the wrong one, sorry. I only found the duplicate after accepting the older one. If that's indeed the case, please manually close the bug.
<geser> stgraber: I've closed the bug manually already.
<slangasek> Laney: bug #1059471> does this machine have an initramfs, and can you modify /etc/init/mountall to call mountall with --verbose and capture the output somewhere useful (probably /run)?
<ubottu> Launchpad bug 1059471 in mountall (Ubuntu) "3.41 fails to mount root partition" [Undecided,New] https://launchpad.net/bugs/1059471
<Laney> slangasek: yes, and sure I'll do that later on tonight
<infinity> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Beta 2 released! | Archive: Frozen | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: infinity
<lamont> anyone want to claim significant dnsmasq knowledge?
<lamont> specifically, can I tell it that it's &*^)*(&^)*(& authoritative for its zone?
<infinity> lamont: You probably want stgraber.
<lamont> who is probably EOD
<lamont> how about a nova expert?
<stgraber> nope, I'm around (US/Canada eastern) though I actually have fairly limited dnsmasq knowledge (limited to using it as a local dns cache, not as authoritative DNS server)
<lamont> smoser: about?
<lamont> stgraber: ah, cool
<lamont> stgraber: so the issue I'm trying to sort out... nova inserts things in to $SOMECACHE, which dnsmasq then happily serves up.  Sadly, NXDOMAIN answers then get forwareded off to the resovlers for the subnet, which turn around and ask NOVA aka dnsmasq for the answer... after 5 seconds we time out
<lamont> smoser: ^^ in case you're wondering, that's the DNS timeout you've been complaining about
<stgraber> I vaguely remember helping highvoltage workaround a similar potential loop in his setup.
<smoser> yeah. and i've been complaining loudly
<smoser> :)
<lamont> stgraber: what I really want is nova to be authoritative for the *(^)^&)( zpones
<stgraber> highvoltage: any chance you can pastebin your dnsmasq config?
<smoser> lamont, you think that is more than a local configuration issue ?
<smoser> ie, is it somethign that any ubuntu user is going to see?
<lamont> smoser: I'd be absolutely pleased as punch to find that it's a config error, and that it's trivial to teach either nova or dnsmasq to be authoritative
<stgraber> lamont: I remember my "fix" being fairly hackish but can't remember from the top of my head, hopefully highvoltage is around and can paste the config we ended up with
<lamont> smoser: anyone who configures bind on a resolver to forward a zone to dnsmasq so that he can map and reverse openstack hostnames, yes.
<lamont> stgraber: tell me where the config lives, and I can get it to you, yes
<lamont> ls -l /etc/dnsm*
<lamont> ls: cannot access /etc/dnsm*: No such file or directory
<lamont> but I'm guessing it's the nova-dnsmasq, not the real one
<highvoltage> stgraber: yep... coming up...
<highvoltage> stgraber, dnsmasq.conf: http://paste.ubuntu.com/1254671/
<highvoltage> (and then /etc/hosts.app799.com is just a usual hosts file)
<stgraber> highvoltage: right, thanks found what I wanted
<stgraber> lamont: I have no idea how openstack/nova works, but if you can get your hands on the config, you'll need something like:
<stgraber> server=/1.17.172.in-addr.arpa/
<stgraber> which in this case says that there's no "upstream" server for 1.17.172.in-addr.arpa
<stgraber> that essentially makes dnsmasq authoritative for the zone
<lamont> stgraber: am I reading this correctly, that dnsmasq (2.59-4), when run with --conf-file= will just run with the default arguments?
<stgraber> lamont: that sounds right, yeah. In that mode it basically just uses whatever is on its command line + whatever hardcoded config it has
<hallyn> tjaalton: any progress with new xserver for qxl bug?
<hallyn> else, should i pursue pushing my patch for now?
<hallyn> (my patch == just a subset of upstream git commits)
<hallyn> (iow, not *my* p[atchs)
<pitti> barry: ah, got it figured out -- how's http://pypi.python.org/pypi/python-dbusmock looking now? :-)
<barry> pitti: it's a thing of beauty! :)
<pitti> barry: and a pita to set up :)
<barry> :)
<pitti> barry: I guess one of these days I need to create a proper account and write a do-release script with the umpteen steps to upload metadata, tarballs, description to pypi and the tarball to LP
<barry> pitti: yeah.  i usually `python setup.py sdist upload -s` then do the release on lp with the resulting tgz and asc files.  but it *is* a pita
<pitti> barry: did you get the pypissh thingy to work?
<pitti> barry: I guess you have an user/pwd, not using OpenID?
<barry> pitti: nope
<barry> pitti: i have both actually.  i usually log in with openid, but it is associated with my pypi user name
<pitti> right now I need to sdist, then open the web page for creating a new release, upload PKG-INFO, then click through the files, upload tar and asc, and then reupload the description to be the README.rst
<barry> ouch
<pitti> anyway, c'est l'heure de dormier (just had TB meeting), bonne nuit!
<kees> cjwatson: can you approve my email to devel-announce, please?
<cjwatson> kees: done
<tedg> kees, Not sure what date format you're using here ;-)  "Next meeting is 2012-19-15"
<stgraber> tedg: 15th of July ;)
<stgraber> tedg: more seriously, it's going to be 2012-10-15
<tedg> Heh, yeah, I figured.  It was just funny.
<kees> tedg: hah, whoops
<kees> tedg: I found the one person reading the minutes! :)
<tedg> kees, I verify everything you send me isn't an attempt at a buffer overflow ;-)
<kees> lol
<kees> did your calendar crash? :)
 * cjwatson sends tedg a Langford basilisk
<kees> tedg: we should totally meet on Smoterday Octember 32nd
<bryceh> not in a leap year!
<tedg> Heh
<tjaalton> hallyn: I have -qxl ready in git, but it needs libspice-protocol-dev from experimental, so haven't actually build-tested it yet..
<hallyn> tjaalton: that is built in ppa:serge-hallyn/virt, if that helps you easily build it
<tjaalton> hallyn: well, you could upload -qxl there :)
<tjaalton> hang on
<tjaalton> or I could steal your stuff
<hallyn> tjaalton: sure (it'll then supersede the patched source i was playing with, but that's ok)
<popey> nope
<toabctl> how is it possible that a lp branch of a ubuntu package is out of date? eg https://code.launchpad.net/ubuntu/+source/icu
<tjaalton> hallyn: sigh, dpkg-source giving pain because of diff-ignore.. pushed the update to git://git.debian.org/git/pkg-xorg/driver/xserver-xorg-video-qxl if you manage to build the source package..
<tjaalton> too tired to fix that
<hallyn> tjaalton: hm, i don't understand.  that is quite a bit older than the version i was doing (0.0.18~gitde66207-0ubuntu2~ppa2).  is there a branch i'm supposed to check out in there?
<infinity> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Beta 2 released! | Archive: Frozen | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
#ubuntu-devel 2012-10-02
<FourDollars> Hi, I have a bug. It just needs to rebuild the package to solve.
<FourDollars> How can I do that for Ubuntu quantal?
<FourDollars> https://bugs.launchpad.net/ubuntu/+source/ibus-chewing/+bug/1028746
<ubottu> Launchpad bug 1028746 in ibus-chewing (Ubuntu Quantal) "quantal alpha3: ibus-engine-chewing crashed with SIGABRT in __assert_fail_base()" [Medium,Confirmed]
<tjaalton> hallyn: yes, the ubuntu branch
<pitti> Good morning
<dholbach> good morning
<dholbach> tjaalton, happy birthday! :)
<tjaalton> dholbach: thx :)
<didrocks> happy birthday tjaalton ;)
<tjaalton> didrocks: :)
<Daviey> jtaylor: hey, did you investigate what pwlib used to be used for?
<xnox> FourDollars: if you want a no-change rebuild, please subscribe ubuntu-sponsors to the bug.
<FourDollars> xnox: Thank you. :)
<xnox> FourDollars: is it just your package that needs rebuilding or a wider set of packages? everything that depends on particular versions of ibus?
<FourDollars> xnox: Not sure.
<FourDollars> xnox: I am only sure for ibus-chewing.
<xnox> FourDollars: ideally we want package uninstallable if there was an api/abi bump. Or a proper transition in place for all rdeps of ibus....
<xnox> FourDollars: that's ok.
<FourDollars> xnox: IIRC, there is no such mechanism in Ubuntu archives. Right?
<xnox> FourDollars: sure there is.
<xnox> FourDollars: tick good on this page http://people.canonical.com/~ubuntu-archive/transitions/boost1.49.html
<xnox> FourDollars: or see this in progress transition http://people.canonical.com/~ubuntu-archive/transitions/gnutls28.html
<FourDollars> xnox: Thanks for your information.
<xnox> we also have uninstallation reports and other bits and bobs ;-)
<cjwatson> Or just do it if it's a small number
<FourDollars> xnox: I don't see any ibus relative under http://people.canonical.com/~ubuntu-archive/transitions/ .
<xnox> FourDollars: either it's small, not done/setup, or ibus had incompatible changes without bumping shlib depends/soname.
<FourDollars> OK.
<gsedej_work> hi! I am trying ubuntu 12.10. Where is "logout", i wish to choose some other DE
<mitya57> gsedej_work: support is in #ubuntu
<gsedej_work> ubuntu 12.10 beta?
<ogra_> for 12.10 i think its rather #ubuntu+1
<gsedej_work> oh, sorry, i didn't see it in channel list
<mitya57> well, the logout button didn't change in 12.10 :)
<gsedej_work> sorry for bothering
<mpt> ev, the #100 crash in 12.10 is in worldofgoo
<ev> nice
<mpt> The first sign of importance for giving access to independent upstreams
<ev> yeah, we can't possibly retrace those at the moment
<ev> but great that we're actually getting them
<cjwatson> The number of people still installing beta-1 is a little scary
<infinity> The number of people who install milestones more than a few days after we release them scares me. :/
<infinity> But, I guess if you have the ISO lying around.
<mpt> and https://wiki.ubuntu.com/QuantalQuetzal/TechnicalOverview/Beta1 gives no clue that beta 2 is out, that I can see
<infinity> mpt: Why would it?
<cjwatson> That's more understandable; it's only relatively recently that daily builds have been worth bothering with
<infinity> mpt: Do the oneiric release notes point to precise?
<cjwatson> mpt: Ah, now that at least is readily fixable, although the question presupposes a charming belief that users read the tech overview ...
<mpt> infinity, why wouldn't it?
<cjwatson> I think it's reasonable for milestone notes to point forward
<mpt> infinity, for people who have heard that beta 1 has been released, and haven't heard that beta 2 has also
<infinity> mpt: I'm not saying that obsolescence notes on release notes might not be a cool idea, just that we've never done it before that I know of, hence my wondering at your wondering. :)
 * cjwatson adds a bold-face note to the top
<infinity> cjwatson: And the alphas!
<mpt> cjwatson, good -- is there also a checklist for "things to do when a beta/final is released" to which that step can be added?
<cjwatson> Probably ought to but have other things to do
<cjwatson> mpt: BetaProcess.  But I'm not bothering since I hear milestones may not be happening next cycle
 * infinity isn't quite sure why we have one set of notes per milestone at all, rather than just a cumulative document for Q that ends up being the final notes.
<mpt> Two eminently plausible ways to solve the problem
<cjwatson> Wouldn't hurt to archive some more of the beta-1 images, either
<cjwatson> I'll do that later today
<doko> cyphermox, yubiserver ftbfs
<doko> cjwatson, a lot of the amd64 only build failures (found now 7) seem to be caused by changed dpkg-dev behaviour. all have in common that either the install target is called in the build step, or that there are missing dependencies for the build-arch target. these build failures are not seen in unstable
<cjwatson> well, unstable or not, they are surely bugs
<cjwatson> I don't see any obviously-relevant changes in dpkg on either side, although I've only checked changelogs
<cjwatson> But at this point I'd rather fix those packages than change dpkg anyway
<doko> looking through the amd64 only ftbfs now
<xnox> I had something like that with addons, e.g. dh_sphinxdoc -a fails
<cjwatson> That doesn't sound related.
<xnox> so I had to make dh_sphinxdoc call only in binary-indep
<cjwatson> Unless DH_OPTIONS is wrong as a result of the above.
<xnox> oh and that one was reproducible in sid, so different problem.
<buxy> kees: Next meeting is 2012-19-15 %-)
<smoser> cyphermox, do you think i'm way off assuming bug 1058517 and bug 1058987
<ubottu> Launchpad bug 1058517 in dbus (Ubuntu) "upgrade of dbus causes unclean unmount of /" [High,Confirmed] https://launchpad.net/bugs/1058517
<ubottu> Launchpad bug 1058987 in network-manager (Ubuntu) "In Quantal, the root filesystem is not cleanly unmounted at shutdown or reboot" [High,In progress] https://launchpad.net/bugs/1058987
<smoser> are related
<cyphermox> smoser: not necessarily
<cyphermox> it looked weird too, since I could have sworn that piece of code (in NM to stop dnsmasq) used to work, and certainly didn't change significantly enough to cause this
<smoser> and in the cloud imageswhere i see this, i have no network manager
<smoser> but do have dbus
<smoser> (and this was in precise)
<cyphermox> ok
<cyphermox> I'm still going to look at dnsmasq/NM closely to be sure
<cyphermox> (since the reporter days they can avoid this by removing dnsmasq-base)
<smoser> cyphermox, right. that didn't make much sense to me either.
<smoser> i'm not even sure how i became aware of your bug.
<cyphermox> hehe
<cyphermox> fwiw, I don't understand because dnsmasq is reportedly no longer running, otherwise things would hang earlier and get caught by report_unkillable in sendsigs
<cyphermox> or at the very least I should always be able to see it on all my systems
<smoser> cyphermox, well, any thoughts you have, i'd be interested in.
<smoser> because this is pretty serious a regression in precise
<cyphermox> smoser: "Also, doing a fully up-to-date netinstall works fine until I install network-manager-gnome (which pulls in dnsmasq-base). That's when this bug starts to show up."
<Laney> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Beta 2 released! | Archive: Frozen | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: Laney
<cyphermox> also, this is a bug in quantal, not precise
<cyphermox> maybe it's really two different things
<smoser> cyphermox, right.
<mpt> Hm, the #1 crash for Ubuntu users overall right now <http://launchpad.net/bugs/821233> is from software that is unmaintained <https://answers.launchpad.net/weather-indicator/+question/209454>
<ubottu> Launchpad bug 821233 in indicator-weather (Ubuntu) "indicator-weather crashed with AttributeError in export_location_details(): Location instance has no attribute 'location_code'" [Medium,Confirmed]
<doko> pitti, https://launchpadlibrarian.net/118057586/buildlog_ubuntu-quantal-amd64.vala-0.10_0.10.4-1ubuntu1_FAILEDTOBUILD.txt.gz
<doko> this is the same error as for ubuntu-drivers-common ...
<pitti> not for the same service, though; but yes, timed out while waiting for a service to get activated
<doko> but I can't see how this connects to a swap space issue
<pitti> swapping makes everything grind to a halt, so everythingthat does I/O (that includes d-bus service activation) just takes ages
<pitti> or at least slow enough to trigger some race conditiosn
<pitti> but this is amd64, not arm
<doko> pitti: do you know it is swapping? I doubt it
<pitti> so apparently this is a different problem
<doko> the arm build is only 12min, so it doesn't like to be a timeout
<cjwatson> Damn, rebootstrapping eclipse-mylyn didn't fix eclipse-egit
<cjwatson> Wonder what's going on there
<pitti> doko: well, it's "slowness"; I just parrot infinity when he said that since the upgrade our arm builders have to do a lot more swapping
<doko> pitti: but here I can't see any reason for that
<pitti> doko: right; pitti | so apparently this is a different problem
<doko> cjwatson, I think I did address all binary-arch issues, maybe uw-imap is another one
<Laney> infinity: would you like to take care of https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/1000498 ?
<ubottu> Launchpad bug 1000498 in eglibc (Ubuntu Quantal) "fmod() incorrectly returns NaN for (some?) denormalized inputs" [Medium,In progress]
<infinity> Laney: Yeah, it's on my TODO today, since I need to re-do my SRU upload ANYWAY.
<infinity> (Thanks, security team)
<infinity> (I'm not bitter)
<Laney> Pfft, security, what do we need THAT for?
<cjwatson> jamespage: I could use help with the eclipse-egit build failure; it's not making a lot of sense to me, as those plug-ins do seem to exist.  But I'm not sure where Eclipse might be looking.
<jamespage> cjwatson, looking now
<jamespage> cjwatson, ergh - that looks like osgi terror - lemme see if I can dig out the DM
<nikitis> Where can one apply for steam linux beta?
<cjwatson> jamespage: Hmm, some dependencies were dropped between Debian and Ubuntu
<barry> jodh: ping
<cjwatson> jamespage: Aha, installing those missing dependencies did it.  So eclipse-mylyn has misbuilt
 * cjwatson hopes this wasn't the result of his bootstrapping attempt
<jamespage> cjwatson, not sure I understand - I would suspect some sort of odd bootstrap sequence to get this stuff working in Debian from scratch so that might make sense
<infinity> cjwatson: What did you do to break it? :)
<cjwatson> Installed eclipse-egit from Debian
<cjwatson> The -mylyn build log has stuff like:
<cjwatson> jh_installeclipse: Cannot determine the package providing /usr/share/java/httpclient.jar.
<cjwatson> Which looks possibly relevant
<infinity> Missing build-deps?
<cjwatson> libhttpclient-java is there
<cjwatson> JDK 6 vs. 7?
<infinity> That seems likely.
<cjwatson> But it just uses dpkg -S for that check
<jodh> barry: howdi
<barry> jodh: hi!  sorry about crossing signals on that bug.  i tried to find you on irc but i think it was past your eod
<infinity> cjwatson: Which would imply the files don't exist...
<cjwatson> And yet.
<jodh> barry: np!
<barry> jodh: did you see the patch and test i uploaded?  i wonder if it makes sense to pull those into your mp for lp:python-apt?
 * infinity scratches his head...
<cjwatson> Trying to construct a matching build locally now.
<jodh> barry: I think mvo has already taken both your + my code and put it into the ubuntu branch.
<Laney> please can someone reject https://code.launchpad.net/~schumski-deactivatedaccount-deactivatedaccount/ubuntu/quantal/kmess/1045090/+merge/122427 per the comment there
<barry> jodh: great!  i still have a few comments about the mp, so i'll just follow up there and let mvo dtrt.
<stgraber> Laney: marked as work-in-progress
<Laney> stgraber: if that gets it off the list, cool
<Laney> (I could have done that too)
 * dholbach hugs Laney
<stgraber> Laney: no you can't do that yourself, you need to be in ~ubuntu-branches (so basically be a TB member)
<Laney> I get the option
<Laney> Work in progress, Needs review, Merged
 * xnox too
<stgraber> oh, is that new?
<xnox> that is not "Rejected" though.
<stgraber> anyway, yes, work in progress will get it off the report
<xnox> and sounds nicer =)
<mvo> barry: I merged a bunch of stuff this morning, I did not see a MP from you though? did I miss that? (just from from jodh)
<infinity> cjwatson: I bet it's just sketchy parsing of "dpkg -l" in perl that the new dpkg may have broken.
<cjwatson> It's possible.  I should be able to tell once I get far enough through the build (unfortunately it's a bit slow).
<barry> mvo: no, i didn't get around to doing the mp.  was going to do that today, but i think i won't need to.  you grabbed the package patch i applied for LP: #1030278 right?
<ubottu> Launchpad bug 1030278 in the python apt bindings "Quantal failed to install: ubiquity crashed in apt/progress/text.py in pulse: OverflowError: Python int too large to convert to C long" [Undecided,New] https://launchpad.net/bugs/1030278
<Laney> jodh: would you care to continue reviewing https://bugs.launchpad.net/ubuntu/+source/zabbix/+bug/1047837 ?
<ubottu> Launchpad bug 1047837 in zabbix (Ubuntu) "Upstart support for Zabbix services" [Wishlist,Triaged]
<barry> jodh, mvo i added a few comments to https://code.launchpad.net/~jamesodhunt/python-apt/test-for-size_to_str/+merge/127435
<infinity> cjwatson: Or not.  A simple copy-and-paste reduced test case from javahelper spits out package and version just fine.
<cjwatson> It's not locale-dependent or something, is it?
<cjwatson> (I do wish eclipse* didn't have 100MB-plus build-deps from universe.)
<infinity> LANG=C seems to behave fine too.
<cjwatson> C.UTF-8?
<infinity> cjwatson: Installing just libhttpclient-java is small.
<cjwatson> Yeah, but since that apparently doesn't reproduce the problem ...
<jodh> Laney: comment added.
<infinity> Well, yes.  But I'm stumped, cause it clearly has the right string there.
<Laney> ty
<infinity> Which it then passes to the sub that I copied verbatim.
<infinity> And it works.
<infinity> >:(
<mvo> barry: thanks, I'm in a call now wil comment in a bit
<jodh> barry: thanks.
<infinity> cjwatson: Any chance those strings could be null-terminated or something wonky?
<infinity> cjwatson: That would asplode the dpkg -S
<cjwatson> Yeah, not sure yet
<mfisch> Riddell: ping
<Riddell> hi mfisch
<mfisch> Riddell: hey, I'll test my deb in a bit here and let you know in the defect
<Riddell> mfisch: point me at it and I can test too
<mfisch> Riddell: okay, need to finish up a phone call first
<ev> ugh, yes python-apt, what I really mean by "extract this deb" is "create a lot of empty directories for each symlink you encounter."
<ogra_> oh, that fix to bug 390247 looks tempting
<ubottu> Launchpad bug 390247 in ubiquity (Ubuntu) "Change I/O scheduler to NOOP when installing in SSD Drive or virtual machines" [Wishlist,Confirmed] https://launchpad.net/bugs/390247
 * ogra_ wonders if there are any drawbacks using udev rules like that
<xnox> ogra_: hmm... is the scheduler per drive? what if I have one rotational and one SSD ?
<Laney> jcastro_: do you know when the HP cloud trial finished/finishes?
<ogra_> yes, it is
<xnox> ogra_: that's ok then. Upload on day one or r-series?
<ogra_> xnox, well i wonder if it could help with bug 864051 as well somehow
<ubottu> Launchpad bug 864051 in partman-target (Ubuntu) "TRIM support not enabled for SSDs" [Medium,Confirmed] https://launchpad.net/bugs/864051
<xnox> ogra_: I like the bug 390247 solution better. If we can enable trim/ change scheduler on the fly the better.
<ubottu> Launchpad bug 390247 in ubiquity (Ubuntu) "Change I/O scheduler to NOOP when installing in SSD Drive or virtual machines" [Wishlist,Confirmed] https://launchpad.net/bugs/390247
<mfisch> Riddell: it will be built in a bit, I haven't tried it yet: https://launchpad.net/~mfisch/+archive/testing/+packages
<mfisch> Riddell: it's looking like it will be a few hours before I can install it
<xnox> ogra_: the caveat here, if we get it wrong we may wear one of the other out.
<xnox> s/of/or/
<ogra_> ogra@anubis:~/Devel/packages/nvidia-graphics-drivers-tegra-16.0$ cat /sys/block/sdd/queue/scheduler
<ogra_> [noop] deadline cfq
<ogra_> ogra@anubis:~/Devel/packages/nvidia-graphics-drivers-tegra-16.0$ cat /sys/block/sda/queue/scheduler
<ogra_> noop [deadline] cfq
<ogra_> wrt your first question
<jcastro_> Laney, they have not given me an exact date.
<jcastro_> Laney, basically, keep an eye on it, lmk if they start charging you.
<Laney> jcastro_: OK, I'm kind of scared to use it any more for this reason
<ogra_> xnox, hmm, i thought if the HW doesnt support TRIM it simply wont be used
<jcastro_> you're an employee, we have a cloud policy you can expense.
<Laney> heh
<xnox> ogra_: but schedulers are available for all drives?
<ogra_> xnox, the question is, can we tell it somehow through sysfs to use TRIM or is that only possible as mount option
<jcastro_> And that would enable us to know if they did start charging us so I can tell community members to either stop or keep going.
<ogra_> ogra@anubis:~/Devel/packages/nvidia-graphics-drivers-tegra-16.0$ ls /sys/block/sd*/queue/scheduler
<ogra_>  /sys/block/sda/queue/scheduler  /sys/block/sdb/queue/scheduler  /sys/block/sdc/queue/scheduler  /sys/block/sdd/queue/scheduler
<ogra_> grmpf ... IRC
<lfaraone|sh> jcastro_: let me know, too, haha. they also ended their 50% discount on cloud usage.
<xnox> jcastro_: Laney: don't they invoice monthly with no updates and that means, if they do invoice it's too late...
<ogra_> xnox, at least for all sdX ones
<jcastro_> xnox, yes, exactly
<Laney> well, you'll then have to claim it back
<Laney> as long as random usage is covered by this policy then it's cool by me
<ogra_> ah, also for sr0 loop and ram devices that i have here
<Laney> like, I'll use it now to do this patch piloting since my PC sucks
<jcastro_> Laney, don't take my word for it, please read the internal cloud policy document (I don't have it handy)
<xnox> Laney: didn't you brag about your new i7 on facebook?!
<Laney> yeah but I'm working
<Laney> can't be building PCs now can I :P
<jcastro_> I am kind of hoping they just love Ubuntu and leave the accounts open and free for the benefit of the project. :)
<ogra_> xnox, hah !
<ogra_> xnox, http://lwn.net/Articles/515790/
<Laney> jcastro_: yeah just read it, seems like it would clearly be fine
<ogra_> so seems trim/discard should be tweakable through sysfs too with that patch
<Laney> I'll give it a go then, thanks
<xnox> ogra_: lol =) interesting.
<jcastro_> Laney, yeah, unfortunately I have no way of finding out when/if they shut it off, I figure it's better for us to find out than having a community member stuck with a bill
<jcastro_> xnox, did you ever do the rebuild thing on HP cloud?
<xnox> jcastro_: i did do recompress https://blueprints.launchpad.net/ubuntu/+spec/foundations-r-dpkg-xz
<xnox> for that blueprint
<xnox> of amd64, all, dbgsym packages.
<xnox> using hadoop cluster on top of HPCloud.
<Laney> isn't there a problem with using xz in the base system, or something?
 * Laney can't remember exactly
<Laney> something to do with debootstrap maybe
<cjwatson> There certainly was at one point, and may still be.
 * lfaraone|sh is reducing his usage to ~3 XS instances, as a precaution. 
<xnox> Laney: cjwatson: but it is awesome for -dbgsym packages =)
<cjwatson> infinity: Argh.  eclipse-mylyn got the right dependencies when built locally.
<Laney> yeah, I'm sure the ddeb archive will thank you
<cjwatson> xnox: You could fix -dbgsym easily independently, in pkg-create-dbgsym.
<xnox> cjwatson: yes.
<infinity> cjwatson: ...
<cjwatson> (And no errors from jh_installeclipse.)
<infinity> cjwatson: Well, that fits with my by-hand unit-test of test.pl, but that's pretty unhelpful.
<cjwatson> I might try another build in a PPA to see if it's cosmic rays.
<infinity> cjwatson: That's some serious cosmic rays...
<infinity> cjwatson: I guess filesystem corruption could have thrown a null in the perl script... Somehow?
<xnox> cjwatson: and then we can discuss if we fill flip the xz switch elsewhere e.g. (amd64, i386, all, armel, armhf, powerpc) x (debs, ddebs, udebs) x (lamba function of your choice)
<cjwatson> xnox: Personally I'm not interested in doing this independently of Debian.
<cjwatson> Too much hassle for too little gain.
<xnox> ok.
<cjwatson> Debian seems to be showing signs of wanting to do it in the near future anyway.
<cjwatson> So if we do it ourselves, that's potentially a non-trivial amount of work that might well be superseded in not very long anyway ...
<infinity> Indeed, it was hotly discussed at Debconf.
<ogra_> pitti, any opinion about bug 390247 ? i think we shoudl ship it, but i'm not sure where to add it, udev or udisks ...
<ubottu> Launchpad bug 390247 in ubiquity (Ubuntu) "Change I/O scheduler to NOOP when installing in SSD Drive or virtual machines" [Wishlist,Confirmed] https://launchpad.net/bugs/390247
<cjwatson> So why not contribute our effort to making it work right in Debian, if that's what we want to do
<infinity> Though, mostly just from the POV of twiddling debhelper's defaults.
<infinity> (And their defaults may still end up not being what we want, given that people think "slow arches" don't deserve good compression, so we'll see)
<infinity> I tried to fight that mentality as hard as I could.
<xnox> or look at the stats and identify packages that are not gaining anything from compression, and e.g. initiate fixing those pre-compressed packages.
<infinity> xnox: Yeah, a lot of compressed stuff shouldn't be.
<infinity> xnox: And some stuff should be gz instead of xz, and, and.. But the per-package tweaks are orthogonal to picking a sane default.
<xnox> infinity: especially after we already optimise our pngs for example.
<cjwatson> I realise there are some sub-block files where it makes no difference; but "fixing" many others might well entail making the installed system bigger.
<cjwatson> Which isn't a good side-effect.
<infinity> cjwatson: We're talking debs specifically, hard to make the installed system bigger by changing compression of debs...
<infinity> (At least, I think we are)
<xnox> cjwatson: how would the installed size change?
 * xnox agrees with infinity 
<cjwatson> "fixing those pre-compressed packages" - any pre-compression is going to be individual files inside those .debs, surely.
<infinity> cjwatson: When I talk about "some stuff shouldn't be compressed", I literally mean some data.tar.gz components should be data.tar (openclipart is a great example).
<cjwatson> Oh, I see
<cjwatson> Apparently nobody's doing that right now since LP doesn't support it
<infinity> Yeah, we noticed that in the BOF. ;)
<cjwatson> So you might want to fix that first
<infinity> dak supports it because they tore out the component filename check a while ago.
<infinity> soyuz should likely just do the same.
<cjwatson> Probably.
<infinity> (Or maybe you pulled it out when you decided it was crusty and unnecessary...?)
<infinity> I dunno, I don't have a checkout in front of me.
<xnox> should I upload at tar compressed package to a ppa?
<xnox> or does it need to be archive?
<infinity> xnox: PPA would explode the same way.  But I'm not sure I care deeply to test this morning, and finding the relevant bit of code is minimal effort. :P
 * xnox goes to make coffee instead =)
<ogra_> coffee !
<Laney> slangasek: If you need any more debugging info on that mountall bug, shout soon because this system is going to be flattened tonight
<slangasek> Laney: flattened?
<Laney> slangasek: replaced
<slangasek> Laney: so one thing I noticed in the output was /media/debian/var/lib/schroot/union/overlay mounted before /var/lib/schroot/union/overlay, which looks like it's probably wrong, but I'm not sure
<cjwatson> infinity: Search for verifyFormat (at least)
<slangasek> Laney: would be interested to know if you get different results when commenting out either or both of that mount point, and the non-standard /cgroup one
<Laney> OK, can do that
<cjwatson> Probably ought to run dpkg-deb -I or something
<Laney> no clue where the second overlay came from
<infinity> cjwatson: Yeah, I feel like we've had this conversation before.
<cjwatson> It's not impossible
<infinity> cjwatson: Cause I remember verifying that dpkg-deb -I exits non-zero on broken archives.
<infinity> cjwatson: Of course, that approach also requires making sure soyuz's dpkg always support the latest and greatest deb formats, but I suspect that's a sane thing to require anyway.
<cjwatson> infinity: ICBW but I think I landed something else a while back which means that it has to nowadays.
<slangasek> Laney: I presume that schroot did some session recovery and mounted it within a chroot for you?  But it looks like it's doing this too early
<Laney> /media/debian is an installation of sid on another partition
<Laney> I can't remember how I set this up :P
<brendand_> who's in charge of errors.ubuntu.com?
<stgraber> brendand_: ev
 * ev hides
<brendand_> ev, who can have access? there's an upstream maintainer who wants to access it
<brendand_> ev, at least they say they are
<mitya57> that's me actually :)
<brendand_> mitya57, i'm sure you are :)
<mitya57> I'm Ubuntu maintainer, not only upstream
<ev> brendand_: at the moment it's only people in ~canonical or ~ubuntu-bugcontrol
<ev> so getting into the latter group would be my suggestion. :)
<ev> we do want to open it up to a wider audience, but there are serious privacy concerns
<ev> as anything at all can be in the crashes
<mitya57> I definitely plan to do that, but I want to become a Ubuntu member first, which won't be possible until November :(
<pitti> ogra_: I don't have an opinion about this, I'm afraid; I know nothing about schedulers :(
<pitti> ogra_: I do know that linux sucks while doing heavy I/O, especially on my rather fast SSD
<ogra_> pitti, no, but you know where device rules usually live :=
<pitti> so maybe this alleviates it a bit
<ogra_> :)
<brendand_> mitya57, no reason to do it that way around. i was in bug-control first and then only after ubuntu-members
<brendand_> mitya57, in fact bug-control membership can be valuable collateral for your application
<ogra_> pitti, the rule is correct ... its just about where to put it
<pitti> ogra_: well, if you mean that, a rule like this would never go into udev itself; it's a workaround for bad kernel defaults (if it is a bad default)
<pitti> at least not upstream
<ogra_> its not
<ogra_> its something the kernel cant detect (yet)
<pitti> so if the kernel can't detect it, how can userspace?
<pitti> but anyway, if you want to put rules into udev, you know where the bzr tree lives :)
<ogra_> theoretically the kernel shoudl just notice the device is an SSD and set the right default scheduler
<mitya57> brendand_: ok, so I'll apply when I have some time, can you still show me that crash?
<ogra_> well, the kernel exposes the feature to userspace ... but doesnt do any proper automated handling of it yet
<smagoun> Hi, would someone review this bug and (hopefully) mark it public? Apport has identified it as the master bug for an issue, I'd like to see the master bug. https://bugs.launchpad.net/bugs/883615
<ubottu> Error: malone bug 883615 not found
<ogra_> pitti, so rather udev than udisks ?
<ogra_> (that was my actual question ;) )
<brendand_> mitya57, anyway i have the screenshot here (of the python stack trace). i'm pretty sure there's nothing confidential/private shown so unless ev wants to veto it i can post the link here...
<pitti> rather "fix the kernel", I'd say, but it's a nasty workaround rule no matter where it lives :)
<stgraber> smagoun: done
<smagoun> stgraber: thank you!
<ev> brendand_: presumably you mean paste the text or put up a pastebin url of the contents - you shouldn't be able to get to the stack trace without going through open ID
<ev> but I don't mind if you share the contents :)
<ogra_> pitti, whats nasty about it ? i prevents your SSD from wearing out and increases performance :)
<pitti> ogra_: I mean having userspace rules to fix broken defaults (that's why it wouldn't go upstream)
<ogra_> andi agree it should be fixed in kernel eventually
<xnox> ogra_: i'd stick it into hdparam package or something like that.
<ogra_> well, its not defaults, but rather missing handling of them
<pitti> ogra_: so for packaging, I guess it's fine to put it into udev, as that has an ubuntu specific packaging anyway, so doesn't introduce a delta; but I don't mind much which package it ends up in
<ogra_> xnox, hmm, i think that would add a depends on udev, no ?
<ogra_> pitti, thanks :)
<pitti> no, it's just shipping a file
<pitti> if udev isn't installed, the rule wouldn't work anyway
<brendand_> ev, heh - pastebin would be even better :) assuming mitya57 is only interested in the stack trace?
<pitti> but then again, you can't uninstall udev
 * pitti waves good night
<pitti> need to run now
<brendand_> mitya57, http://paste.ubuntu.com/1256228/
<mitya57> thanks brendand_!
<ogra_> ciao pitti and thanks again
<brendand_> mitya57, and do get bug-control sooner rather than later :) make your life easier
<mitya57> brendand_: sure
<davidcalle> jbicha, hi. I'd like to have your advice on https://bugs.launchpad.net/unity-lens-photos/+bug/1049090. It's a OEM team request to change a lens shortcut (Super+P to Super+C).
<ubottu> Launchpad bug 1049090 in OEM Priority Project quantal "The shortcut Super + P of photo lens is conflict to Video out hotkey" [High,Confirmed]
<davidcalle> jbicha, is this shortcut documented?
<ev> pitti: any objections to depending on python3-debian? I had to rework that merge
<ev> python-debian is in main
<ev> I'll need to work out a MIR for python3-debian
<cjwatson> No, you don't
<ev> ORLY
<cjwatson> MIRs are by source package
<ev> oh, right
<ev> cheers
<cjwatson> python3-debian can be promoted as soon as something depends on it
<ev> woohoo
<cjwatson> (Or just in advance, if that's more convenient - but not too much in advance so that we don't spend too long with junk in component-mismatches)
<jbicha> davidcalle: yes http://bazaar.launchpad.net/~ubuntu-core-doc/ubuntu-docs/quantal/view/head:/ubuntu-help/C/unity-dash-photos.page
<smoser> slangasek, i'm guessing that this is fallout of the mountall change
<smoser> https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/1060296
<ubottu> Launchpad bug 1060296 in coreutils (Ubuntu) "'df /' reports Filesystem '-'" [Undecided,New]
<jbicha> but Super+P as a video out shortcut isn't in ubuntu-docs
<davidcalle> jbicha, I see. It's apparently a standard for some OEM.
<slangasek> smoser: please get me the boot-time output of mountall --verbose
<smoser> slangasek, isnt it clear this is a fallout?
<jbicha> davidcalle: we might be able to sed replace it, do different languages have different keyboard shortcuts?
<jbicha> on the other hand, the Ubuntu Manual is almost string-frozen too
<smoser> i can do that though.
<slangasek> smoser: knowing that it's fallout doesn't tell me how to fix it
<davidcalle> jbicha, no, same shortcut.
<smoser> well, mountall is trying to write stuff to /etc/mtab before / is rw
<smoser> because we told it to mount other stuff before / is rw
<slangasek> smoser: I need the debugging output from the machine where this is happening
<smoser> :)
<jbicha> davidcalle: ok, I guess it's fixable with a text replacement, but...
<Laney> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Beta 2 released! | Archive: Frozen | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<jbicha> currently all the lenses are ordered alphabetically in English, and photo lens or even picture lens sounds better than camera lens
<davidcalle> jbicha, I know, that's why I'm worried about this. The new shortcut has been decided on this morning, the comment timeline on the report is... well, let's say it could have been fixed a long time ago. :/
<jbicha> so changing the shortcut would make other stuff more inconsistent
<davidcalle> jbicha, I agree.
<davidcalle> jbicha, but Super+P is an OEM blocker.
<jbicha> davidcalle: while you're here, my wife really hates that there aren't tooltips to let people know what the different lenses are
<jbicha> I need to bug the designers about that since it's a wife blocker ;)
<davidcalle> jbicha, I thought the social bird was pretty clear ;-)
<jbicha> I don't know, it hasn't landed yet... the applications icon isn't clear at all though
<davidcalle> jbicha, it isn't. About tooltips I think it would be nice to experiment with it, or to redesign the lens bar completely to accomodate icons + text.
<mvo> barry: had a bit of a busy afternoon, please merge from lp:~mvo/python-apt/debian-sid-mirror that will contain some of your suggestions :)
<jbicha> davidcalle: let's see, GNOME Shell & Android both use a bunch of squares to represent "All Applications"
<jbicha> davidcalle: anyway, the keyboard shortcut change could get an UIFe, it's just less clear that it's the right change to make
<davidcalle> jbicha, they both use it in the same context as other app icons, i'm not sure it would work here.
<davidcalle> jbicha, could you make this comment on the report, to have it seen by design? Anything I need to do to make it a proper UIFE request?
<jbicha> davidcalle: https://wiki.ubuntu.com/FreezeExceptionProcess#UserInterfaceFreeze_Exceptions
<davidcalle> jbicha, ty
 * cjwatson swears at Python 2.  It can't die quickly enough
<cjwatson> Stupid bytes.decode() default encoding
<Laney> slangasek: so commenting out those entries indeed made it boot with 2.41
<Laney> turns out /var/lib/schroot is a symlink to /media/debian/var/lib/schroot/
<Laney> and it works if I change the mount point to the real path rather than going through the symlink
<slangasek> Laney: thanks, useful to know - can you mention that in the bug (if you haven't already)?
<Laney> yeah, pasting it in now
<smoser> anyone seen this: http://paste.ubuntu.com/1256365/
<infinity> smoser: Which part?
<smoser> the failure
<smoser> i've never seen thnat fail
<smoser> (well, not like that)
<infinity> Oh, I didn't notice that was fatal.
<infinity> Is /home/ubuntu writeable?
<smoser> yeah
<smoser> actually, just creating that dir made it exit success
<smoser> but still loud
<infinity> Though, you'd think after going to all the trouble to make a tmpdir and put keyrings in it, it would also set the gpghome to that.
<roaksoax> howdy! So i have a question regarding upgrades. So we had older maas install several files, including maas-celery.upstart. Now, in quantal, maas has simply become a virtual package. maas-celery.upstart no loonger exists anywhere
<roaksoax> so on upgrade, maas-celey.upstart remains there
<smoser> yeah.
<roaksoax> any ideas of how to force the removal of those files that previous 'maas' package installed, when upgrading to new 'maas' (virtual) package?
<smoser> and worse, if I create that directory, now i have root owned content in there.
<infinity> roaksoax: Are you sure you mean virtual package, not metapackage?
<infinity> roaksoax: I certainly see a "mass" package in quantal...
<roaksoax> infinity: err yeah, metapackage :)
<roaksoax> infinity: this is the new stuff that hasn't yet been uploaded to archives
<infinity> roaksoax: man dpkg-maintscript-helper, see rm_conffile
<roaksoax> infinity: cool thanks!
<smoser> mvo, i'm guessing this is regression:
<smoser> https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1060335
<ubottu> Launchpad bug 1060335 in software-properties (Ubuntu) "apt-add-repository fails" [Undecided,New]
<infinity> Ahh, yeah, this calling GPG thing is shiny and new.
<cjwatson> infinity: https://launchpadlibrarian.net/118143204/buildlog_ubuntu-quantal-i386.eclipse-mylyn_3.8.0-1%2Bppa1_BUILDING.txt.gz hmmmm
<cjwatson> Same symptom
<cjwatson> Any bright ideas?  I don't care about that PPA so I can push arbitrary debugging nonsense into it
<infinity> smoser: Can you try editing ppa.py to add '"--homedir", tmp_keyring_dir' to GPG_DEFAULT_OPTIONS?
<cjwatson> dpkg -S must be saying something since otherwise it wouldn't try dpkg -l.
<cjwatson> I guess I could try PERLDB_OPTS='NonStop=1 AutoTrace' perl -d /usr/bin/jh_installeclipse
<infinity> cjwatson: Oh weird.  That's pretty bizzarely not what I was expecting.
<infinity> cjwatson: This is probably where I'd upload a custom javahelper with random print()s in that subroutine to try to figure out WTF dpkg -S is returning.
<infinity> cjwatson: Or why it things pkg is unset.
<infinity> cjwatson: Cause I can't even fathom why that's failing in production but not here.
<infinity> smoser: Is that on quantal?
<infinity> smoser: It looks to me like the precise upload DTRT, and quantal has an incomplete forward-port.
<cjwatson> infinity: Check.  Stupidly verbose javahelper coming up.
<smoser> infinity, quantal, yes.
<infinity> cjwatson: It could still be dpkg -S not finding it, if it's just piping the output and ignoring the return.
<infinity> cjwatson: Then you'd get a dpkg -l for "dpkg-query", which would return null.
<cjwatson> It doesn't get into the dpkg -l unless dpkg -S returned some actual output.
<cjwatson> On stdout.
<cjwatson> "dpkg-query: no path found matching pattern /foo/bar" goes to stderr, so that won't get matched.
<cjwatson> I think what actually happened is that something decided I didn't have enough odd puzzles.
<bdmurray> slangasek: bug 1060249 is receiving a few duplicates now
<ubottu> Launchpad bug 1060249 in debconf (Ubuntu) "frontend crashed with signal 5 in g_node_copy_deep()" [High,Confirmed] https://launchpad.net/bugs/1060249
<infinity> cjwatson: Yeah, it almost certainly failed for your benefit.  Way to fight off dementia.
<slangasek> cjwatson: ^^ any idea about this debconf crash?  looks like a new problem with the gnome frontend :/
<ogra_> oh, that really has a few dups
<cjwatson> No, but surely a libglib-perl/libgtk2-perl bug ...
<cjwatson> Probably doesn't help that libgtk2-perl currently fails to build
<slangasek> ah fun
<cjwatson> slangasek: Every single one of the dups has been marked Invalid, presumably by apport due to lack of retraceability :-(
<slangasek> score
<cjwatson> So ... I have no idea.  rls-q-incoming it I guess ...
<cjwatson> Oh, it's already targeted
<jtaylor> Riddell: you did the new taglib version?
<jtaylor> Riddell: tfile.h includes a nonexistant file (tiostream.h) which breaks mediatomb
<mvo> smoser: yeah, what infinity said earlier :/
<infinity> mvo: I'll be committing/uploading in a moment, don't worry about it.
<infinity> mvo: (And don't read my POC patch, it was clearly broken)
<barry> mvo: will look, thanks
<infinity> mvo: Okay, fix uploaded and committed.
<infinity> smoser: Done with the instance, thanks.
<cjwatson> Huh.  https://launchpadlibrarian.net/118149510/buildlog_ubuntu-quantal-i386.eclipse-mylyn_3.8.0-1%2Bppa2_BUILDING.txt.gz
<cjwatson> Not being printed by 'dpkg -l | grep -E ^ii'.
<cjwatson> I'll have to finish up now and look again tomorrow though.
<mvo> infinity: weeh, thanks!
<infinity> cjwatson: You weren't kidding about cranking the verbosity to ridiculous...
<cjwatson> I'm going to dump out raw dpkg -l next.
<mvo> infinity: I will commit a simplification to trunk soonish as python-apt has apt.auth.add_key_from_keyserver() now (since ~yesterday) that performs the same verification
<infinity> mvo: Heh, fair enough.
<mvo> infinity: but thanks for taking care of this it means I can call it a day and worry about this later
<infinity> mvo: NP.
<clahey> Hey all.
<clahey> I've got an internal bug assigned to me that points out that when I go to the Open With tab of the Properties dialog of a vmx file, it doesn't list vmware-player and vmware as options.
<clahey> They're both there in the right click menu "Open With VMware Player" and "Open with VMware Workstation"
<clahey> I'm curious how that dialog makes its list so that I can fix this.
<Daviey> Gah, please can someone give me n00b lessons on the differnece between Reply and Reply-All. Seems i suck.
<ogra_> Daviey, ??
<clahey> Daviey: I have that issue sometimes.  I've decided to have the default be Reply All since that's almost always what I want, but when it's not, it can be pretty embarrassing.
<Daviey> ogra_: ubuntu-devel, intended to send an offlist reply :)
<ogra_> use reply-to-list then :)
<ogra_> vs reply
 * ogra_ never uses reply-all ...
 * Daviey notes he didn't have this problem with telnet as a mail client :)
<ogra_> heh
<soren> Daviey: It also never happens with carrier pigeons.
<soren> Daviey: Just saying.
<clahey> soren: Are you saying you've never sent a flock of carrier pigeons when you meant to send only one?  That happens to me ALL THE TIME.
<dead_inside> thats why i keep a shotgun at my desk clahey
<dead_inside> kill them before they reach everyone
<clahey> dead_inside: Tou chÃ©.
<arges> infinity, hello. I finally got access to AMD hardware to verify pad.lv/979003. Any other verification you'd like to see on the hardware while rtg  lets me use it?
<infinity> arges: Nope, but I'll need to reupload all over again later tonight, cause the security update reverted it all.
<infinity> arges: So, if Tim's going to let you have access to it for a day or two, I'll ping you as soon as I get a fresh upload in (probably by tomorrow).
<arges> infinity, yea saw that,I was able to apply the diff cleanly on top, so it shouldn't be too bad
<arges> infinity, ok perfect
<infinity> arges: Yeah, it'll not be much effort.  I want to nail one or two more bugs while I'm at it, though, since I have to re-upload anyway.
<infinity> arges: Anyhow.  I'll poke you about it tomorrow.  I've been up for ~30h, it might be time for a nap.
<arges> infinity, wow... yea sounds good
<TheBurrito> Anyone have tips for getting Ubuntu Core running on an Odroid-X? I've gotten Android 4.0.4 running, as well as the linaro image that hardkernel links to. I'm now using the original boot partitions with ubuntu-core as the root fs. I have copied all of the modules over from the linaro image to accompany the kernel with this new rootfs. I get serial consol output all the way up to fsck running. Is ubuntu core setup to run a serial
<TheBurrito>  console?
<ogra_> ubuntu core is intended for people who build images out of it (or as a cheap chroot if you are to lazy to debootstrap), its extremely minimal and totally unconfigured
<ogra_> you need to create a serial upstart job to make it start a getty on serial
<cjwatson> infinity: ahahahahahaha bonk
<cjwatson> pi  libhttpclient-java                  4.1.1-2ubuntu1                    all          HTTP/1.1 compliant HTTP agent implementation
<cjwatson> thanks, ... something
<TheBurrito> I've tried that wihtout success. I followed the post at www.omappedia.com/wiki/OMAP_Ubuntu_Core to no avail. I was hoping to get a lightweight rootfs to create a robotics platform. perhaps i'll get the server rootfs and start from there until my linux-fu is stronger.
<arges> micahg, hi. I have a backport that should be a no-change now.  is there anything I need to change to get it on to the backports queue? pad.lv/943502  .. thanks
<stgraber> TheMuso: heya. I'm looking at the casper bugs, any progress on bug 122024?
<ubottu> Launchpad bug 122024 in casper (Ubuntu) "orca should automatically get started when braille is activated" [Medium,In progress] https://launchpad.net/bugs/122024
<TheBurrito> ogra_: I'm in. thanks for the pointer to upstart/getty.
<tjaalton> hallyn: -qxl 0.1.0 needs spice-protocol 0.12.2 to build
<tjaalton> bad upstream for not bumping the dep on configure.ac..
<hallyn> tjaalton: drat
<tjaalton> so just update it :)
<hallyn> tjaalton: there is no 0.12.2 release, only 0.12
<tjaalton> it's tagged in git
<hallyn> do we care about risking having different .orig.tar.gz than debian?  or do we just stick git commit int he version #?
<hallyn> well anyway, i'll put my best guess up at ppa:serge-hallyn/virt
<tjaalton> http://spice-space.org/download/releases/ has the tarball
<hallyn> tjaalton: I'm perhaps missing something. a re you suggesting i use 0.12.0 tarball and push the patches on top?
<tjaalton> no, update the package
<tjaalton> bump it to 0.12.2
<tjaalton> oh it's in collab-maint
<tjaalton> doesn't matter
<hallyn> oh.  feh.  i was looking at spice.  spice-protocl does indeed have a 0.12.2. tarball. <slap>
<tjaalton> hehe :)
<tjaalton> pushed -qxl git, just use the current one on the ubuntu branch
<hallyn> tjaalton: ok so i tried that last night and got stuck - where should i get the tarball so i can debuild -S?
<hallyn> there didn't seem to be a rule in debian/rules to make it
<tjaalton> tarball for what?
<tjaalton> use uscan --download-current
<hallyn> (meanwhile, new spice-protocol pushed to ppa:serge-hallyn/virt)
<hallyn> huh
<hallyn> ok, will do, thx
<tjaalton> also, I just deleted the files that diff-ignore tries to ignore but fails
<tjaalton> to build the source package for my tests
<tjaalton> hallyn: once you're satisfied, please upload if you think it's worth it. you know this spice stuff better than I do :)
<hallyn> tjaalton: i don't believe i have the perms to push any of it :)
<hallyn> but i'll test and ping you tomorrow if that' sok
<tjaalton> ahh, ok then I can push it
<tjaalton> sure thing
<tjaalton> I'll get up in ~7h
<hallyn> tjaalton: cool then i'll try to finish befor ebed :)  thanks again, ttyl
<tjaalton> hallyn: great
<melodie> hello
<melodie> I have searched in several places where to ask for more info about blueprints, what can be done in this matter and what belongs elsewhere (for 2 ideas I would like to communicate) but didn't find yet a place where I can get adviced. Is there someone here who could tell me about it ?
<barry> tumbleweed: i requested your review on the mp for my branch for bug 935516.  i'm not sure the fix is right, or whether we should wait a little longer to hear from upstream.  comments are welcome.
<ubottu> Launchpad bug 935516 in genshi (Ubuntu Quantal) "genshi version 0.6-2 FTBFS on i386 in precise" [High,Triaged] https://launchpad.net/bugs/935516
<zyga> pitti: ping
<zyga> pitti: https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1007826
<ubottu> Launchpad bug 1007826 in apport (Ubuntu) "crash with AssertionError: file stream must be in binary mode when trying to save report to file" [High,Fix released]
<zyga> pitti: I just reproduced that on quantal
<zyga> pitti: shall I repen it or file a new one (it was filed and fixedc on 2.2.4-0ubuntu1 and I have 2.6.1-0ubuntu1)
<hallyn> tjaalton: works like a charm!
<tumbleweed> barry: yeah, I never did it myself, because I wasn't entirely sure wha tthe best solution was. But that seems appropriate for Ubuntu
<barry> tumbleweed: cool.  unless you disagree, i'll upload that fix and we can always back it out, or resync to debian later
<tumbleweed> sounds fine
<barry> thx
<bryceh> anyone with NVIDIA graphics on precise want to help me test something real quick?
<ion> bryceh: sure
<bryceh> ion, thanks, I'll PM you the directions
<bryceh> thanks ion!
<ion> np
<melodie> gn
<Laney> Did something change to make me get mail for openstack-ubuntu-packagers?
<Daviey> Laney: someone reviewed the moderated mail queue
#ubuntu-devel 2012-10-03
<micahg> arges: as commented in the bug, just reverse dependency install/run testing for precise and oneiric as well as install/run testing for the whois backport itself, thanks
<infinity> cjwatson: Oh, that pi state may be a feature of the old sbuild, come to think of it.  Totally didn't think of that when I saw the grep ^ii
<infinity> cjwatson: Yay verbosity. ;)
<tjaalton> hallyn: excellent, thanks
<StevenK> RAOF: xvfb-run makes me sad
<RAOF> Whyso?
<StevenK> jenkins@lptests-temp-k0hHY4M:~$ xvfb-run bash
<StevenK> xvfb-run: error: Xvfb failed to start
<StevenK> Some helpful information would be nice
<RAOF> StevenK: Fair call.
<RAOF> --error-file might help you.
<StevenK> Fatal server error:
<StevenK> Can't read lock file /tmp/.X99-lock
<StevenK> That is roughly as helpful. :-)
<RAOF> Whee!
<RAOF> Yeah, that's not awesome.
<Daviey> seb128: Are you able to provide a debian/watch for geary?
<seb128> Daviey, I guess yes
<Daviey> (currently, i cannot validate the orig src tarball)
<seb128> Daviey, the tarball is coming from http://www.yorba.org/download/geary/0.2/geary-0.2.0.tar.xz
<Daviey> seb128: ok, rejected this.. Can you add a watch file, and re-upload please?
<seb128> sure
<Daviey> seb128: (everything else looks good, will accept then)
<seb128> Daviey, is that a new thing requiring a watch file? ;-) just curious, it feels weird :p
<cjwatson> MIRs strongly suggest it; archive acceptance doesn't generally
<Daviey> seb128: jdstrand was mostly the driver for this.  It's not a firm requirement but a best practice that AA's seem to be pushign for.  If a watch file isn't viable, then a debian/rules get-orig-source (or packaged-source) or a debian/Readme.source explaining how it was created.
<cjwatson> the MIR team is pushing for it, not AAs
<cjwatson> it wouldn't be practical to enforce something like that over the whole archive
<Daviey> well, considering the complexity of most watch files.. I don't think it is a bad idea
<cjwatson> I think many things are a good idea but wouldn't reject for their absence
<Daviey> Note, i did ask if it was viable before rejecting
<cjwatson> "accept with suggestions" is usually a better workflow
<Riddell> what's the script to copy packages between PPAs?
<cjwatson> copy-package
<cjwatson> (in ubuntu-archive-tools)
<seb128> Daviey, reuploaded with a watch ;-)
<seb128> Daviey, should be in the queue in 3 minutes or so (next run)
<Riddell> oh yes, I was trying ubuntu-dev-tools
<mpt> ev, mvo introduced the recoverable errors on Sep 22. So it might explain a bit of the difference between 12.04 and Q, but probably not much of it.
<ev> mpt: noted, cheers
<mpt> ev, actually, Aug 22.
<mpt> hm, so maybe it does explain much of it
<ev> I've laid the groundwork for the like for like comparisons in RT 56497
<pitti> zyga: apport crash in binary mode> if you are absolutely sure it's really the same bug, please reopen; otherwise, just file a new one
<pitti> ev: py3-debian seems fine to me
<ev> pitti: cheers
<pitti> zyga, ev: (on holiday today)
<darkxst> anyone able to sponsor my casper patches for ubuntu gnome remix?
<darkxst> https://code.launchpad.net/~darkxst/casper/ubuntu-gnome-casper-tweaks/+merge/127634
<cjwatson> stgraber: ^-
<zyga> pitti: thanks
<mdeslaur> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Beta 2 released! | Archive: Frozen | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mdeslaur
<jdstrand> cjwatson, seb128, Daviey: I have been pushing for a watch file as an AA where practical (eg, certainly not native packages). a watch file is gives us the only glimmer of a possibility to be able to do an integrity check of the archive
<jdstrand> (systematically)
<cjwatson> There's still no point in rejecting on it because Debian doesn't
<cjwatson> Offer advice, certainly
<seb128> jdstrand, hey, ok, fair enough, it's just something that wasn't flagged as important on my checklist until today, but that makes sense
<jdstrand> I don't think I've ever rejecting on that reason alone
<jdstrand> rejected
<cjwatson> Right.  Daviey did
<cjwatson> I guess what I'm saying is that having inconsistent standards based on non-agreed whims of individual AAs makes it unnecessarily difficult for uploaders
<Daviey> I didn't just reject out of hand, I did check if it was reasonable to do first.
<jdstrand> I might file a bug-- certainly give advice. I'd even phrase it as one of a list of things that needed to be fixed before being accepted
<cjwatson> I wouldn't have rejected even after checking that it was reasonable to add the watch file.
<cjwatson> I'd have let the uploader add it in a subsequent upload.
<jdstrand> actually, we discussed this before
<jdstrand> I forget if it was at a rally/sprint or a uds (not a session)
<cjwatson> It came up at a rally in the context of MIRs only
<jdstrand> right
<jdstrand> ah, that was the other bit-- main only
<cjwatson> Look, I'm not objecting to people trying to improve the archive
<jdstrand> but I wasn't a mir reviewer at the time
<jdstrand> I was pushing it as an aa
<cjwatson> I'm just saying that archive rejections are an awfully heavy tool for doing so
<Daviey> I know that I've been unsuccessful in getting debian sponsorship for NEW without a watch file on two occasions, but that is sponsors etiquette rather than polciy.
<cjwatson> Sponsors can and should be stricter than the base requirements for archive acceptance
<jdstrand> I would agree with that-- I also wouldn't nak something that went through Debian NEW (I would file a bug there). I do strongly encourage new Ubuntu uploads to have one though
<cjwatson> I mean, a sponsor might reasonably ask you to fix typos in your package description, but it'd be ridiculous to reject for that
<jdstrand> let me rephrase: I wouldn't nak something that went through Debian NEW based on lack of a watch file alone
 * jdstrand nods
<Daviey> I do like to check that what is in orig, is the true orig whilst reviewing.  Without one of the ways to get the source it does make life harder.  Considering the simplicity in most cases of writing a watch file, it also seems wise to promote it as a best pratice.
<cjwatson> Lack of best practice != reject
<cjwatson> That's all I'm saying
<Daviey> If the consensus is different, then ok, i won;t do that
<cjwatson> Otherwise I'd reject a LOT more and I don't think that would actually help
<cjwatson> It would just reduce velocity and piss people off
<jdstrand> Daviey: I whole-heartedly agree with checking the orig.tar.gz-- I have found cases where they were different (not ever malicious, but still)
<jdstrand> I also agree that if other nakable things are wrong, listing the watch file as a requirement is ok. if it is only the watch file, a bug seems fine
<jdstrand> eg, maybe treat it like lintian warnings
<jdstrand> nakable-- that looks funny :)
<cjwatson> We should probably have a fork of http://ftp-master.debian.org/REJECT-FAQ.html
<jdstrand> yeah
<jdstrand> I added it to my todo list
<Daviey> cjwatson: Do you think a UDS session for this makes sense?  More of a standardisation healthcheck?
<cjwatson> It's probably the kind of thing that would work better by e-mail
 * jdstrand doesn't think it needs a session
<jdstrand> cjwatson: +1
<jdstrand> so, while I've added it to my todo list, there is a fairly good chance I will not get to it super-soon
<Daviey> bah, these sort of threads rarely end in consensus IMO :).. but ok
<jdstrand> (there is a good deal of understatement there ;)
<cjwatson> Artificial consensus by doing it in a room while nobody's watching doesn't count :-)
<cjwatson> If a session, it should at most be an exercise for gathering suggestions that form the agenda for a thread
<cjwatson> IMO
<jdstrand> Daviey: actually, I've had the opposite experience with ubuntu-archive
<Daviey> Okay, i'll shuddup.
<jdstrand> heh. I don't think that is quite what I said :P
<jdstrand> but if it works...
<jdstrand> ;)
<Daviey> heh
 * jdstrand hugs Daviey 
<jdstrand> Daviey: seriously though, thanks for the careful reviews and bringing this up. it will (eventually) end up as something good for the team
<Daviey> jdstrand: well, i certainly agree with the need for standardisation.  I know i found it frustrating when i was a newcomer.
 * jdstrand nods
<cjwatson> argh.  you know what annoys me?  build systems that don't stop on error
 * cjwatson finds the real error message a few hundred lines back
<Daviey> well, that is what confused me about bug 1052056, apparently it doesn't fail on error jdstrand ?
<ubottu> Launchpad bug 1052056 in freeipmi (Ubuntu) "[FFe] [MIR] freeipmi" [Undecided,In progress] https://launchpad.net/bugs/1052056
<Daviey> (roaksox was looking to resolve that, i've not looked into it)
<stgraber> darkxst, cjwatson: I'll take a look. I'm planning to spend some more time on casper today trying to reduce the bug count a bit.
<cjwatson> Daviey: You mean the compiler warnings?
<Daviey> cjwatson: roaksoax/doko made it sound like it wasn't reasonably failing on error.
<jdstrand> Daviey: are you referring to the compiler warnings? those don't fail the build unless you build with -Werror
<Daviey> http://irclogs.ubuntu.com/2012/10/02/%23ubuntu-server.html#t14:49
<cjwatson> I don't see any warnings in https://launchpadlibrarian.net/108137937/buildlog_ubuntu-quantal-i386.freeipmi_1.1.5-3_BUILDING.txt.gz
<cjwatson> Er, any errors, I mean
<cjwatson> Right, I disagree that those warnings should fail the build
<cjwatson> -Werror is a good thing for upstreams to use during development; it's highly questionable at a distribution scale
<Daviey> I suspect it's misscommunication, jdstrand wanted the Warnings looked at.. and it was interrupted wrongly.
 * jdstrand nods
<cjwatson> And doko wasn't talking about the build system there, anyway; he was suggesting behaviour of the C code
<jdstrand> doko summarized it pretty clearly in his initial response, fwiw
<jdstrand> well, to me anyway, cause I knew what I wanted :)
<Daviey> 3 way failure :).. i see that now, i've bothered looking at the warning :)
<stgraber> darkxst: posted a comment about some problems in your MP
<cjwatson> warn_unused_result is often worth fixing but has a fair few false positives too
<cjwatson> And unfortunately there's been a bit of an arms race on how to silence it, so what seems like an obvious (void) cast doesn't actually work
<herton> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Beta 2 released! | Archive: Frozen | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: herton, mdeslaur
<cjwatson> seb128: Hopefully upstream will respond quickly enough, but do you think we could pull in the fix for https://bugzilla.gnome.org/show_bug.cgi?id=685388 ?  Recent regression, not sure how many packages it affects ...
<ubottu> Gnome bug 685388 in general "Confused shell syntax in omf.make" [Normal,Unconfirmed]
<seb128> cjwatson, I've pinged David & lool for review but the patch looks fine to me so feel free to upload that to quantal
<seb128> cjwatson, or I can backport it if you want
<cjwatson> I'll upload it then, thanks
<cjwatson> obscure bugs unearthed by +1 maint for the win
<seb128> cjwatson, thanks for tracking it down ;-)
<cjwatson> Any Ubuntu VCS for gnome-common?
<seb128> cjwatson, no
<cjwatson> OK
<seb128> we avoid Vcses for easy packages that are often in sync with debian (which is the case of this one) since they get outdated when we do direct syncs
<cjwatson> Fair enough
<darkxst> stgraber, thanks, I have fixed it now
<stgraber> darkxst: looks good, merging it now
<stgraber> darkxst: hmm, one last thing actually, don't you need to run glib-compile-schemas after you change an override?
<stgraber> darkxst: if so, you probably should move your .override change to 22desktop_settings where we already have code to change overrides and run a compile-schemas a single time
<darkxst> stgraber, yes need compile schemas
<stgraber> darkxst: ok, can you move that bit over to 22desktop_settings then?
<darkxst> stgraber, yeh
<darkxst> stgraber, done..
<stgraber> darkxst: thanks. Merged. Will be uploaded later today.
<rbasak> Is there a way to get apt-file to search d-i contents, or perhaps some other way to achieve the same thing?
<rbasak> Right now I'm trying to find out how d-i reboots to debug a d-i rebooting problem. I've found finish-install, debian-installer-utils and rootskel. Ultimately it seems that I'm looking for reboot in the path, but I haven't found it yet
<darkxst> stgraber, thanks
<darkxst> jbicha, casper changes are merged
<jbicha> cool, thanks darkxst & stgraber
<mpt> ev, I just reported bug 1060989 because I could reproduce it reliably, but I think it's been happening for months
<ubottu> Launchpad bug 1060989 in Apport "Report isn't sent after clicking "Continue" while details load" [Undecided,New] https://launchpad.net/bugs/1060989
<cjwatson> rbasak: finish-install/finish-install.d/99reboot -> /lib/debian-installer/exit which is in rootskel/src/lib/debian-installer/exit-linux
<rbasak> cjwatson: thanks - but then exit-linux calls "reboot". On my system that's linked to upstart, but I presume not in d-i?
<rbasak> cjwatson: and I was a bit surprised to find that busybox doesn't appear to provide one
<cjwatson> $ dpkg -c /mirror/ubuntu/pool/main/b/busybox/busybox-udeb_1.19.3-7ubuntu1_i386.udeb | grep reboot
<cjwatson> lrwxrwxrwx root/root         0 2012-05-01 06:10 ./sbin/reboot -> /bin/busybox
<cjwatson> The busybox deb configuration isn't the same as the udeb configuration
<rbasak> ah, ok
<rbasak> Oddly, upstream's docs at http://busybox.net/downloads/BusyBox.html doesn't list reboot as a command either
<rbasak> thanks!
<cjwatson> I suspect that's not especially up to date
<rbasak> especially?
 * rbasak wonders how long busybox has supported reboot :-)
<ogra_> it definitely has shutdown for a long time
<cjwatson> Mm, but that page is generated
<cjwatson> It probably depends on the configuration used in the relevant build ...
<rbasak> From a busybox build that misses out reboot I'm guessing? :)
<cjwatson> Presumably - that would be fairly normal if it's in use on a system with some other reboot
<cjwatson> Dunno really
<cjwatson> I wouldn't bother using that page for anything :)
<lool> cjwatson: Yup, looks good; looking back at this 2007 patch I can see how I got it wrong back then, thanks for fixing
<smoser> ok. i have a apparently stupid upstart question
<smoser> upstart job : http://paste.ubuntu.com/1258106/
<smoser> ok. better explained/demonstrated http://paste.ubuntu.com/1258126/
<smoser> why does my upstart job not get respawned?
<smoser> GAH
<smoser> need 'respawn' by itself.
<smoser> i was confused by "Default COUNT is 10. Default INTERVAL is 5 seconds."
<mitya57> Hi ev (again)
<mitya57> I've been added to bug-control, but errors.u.c shows me:
<mitya57> OpenID failed OpenID authentication failed: Invalid openid.mode: '<No mode set>'
<mitya57> Should I wait some time or is it a bug?
<mitya57> Hm, this works for another report
<mitya57> Ah, it works now, ignore all that :)
<ev> :)
<ev> mpt: cheers
<mterry> ev, how does one associate a bug with an errors.ubuntu.com entry?
<ev> mterry: click on the "Create" link on errors.ubuntu.com
<mterry> ev, huh, don't see it.  Maybe I'm not in a group I would need to be
<ev> mterry: does the problem start with "failed:"?
<mterry> ev, no
<ev> which one is it?
<mterry> https://errors.ubuntu.com/bucket/?id=%2Fusr%2Flib%2Funity-scope-video-remote%2Funity-scope-video-remote%3AGError%3A%3Cmodule%3E%3Amain%3Afunction
<mterry> ev, ^
<ev> mterry: https://bugs.launchpad.net/ubuntu/+source/unity-scope-video-remote/+bug/1061038
<ubottu> Launchpad bug 1061038 in unity-scope-video-remote (Ubuntu) "/usr/lib/unity-scope-video-remote/unity-scope-video-remote:GError:<module>:main:function" [Undecided,New]
<ev> the Create links only appear on the front page
<ev> but we should show them on the problem pages as well
<mterry> ev, I was looking at bug 950862 too
<ubottu> Launchpad bug 950862 in Unity Videos Lens "unity-scope-video-remote crashed with GError in function(): Could not connect: Connection refused" [Undecided,Fix committed] https://launchpad.net/bugs/950862
<ev> filing a bug for this now
<mterry> ev, I don't see it on the front page either
<ev> https://bugs.launchpad.net/errors/+bug/1061041
<ubottu> Launchpad bug 1061041 in Errors "The 'create' link should appear on the problem pages as well" [Undecided,New]
<mterry> ev, OK, so two problems then: I don't see the create link on the front page and I want to be able to link a report and a bug, not create a new one
<ev> mterry: so the plan for dealing with already existing bugs is still evovling
<ev> evolving*
<mterry> ev, ok
<mterry> ev, oh now
<ev> mterry: oh, and you wont see the create link on the front page unless you're logged in
<ev> sorry about that
<mterry> ev, aha.  I see them now, I'm an idiot
<ev> mind is a bit mush as we're near the end of the day
<ev> no, entirely my fault there
<ev> it's confusing
<mterry> ev, I had launchpad=false in the URL.  ahem
<ev> that would do it as well :)
<ev> launchpad=false isn't necessary anymore by the way
<ev> it asynchronously loads the data from launchpad now
<mterry> ev, yeah, seems snappier
<mterry> ev, OK, so best way to link to an existing bug for someone like me seems to be to intentionally create a dup, then mark it as such.
<mterry> ev, though then the page doesn't "follow the link" of the dup and use appropriate strikethrough or highlighting
<ev> mpt: ^ remind me, did you have any thoughts on what the interface should look like for linking to an existing bug
<ev> just "[create ] [ link ]" maybe?
<mpt> ev, not really, except that it should look more different to a bug number than it does now :-)
<mpt> (a chain icon? A "+" symbol?)
<mpt> (or maybe both, one for Create and the other for Link)
<ev> okay
<ev> https://bugs.launchpad.net/errors/+bug/1061049
<ubottu> Launchpad bug 1061049 in Errors "We should allow users to manually input a linked bug and better present both the create and link options" [Undecided,New]
<mdeslaur> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Beta 2 released! | Archive: Frozen | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: herton
<Darxus> Is there a bzr branch containing the source for the released gtk packages anywhere?  An lp: branch of https://launchpad.net/ubuntu/+source/gtk+3.0/3.6.0-0ubuntu2 is exactly what I'm looking for, but I don't see it there.  Trying to do an automated daily build.
<micahg> Darxus: should be lp:ubuntu/gtk+3.0
<Darxus> micahg: That seems reasonable, but looks out of date.  Last update is in August, and there have been a bunch of releases since:  https://code.launchpad.net/~ubuntu-branches/ubuntu/quantal/gtk+3.0/quantal
<micahg> lp:ubuntu/quantal-proposed/gtk+3.0 ATM
 * micahg wonders if it's a UDD bug
<mitya57> Darxus: also lp:~ubuntu-desktop/gtk/ubuntugtk3
<mitya57> (debian-dir-only)
<micahg> the desktop branch might be better
<Darxus> Yeah, I know about the ubuntu-dekstop branch, but still need the upstream source.
<Darxus> micahg: lp:ubuntu/quantal-proposed/gtk+3.0 also hasn't been updated since 2012-08-22.
<micahg> Darxus: http://package-import.ubuntu.com/status/gtk+3.0.html#2012-09-06%2020:27:25.211657
<Darxus> micahg: So lp:ubuntu/gtk+3.0 *should* have it, but the import is broken?
<micahg> seems like it
<Darxus> Thanks.
<Darxus> Just like when I wanted to use the same stuff for spamassassin.  That was exactly what I was looking forward to / remembered, thanks.
<infinity> soren: *pokity poke*
<infinity> soren: Your qemu-kvm/precise upload for bug 997978 was superseded by a security upload with the same version.  Could you re-base and re-upload?
<ubottu> Launchpad bug 997978 in qemu-kvm (Ubuntu Precise) "KVM images lose connectivity with bridged network" [High,In progress] https://launchpad.net/bugs/997978
<infinity> soren: And while you're at it, fix the LP: #1234 ref in the changelog so it actually lands in .changes (you missed the # character last time)
<ubottu> Launchpad bug 1234 in Launchpad itself "Gina is an unmaintainable mess of command line options, environment variables and shell scripts" [Medium,Fix released] https://launchpad.net/bugs/1234
<infinity> ubottu: I hate you so much right now.
<ubottu> infinity: I am only a bot, please don't think I'm intelligent :)
<Darxus> Heh.
<zyga> hi
<zyga> I need some help
<zyga> on quantal current
<zyga> both my machines are borked on boot
<zyga> not getting to lightdm
<zyga> lightdm itself works
<zyga> but my screen is blank black on (fglrx/radon hd5450) and black+console text (gma500)
<zyga> I have no idea what is crashing
<zyga> X is not
<zyga> as on fglrx/desktop I can run X alone and see cursors working
<zyga> I suspected lightdm or unity greeter
<zyga> but I don't knwo how to debug those
<zyga> any hjnts please?
<sarnold> zyga: do you have ssh? is there anything interesting in /var/log ?
<zyga> I'm logged in to both macines via console
<zyga> syslog, not much, let me re-check
<zyga> ok, watching syslog now, I'll restart lightdm
<sarnold> zyga: how about /var/log/Xorg.0.log?
<sarnold> (or the other displays...)
<sarnold> any EE lines? WW lines?
<zyga> syslog -- nothing acpid and backlight noise
<zyga> checking x
<zyga> upon starting I briefly switch to vt7
<zyga> then screen goes blank and reverts to vt7
<zyga> in text mode
<zyga> sarnold: it ends with 'server terminated sucessfully'
<zyga> sarnold: I'm not sure how this part of boot works
<dobey> is there any where to see an overview of package sets in ubuntu, showing the status of all the packages in that set?
<micahg> dobey: define status?
<sarnold> zyga: hrm, maybe your session starts, dies, and then X quits as it expects a short session to do?
<zyga> ok
<zyga> what gets started?
<zyga> can I check any config files
<zyga> and run it myself?
<dobey> micahg: currently accepted versions in ubuntu at least would be a good start. unapproved queue and all would be nice too of course
<sarnold> zyga: how about ~/.xsession-errors ?
<zyga> is that still managed with xsession?
<dobey> zyga: on the gma500, switch to vt1, log in, service lightdm restart
<zyga> dobey: it does not help, I'm using this gma500 daily and it was working just fine
<dobey> zyga: my gma500 laptop does the same thing since precise. and on it lightdm seems to show on only half of the screen until i restart it
<zyga> dobey: on quantal it actually got usable :)
<infinity> dobey: I know of no such report.
<zyga> sarnold: so, gnome-panel crashes
<dobey> zyga: i just upgraded to quantal on that machine, and no change. does the same thing for me :)
<dobey> infinity: ok, thanks
<zyga> actually there's a lot of errors there
<zyga> I need to have a look
<micahg> dobey: something like this? https://launchpad.net/ubuntu/quantal/+uniquepackages?field.name_filter=&field.package_type=all&field.package_type-empty-marker=1&field.packageset=146 (
<micahg> dobey: that's ubuntu specific packages though
<cjwatson> sigh, webkit/armel failed again
<cjwatson> Laney: ^0
<zyga> dobey: which machine do you have?
<dobey> zyga: fujitsu u820
<dobey> micahg: something like that, yeah. would be nice to have that work on all series too, and not just one at a time; but it's a start :)
<zyga> dobey: hmm, I don't know that model, I'm using second gen vaio-p
<dobey> zyga: it's not a common laptop. it's a 5.6" ultra-portable :)
<zyga> dobey: I'll have to look it up, neither is mine, it's rather cool form-factor wise :)
<dobey> yeah, just remembered the P is the 1600x900 weird one
 * zyga uses an ipad to browse the web while some packages get downloaded 
<dobey> err, 1600x800 even
<zyga> 1900x768 IIRC
<zyga> er
<zyga> 1600x768
<dobey> the one that looks like a wallet :)
<micahg> slangasek: are you uploading all the metas or just ubuntu desktop for the pam-xdg support?
<slangasek> micahg: was only uploading ubuntu-meta; I don't know what else other teams might have staged
<micahg> ok, thanks
<infinity> cjwatson: I think this is now down to trying to debug why the buildds hate us, rather than fiddling more and more with packaging.
<infinity> cjwatson: I need to try to reproduce this locally, probably, since puppetting GSA through endless procfs tweaks to test in production sounds like it would get annoying to both of us pretty quickly.
<Laney> Bah, yeah, probably for the best.
<bryceh> is there a comprehensive listing of all the .deb's present on the precise ubuntu desktop image?
<micahg> bryceh: manifest file?
<micahg> wait, debs?
<bryceh> micahg, well, the question is what packages are included in a generic ubuntu install as of 12.04.1
<micahg> hrm, do an install then grab dpkg -l?
<micahg> the manifest has what's in the squashfs AIUI
<micahg> but that's not the same as installed
<xnox> bryceh: and it depends on the installation type: langpacks, detected hardware, whether network was available and install updates was ticked as well as whether third-party proprietary was ticked.
<cjwatson> infinity: OTOH I see qt4-x11 finally managed to build
<infinity> cjwatson: Yeah, via magic or sheer luck.
<infinity> cjwatson: I think that was the second try for both arches.
<ScottK> I think armel went in one try, but I'm not sure.
<Laney> pretty sure it did
<barry> dobey: ping, re: bug 711162.  is this really a bug in dbus-python or can i remove the dbus-python bug task?
<ubottu> Launchpad bug 711162 in dbus-python (Ubuntu Quantal) "ubuntuone-login crashed with ValueError in call_async(): Unable to guess signature from an empty dict" [Medium,Confirmed] https://launchpad.net/bugs/711162
<infinity> ScottK: Right, looking at the build timestamps, looks like armel went in one go, armhf took two.  So, sort of progress, but not really. :P
<ScottK> A win is a win.
<infinity> (At least it's built for now)
<ScottK> But yeay, it could be better.
<infinity> ScottK: Yeah, it's only a win from my perspective if we can reproducibly build the thing. :/
<dobey> barry: i think it should probably be considered a bug in it. dbus should know the expected signature for the method being called already, and should be able to coerce an empty dict to match the method's signature. at least, that's how i'd expect the dbus API to work
<dobey> barry: we've worked around it in u1 for now, but it might come up again in the future elsewhere. but it's your call if you want to drop dbus-python from that
<barry> dobey: cool.  let me see if i can boil it down into something reportable upstream.  i'll leave the bug task alone for now
<ScottK> infinity: Do you have an ETA in -proposed for the redo of your eglibc SRU?
<infinity> ScottK: Today.
<ScottK> Thanks.
<barry> dobey: on further examination, i'm going to remove the bug task.  this isn't a bug in dbus, it's a deliberate refusal to guess when not enough information is available.  e.g. this comment:
<barry> /* No items, so fail. Or should we guess "a{vv}"? */
<barry> dobey: so, i suppose it would be a wishlist to do that guess, or an upstream bug in the documentation that signatures of empty dicts cannot be introspected.
<dobey> barry: well i wouldn't say it guesses. it introspects the signature from the method being called, is my understanding. but i'm not going to bother arguing with upstream about it. like i said, do what you will. :)
<barry> dobey: right, but in the case of empty dicts, introspection doesn't provide enough information to know the mapping.  so the refusal to guess is pythonically zen :)
<dobey> barry: no, i don't mean introspecting from the caller. i mean introspecting from the server side. ie, it already knows the expected signature is ia{ss} or whatever for example. it could then coerce {} to be {"", ""} or just send whatever an acceptable equivalent is to mean empty. of course, if dbus has no way to send empy values at all, that's another issue.
<dobey> but again, not a huge deal
<dobey> just really annoying
<barry> dobey: cool
<Daviey> mdeslaur: dbus doesn't run it's test suite at build time?
<mdeslaur> Daviey: I don't believe they work on the buildds, they require X and a bunch of stuff IIRC
<Daviey> mdeslaur: ahh
<mdeslaur> Daviey: I haven't looked closely at it though
#ubuntu-devel 2012-10-04
<infinity> soren: Don't worry about rebasing that qemu-kvm SRU, I just did it for you.
<TheMuso> ?C
<herton> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Beta 2 released! | Archive: Frozen | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<ScottK> doko__: kmediafactory in the rebuild could be retried.  I think it'd work.
<pitti> Good morning
<cjwatson> ScottK,doko__: retried kmediafactory
<pitti> cjwatson: hm, do you see what's wrong with this command?
<pitti> copy-package -b -s oneiric --ppa-name ppa -p ubuntu-langpack --to-suite=oneiric-proposed language-pack-{,gnome-,kde-}se{,-base}
<pitti> cjwatson: it always fails with "400 Bad Request: name: Required input is missing"
<pitti> same with just one package name
<cjwatson> PPAs don't have -proposed; are you trying to copy to the primary archive?
<pitti> no, from langpack PPA to the real oneiric-proposed
<cjwatson> So "yes" then
<cjwatson> Try --to-primary
<pitti> but I didn't specify --to-ppa*
<cjwatson> It defaults to the source archive
<pitti> ah
<cjwatson> Note, this is different from the old copy-package.py
<pitti> thanks
<gsedej_work> hi! Is it ok to report bug "missing logout option" in 12.10 live?
<darkxst> gsedej_work, that will be fixed in the next images (if you are talking about ubuntu gnome remix)
<gsedej_work> darkxst, I don't see "logout" in ubuntu unity
<gsedej_work> live
<gsedej_work> I have big problems for testing KDE in 12.10
<gsedej_work> Or is it just me not seeing option "logout" in top right corner (LiveCD/USB)
<darkxst> unity disables logout on livecd
<darkxst> (well indicator-session does)
<darkxst> but it should return it you add another user (or rename the ubuntu user)
<gsedej_work> darkxst, thanks for explanation, but this still complicates very much the way to test other DE
<gsedej_work> I had to install kdm and use it
<gsedej_work> lightdm config was not permanent, it was always rewritten
<cjwatson> wookey: gdbm from your aarch64 config.guess/sub patch stack seems to be unnecessary; debian/rules copies in current versions from /usr/share/misc/ on every build
<wookey> cjwatson: OK, sorry missed that
<wookey> good for it :-)
<wookey> if only everything did that...
<cjwatson> wookey: I'm getting there with this set; just dropbear, expat, libgpg-error, libx11, libxml2, libxslt, make-dfsg, pcre3, and slang2 to do
<cjwatson> keeping track by way of visited link colours :)
<wookey> cjwatson: I've got some aarch64 fixes for linux-3.5.0 so that it makes a source package suitable for cross-toolchain building
<wookey> I'm assuming that's not the sort of change you'll want to be putting in at this stage
<cjwatson> wookey: nooooooooooo
<cjwatson> wookey: but in any case, send them to the kernel team
<cjwatson> I'm definitely not going to be uploading linux independently :)
<wookey> yeah, I'll file a bug with the patch soonish (still hacking eglibc to work)
 * cjwatson looks deeply confused at libgpg-error
<cjwatson> $ cat debian/source/format
<cjwatson> 3.0 (quilt)
<cjwatson> $ ls debian/patches/
<cjwatson> 00list                 06_Makefile.in.dpatch   m4_macros.dpatch
<cjwatson> 05_Makefile.am.dpatch  10_relibtoolize.dpatch
<cjwatson> Just when you think you've seen all the weird ways people construct packages
<ogra_> well, it has error in the name ...
<mlankhorst> m is a number right? :P
<ion> m4 is a perfectly cromulent base-64 number.
<ion> err, base-36
<ogra_> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Beta 2 released! | Archive: Frozen | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: ogra_
<cjwatson> mlankhorst: that's the least of the problems ...
<mlankhorst> or maybe I'm selectively blocking horrors so I don't have to worry about it
<tjaalton> dpatch with 3.0 (quilt), lovely
<mlankhorst> not listening! :o
<xnox> cjwatson: I had sponsoree package without source/format specified (that is 1.0) with bzr-bd branch with quilt patches applied. Seeing .pc dir in diff.gz was natural to me.... until it was not bzr log of a udd branch =)
<cjwatson> jamespage: I've noticed several Java packages failing to build because of missing javax.http.servlet.  The fix seems to be to build-depend on libservlet3.0-java, but I wanted to check (a) that this was correct (since there are several libservlet*-java) and (b) why this failure seems to be associated with the OpenJDK 7 change
<diwic_> packages who do anything with multiarch should upload to quantal-proposed instead of quantal, right? To ensure safe upgrades for people having both amd64 and i386 versions of the package installed.
<jamespage> cjwatson, odd - can you point me at an example please
<cjwatson> jamespage: openid4java
<cjwatson> diwic_: Theoretically yes; although realistically multiarch is going to be rocky during development releases until such time as we're directing everything to -proposed and handling it automatically
<cjwatson> But it's OK to do so
<diwic_> cjwatson, what's the recommendation?
<cjwatson> Me having noticed this before recommending this morning that jodh use quantal not quantal-proposed for libnih ;-)
<cjwatson> diwic_: -proposed is the conscientious option
<tjaalton> could an archive admin remove libmusicbrainz from quantal, there's lmb-5 that replaced it. would fix bug 1036511
<ubottu> Launchpad bug 1036511 in libmusicbrainz (Ubuntu) "Please remove libmusicbrainz from the archive" [Wishlist,Confirmed] https://launchpad.net/bugs/1036511
 * diwic_ uploads to quantal-proposed for an extra gold star in the booklet.
<diwic_> thanks
<cjwatson> tjaalton: it's in my queue
<tjaalton> cjwatson: oh cool
<jamespage> cjwatson, I think it may have something todo with the switch of tomcat6/7 in main this cycle
 * jamespage refreshes his memory
<cjwatson> tjaalton: done
<tjaalton> cjwatson: thanks
<jamespage> cjwatson, oddness in libcommons-logging-java is the root cause
<jamespage> and the fact that I only transitioned r-b-d's in main to depend on tomcat7
<cjwatson> Ah
<cjwatson> So I should just s/servlet2\.5/servlet3.0/ and move on?
<cjwatson> hm, wait, it doesn't b-d on libservlet3.0-java directly
<cjwatson> libehcache-java Depends: libservlet2.5-java
<jamespage> cjwatson, TBH its a fluke it works
<jamespage> libcommons-logging-java sets a classpath manifest which openjdk which read
<jamespage> which includes servlet3.0.jar
<jamespage> but the package only Suggest's it
<cjwatson>   * Move libservlet2.3-java from Depends to Suggests (Closes: #526043)
<Sweetshark> doko: I assume the vigra stuff is solved now? I would have time to look at it now, but I guess I can dump that now as you already tested it?
<cjwatson> "It is pretty unexpected to have a dep related to servlets on a logging application" says the bug reporter
<jamespage> cjwatson, which is kinda of right
<jamespage> commons-logging is design to work in servlet containers
<jamespage> where the servlet api is 'provided' by the container
<jamespage> so its a build-time only dependency
<cjwatson> I wonder how things like https://launchpadlibrarian.net/117244429/buildlog_ubuntu-quantal-i386.acegi-security_1.0.7-3_BUILDING.txt.gz work
<doko> Sweetshark, lo builds with the new one, as commented in the issue
<jamespage> cjwatson, the correct fix IMHO is to BD in openid4java on libservlet3.0-java (its backwards compat with 2.5)
<Sweetshark> doko: yeah, I also did a ppa build against it in the meantime.
<cjwatson> hrw: I'm confused by your rules changes in gcc-defaults-armel-cross (and presumably armhf but I haven't looked at that yet)
<jamespage> and fix its build process to sort out its own classpath rather than depend on the only partially implemented Class-Path manifest method
<cjwatson> hrw: you have build-arch depending on build-stamp, which now depends on install, which runs dh_testroot
<mterry> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Beta 2 released! | Archive: Frozen | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: ogra_, mterry
<cjwatson> hrw: build-arch is not allowed to require (fake)root, so this looks wrong
<cjwatson> hrw: can you explain the problem you were trying to solve?
<cjwatson> jamespage: OK, that would have been my first instinct, so that's good, thanks
<cjwatson> jamespage: I'll take care of it
<jamespage> cjwatson, ta
<doko> cjwatson, hrw: the previous build failure was caused by calling a binary target in a build target
<doko> (in the test rebuild)
<cjwatson> well, it's not the target names that matter here, it's the use of dh_testroot
<cjwatson> I don't see how this upload will fix that failure
<cjwatson> in general build{,-arch,-indep} should not depend on install-type rules
<hallyn> cjwatson: hi, do you have any objections to the proposed fix for bug 1060404 ?  without some solution, ubuntu-cloud containers can't be updated... (not sure if juju is going to default to ubuntu-cloud conainers during q or not)
<ubottu> Launchpad bug 1060404 in grub2 (Ubuntu) "update-grub runs and fails in containers" [High,Confirmed] https://launchpad.net/bugs/1060404
<hrw> reject it - will rewrite that rules
<cjwatson> hrw: OK, done, thanks
<cjwatson> hallyn: Hmm.  Does /boot/grub/grub.cfg exist when the container is first built?
<hrw> cjwatson: when it comes to cross packages then both armel and armhf have same packaging cause I generate them
<cjwatson> hallyn: I assume not, since you need update-grub to build that
<hallyn> cjwatson: not sure, but i think so, because these are the same cloud images you can use in kvm
<hallyn> cjwatson: yeah, it is there
<cjwatson> Then that means that if you update the image in a container you can't later boot it in kvm
<hallyn> i think we're ok with that.  simply being unable to cleanly update is a bigger problem
<cjwatson> Well, I'm willing to apply that for 12.10, but I don't consider it the right fix.  I'd like to leave a comment that it's temporary, and I'd like to have a bug with the details of what goes wrong when you run update-grub in a containere
<cjwatson> *container
<cjwatson> Because the intent is absolutely that you should be able to run update-grub no matter what
<cjwatson> hallyn: In fact, something along the lines of debian/patches/mkconfig_skip_dmcrypt.patch might be a cleaner approach
<hallyn> that would be nice.  but i dont' think there is a general way grub can know what the root dev should be.
<hallyn> checking
<cjwatson> (That patch may actually be obsolete now with LUKS support, but that aside ...)
<hallyn> yes, something like that.  there will be more than one case to consider...
<cjwatson> Well, it could call running-in-container, even
<hallyn> as long as we're updating grub itself it's worth trying to do better;
<hallyn> it *is* possible to be in a container that is backed by a real rootdev which you're allowed to open;
<cjwatson> It'd be no worse there than in the update-grub wrapper, and I think it might be neater
<hallyn> agreed, but i'm saying for a longer term (13.04) solution ...
<cjwatson> Do you have a log somewhere of the update-grub failure?
<cjwatson> I'd like to see what it's doing
<cjwatson> In particular, which grub-probe command is failing
<hallyn> no, but it's trivial to reproduce.  am on mobile net, need a few mins to spin up an instance
<cjwatson> At this stage, GRUB is only trying to work out the root device in order to work out which modules to include (LVM, RAID, the filesystem, etc.) and to add probing hints to speed things up at runtime
<cjwatson> Even if it can't open the root device, in principle it ought to be possible to set GRUB_MODULES to augment the autodetection, and still have update-grub work
<cjwatson> hallyn: Oh, BTW, I think your patch as written is a no-op due to the unnecessary ``
<cjwatson> Actually maybe not a no-op.  But hard to parse.
<hallyn> oops, yeah that shouldn't be there
<cjwatson> 'type' returns a perfectly good exit code, so you don't need to wrap it in command substitution
<hallyn> hm, pretty quick:
<hallyn> ubuntu@q1:~$ sudo update-grub
<hallyn> /usr/sbin/grub-probe: error: failed to get canonical path of /dev/disk/by-label/cloudimg-rootfs.
<hallyn> (/dev/disk isn't in the container, of course)
<cjwatson> hallyn: Could you put 'set -x' at the top of /usr/share/grub/grub-mkconfig_lib ?  I'd like to see a trace
<hallyn> cjwatson: http://paste.ubuntu.com/1260027/
<cjwatson> hm, right, *very* early
<cjwatson> hallyn: OK, so I would like a separate bug with that trace, but I'll apply a tweaked version of your patch for now then
<hallyn> cjwatson: yeah, but again i guess it just sees '/dev/disk/by-label/cloudimg-rootfs on / type ext4 (rw)' in mount output
<hallyn> cjwatson: so while i would bristle at this, it coudl be lcaimed that th eproblem is the container doesn't have /dev/disk/by-label set up
 * hallyn tries to fake that one
<pitti> doko: not all python crashes are pyobject crashes ... :)
<doko> pitti, no, some are dbus-python too ;-P
<cjwatson> Well, it uses mountinfo, but yes
<cjwatson> But it'd need a fairly complete /dev for it to actually work
<pitti> doko: (j/k; following up with requests for reproducers)
<hallyn> cjwatson: yes, when i mknod /dev/vda1 and thenln that to /dev/disk/by-label/cloudimg-rootfs, update-grub succeeds
<doko> pitti: still wondering why these end up assign to python2.7, because the script name is available ...
<pitti> doko: looking at bug 1036438
<ubottu> Launchpad bug 1036438 in pygobject (Ubuntu) "python2.7 crashed with SIGABRT" [Undecided,Incomplete] https://launchpad.net/bugs/1036438
<pitti> doko: that seems to be a local script (not packaged)
<l3on> Hi guys.. what does the packages you think this bug can be related (see the red rectangle) http://people.ubuntu.com/~l3on/tmp/underscore_replace-bug.gif ?
<pitti> doko: and no useful stuff in the stack trace at all; I'll just ask for a reproducer
<cjwatson> hallyn: hm, so is that doable by default?
<cjwatson> I'd obviously rather not change common code if it's avoidable
<hallyn> well it'll be common code one way or the other.  what we'd do (i think) is have an upstart job (shipped with upstart) which runs if in a container and set up the dev/disk stuff for the rootfs at startup
<hallyn> stgraber: ^
<cjwatson> OK.  Well, personally I prefer that option, but perhaps that's because it doesn't involve changing my package ... can I let you and stgraber hash it out and let me know what you decide? ;-)
<hallyn> cjwatson: absolutely.  thanks, ttyl
<cjwatson> I have your patch ready to commit if that's what you opt for
<hallyn> thanks (i think the attached version stupidly left out the 'LP:' tag fwiw)
<mterry> cjwatson, I'm seeing an SRU bug in the sponsor queue that you uploaded to quantal and have assigned to you for precise.  (bug 978654)  Did you upload already?  Else, I'd be happy to upload
<cjwatson> Yeah, I have that locally
<ubottu> Launchpad bug 978654 in aptdaemon (Ubuntu Precise) "aptd crashes when PPAs have non-ascii descriptions" [Medium,Triaged] https://launchpad.net/bugs/978654
<cjwatson> mterry: I didn't upload, and the assignment was mostly a reminder to get back to it after 12.10 (I don't plan to do much SRU work before then).  Feel free to take it
<mterry> cjwatson, k
<cjwatson> mterry: (But please use the patch I uploaded rather than the previous incorrect ones in the bug)
<mterry> cjwatson, yes
<ogra_> hmm, no alkisg
<ogra_> cjwatson, i dont realy understand the bug status for bug 978654 ... your barnch has been merged into precise-poposed the top-level task is fix released but there is still a precise task in triaged state ?
<ubottu> Launchpad bug 978654 in aptdaemon (Ubuntu Precise) "aptd crashes when PPAs have non-ascii descriptions" [Medium,Triaged] https://launchpad.net/bugs/978654
<ogra_> *branch
<ogra_> should that be closed or should tehere be a quantal task  ?
 * hallyn wonders whether grub_find_root_devices_from_mountinfo should be provided by a tiny general library
<ogra_> oh, the upload actually wnet to quantal, its just the branch naming thats confusing
<cjwatson> ogra_,mterry: ... oh, maybe I did upload that
<cjwatson> mterry: Sorry, yeah, that's actually waiting for approval in precise-proposed
<cjwatson> There's something of a backlog
<mterry> cjwatson, ah ok.  I'll mark as in progress then I guess
<cjwatson> Yeah, please
<ogra_> mterry, oh, we clashed
<cjwatson> Sorry for the confusion
 * ogra_ didnt read backlog :)
<mterry> ogra_, ah yes, both on sponsor duty.  Shall I go from the bottom?
 * ogra_ decides to rather work from the bottom of the list upwards then :=)
<mterry> heh
<ogra_> first !
 * mterry works from the top
<cjwatson> doko: So, you were asking why these amd64 build-arch failures weren't showing up in Debian; well, I just ran across one that does: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=666307
<ubottu> Debian bug 666307 in src:htp "htp: FTBFS: snprintf.c:856:2: error: incompatible types when assigning to type 'va_list' from type 'struct __va_list_tag *'" [Serious,Open]
<cjwatson> The package is orphaned so I think I'll fix that in a QA upload
<doko> cjwatson, hmm, but that's not related to dpkg-dev?
<ogra_> wookey, your patch to bug 1056975 is for precise only but there is no precise SRU task ... i'll upload it into quantal (with the series adjusted) could you take care of the paperwork to also have it in precise ?
<ubottu> Launchpad bug 1056975 in libsepol (Ubuntu) "libsepol fails to cross-build" [Undecided,New] https://launchpad.net/bugs/1056975
<cjwatson> doko: Sure it is, it's dpkg-dev now choosing to use build-arch
<cjwatson> And the package having 'build: patch' in debian/rules, but a % target which means that build-arch doesn't apply patchces
<cjwatson> *patches
<cjwatson> Sane fix in this day and age is to convert to 3.0 (quilt), which I'll do
<doko> ahh, ok
<doko> yes, did the 3.0 conversion for another package too
<Laney> not sure the release team will like that, if you plan on asking for an unblock
<cjwatson> Laney: *shrug* it's simpler than any other fix, and the package already uses quilt
<cjwatson> I'm happy to argue that with them directly
<cjwatson> Laney: But as it happens the package in question has already been removed from testing, so I don't see a need to have that debate
<Laney> Good. I didn't check
<mlankhorst> cjwatson: does initramfs-tools have a git repository for ubuntu?
<cjwatson> mlankhorst: No
<cjwatson> mlankhorst: bzr - lp:ubuntu/initramfs-tools
<mlankhorst> ah k
<cjwatson> It's in a weird state at the moment due to a cherry-pick with an odd version number
<cjwatson> But should be usable
<xnox> mlankhorst: if in daubt, ask infinity =) he should know.
<cjwatson> So should I :-P
 * cjwatson <- last uploader
<xnox> cjwatson: well you generally don't cause confusion with cherry-picks
 * xnox can still blame infinity =)
<cjwatson> No, but I understand the reason for this one
<xnox> ah, ok.
<mlankhorst> cjwatson: what about sru's for precise, are they tracked in a separate bzr branch?
<cjwatson> mlankhorst: I'd assume the usual naming scheme but don't especially care about bzr branches for SRUs :-)
<cjwatson> Don't worry about it - the importer will take care of it
<mlankhorst> I wanted to sru the fix for #1017991, and add any other drivers that are similarly missing, I need hid-logitech-dj for my keyboard
<mlankhorst> bug #1017991
<ubottu> Launchpad bug 1017991 in initramfs-tools (Ubuntu) "Keyboard stops working after completing 'Check disk'" [Undecided,Fix released] https://launchpad.net/bugs/1017991
<cjwatson> just prepare a source package or whatever
<mlankhorst> yeah k
<mlankhorst> off for a bit, will do it tomorrow :)
<jamespage> barry, thanks for fixing that FTBFS in genshi
<ogra_> mfisch, lookin at your merge at bug 1054353, seems you missed to use -v  4ubuntu1 when generating the patch for xfonts-mathml-6 ... could you fix that ? then i'll upload
<ubottu> Launchpad bug 1054353 in xfonts-mathml (Ubuntu) "merge xfonts-mathml 6 (main) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/1054353
<barry> jamespage: np.  not sure the way i did it is what upstream will eventually adopt, since i'm not sure what the intent is for those previously failing examples.  but hey, at least it gets built now :)
<mfisch> ogra_: let me look
<ogra_> the second patch looks ok
<mfisch> ogra_: -v when running debdiff?
<cjwatson> err, yeah, -v is something the sponsor does when building the source package
<ogra_> no, when generating the source package
<cjwatson> you should be building it yourself
<ogra_> cjwatson, oh, i always ask for that in the debdiff too
<cjwatson> based on the submitter's patch
<cjwatson> why?
<cjwatson> there's no need for a patch submitter to worry about this
<ogra_> for completeness and to train good habits :)
<ogra_> ok
<ogra_> i'll move on with it as is then
<mfisch> I'll try to do that next time if it's helpful in the process
<ogra_> mfisch, well, its only helpful to have it in your finger-memory once you upload the merges yourself
<mfisch> ogra_: understood
 * ogra_ glares at all these misc depends merge requests  
<ogra_> do we really want to add that in ubuntu ? it should go to debian, no ?
<micahg> ogra_: they should be for Ubuntu only packages, but probably shouldn't be a priority at this point in the release unless they're actually adding something to the package
<Laney> ogra_: you can just merge them to the packaging branch and leave it unreleased
<Laney> in theory that gets it included next time ... ahem.
<ogra_> if MoM is clever :)
<stokachu> ogra_, mterry : could either of you sponsor https://launchpad.net/bugs/1036834?
<ubottu> Launchpad bug 1036834 in gdb (Ubuntu Precise) "gdb should be marked "Multi-arch: allowed"" [High,In progress]
<micahg> which since these are most likely neglected packages as well, will result in yet another merge proposal
<stokachu> it is a pretty easy one
<ogra_> stokachu, yeah, just looked into it and then fell over when i downloaded the source package :P
<stokachu> lol
<ogra_> i'll get to it
<stokachu> ok cool, thanks a bunch
<pitti> ev: just looked at your recent apport commit; is df.data.tgz() actually going to work for bz2 and xz compressed .debs as well?
<ogra_> argh
<ev> pitti: seems to
<ev> I think it's just a poorly named function
<cjwatson> mterry: ah, hooray for your aptitude merge
<mterry> :)
 * cjwatson scratches an item off his to-do list
<barry> doko: i think the b-d conflict that was causing claws-mail-extra-plugins to ftbfs in your test rebuild has been resolved with a new upload of libgdata.  i can't do a retry, not sure if you can, or if its worth it
<doko> barry, given back
<barry> doko: thanks.  i'll keep an eye on it, but i think bug 1060489 is resolved
<ubottu> Launchpad bug 1060489 in claws-mail-extra-plugins (Ubuntu) "FTBFS due to build-dep conflicts" [High,Invalid] https://launchpad.net/bugs/1060489
<ogra_> stokachu, :/ ... the build-deps are totally messed up in the gdb patch
<ogra_> ...  mig [], cdbs (>= 0.4.17), libkvm-dev [], ....
<ogra_> something seems to have wiped all traces of hurd
<ogra_> butu left the packages and brackets in place
<stokachu> wow, how did that happen
<ogra_> stokachu, i assume you didnt mean to touch them, right ?
<stokachu> yea i just changed one line in the control file
<stokachu> ogra_: thats so odd, the debdiff's show a changelog entry and a one line change
<stokachu> oh wtf
<stokachu> the precise shows the build-depends
<stokachu> ogra_: honestly i have no idea how that happened
<stokachu> the build-depends shouldnt have been touched, want me to generate a new debdiff?
<ogra_> well, there seems to be some control.in processing
<stokachu> quantal looks fine, however
<stokachu> lemme regenerate the precise debdiff
<stokachu> ogra_: so odd, i change the control.in file and when i generate the source it alters the build-depends
<hallyn> ok what am i doing that's silly?
<hallyn> MAKEDEV -n vda1
<hallyn> /sbin/MAKEDEV: don't know how to make device "vda1"
<sarnold> my precise MAKEDEV doesn't know vda either
<hallyn> drat
<hrw> doko: checking 4.5/cross - maybe will update it instead of removing
<hallyn> course vda1 would be wrong anyway :)  'sd' works, 'sda1' does not
<stokachu> is altering control.in deprecated now?
<hallyn> well if makedev needs a patch to know about vda, then i'm afraid that brings me over the 'wait for 13.04' threshold
<ogra_> stokachu, i guess that needs some hint from doko or hrw
<mitya57> barry: how do you feel about uploading py3-defaults snapshot (something like 3.2.3-5+bzr171) into quantal?
<mitya57> (or do you think we can SRU that / ignore those bugs?)
<hrw> hallyn: devtmpfs.mount=1 and ignore any makedev
<stokachu> doko,hrw: should i be altering control.in for gdb?
<hrw> stokachu: yes, cause debian/control at one day will be regenerated
<stokachu> hrw: when altering control.in in precise and regenerating the debdiff https://launchpadlibrarian.net/116712597/gdb_7.4-2012.04-0ubuntu2.1.precise.debdiff
<stokachu> that is the result where it alters the build-depends
<hrw> ugly indeed
<wookey> cjwatson: libxslt and libxml2 also use dh --with autoreconf, so my bugregreps are null. And libx11 autoreconfs every time too.
<wookey> The others seems to remain valid.
<cjwatson> Ah, good.  Yes, I've been checking for autoreconf
<hrw> stokachu: leave original b-d than
<stokachu> hrw: should i copy the original b-d over to the control.in and build patch for that as well
<hrw> stokachu: in control.in you only added m-a line. add it by hand to control
<hallyn> hrw: may or may not be an option.
<hrw> stokachu: I would have to check packaging but not today
<stokachu> hrw: ok
<stokachu> hrw: would you like me to create a bug on it?
 * micahg would think that you'd add it to control.in and regenerate control
<stokachu> yea adding it to control just gets overwritten during source packaging
<hallyn> hm, but yeah, just putting devtmpfs in the container fstab (so it gets mounted before apparmor restrictions) may be working
<stokachu> http://paste.ubuntu.com/1260320/ - this is what is generated now when updating control.in
<stokachu> properly alters control to just change the multi-arch and updates the b-d in control.in
<stokachu> question is do you want this separated out or have the control.in modifications included
<stokachu> i can certainly create a new bug with the control.in patch
<tjaalton> slangasek: ping re bug 804109
<ubottu> Launchpad bug 804109 in acpi-support (Ubuntu) "drop synaptics from racy /etc/acpi/asus-touchpad.sh" [Medium,Triaged] https://launchpad.net/bugs/804109
<micahg> stokachu: well, if an empty variable is bad there, just fix debian/rules to make the substitution work properly in Ubuntu as well (or put some sane value there)
<doko> slangasek, stokachu: libgnome MA upload was rejected by stgraber, missing a FFe. is the FFe now done?
<micahg> stokachu: I mean empty brackets
<hrw> stokachu: I logged into precise, fetched gdb/precise, changed debian/control.in to add m-a line. then 'debian/rules debian/control -B' and debian/control had only m-a added, rest was same
<stokachu> hrw: ok i was running a bzr ci; bzr bd -- -S -us -uc
<stokachu> doko: one sec
<stokachu> doko: FFe for precise?
<stokachu> doko: it says libgnome is fix released in quantal
<hrw> stokachu: I do not use bzr for such things
<hallyn> cjwatson: ok, so if the ubuntu templates cause devtmpfs to be mounted before the container init starts, update-grub succeeds.  However then you're annoyingly prompted whether you want to install grub in /dev/vda1 (as it hasn't been installed yet)
<hrw> stokachu: basically I do not use bzr at all nowadays
<hallyn> if you say yes, it fails.  if you say no, it happily continues
<stokachu> hrw: ok so you are saying this is not a bug then?
<hallyn> i guess we can be happy with that for q, but for r it woudl be nice if grub woudl say "oh, but i can't write to /dev/vda1" (cgroup prevents it) and then shut up
<doko> stokachu, hmm, which lib was the other one?
<stokachu> doko: https://bugs.launchpad.net/ubuntu/+source/libgnomecanvas/+bug/1013211
<ubottu> Launchpad bug 1013211 in libgnomecanvas (Ubuntu Precise) "[FFe] Please transition libgnomecanvas to multi-arch" [High,In progress]
<stokachu> that has the ffe
<stokachu> which *i think* is done
<cjwatson> hallyn: Well, that relates to grub-install rather than update-grub; I expect that's fixable ...
<cjwatson> I'm not totally sure writability is the right test; tricky to establish in advance of asking the question
<hallyn> cjwatson: agreed, i'm also not sure :)  but offhand it feels right;  if i'm not allowed to write to it, no sense trying to install grub to it.  we can discuss that at uds or around that time?
<cjwatson> I don't see a need to wait :)
<cjwatson> So GRUB hasn't been installed *anywhere* yet?
<hallyn> nope
<doko> stgraber, stokachu: hmm, then why was it rejected? don't see a comment from the release team either
<hallyn> it's a container running in a chroot
<hallyn> i mean yes, it has been installed on /dev/vda (for the amazon instance itself), but not on /dev/vda1 (which has '/' for the container)
<cjwatson> Right, as far as the postinst is concerned that means it's been installed somewhere
<stokachu> doko: no idea :)
<cjwatson> Because /boot/grub/{,*/}core.img will exist
<cjwatson> I suppose we could just skip the whole grub-install path in a container
<cjwatson> Bit nasty but maybe tolerable
<cjwatson> And no worse than skipping update-grub in a container, possibly better
<hallyn> hold on, i'mnot convinced core.img exists in the container, checking
<stokachu> hrw: no idea then i ran your command and it still alters the build-depends on debian/control
<cjwatson> Well, from the code, either it exists, or grub-pc is being installed from scratch
<hallyn> cjwatson: nope, doesn't exist
<cjwatson> Huh
<cjwatson> That's truly bizarre
<hallyn> why?
<cjwatson> Because in that case you shouldn't be asked that question
<hallyn> it could exist if utlemming left it int he cloud tarballs,
<cjwatson> It's only asked if:
<hallyn> huh
<cjwatson>  1) grub-pc is being installed from scratch
<stokachu> ogra_: if i attach the debdiff http://paste.ubuntu.com/1260320/ do you want that in two separate patches and a bug for the control.in or will you accept both changes
<cjwatson>  2) There's already a core.img
<cjwatson>  3) We're upgrading from GRUB Legacy
<cjwatson>  4) The postinst thinks it's running inside Wubi
<cjwatson> None of which AIUI should hold here
<cjwatson> (There are other conditions as well, but that's the disjunction at the top)
<cjwatson> Any way to get set -x output from grub-pc.postinst?
<ogra_> hrw, if you say fetched above, how did you fetch ? apt-get source (as i do here) ?
<hallyn> cjwatson: perhaps grub-pc isn't installed yet  (checking)
<cjwatson> hallyn: That would raise the question of why something thinks it's a good idea to install it, then :-)
<hallyn> hm, no, it is installed
<ogra_> stokachu, fine as is i think
<stokachu> ogra_: ok i attached an updated debdiff
<hallyn> oh, there it is.  /boot/grub/i386-pc/core.img.
<hallyn> oh i get it - apt-get update had deleted that perhaps.  it's there ina  newly created container
<ogra_> stokachu, yep, looking at it already
<stokachu> this allows me to run bzr bd -- -S -us -uc a
<stokachu> this was the way i was told to do it so if there is another way im all ears
<hallyn> cjwatson: so i've lost your train of thought :)  if core.img does exist, you think our best option is what at that point?  not run grub-install?
<cjwatson> hallyn: My suggestion was that we do something similar here to what you were proposing for update-grub; that is, bypass the entire code path that deals with figuring out where to install GRUB and then running grub-install in the event that we're running in a container
<cjwatson> (But I have to go for dinner nowish)
<hallyn> cjwatson: ok, would you prefer to chat later, or to have me push an attempt to my grub branch?
<cjwatson> hallyn: I was going to suggest something like http://paste.ubuntu.com/1260370/
<cjwatson> Maybe try that out by local editing or something to see if I'm vaguely close :)
<cjwatson> But will need to talk later anyway
<hallyn> cjwatson: ok thx, ttyl
<hrw> ogra_: apt-get source gdb
<stokachu> you know what would be awsome, if there were quake sounds embedded into the LP comments if a package was accepted or rejected
<ogra_> hrw, good then
<hrw> ogra_: you use other way?
<ogra_> hrw, nope, same
<ogra_> EEK
 * ogra_ better re-rolls the gdb fix without -sa attached to dpkg-buildpackage 
<ogra_> :P
<barry> doko: looks like the retry worked.  thanks
<zyga> pitti: hi
<zyga> pitti: quick question, python3-pyudev, can we ship it on the cd?
<zyga> pitti: it's whooping 30KB in size
<sarnold> zyga: I believe he went to bed an hour ago..
<zyga> sarnold: never hurts to ask :), I'll grab him tomorrow
<sarnold> zyga: indeed :)
<zyga> which timezone is he in BTW? I thought he was in Europe
<sarnold> I've assumed Germany's TZ, +1 ...
<roaksoax> cjwatson: howdy!! in debian/maintscript -> is the version listed there, such as "rm_conffile /etc/init/maas-celery.upstart 0.1+bzr1170+dfsg-0ubuntu1" is the last version of the package that contained that file
<ogra_> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Beta 2 released! | Archive: Frozen | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mterry
<ogra_> (oops, had totally forgotten)
<hallyn> cjwatson: http://paste.ubuntu.com/1260370/ seems to be working (if i'm testing this right)
<hallyn> ttyl
<cjwatson> roaksoax: 'man dpkg-maintscript-helper' has an exact specification
<roaksoax> cjwatson: got it alreayd, thanks though :)
<cjwatson> hallyn: OK - if I don't hear further from you I'll upload that tomorrow morning, then
<hallyn> cjwatson: thanks!  I'll upload the new lxc to do the devtmpfs mount in the meantime
<hallyn> stgraber: are you around?
<infinity> kirkland: *nudge*
<infinity> kirkland: That sks upload to precise-proposed was an oops, I assume?
<infinity> kirkland: Since what you were fixing was something in precise-backports, which could just be done with a new backport.
<radix> jml: so, the conditional in undistract-me's profile.d script seems to be causing it to exit for me
<kirkland> infinity: hmm, well, I do want to fix this in precise-proposed;  looks like I grabbed the wrong base package to work from (from backports, rather than from updates)
<infinity> kirkland: Okay, if it needs fixing in updates as well, please do, but with the right base. ;)
<kirkland> infinity: yep, good catch
<kirkland> infinity: okay, just re-uploaded with the right base
<bryceh> kirkland, heya
<infinity> kirkland: Thanks, accepted.
<darkxst> how can I enable debug logging for indicator session?
<mterry> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Beta 2 released! | Archive: Frozen | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<trism> darkxst: indicator-applet in a gnome-panel session logs the indicator debug messages to ~/.cache/indicator-applet-complete.log (don't know how to get that output in unity, though if anyone does I'd be interested)
<darkxst> trism, thanks
#ubuntu-devel 2012-10-05
<bryceh> doko_, I've chased down fixes for the three nvidia build failures you mentioned a while back.  Two are basically due to unresolved differences in packaging strategy between us and debian (see bug #950963), but the packages in question have been fixed to work with ubuntu, and now build.
<ubottu> Launchpad bug 950963 in viennacl (Ubuntu) "nvidia-graphics-drivers needs to provide separate packages such as libcuda1" [High,Confirmed] https://launchpad.net/bugs/950963
<bryceh> dobey, the third build failure I located a fix and worked with debian on getting a fix.  Debian's 2.0.8-1+dfsg-3 includes this fix, and I'll sync it to quantal once LP picks it up.
<bryceh> damn tab completion
<bryceh> sorry dobey.
<bryceh> doko_, bug #1061969 tracks the sync request for that issue.
<ubottu> Launchpad bug 1061969 in nvidia-texture-tools (Ubuntu) "Sync 2.0.8-1+dfsg-3 to fix FTBS" [Undecided,New] https://launchpad.net/bugs/1061969
<bryceh> doko_, you also asked me to look into the vnc4 issue.  I investigated this and figured out what's wrong.  Looks like the fix is to backport some of the arm support from xorg-server to vnc4's embedded copy of xserver.  See bug #945368 in ubuntu and debian #621409.
<ubottu> Launchpad bug 945368 in vnc4 (Ubuntu) "vnc4 version 4.1.1+xorg4.3.0-37ubuntu4 failed to build on armhf" [High,Confirmed] https://launchpad.net/bugs/945368
<ubottu> Debian bug 621409 in src:vnc4 "vnc4: FTBFS on armel: macro 'in' not recognized -- ignoring" [Important,Open] http://bugs.debian.org/621409
<bryceh> doko_, unfortunately I'm starting another project and won't have further time to work on it.  I think the porting work should be straightforward C hacking, so really anyone could do it.  I was hoping Debian would take care of it for us since it's a bug on their end, but not so far.
<infinity> bryceh: And by "backport", you mean "stop having an ancient embedded copy of X in vnc"?
<bryceh> infinity, no I mean cut and paste the #ifdef arm bits from the shiny new xserver into the antique xserver
<infinity> bryceh: Yeah, I knew what you meant, I was just hoping for the other. :P
<bryceh> but the two files are vastly different so it's a little unclear where exactly to paste.  It'll take some care to make sure it doesn't break some other random obscure hardware...
<bryceh> infinity, you and me both.  I had forgotten that was in there, so it was a bit creepy browsing through it
<smoser> hey all. looking for some hints.
<smoser> https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1061977 is my bug.
<ubottu> Launchpad bug 1061977 in MAAS "Machine fails to commission when console=ttyS0 is present on kernel opts" [Critical,Triaged]
<smoser> machine boots with console=ttyS0, generally boots fine until some point an upstart job that has 'console output' fails
<smoser> running it through upstart again, will fail
<smoser> running the same thing not through upstart will succeed.
<smoser> and if we do: echo HELLO | sudo tee /dev/console
<smoser> we get
<smoser> tee: /dev/console: Input/output error
<mwhudson> smoser: i ask this from a position of ignorance, but why have console=ttyS0 in the kernel arguments if that's not the correct value?
<mwhudson> which that looks like
<smoser> because they're default parameters.
<smoser> and in general the target for this is something that is likely to have ipmi serial or logged serial or something.
<smoser> as i understood it, the kernel would basically go through console= taking the last valid entry and making that /dev/console
<smoser> but it seems to be convinced that /dev/ttyS0 is "good enough" and then croaks later when user space writes a bunch more data there.
<mwhudson> ah
<mwhudson> no idea then
<sarnold> what's cc_keys_to_console.py supposed to do?
<sarnold> smoser: "console=tty1 console=ttyS0" ?
<smoser> sarnold, supposed to just write the ssh keys for the hsot to the console
<sarnold> smoser: does it rely upon any 'odd' terminal escape sequences or termcap/terminfo along the way?
<smoser> (on ec2 and other clouds, the serial console is logged and you can collect it)
<smoser> nah. just normal text.
<sarnold> aha, and I see multiple consoles should be supported. Hrm.
<smoser> well, yeah, it *does* work.
<smoser> ie, in kvm when i boot i see kernel messages on both, and then user-space messages on the serial
<sarnold> smoser: "Read 3 bytes from /home/ubuntu/.ssh/authorized_keys" -- why only 3 bytes?
<smoser> i dont knwo. that is strange.
<sarnold> (not that this _really_ helps with the /dev/console, but it's odd, and maybe you'll get lucky?)
<smoser> i dont think so. i thikn its probably just abug.
<smoser> in cloud-init.
<smoser> as that file likely doesn't have anything in it.
<smoser> as there were no ssh keys imported
<sarnold> the logs did say "read 0 bytes" elsewhere though, so it seems prepared to handle zero-byte files alright.
<stgraber> hallyn: I'm around now :)
<smoser> sarnold, well thanks for the thoughts.
<hallyn> stgraber: i went ahead and pushed part of the fix for grub updates to lxc in quantal
<hallyn> stgraber: cjwatson will push the other bit to grub tomorrow
<stgraber> hallyn: is fstab processed before the /dev/lxc/* entries are created? if not, I'd expect that fstab entry to hide them and start giving direct access to the host devices which would be kinda bad
<hallyn> stgraber: it is.  mounts are done first
<stgraber> hallyn: good, so yeah, should be fine. I'll takk a look at github in a sec
<micahg> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Quantal Quetzal development | Beta 2 released! | Archive: Frozen | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: micahg
<micahg> hrw: BTW, if we can get wine ported to use a different gcc before release, gcc-4.5 will be removed from quantal
 * micahg decides to stop trying to UDD merge when people aren't using the VCS as a VCS...
<infinity> micahg: That's a pretty hopeful "if".
<micahg> infinity: I can dream, can't i?
<infinity> micahg: Sure, carry on.
<darkxst> I have a small accounts services fix, that needs sponsoring https://bugs.launchpad.net/ubuntu/+source/gdm/+bug/1059090/comments/4
<ubottu> Launchpad bug 1059090 in accountsservice (Ubuntu) "Unable to autologin" [Undecided,In progress]
<bkerensa> infinity: any reason xserver-xorg-video-displaylink was deleted from Quantal?
<RAOF> bkerensa: I think because it's supported by the kms driver, now?
<bkerensa> RAOF: idk I just had a Mozilla colleague indicate that they have zero USB Monitor support since the package was deleted
<bkerensa> I will check back with him
<RAOF> It should be picked up by the kms driver and then xf86-video-modesetting should kick in.
<pitti> Good morning
<epikvision> Good evening.
<hrw> micahg: when gcc-4.[45] get removed I will post for removal of cross one as well
<infinity> hrw: We may as well just remove the cross 4.5 now, to be honest, we don't want to encourage people to be using old toolchains.
<infinity> hrw: If the only reason to keep it around it one package, why make it two?
<micahg> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Quantal Quetzal development | Beta 2 released! | Archive: Frozen | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<hrw> infinity: right
<cjwatson> bryceh: nvidia-texture-tools - FWIW it would have been great if you'd filed a bug about that somewhere (Debian or Ubuntu) in advance.  I spent half an hour or so on it only to find you'd been dealing with it already out of public view.
<bryceh> cjwatson, did you see bug #1061969?
<ubottu> Launchpad bug 1061969 in nvidia-texture-tools (Ubuntu) "Sync 2.0.8-1+dfsg-3 to fix FTBS" [Undecided,New] https://launchpad.net/bugs/1061969
<cjwatson> bryceh: That was filed after I spent some time working on it (having checked all the bug lists first) only to have the Debian maintainer tell me you already had.
<bryceh> cjwatson, any issue if I proceed with the sync?
<cjwatson> bryceh: No, go ahead
<cjwatson> (Why file bugs for syncs you don't need sponsorship for anyway?)
<bryceh> cjwatson, because we're in freeze, for traceability if the package is held
<cjwatson> Well, sync it and I'll accept it, anyway
<tjaalton> is bug 1017603 valid? it's what I had in mind too
<ubottu> Launchpad bug 1017603 in perl (Ubuntu) "perl needs to be multiarch" [Undecided,New] https://launchpad.net/bugs/1017603
<cjwatson> bryceh: accepted
<cjwatson> (oops, accepted my -2ubuntu1 as well, but no harm done there)
<cjwatson> tjaalton: the principle is valid and the Linaro guys have been working on this
<tjaalton> cjwatson: oh cool
<cjwatson> triaged the bug
<tjaalton> could it be sru'd to precise too, or are such changes not acceptable?
<bryceh> cjwatson, doko had asked me to look at the build issue, but there wasn't a bug report.  didn't realize there was a protocol for how to work on build failures.
<cjwatson> bryceh: Well, I would suggest that if you're working with Debian you should do it through the bug system rather than by e-mailing the maintainer directly
<cjwatson> (the Debian bug system that is)
<cjwatson> That way I'd have seen it and moved on :)
<cjwatson> aaaaaaargh, why does my right trackpad button randomly stop working
<bryceh> cjwatson, well don't ask me for help with that button, I might fix it but fail to file a bug report on it.  ;-)
<cjwatson> heh
<cjwatson> Sorry, glad you fixed it
<bryceh> no prob, night.
<zyga> pitti: ping
<zyga> pitti: two questions, same as before: can we ship python3-pyudev on the CD (for checkbox)
<pitti> zyga: (in interview, bbl)
<zyga> pitti: and can we upgrade that package (rdepends are empty) from 0.13 to 0.17
<zyga> pitti: k, thanks
<zyga> pitti: (debian does not have updated versions but it's pure python so it should be trivial to do)
 * zyga looks into the new source package
<pitti> zyga: so, the marathon guys let me go :)
<pitti> zyga: no objections, but I think pyudev is a dead end
<pitti> zyga: we have had introspection bindings for years which work very well
<zyga> hmm
<zyga> so which api should I use/
<zyga> gi + gudev?
<zyga> pyudev has some pythonic goodness on top of raw udev, I'd rather not loose that
<pitti> I think gi.repository.GUdev works very well, but as I said, I don't object to pyudev
<pitti> zyga: what goodness, OOI?
<pitti> if you use this in a GLib-ish project already, then gudev is certainly the way to go; you have automatic main loop integration, signal support, etc.
<zyga> pitti: I'll have a look at that
<pitti> if you use this in a Qt-ish project, you might not want the additional dependencies
<pitti> is this for checkbox?
<zyga> pitti: well, I only used it briefly but it has python wrappers for udev devices and attributes
<zyga> yes
<zyga> sadly we need udev too
<zyga> it's not merged in yet
<pitti> "udev is not merged"?
<zyga> the branch that depends on udev has not landed
<zyga> https://code.launchpad.net/~zkrynicki/checkbox/usb3/+merge/127993
<zyga> have a look at the brief discussion there
<zyga> hmm
<zyga> GUdev looks very similar
<pitti> zyga: ah, you already use gi.repository.GObject, so you already have all the glib, libgirepository and pygobject dependencies anyway
<zyga> that's right
<zyga> pitti: so it's my first time with using gi.repository magic, where do I find docs on the GUdev module, in the upstream C version?
<pitti> zyga: http://www.freedesktop.org/software/systemd/gudev/ is the C API
<pitti> it translates to the Python API in a straightforward way, but if you prefer a really Python-ish doc, you can get that as well
<zyga> I know the idea behing gobject introspection
<pitti> mkdir /tmp/gudev; g-ir-doc-tool -o /tmp/gudev/ /usr/share/gir-1.0/GUdev-1.0.gir; yelp /tmp/gudev/
<zyga> just never used it in practice
<zyga> ohhh
<zyga> thanks a lot
<pitti> that's still a bit inconvenient, sorry
<zyga> I'll try to use that instead
<pitti> but you get the class/method name separation instead of the C-style class_name_method()
<zyga> pitti: g-ir-doc-tool? where is that from cnf does not know about it
<pitti> "gobject-introspection" package
<zyga> thanks
<pitti> oh, indeed that's not on a default install
<zyga> pitti: which package has /usr/share/gir-1.0/GUdev1.0.gir
<zyga> it's not in gir-1.2-gudev
<pitti> zyga: gir1.2-gudev-1.0 is the typelib, libgudev-1.0-dev has the gir
<zyga> ah
<zyga> ok
<zyga> thanks
<pitti> (yay for confusing package names)
<zyga> :D
<zyga> no, it's okay
<zyga> well
<zyga> it's not better than anything else
<pitti> zyga: at runtime you only need the .typelib, which is the compiled gir (which is XML and human readable)
<zyga> I wish something like online apt-file was built into ubuntu by default
<zyga> right
<pitti> yeah, similar to rmadison
<zyga> pitti: hmm it crashes on missing GObject-2.0.gir
 * zyga looks for that
<pitti> zyga: libglib2.0-dev
<seb128> pitti, speaking of gobject-introspection, did you not package 1.34 on purpose?
<seb128> (it's one of the few tarballs were we didn't upate to the stable GNOME 3.6 one)
<pitti> seb128: oh, it might have been released late
<pitti> seb128: doing now
<zyga> pitti: no, I already have that
<pitti> seb128: I'm currently updating udisks to 2.0.0 final
<seb128> pitti, danke
<zyga> pitti: there are no .gir files in that package
<seb128> zyga, libgirepository1.0-dev
<pitti> zyga: whoops, sorry; gobject/glib girs are special, what seb128 says
<zyga> thanks
<pitti> zyga: (glib2.0 source cannot build its own girs)
<zyga> pitti: I'm trying to use that, how do I enumerate devices, Enumerator is not really iterable and there are no other methods that look like something accessing a collection
<pitti> zyga: calling .execute() on the enumerator after setting it up will give you an iterable Python array
<zyga> ahh, thanks, I've missed that
<zyga> pitti: reading the docs on that
<zyga> pitti: do I need to worry about gobject references form python?
<pitti> no, pygobject does that for you
<zyga> ok, cool
<zyga> it seems to work, thanks, I'll take it form there
<pitti> nice
<zyga> pitti: Device.get_parent() does not exist, I need that method, could this be a bug in gir? (it's documented that this method exists)
<zyga> http://www.freedesktop.org/software/systemd/gudev/GUdevDevice.html#g-udev-device-get-parent
<pitti> zyga: indeed, it's marked as non-introspectable; presumably a missing annotation
<zyga> ohhh
<pitti> zyga: you can use os.path.dirname(path) to get the parent, too; but I'll investigate
<zyga> crap
<pitti> I'll get this fixed upstream and backport it to our udev
<zyga> thanks
<zyga> pitti: dirname() on which path? sysfs?
<pitti> zyga: right, in sysfs; getting the parent dev is just that
<zyga> cool, thanks
<wookey> doko_: do you have guesses as to which patches might be responsible for http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=680439
<ubottu> Debian bug 680439 in gcc-snapshot "gcc-4.7: Fails to build glibc (git master) [amd64]: '__EI___isnan' aliased to external symbol '__GI___isnan'" [Important,Open]
<wookey> don't worry if not - I'll just wait for infinity to wake up
<pitti> zyga: ah, it's fixed upstream already, it's just that our udev is really old; I'll backport the fixes
<zyga> pitti: good news, thanks
<zyga> 193 vs 175
<zyga> 194 even
<darkxst> we need to drop an  old debian patch in accounts services to make the autologin toggle work in user accounts on ubuntu gnome remix. I attached a debdiff to this bug, if anyone is able to sponsor it. https://bugs.launchpad.net/ubuntu/+source/gdm/+bug/1059090/comments/4
<ubottu> Launchpad bug 1059090 in accountsservice (Ubuntu) "Unable to autologin" [Undecided,In progress]
<hrw> Bug #1062137 filled to get rid of old cross compilers
<ubottu> Launchpad bug 1062137 in gcc-4.5-armhf-cross (Ubuntu) "Remove from quantal" [Undecided,New] https://launchpad.net/bugs/1062137
<zyga> pitti: hmm, it seems I cannot just chop the path to traverse devices
<zyga> pitti: for /dev/sdb1 I got /dev/sdb but then stop -- I wanted to traverse all the way up to the USB hub device (it's a thumb drive)
<pitti> yes, it should do that
<zyga> pitti: starting from /sys/devices/pci0000:00/0000:00:1d.7/usb1/1-7/1-7:1.0/host0/target0:0:0/0:0:0:1/block/sdb/sdb1
<pitti> zyga: (anyway, test-building udev now)
<zyga> it only got to /sys/devices/pci0000:00/0000:00:1d.7/usb1/1-7/1-7:1.0/host0/target0:0:0/0:0:0:1/block/sdb
<pitti> zyga: sure, that's the next parent
<zyga> going higher made Client.query_by_sysfs_path() return None
<pitti> you have to iterate through all parents
<pitti> zyga: libudev's get_parent() really does the same -- just chop off the last path component
<cjwatson> hrw: Thanks, I'll process that
<zyga> pitti: so until I get all the way up to /sys?
<hrw> cjwatson: thanks
<cjwatson> hrw: I assume I can reject the corresponding uploads in the unapproved queue?
<zyga> ignoring things that don't look like devices?
<hrw> cjwatson: yes
<cjwatson> OK, done
<hrw> cool
<cjwatson> Just triple-checking reverse dependencies
<pitti> zyga: perhaps you want get_parent_with_subsystem() if you are looking for a particular kind of parent dev
<cjwatson> Which is hard with a headache and a toddler talking to me
<pitti> zyga: well, in kernel teams all of those are devices
<pitti> zyga: you have to specify "what shoudl the device look like" yourself, in terms of subsystem, attributes, and properties
<pitti> $ grep introspectable /usr/share/gir-1.0/GUdev-1.0.gir
<pitti> $
<pitti> zyga: ^ voila :)
<zyga> pitti: for me /sys/devices/pci0000:00/0000:00:1d.7/usb1/1-7/1-7:1.0/host0/target0:0:0/0:0:0:1/block/ is empty apart form the 'sdb' directory, there are no attribute files there
<pitti> ah, right
<zyga> pitti: anyway, ignoring stuff that fails to create a udev device they way I said seems to work
<pitti> zyga: right, sorry; udev's skips directories without an "uevent" file
<pitti> zyga: I uploaded the fixed udev, now waiting for a release team member to review, then you'll have it an hour after that
<jtaylor> doko_: do you have objections to syncing poco just to test if bug 903347 is fixed in quantal?
<ubottu> Launchpad bug 903347 in poco (Ubuntu Precise) "[armel/armhf] file fails to compile (indefinite loop?)" [Medium,Triaged] https://launchpad.net/bugs/903347
<jtaylor> or someone here has the hardware could test it for me :)
<zyga> pitti: awesome, thanks for the help! :-)
<cjwatson> hrw: all right, all done now
<pitti> dholbach, jono, dpm, jcastro_, mhall119: wohoo, > 5000! go, go, go!
<dholbach> :-D
<mhall119> \o/
<jono> pitti, :-)
<mhall119> ..zzZZ
<dpm> pitti, \m/
<ajmitch> jcastro_: live juju demo
<pitti> doko_: https://launchpad.net/ubuntu/+source/ubuntu-drivers-common/1:0.2.71 :)
<pitti> dholbach: who's DJing, you?
<dholbach> pitti, very short :)
<dholbach> just a bit
<cjwatson> mlankhorst,tjaalton: so, I notice you removed xserver-xorg-video-geode from xserver-xorg-video-all, which has caused it to be listed for movement to universe on http://people.canonical.com/~ubuntu-archive/component-mismatches.txt; was it intentional to drop it out of main, or just out of the default set?
<pitti> zyga: If you are anxious for the fixed packages, grab them from https://launchpad.net/ubuntu/+source/udev/175-0ubuntu12
<tjaalton> cjwatson: move to universe is fine, it's not that useful anymore since the kernel requires PAE support. but keep it there for now if some folks want to use their own kernels..
<cjwatson> tjaalton: OK, moved to universe
<cjwatson> thanks
<mlankhorst> cjwatson: intentional :)
<pitti> jono, dholbach: ah, the last few minutes weren't broadcasted any more; anyway, good night! awesome job!
<mlankhorst> but tjaalton beat me to it
<dholbach> pitti, they were - we had to restart the hangout
<jono> thanks, pitti!
<jono> thanks for joining us earlier!
<pitti> dholbach: right, I tried to reload several times, it always said "will be available soon"
<dholbach> hum
<pitti> jono: de rien
<dholbach> it seems to have worked for others
<pitti> *shrug* no biggie
<pitti> why are you still online anyway! :)
<pitti> james_w: hey James, how are you?
<pitti> james_w: who can I bother about pushing buttons for UDD imports these days? (gvfs is out of date)
<chrisccoulson> jono, have you started hallucinating yet? ;)
<chrisccoulson> i think i would be after 24h
<jono> chrisccoulson, getting there :-)
<chrisccoulson> hah :)
<cjwatson> That usually starts at around 35h for me
<cjwatson> Not that I'm much use between 24h and 35h
<pitti> jono: for example, you might imagine it was already over :)
<ogra_> you guys dont take the day off, do you ? :)
<doko_> wookey, http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33763
<ubottu> gcc.gnu.org bug 33763 in c "[4.6/4.7/4.8 Regression] Bogus inlining failed in call to `xxx': redefined extern inline functions are not considered for inlining" [Normal,New]
<doko_> wookey, my understanding is, that this should be fixed in glibc
<doko_> jtaylor, why? is there a fix for GCC?
<jtaylor> don't know
<doko_> wookey, no, apparently I'm wrong. just drop it for now
<pitti> davmor2: FYI, I now added a gvfs test case for recognizing media players as such :)
<pitti> davmor2: this broke $DEITY knows how many times already..
<davmor2> pitti: just tested it, S3 works correctly although the system thinks it's a tablet and the music player is detected however the icon in the launcher isn't a music player but a usb stick is this a change in behaviour?
<pitti> davmor2: yes, very close to gnome bug 631809
<ubottu> Gnome bug 631809 in gdu volume monitor "Nautilus should use the media-player name from media-player-info if available" [Normal,Unconfirmed] http://bugzilla.gnome.org/show_bug.cgi?id=631809
<davmor2> pitti: I'm just happy that I have my sansa fuse to keep testing it is broken or not hopefully now :)
<pitti> davmor2: these bugs apply to any media player, though (same for my xperia mobile)
<davmor2> pitti: indeed
<davmor2> pitti: mine just happens to be a sansa fuze that I've had for a while so seem to keep finding the breakage with it :)  I'm happy to here that there could be an upstream fix for it now though :)
<pitti> davmor2: my fix from yesterday to detect them at all already went upstream
<pitti> icons and volume names still need to be fixed, that's on my list
<pitti> (and now that's trivial to test)
<davmor2> pitti: cool :)
<zyga> pitti: thanks
<davmor2> pitti: on a plus side the system thinks I have a music player WooHOO!!!!
<ogra_> hmm, i have two packages that should never be unpacked on the same system at the same time, can i just use Conflicts here ?
<cjwatson> That's the exact meaning of Conflicts
<ogra_> k
<ogra_> no need to use replacess i guess
<cjwatson> Not in general but you might want to if one of the two is going away
<cjwatson> The policy manual has detailed advice
<ogra_> by going away you mean that the other package then comes in as a replacement ?
<ogra_> thats definitely not waht i want ...
<ogra_> *what
<cjwatson> for example
<cjwatson> pitti: is the stack of language pack uploads yours?
<cjwatson> pitti: Never mind, looks like a straightforward update so I'll just accept it all
<pitti> cjwatson: (OTP) presumably from the automatic cronjob
<cjwatson> OK
<jamespage> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Quantal Quetzal development | Beta 2 released! | Archive: Frozen | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: jamespage
<pitti> ev: hey Evan
<ev> hi Pici
<ev> pitti even
<pitti> ev: I assigned a bug to you this morning about unpacking xz debs not working any more
<ev> yikes, on it
<pitti> ev: it seems that none of our three implementations gets it right :(
<pitti> ev: but I'm really concerned about dpkg-deb -x having that bug; how does it deal with symlinks in the actual system?
<ev> pitti: how does dpkg -x deal with symlinks?
<ev> or dpkg -i?
<ev> dpkg -i notices that there's something there already and happily carries on
<pitti> ev: or whichever bug you wanted to fix by moving to python-debian/apt_inst
<cjwatson> dpkg -x should extract symlinks perfectly normally
<ev> https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1059621
<ubottu> Launchpad bug 1059621 in apport (Ubuntu) "Sandbox option breaks on extraction of precise gnat-gps and gnat-gps-common" [Undecided,New]
<cjwatson> the random package I have to hand that contains symlinks extracts just fine
<ev> cjwatson: it extracts symlinks fine. But while dpkg -i notices that the symlink it's trying to create already exists as a directory and skips it, dpkg -x does not.
<ev> thus the "tar: ./usr/share/doc/gnat-gps: Cannot create symlink to `gnat-gps-common': File exists"
<cjwatson> that looks like an outright bug in the package to me, really
<cjwatson> gnat-gps-common should put features.gz and known-problems.gz in /usr/share/doc/gnat-gps-common/, not gnat-gps/
<cjwatson> the way it is right now, even with dpkg -i it's probably nondeterministic what ends up in gnat-gps/
<ev> hmm
<cjwatson> Debian #684194
<ubottu> Debian bug 684194 in gnat-gps "gnat-gps: /u/s/d/gnat-gps is empty after upgrade from squeeze" [Serious,Fixed] http://bugs.debian.org/684194
<ev> pitti: do you think we should back out the change and consider these unretraceable?
<ev> cjwatson: massive, massive thanks
<cjwatson> (so fixed in quantal, I believe)
<cjwatson> might not be totally insane to SRU that fix
<smoser> jodh, around ?
<smoser> i'm running into a problem where getting the "right" console= parms is not easily done. and as a result, /dev/console (stdout for upstart) is hosed.
<smoser> that, in turn, hoses anything that has 'console output'.
<smoser> is there any way in upstart to fix that case?  ie, if stdout gives io error when written to, try somewhere else.
<pitti> ev: works for me
<jodh> smoser: what console= kernel param are you specifying
<jodh> smoser: ?
<smoser> https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1061977/comments/4 has more info
<ubottu> Launchpad bug 1061977 in MAAS "Machine fails to commission when console=ttyS0 is present on kernel opts" [Critical,Triaged]
<smoser> i'm specifying "console=tty1 console=/dev/ttyS0" which tells the kernel to make /dev/console == /dev/ttyS0
<smoser> but /dev/ttyS0 might not actually be a device.
<ogra_> smoser, sudo in an upstart job ?
<smoser> where do you see that?
<smoser> ah. that was just an example.
<ogra_> ahm, thats only manual test code ?
<jodh> smoser: I thought that meant redirect console output to *both* devices? One sec...
<smoser> saying /dev/ttyS0 is busted.
<smoser> err... /dev/console.
<smoser> jodh, it sends kernel messages to both devices
<ogra_> hmm, it shoudlnt
<smoser> but /dev/console is not a multiplexer. "last one wins"
<ogra_> the second console= option is ususally handed to userspace
<smoser> ogra_, right.
<ogra_> while the first one is used for kernel messages
<smoser> no.
<ogra_> (if you actually use two)
<smoser> kernel messages go to both.
<smoser> user space gets the last.
<ogra_> they shouldnt
<smoser> the doc and experience say otherwise :)
<jodh> smoser:
<jodh> You can specify multiple console= options on the kernel command line.
<jodh> Output will appear on all of them. The last device will be used when
<jodh> you open /dev/console.
<jodh> smoser: so, trying changing the order.
<smoser> jodh, yeah, that will work.
 * ogra_ has never seen the kernel output to more than one tty
<jodh> smoser: that was from Documentation/serial-console.txt in the kernel fwiw.
<smoser> jodh, i liked to that.
<smoser> linked to that
<smoser> jodh, my problem is that if i do that, i will *never* (well, 98% of never) get /dev/console == /dev/ttyS0.
<seb128> ev, do you know when bug #1061867 is not registering on the front page of e.u.c ... it's a recent issue and it has been ranking high on the launchpad retracer, that's reality the sort of issues we need to know about, it's a bit disturbing that the error tracker doesn't catch those
<ubottu> Launchpad bug 1061867 in indicator-datetime (Ubuntu) "indicator-datetime-service crashed with SIGSEGV in e_client_open_sync()" [High,Confirmed] https://launchpad.net/bugs/1061867
<smoser> which is better in the case where there *is* a ttyS0
<smoser> jodh, the reason i bothered you, is that there seems no [easy] way to change /dev/console, and whatever is the last 'console=' parm will become /dev/console.
<smoser> but upstart could potentially recognize that its stdout is busted.
<smoser> and i could potentially tell upstart (configuration or kernel cmdlines) "if your stdout is busted, try others in this order"
<jodh> smoser: that's kernel behaviour I'm afraid :) You could try playing tricks likehttp://upstart.ubuntu.com/cookbook/#versions-of-upstart-older-than-1-4 maybe?
<ogra_> you can surely work around it in /init in the initrd
<jodh> smoser: ... where the device is passed in as a job param maybe or config variable?
<ogra_> (theoretically it does that already)
<smoser> ogra_, well, i sort of could.
<jodh> smoser/ogra_: but do you even need an initrd for those cloud images I wonder.
<smoser> i could set init's stderr, stdin, stdout to something other than /dev/console if /dev/console was busted, yes.
<smoser> and that would be essentially the same as having upstart do it.
<ogra_> just easier to hcak it into the shell script :)
<smoser> jodh, we like initrd.
<ogra_> *hack
<smoser> ogra_, right.
<ogra_> jodh, you neeed one if they use root=UUID=
<ogra_> our kernel cant mount by UUID
<jodh> ogra_: I know
<smoser> i was hoping that from user space i could tell the kernel "please re-assign /dev/console to be /dev/tty0"
<smoser> but it seems not possible.
<smoser> ogra_, jodh we like initrd.
<smoser> we do clever, valuable things there.
<ogra_> ++
<ogra_> thats what its for ;)
<smoser> (iscsi root, overlayroot, grow a partition)
<ogra_> yep
<smoser> so, yeah, in the initramfs i coudl change 'exec >/dev/console 2>&1 </dev/console' to be 'exec >$MYDEVICE ... '
<smoser> but writes explicitly to /dev/console would still fail.
<ogra_> hmm, i would rather look for why you cant write to it and fix that
<smoser> hm..
<smoser> jodh, one question.
<smoser> the doc for upstart says: [console] output: If output is specified, the standard input, standard output and standard error file descriptors are connected  to /dev/console.
<smoser> is that really mean "by convention"
<smoser> or does upstart explicitly close stdin/stdout/stderr and re-open them from /dev/console
<smoser> (in which case i cannot hack in the initramfs)
<jodh> smoser: it actually closes and reopens.
<smoser> so i can't workaround in initramfs
<smoser> ogra_, yeah, i meant where $MYDEVICE is the result of a search.
<smoser> but i dont think that will work anyway.
<ev> seb128: https://errors.ubuntu.com/bucket/?id=/usr/lib/indicator-datetime/indicator-datetime-service%3A11%3Ae_client_open_sync%3Aupdate_appointment_menu_items%3Ag_closure_invoke%3Asignal_emit_unlocked_R%3Ag_signal_emit_valist
<smoser> well, i can't seem to see any solution other than removing console=ttyS0 as a default parameter.
<seb128> ev, I wonder why it has 1 instance where launchpad has 6 duplicates, whoopsie is supposed to bring more report than successful launchpad retraces no?
<smoser> which means that "by default" systems that would have logged ttyS0 will get no messages written to them at all if they have a vga device.
<smoser> :-(
<KRF> could someone please have a look at https://bugs.launchpad.net/ubuntu/+source/valgrind/+bug/1036283 ?
<ubottu> Launchpad bug 1036283 in valgrind (Ubuntu) "callgrind_control cannot connect because of different executable name" [Undecided,Confirmed]
<ev> seb128: indeed, I'm curious about that as well. It is *possible* - they might have whoopsie in a stopped state. But it seems unlikely.
<ogra_> smoser, oh, coudl it be that you have a job anywhere that has "console owner" ?
<smoser> console output
<ogra_> console will get detached from the tty for that
<ogra_> if any job cals it
<ev> seb128: I've made a note to dig into that deeper
<smoser> possible. but i have 'console output' on my jobs.
<seb128> ev, thanks
<ev> sure thing
<smoser> which, seems to mean /dev/console even if that is busted.
<ogra_> smoser, well there might bew jobs you didnt add :)
<smoser> oh well.
<smoser> right.
<smoser> but why would that matter?
<smoser> at least i dont care about those jobs at the moment.
<ogra_> i just noticed that my tty's die if console owner is set (and respawn due to their job)
<smoser> well, ogra_ jodh thanks for the discussion.
<smoser> it seems to me the only way to do this would be to be able to tell the kernel "hey, could you make /dev/console point somewhere else please"
<smoser> and have that work even with open filehandles
<smoser> well, maybe in the initramfs i could get all /dev/console closed.
<smoser> hm.. i guess the other hting i could do is kexec from initramfs.
<doko> mvo: can you just black-list pentium-builder for command-not-found? see bug #1062043
<ubottu> Launchpad bug 1062043 in gcc-4.7 (Ubuntu) "no symlink for g++ is created when g++-4.7 package manually installed" [Undecided,New] https://launchpad.net/bugs/1062043
<mvo> doko: yeah
<doko> pitti, seb128: would be nice if somebody could look at libgtk2-perl, bug #1056811. update needed for gtk changes?
<ubottu> Launchpad bug 1056811 in libgtk2-perl (Ubuntu Quantal) "libgtk2-perl ftbfs in quantal (hangs in the testsuite)" [High,Confirmed] https://launchpad.net/bugs/1056811
<pitti> c'est un travail pour l'Ã©quipe de desktop :)
<pitti> oui, Monsieur Bacher?
<pitti> mvo: so we still have libgtk2-perl for debconf?
<seb128> pitti, on dirait oui ...
<seb128> doko, I will try to have a look, no promise today though, release team meeting just started and it will be 6pm after the meeting
<doko> it's the last real build failure in main
<pitti> Riddell: ah, so we should remove language-pack-* from quantal, except for the ones you created manually?
<seb128> doko, kick a build while the meeting is ongoing, let's see
<Riddell> pitti: yes I think so
<doko> well, maybe except for webkit on arm
<Riddell> pitti: including the base ones
<Riddell> I guess
<pitti> Riddell: that's all except language-pack-kde-{engb,zhcn,zhtw}?
<Riddell> pitti: I've removed language-pack-kde-{engb,zhcn,zhtw} already
<Riddell> pitti: here's the ones I make http://paste.kde.org/562928/
<pitti> Riddell: ah, thanks; so I'll remove all but those
<Riddell> pitti: thanks
<mvo> pitti: I think so - if we want to support debconf gtk dialogs
<mvo> pitti: still in the suggests line of debconf, but TBH i haven't payed much attention to debconf lately
<smoser> can i get someone from SRU team to look at https://launchpad.net/ubuntu/precise/+queue?queue_state=1&queue_text=cloud-init please ?
<smoser> i have other things in cloud-init that are fairly high priority to get fixed in 12.04 and i need that ximple fix through the queue sooner rather than later.
<pitti> Riddell: oh, bloody CRLF line endings on pastebin
<pitti> Riddell: I was staring at my join command for 5 minutes, wondering why it didn't work
<Riddell> pitti: I know, I really should report that to the kde sysadmins
<pitti> Riddell: http://paste.ubuntu.com/1262096/
<pitti> command and output, this would be the "to kill" list
<Riddell> pitti: looks right
<pitti> Riddell: could you add Conflicts to the -base packages to the transitionals, to get them cleaned up on upgrade?
<Riddell> pitti: can do
<cjwatson> pitti,seb128: if you guys can't figure out the libgtk2-perl failure I expect I'll take a look at it on Monday and see if any of the recent upstream changes help
<cjwatson> I hadn't been going to ask you to support it because I know how much you love the perl bindings
<seb128> cjwatson, I indeed *love* perl :p
<seb128> cjwatson, I started looking at it but the test seems to run fine when ran manually
<cjwatson> in an sbuild chroot?
<seb128> cjwatson, I will poke a bit longer to it today but I don't figure it out help on monday would be welcome
<seb128> cjwatson, no, on my box, but the package build hangs on the same environment
<seb128> well "same environment", the package run through fakerook, xvfb, etc
<wookey> infinity: libc_extra_config_options = --with-selinux $(extra_config_options) which ends up coming after the --without-selinux in the eglibc stage1 build and turning selinux back on.
<wookey> any idea where the right place to fix that is?
<wookey> in 2.15 libc_extra_config_options = $(extra_config_options)
<wookey> so it worked
<infinity> wookey: Oh, has aurel turned on selinux unconditionally in 2.16?
<wookey> apparently
<wookey> which may well be OK for normal builds, but not bootstrapping
<cjwatson> seb128: Yeah, hangs for me too in sbuild, at least
<infinity> ifeq ($(DEB_STAGE),stage1)
<infinity>     libc_extra_config_options = $(extra_config_options) --without-selinux
<infinity> endif
<infinity> ?
<wookey> seems sensible.
<micahg> could someone familiar with objective c binary dependencies take a look at this bug for me and see if my concerns are valid or not?
<micahg> Bug #1051389
<ubottu> Launchpad bug 1051389 in sope (Ubuntu) "Sync sope 1.3.16-1 (universe) from Debian unstable (main)" [Undecided,In progress] https://launchpad.net/bugs/1051389
<mlankhorst> who handles apt bugs?
<KRF> could somebody take care of https://bugs.launchpad.net/bugs/1036283 please?
<ubottu> Launchpad bug 1036283 in valgrind (Ubuntu) "callgrind_control cannot connect because of different executable name" [Undecided,Confirmed]
<KRF> that's a pretty trivial fix
<mlankhorst> hitting a weird bug in apt that seems multiarch related
<cjwatson> mlankhorst: normally mvo
<mlankhorst> ah what time is he on?
<mlankhorst> I was hitting a bug switching stacks but it kind of looks like I've hit that one before
<slangasek> mlankhorst: Europe/Berlin; but if you can describe the problem perhaps someone else can help
<Darxus> A sensors-applet package is "waiting in New for approval".  It got an FFE.  What needs to happen?  Is there any part of that I can see?  Bug 1049343.
<ubottu> Launchpad bug 1049343 in sensors-applet (Ubuntu) "FFe: Un-blacklist and merge sensors-applet 3.0.0-0.2 (universe) from Debian testing (main)" [Wishlist,Fix committed] https://launchpad.net/bugs/1049343
<mlankhorst> slangasek: basically I am working on q-lts-backport in ~mlankhorst/ppa, but switching between normal and other stack with apt-get install xserver-xorg-lts-quantal libgl1-mesa-{glx,dri}-lts-quantal{,:i386} is broken and dies on swapping out libglapi
<slangasek> ok, what's the error?
<mlankhorst> just that libglapi-mesa-lts-quantal is extracted for i386, then it dies on trying to extract libgl1-mesa-glx-lts-quantal which requires that package for 64-bits
<slangasek> please show the exact apt output
<mlankhorst> with problem resolver debug enabled http://paste.ubuntu.com/1262441/
<mlankhorst> sadly in dutch but should still be understandable
<smoser> infinity, it would appear to me that the last upload of software-properties did not fix
<smoser> https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1060335
<ubottu> Launchpad bug 1060335 in software-properties (Ubuntu) "apt-add-repository fails" [Undecided,Fix released]
<infinity> smoser: Erk.  It fixed it when I tested...
<smoser> look at the comment there. comment 5. i'm fairly sure i didn't make a user error of some sort.
<slangasek> mlankhorst: English (and without the resolver debug) would be helpful, if you can reproduce this easily; the Dutch is slowing me down a bit
<infinity> smoser: Yeah, I'm reading.  I'm just stumped as to why my testing went okay.  Maybe it was multiple runs in a row that broke something.
<smoser> infinity, so this wasn't 100% instance.
<smoser> i had tried once with the old version
<infinity> smoser: Anyhow, mvo was going to land something that removed all that code and replaced it with a call into python-apt.  Maybe I should review that and give him an FFe instead of fiddling with it more.
<smoser> but you would still need to fix that case anyway, and it surely dodn'st look like it.
<infinity> smoser: No, having run it once with the old version shouldn't matter, it just looks like I missed one spot where I needed home-dir, from your log.
<slangasek> mlankhorst: fwiw I don't think I've ever seen this bug before
<infinity> smoser: (Though, I'm curious where that is...)
<slangasek> seems to be a previously-unnoticed apt bug
<mlankhorst> slangasek: yeah my q-lts-backports archive kind of hits the limits in many way of apt :)
<infinity> smoser: Did you upgrade python3-software-properties as well?
<infinity> smoser: That's what actually contains the fix.
<smoser> i did not.
<smoser> duh.
<infinity> smoser: Double-check that for my peace of mind, but it should fix you up.
<smoser> well, in a new machine with that installed it is fixed, infinity
<mlankhorst> slangasek: but my ppa has the stack I was using, I think it worked before because of a workaround
<james_w> pitti, oops, sorry, missed the message, you can poke me, or people from the bzr team should be able to do it
<slangasek> mlankhorst: what kind of workaround do you mean?
<mlankhorst> i had a conflicts on everything before
<mlankhorst> or maybe because i only tested pure 64-bits before mostly
<mlankhorst> shall I just file a launchpad bug?
<slangasek> mlankhorst: yes, please
<james_w> pitti, should be up to date now
<mlankhorst> slangasek: bug 1062503 ?
<ubottu> Launchpad bug 1062503 in apt (Ubuntu) "apt fails to install libglapi-mesa-lts-quantal correctly on switching x stacks" [Undecided,New] https://launchpad.net/bugs/1062503
<slangasek> mlankhorst: attach the apt output in English, please
<mlankhorst> slangasek: tomorrow :P
<slangasek> ok
<mlankhorst> ah who am I kidding, got nothing better to do, sec breaking my system again
<mlankhorst> there
<micahg> slangasek: infinity: either of you familiar with binary dependencies for objective C apps?
<slangasek> moreso than I would like?
<micahg> can you look at Bug #1051389 to tell me if I'm right or wrong?
<ubottu> Launchpad bug 1051389 in sope (Ubuntu) "Sync sope 1.3.16-1 (universe) from Debian unstable (main)" [Undecided,In progress] https://launchpad.net/bugs/1051389
<slangasek> micahg: ok, hmm; I've never heard this before at all
<micahg> heh, ok, I don't feel so bad now :)
<micahg> but I'm quite unsure of where to go from here as sogo 1.3.16 is already in quantal
 * micahg can always punt to release team...
<slangasek> micahg: checking a random library, I can confirm that there are only symbols for the classes.  This seems quite horrid.
<slangasek> but if sogo is broken without the new sope, seems like it ought to get in as a bugfix
<slangasek> I'm sure both our gnustep users will be happier that way. :)
<micahg> slangasek: so, do I have a pass from you to sync it or should I make him write an FFe?
<ScottK> That sounded like a pass to me.
<Laney> Yeah. Paste it in the bug for audit, and do it.
<slangasek> yep
<micahg> slangasek: thanks
#ubuntu-devel 2012-10-06
<infinity> tyhicks: Around?
<infinity> micahg: Or you?
<tyhicks> infinity: Hi - I'll respond in the bug shortly
<infinity> tyhicks: Danke.
<gotwig> I would be pleased if someone could tell me where the code for "keyboard indicator" is on lauchpad.
<doko_> Sweetsha1k, libreoffice ftbfs on armel/armhf
<doko_> verbose build logs are again turned off :-(
<ogra_> doko_, well, there is also Bug 1062448
<ubottu> Launchpad bug 1062448 in libreoffice (Ubuntu) "soffice.bin crashed with SIGSEGV in lucene::index::IndexFileNames::fileNameFromGeneration()" [Undecided,New] https://launchpad.net/bugs/1062448
<ogra_> plars found it yesterday
<Sweetsha1k> doko_: That buildlog says it segfaults in XHC for the presenter-screen. All that does is calling cp and zip. So either: 1/ zip is broken on arm (and hasnt been at the last upload) 2/ zip on arm has a heisenbug. 3/ LibreOffice does something totally different in 3.6.2. the chances of 3/ are slim to zero compared with the other options.
<doko_> Sweetsha1k, could you start a local build on scheat to verify?
<Sweetsha1k> doko_: I will give it a try.
<doko_> thanks
<doko_> don't forget to dist-upgrade first
<Sweetsha1k> doko_: will do. thanks for the heads-up about the ftbfs.
<Sweetsha1k> ogra_s bug could be more interesting.
<Sweetsha1k> :/
<doko_> yeah, I mentioned scheat, so your local machine is available for debugging ;p
<Sweetsha1k> oh, I lied. It only does cp/zip on LO master, but on 3.6 it actually calls HelpLinker, so LibreOffice is in the mix there still. So my bet is on HelpLinker being unstable and having been so the last upload too (just being lucky then).
 * ogra_ doesnt think anyone tested libreoffice on arm since tobin is gone 
<ogra_> (which was mid 12.04)
<Sweetsha1k> armboard have never been the limiting resource. But there are only limited amounts of me available (in numbers: 1)
<penguin42> do things like LO have automated test scripts as part of the build?
<sladen> Laney: if you're uploading modified versions of the font, can you please stick  0.80-0ubuntu5+console+renamedmedium  in the version number or something
<sladen> Laney: so that these don't interfere with virgin .debs
<sladen> or  +console~renamedmedium  as the binary hacking is a negation
<jtaylor> does this patch look ok to fix the lustre ftbs: http://paste.ubuntu.com/1263823/
<doko> chrisccoulson, micahg: the recent firefox and thunderbird uploads did send our arm buildds to death. please don't retry these builds once the buildds come up again
<chrisccoulson> doko, ok. i guess armel will not get this security update then
<doko> chrisccoulson, do you have access to the ubuntu-mozilla-security ppa? were just the armel builds failing?
<chrisccoulson> doko, yeah, it looks like all of the armel builds are failing :(
<doko> and somebody did give them back :-/
<chrisccoulson> i really need a native PPA for the beta channel, so i don't get surprises like this 2 days before the release :/
<chrisccoulson> hmmm
<chrisccoulson> it wasn't me who gave them back
<ogra_> thats what we have a community for :P
<doko> chrisccoulson, does canonical-arm-dev work for you?
<ogra_> not yet
<ogra_> i can add him immediately
<ogra_> done :)
 * SpamapS suddenly realizes we don't know what R will be.. but hopes it is Revolting Racoon
 * penguin42 was hoping for Rampant Rabbit
<ogra_> SpamapS, racoons ++
<ogra_> (no matter if they rotate or revolve :) )
<SpamapS> Resurrected Rhino would be fun... they're scary alive.. but.. undead?!
<penguin42> SpamapS: A large EDA company had a mascot called Roger the Rhino; apparently it was named in the US
<SpamapS> Not many R animals actually
<ScottK> Roger Rabbit is taken.
<SpamapS> rattlesnake would be cool
<ScottK> Rapscallion Rattlesnake
<SpamapS> Rash Ram
<SpamapS> no no ..   Red Ram
<SpamapS> hahaha
<SpamapS> Ridiculous Rat ..
<blaze> rumbustious racoon
<Guest1280> what kernel version will be used for quantal?
<mlankhorst> 3.5.x
<Guest1280> thanks
#ubuntu-devel 2012-10-07
<s1aden> oooh, cool, I have a Unity Launcher screen-burnt into my laptop display
<lifeless> noice
<lifeless> I didn't think modern laptops suffered burnin
 * s1aden neither...
<sladen> shows up under purple (eg. #6d1d4a).  It's the 100%-white CoF in the top left that is really visible
<micahg> infinity: does the following look transient? https://launchpadlibrarian.net/118757501/buildlog_ubuntu-quantal-armhf.openssl_1.0.1c-3ubuntu2_FAILEDTOBUILD.txt.gz
<infinity> micahg: Looks like cosmic rays.
<micahg> infinity: ok, retrying, thanks
<infinity> micahg: (Or possibly filesystem dying)
<micahg> ah, you did already :)
<infinity> micahg: Can you make a note to bug webops (or ask me to) to check sigbin for kernel messages after the weekend?
<micahg> infinity: can try, but I'm off Mon/Tue
<infinity> Yeah, I'm off Monday too.
<infinity> I'll try to remember.
<infinity> micahg: Though, sigbin's build history doesn't look sketchy, so cosmic rays seem more likely.
<infinity> micahg: Unless it really is a toolchain bug that broke the build, but it better not be...
<micahg> well, last time it was built was 3 months ago, so that's possible
<infinity> micahg: Yeah, but a toolchain bug on only one (sub)arch is disconcerting.
<infinity> micahg: So, I'm hoping not.
 * micahg too, especially at this stage of the game
<infinity> Ed Zachary.
<infinity> Well, we'll find out in a few minutes, I guess.
<infinity> micahg: It failed at ~7m in, right?
<micahg> ~8
<infinity> Kay.  We're probably close to or passed where it died, though I didn't make a note of the file it choked on.
<micahg> eng_dyn.c
<infinity> Oh, the log's still there.  Handy.
 * micahg had it open in a tab regardless
<infinity> Yeah, it's passed where it failed.
<infinity> \o/
<micahg> great, one less thing to fix
<infinity> Replacing these glorified cell phones can't come a moment too soon.
<infinity> Still, I may have to waste some of my long weekend on trying to figure out shoestring and bubblegum hacks to get us to hobble along until then. :/
<infinity> THe easiest way might just be to throw the natty or oneiric kernel on a couple machines, and aim problematic builds at them.  But that seems like a last resort "eww" solution, if I can't proc-tune these into submission.
<micahg> infinity: it it gets arm* builds for Firefox/Thunderbird, I'll take it
<infinity> Pretty sure that would fix up wekbit/ffox/tbird, but it introduces other problems.
<infinity> So, it's an irksome tradeoff.
<infinity> Hence the proc-tuning and trying to hunt ways to make buildd-manager less touchy first.
<infinity> But we're running out of time, obviously.
<geser> zul: your (binary) package "python-ceilometer" (ceilometer) has two typos in its dependencies: "python-iso9601" should be "python-iso8601" and "python-sqlaclhemy" should be "python-sqlalchemy" (you got it right in Build-Depends but not Depends for the binary package)
<zul> geser:  please open up a bug ill look at it monday
<infinity> geser, zul: Fixed.
<dupondje> Seems we do not support Samsung Galaxy S3 :(
<dupondje> https://bugs.launchpad.net/ubuntu/+source/udev/+bug/903422
<ubottu> Launchpad bug 903422 in udev (Ubuntu Precise) "Mount / Provide access to Android 4.x (Ice Cream Sandwich and above) MTP devices" [High,Confirmed]
<dupondje> High for Precise, Whishlist for Quantal ?!
<maxb> dupondje: Precise will talk fine to an S3 in Camera (PTP) mode. I did that yesterday
<maxb> Full MTP support would be *nice*, but not essential, as far as I can see
<dupondje> maxb: libmtp seems to support it, but gphoto2 not, but ubuntu seems to use gphoto2 as default?
<dupondje> maxb: PTP mode doesnt show SD card data neither?
<maxb> dupondje: Hm, it did for me
<maxb> It seemed to enable nautilus to address files under the root /mnt/sdcard (but that wasn't a real sdcard)
<dupondje> maxb: well it shows sd card in nautilus, but its all empty
<dupondje> so :)
<maxb> I was able to copy files to the device and subsequently play them
 * dupondje compiling libgphoto2 2.5.0, lets see what that gives
<dupondje> bleh, seems a mess compiling a new version :(
<mwhudson> i presume complaining about the usn-1592-1 updates breaking virtualenvs has happened already?
<soniah> I'm looking for a sponsor for https://code.launchpad.net/~sonia/ubuntu/quantal/vim-scripts/fix-for-31204/+merge/126966
<soniah> Is there anything else I need to do? More a question about process, as I'm unsure how the process works...
#ubuntu-devel 2013-09-30
<pitti> Good morning
<pitti> rbasak: psql version> thanks for confirming
<dholbach> good morning
<darkxst> seb128, hi
<darkxst> I fixed Bug 1228939 if you have time for a review
<ubottu> bug 1228939 in gnome-control-center (Ubuntu) "The "turn screen off when intactive for" option is not saved" [High,Confirmed] https://launchpad.net/bugs/1228939
<darkxst> not sure about the on_shell_disapeared crash, though it looks like a use-after-free issue
<didrocks> seb128: cjwatson: hey, it seems that lubuntu has ubuntu-system-settings installed by default. That discussion rings a bell to me with something about edubuntu, what was the fix needed?
<seb128> Laney, ^
<seb128> didrocks, is lubuntu using gnome-control-center?
<Laney> http://cdimage.ubuntu.com/lubuntu/daily-live/pending/saucy-desktop-amd64.manifest
<seb128> didrocks, some of the indicators recommends u-s-s | g-c-c
<Laney> I don't see it there
<didrocks> Laney: seed-in-ubuntu says   lubuntu: supported
<didrocks> it's not installed then? just supported?
<Laney> I don't know how supported is generated
<didrocks> (that won't block in the automatic UNAPPROVED queue?)
<didrocks> I guess that's our only question ;)
<Laney> didrocks: it will
<didrocks> ahâ¦
<didrocks> I think it's weird that ubuntu-system-settings is supported by lubuntu
<didrocks> seb128: does it make sense to you? ^
<Laney> It's automatically generated, I just don't know how
<Laney> ubuntu-system-settings | ubuntu-system-settings | indicator-bluetooth | Ubuntu Desktop Team <ubuntu-desktop@lists.ubuntu.com> | 833194 | 2125
<Laney> from germinate
<seb128> oh, indicator-bluetooth Depends on ubuntu-system-settings | gnome-bluetooth
<seb128> lubuntu is not using gnome-bluetooth right?
<cjwatson> didrocks: The fix for Edubuntu was in livecd-rootfs 2.189; but I don't think that situation applies to Lubuntu.
<cjwatson> didrocks: If the standard germinate output lists ubuntu-system-settings, then Lubuntu needs some different fix.
<didrocks> cjwatson: ok, so yeah, probably what seb128 just told ;) sorry for mapping the same issue mentally
<cjwatson> Yep
<didrocks> seb128: I don't see indicator-bluetooth in the manifest
<seb128> didrocks, wait, indicator-bluetooth is not listed
<seb128> right
<seb128> I was coming from what Laney copied
<didrocks>   lubuntu: supported
<didrocks> though
<didrocks> for indicator-bluetooth
<seb128> cjwatson, do you know how lubuntu:supported is built?
<cjwatson> I expect it's just the usual germinate supported seed
<cjwatson> http://people.canonical.com/~ubuntu-archive/germinate-output/lubuntu.saucy/supported
<seb128> darkxst, hey, thanks for the g-c-c fix, I'm going to have a look. The other segfault could be a callback not disconnect properly or something?
<cjwatson> ubuntu-system-settings <- indicator-bluetooth <-(recommends) unity <- libunity-2d-private-dev <- rescued from unity
<seb128> hum
<cjwatson> That might be fixable with Extra-Exclude
<seb128> indicator-bluetooth                     | indicator-bluetooth                    | unity (Recommends)                          | Ubuntu Desktop Team <ubuntu-desktop@lists.ubuntu.com>          |           54158 |             248
<Laney> what does rescued from mean?
<seb128> why is unity listed on the lubuntu list?
<cjwatson> it means it's a binary from a source some other part of which is in main
<cjwatson> er, not in main, included in the seed expansion for the seed structure
<cjwatson> I could explain or I could fix it :)
<Laney> Well, if we manage to understand then we might be able to fix such things in future
<cjwatson> So, there's a thing where we try to automatically ensure that *-dev packages are supported
<cjwatson> That's done by this entry in supported:
<cjwatson>  * Extra-Include: *-dbg *-debug *-dev *-doc *-docs *-gcj gir1.2-* *-examples
<cjwatson> Which automatically adds any package matching *-dev (etc.) from any source which produces a binary which is in the expansion of supported or any seed inside it
<cjwatson> Sometimes this misfires
<cjwatson> Say, if you have a source package that generates foo-data libfoo1 libfoo1-dev and you only care about foo-data and not libfoo1
<cjwatson> In such cases you can add Extra-Exclude lines to filter them back out again
<cjwatson> In this case what's happening is that ubuntu-defaults-builder depends on unity-common, which is provided by libunity-core-6.0-8; and ubuntu-defaults-builder is seeded in lubuntu.saucy/supported-development-desktop
<cjwatson> Just testing a fix now
<Laney> I see; the last unity is a source package name and the first is (obviously) a binary
<cjwatson> Yes
<cjwatson> http://bazaar.launchpad.net/~lubuntu-dev/ubuntu-seeds/lubuntu.saucy/revision/277 should fix this
<didrocks> thanks cjwatson :)
<cjwatson> I don't know how often the seeded-in-ubuntu data is updated
<cjwatson> It's quite possible it'll take a day or so
<Laney> Forgot how to get into the box
<didrocks> ok, meanwhile maybe Laney can fast-process indicabot-bluetooth, ubuntu-system-settings and the qt things if needed I guess
<Laney> oh no, here we go
<seb128> hum, it's a bit suboptimal that the unity stacks end up in the lubuntu supported set only for a gsettings schemas
<cjwatson> seb128: Huh?
<cjwatson> seb128: Where are you seeing that?  That's not the path I traced and fixed
<seb128> cjwatson, "ubuntu-defaults-builder depends on unity-common, which is provided by libunity-core-6.0-8;"
<cjwatson> seb128: And I fixed that ...
<seb128> oh, ok
<cjwatson> I mean, sure, it still pulls in that one binary
<cjwatson> But that doesn't pull in the whole stack
<seb128> I see
<cjwatson> Just libunity-core-6.0-8 and libunity-protocol-private0
<seb128> so it's mostly the unity source, which is ok
<seb128> cjwatson, thanks
<cjwatson> Well, and unity-services
<cjwatson> But yeah, it's not all the indicators and stuff any more
<darkxst> seb128, the signal is disconnected slightly after the destroy, however I don't think thats the problem other we would also see on_unity_dissappeared crashes
<seb128> darkxst, yeah, I don't really know, I didn't look at the code, it's just a frequently reported issue ... seems to happen for gnome-shell users at logout
<darkxst> seb128, yeh, I have seen it hovering quite high on errors.u.c
<darkxst> though if its happening at logout its actually quite harmless, and will just disappear once crash reports are disabled
<seb128> darkxst, you are still going to get whoopsie, that's never disabled
<darkxst> well they dont go to launchpad ;)
<darkxst> anyway I will try work out the problem, but I have only seen the crash once here
<seb128> darkxst, right, I don't care much about launchpad noise, rather about those users getting the annoying prompt on their screens...
<mpt> The most frequent crash in Ubuntu is a bug that was fixed in an update six weeks ago.
<ritz> mvo ping
<mvo> ritz: pong
<ritz> mvo wrt https://code.launchpad.net/~mvo/software-center/lp926763/+merge/187206
<mvo> ritz: thanks, give me a minute or two
<mardy> seb128: hi! Can you have a look at https://bugs.launchpad.net/ubuntu/+source/evolution/+bug/1210866?
<ubottu> Ubuntu bug 1210866 in evolution (Ubuntu) "Ubuntu Online Accounts integration broken in Saucy" [Undecided,Confirmed]
<ritz> mvo++
<mardy> seb128: the next question is: provided that EDS 3.9.5 doesn't bring in new dependencies (which I've yet to verify), do you think we could ship it in saucy?
<seb128> mardy, hey, was exactly about it?
<seb128> mardy, no, it's too late to take on a new e-d-s serie
<seb128> mardy, next cycle
<mardy> seb128: OK
<seb128> mardy, the goa split was buggy, I have it on my list for this week, I'm just going to undo it
<seb128> mardy, not sure what to do about the password prompt issue...
<mardy> seb128: you don't think we could update just EDS, if it doesn't bring in new dependencies?
<seb128> mardy, I doubt it, it's almost release time, not time to bring such changes in
<Laney> It'll be a transition
<mardy> seb128: not even post-release, as an update?
<seb128> mardy, no, we don't do major updates in SRUs
<seb128> Laney, is there soname changes?
<Laney> yeah
<Laney> well, maybe not for 3.9.5 but certainly for 3.10
<Laney> it is e-d-s after all :P
<mardy> seb128, Laney: a diff of the configure.ac between the 3.8.4 and 3.9.5 releases shows that the _CURRENT field of some libs was bumped (I don't remember if that counts as a soname bump)
<mardy> seb128, Laney: http://paste.ubuntu.com/6175141/
<seb128> mardy, the soname is current-age iirc
<Laney> It does, that's the major version
<Laney> And we couldn't take a random mid-cycle development version anyway
<mardy> Laney: OK
<Laney> Maybe the individual fix is cherry-pickable, but I'd bet probably not
<mardy> Laney: I could have a look at it
<mardy> Laney: no, it doesn't seem to be cherry-pickable
<labsin> ping mardy
<mardy> labsin: pong
<labsin> mardy, I'm trying to add a online account provider but I run in errors
<labsin> mardy, they told me you could maybe help
<mardy> labsin: yep. Do you have the .provider file somewhere online where I can see it?
<labsin> mardy, http://pastebin.com/sV0qcwHs
<mardy> labsin: where is the mobilevikings OAuth API documented? I can't find it
<labsin> mardy, https://mobilevikings.com/api/2.0/doc/
<mardy> labsin: right, just found it. Your file seems correct, what error do you get?
<labsin> mardy, If I launch gnome-control-center verbose, I get "(gnome-control-center:1194): account-plugin-WARNING **: AuthSession error: GDBus.Error:com.google.code.AccountsSSO.SingleSignOn.Error.OperationFailed: Operation failed."
<labsin> http://paste.ubuntu.com/6175651/
<mardy> labsin: I need to quit now, could you please send me more logs to e-mail? (set the LoggingLevel to 2 in /etc/signond.conf, and then you'll see more logs in the syslog)
<mardy> labsin: alberto.mardegan@canonical.com
<labsin> mardy, tnx
<pitti> jibel: FYI, I reported bug 1233185 with a simplified test case of what is broken in gdb-multiarch for retracing ARM
<ubottu> bug 1233185 in gdb (Ubuntu) "gdb-multiarch cannot read ARM cores: "wrong size gregset struct in core file"" [Undecided,New] https://launchpad.net/bugs/1233185
<jibel> pitti, thanks, subscribed. For the moment, I produce most traces on the phone.
<pitti> jibel: it seems precise's gdb-multiarch still works, so I'll run the ARM ones under precise
<pitti> jibel: do you happen to have a bug # handy for one which is broken?
<pitti> jibel: using bug 1227546
<ubottu> bug 1227546 in unity8 (Ubuntu) "unity8 crashed with SIGSEGV" [Undecided,Invalid] https://launchpad.net/bugs/1227546
<jibel> pitti, ok or bug 1233191 . It's smaller than unity8
<ubottu> bug 1233191 in upstart-app-launch (Ubuntu) "zg-report-app crashed with signal 5 in _start()" [Undecided,New] https://launchpad.net/bugs/1233191
<jibel> pitti, trace on 1233191 looks a bit better
<pitti> re
<pitti> jibel: indeed, at least usable
<catbus1> Hi, anyone know when the next UDS will be?
<smartboyhw> catbus1, approximately October 20 something (I believe)
<catbus1> smartboyhw: ok, like right after 13.10 is release.. thanks.
<catbus1> s/release/released
<dobey> catbus1, smartboyhw: november would be 3 months since the last one
<smartboyhw> dobey, so? Aren't we planning for 2 months?
<smartboyhw> (Or maybe the Community Team changed it's schedule, dunno)
<dobey> smartboyhw: they are supposed to be every 3 months afaik
<dobey> and they have been
<smartboyhw> I remembered it was one in April, one in June, one in August-.-
<stgraber> so far we had early March, mid-May and end of August
<dobey> right
<dobey> and the march one was the odd one out
 * smartboyhw does not exactly like vUDS, anyhow
<smoser> stgraber, if you have some time .. https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1231988 would be nice to read that.
<ubottu> Ubuntu bug 1231988 in isc-dhcp (Ubuntu) "isc-dhcp-server creates pid and leases file with root:root if running unpriviledge" [Undecided,New]
<stgraber> smoser: might be good to have mdeslaur double check the patch, but a quick look through looks good to me so I guess we can add that to our package
<stgraber> smoser: (and you're correct that ISC doesn't have a public bug tracker, as annoying as that's ...)
<smoser> stgraber, the real pita is there...
<smoser> that we have will then have this is we have to patch the package to deal with the old-working, old-broken, now-working
<stgraber> yeah, it's really quite annoying having to watch 3-4 distros to figure out who already found a particular issue and then try and share patches...
<smoser> hey...
<smoser> anyone have suggestions on this approach.
<smoser> for 'python-simplestreams' it contains some function that depends on some openstack libraries (python-glanceclient, python-swiftclient).
<smoser> we want python-simplstreams to be installable without those.
<smoser> the suggestion that rbasak had was just to add a metapackage 'python-openstack' that had the depdends.
<smoser> and drop the depends form python-simpelstreams
<smoser> err.. 'python-simplestreams-openstack' above (not 'python-openstack').
<smoser> hm... barry maybe ? sorry to call you out by name, but this seems to be a reasonbable solution to me. anyone?
<barry> smoser: at quick glance (sorry, very busy atm) that seems reasonable
<smoser> thank you. (i fully understand the "very busy" disclaimer)
<jtaylor> barry: would you sponsor a new numpy stable release rc for saucy?
<jtaylor> final release might not be done for saucy, but many changes are unlikely
<barry> jtaylor: i'm slammed right now.  if you can't find anyone else, ping me again in a few hours
<jtaylor> not today, generally
<robert_ancell> mterry, did you test that make check works with the new --standalone change? I fixed the tests yesterday
<robert_ancell> mterry, (I'm pretty sure it will fail with that change)
<robert_ancell> mterry, though we can just ditch the standalone now  we have https://code.launchpad.net/~mterry/unity-system-compositor/assume-standalone/+merge/188395 right?
<robert_ancell> oh, I see the no-standalone branch now
<mterry> robert_ancell, yeah though I should update no-standalone to drop the handling in the test u-s-c
<mterry> robert_ancell, OK, updated both branches' test USCs
<mterry> robert_ancell, I'm not super pleased with the assume-standalone branch.  I wish Mir's option handling let you specify a default for an option (rather than as an argument to get() each call)
<mterry> robert_ancell, and I wish that default showed up in help() automatically
<robert_ancell> mterry, yeah, I don't know of any method to do that
<brainwash> seb128: can you have a look at bug 1231978 please? it looks like the recent gvfs "bug fix" update is causing some trouble, affecting thunar and pcmanfm users
<ubottu> bug 1231978 in thunar (Ubuntu) "Thunar 1.6.3 locks when browsing Trash with Xubuntu 13.10 Beta 2 and following dailies" [Undecided,Confirmed] https://launchpad.net/bugs/1231978
<seb128> brainwash, somebody should report the issue upstream, I didn't do that update
<brainwash> seb128: ok, I'll report it upstream after some more testing, thanks :)
<seb128> brainwash, yw, thanks for reporting it there
<tomreyn> hi
<tomreyn> i'm looking for some statistics on how many users there are (or just ISO downloads) on 32 vs 64 bit
<tomreyn> any idea where i could find those?
<jtaylor> tomreyn: http://popcon.ubuntu.com/
<jtaylor> 64 vs 32 debian is interesting too, there 64 overtook 32 a short while ago: http://popcon.debian.org/
<tomreyn> jtaylor: thank you!
<tomreyn> that's like a year ago
<tomreyn> i guess you could consider that a short while based on debian's lifetime
<sarnold> tomreyn: don't forget that at least ubuntu.com/download suggests 32 bit and pre-selects 32 bit..
<sarnold> tomreyn: depending upon what you're trying to measure (installed architectures vs types of CPUs in use) you might get skewed results one way or another..
<tomreyn> sarnold: thanks, i'll keep this in mind. but i'm really after what people use as installed architectures, so i guess i'm fine.
<tomreyn> what's the design choice behind defaulting to 32-bit, i never understand this.
#ubuntu-devel 2013-10-01
<hallyn> tomreyn: making 64-bit the default has been proposed many times.  i thought it might happen this cycle...  guess it didn't
<slangasek> hallyn: the cycle's not over yet
<tomreyn> i remember there were limitations regarding 64-bit releases in the past, as mentioned on the release notes
<tomreyn> but maybe those could just be shifted if maintaining stuff for both archs involves too much effort
<tomreyn> i bet people looked into this already...
<sarnold> I think it's more to do with end-user confusion and success-rates for not knowing much about their computer when they download something to burn to disc.
<hallyn> slangasek: here's hopin' :)
<pitti> Good morning
<dholbach> good morning
<mlankhorst> morning
<mlankhorst> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.10 Beta 1 released | Archive: frozen | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mlankhorst
 * dholbach hugs mlankhorst
<pitti> jdstrand: apparmor's Vcs-Bzr: is 6 versions behind, are we not using this any more?
<pitti> jdstrand: I'm about to do an upload for bug 1227520, so I'll just use the UDD branch
<ubottu> bug 1227520 in apparmor (Ubuntu) "Timezone changes are not working due to ro /etc and bind mounts" [High,In progress] https://launchpad.net/bugs/1227520
<pitti> doko_: good morning, how are you?
<pitti> doko_: does the patch in bug 1233185 look okay to you?
<ubottu> bug 1233185 in gdb (Ubuntu) "gdb-multiarch cannot read ARM cores: "wrong size gregset struct in core file"" [Undecided,New] https://launchpad.net/bugs/1233185
<infinity> pitti: That looks sane, except that it might be nice to see what "all" evaluates to currently, to see if you're leaving anything out.
<ogra_> cjwatson, classmate-tools ?
<ogra_> i wasnt aware thats still in the archive
<infinity> pitti: Either way, regressing for some random arch we don't ship in favour of fixing things on ARM seems a safe option for today.
<pitti> infinity: I'll have a look how I can find out what "all" does; hopefully it's just some kind of static macro that will get expanded in config.h or so
<infinity> pitti: Looks like it ends up with ALL_64_TARGET_OBS + ALL_TARGET_OBS = \
<infinity> pitti: From gdb/Makefile.in
<infinity> pitti: But then I'm not sure why ARM wouldn't work, as arm-linux is in there.
<pitti> infinity: but maybe not arm-linux-gnueabihf/arm-linux-gnueabi ?
<infinity> pitti: Not sure gdb has such a distinction there.
<infinity> pitti: All the same objects included in 'arm*-*-linux*)' in configure.tgt are also included in ALL_TARGET_OBS, so it's a bit confusing why this change would work.
<infinity> pitti: Unless what's actually happening is that including some OTHER targets (like arm-symbian, etc) ends up breaking arm-linux.
<pitti> infinity: I don't know, I'm afraid; I bisected it down from "broken since precise" to that change, but I have no idea how gdb works internally or what that "wrong size of gregset" thingy wants to tell me :(
<infinity> pitti: Anyhow, disabling a bunch of targets we don't deeply care about seems like the path of least resistence for now, until someone can unwind this further.
<pitti> infinity: ah, so now one could bisect the targets to see whether/which one breaks arm-linux, or whether something with "all" is broken in general?
<infinity> pitti: Yeah.  My hunch is that if you keep adding new arm* targets (armbsd, arm-symbian, etc), you'll find that one of them blows up your arm-linux support.
<infinity> pitti: And then maybe we could just patch that target out of all in Makefile.in
<infinity> pitti: But, like I said, I doubt anyone deeply cares about debugging Solaris binaries on Ubuntu and, since they couldn't do so in precise either, meh.
<infinity> pitti: Your fix should work for now, and an upstream and/or Debian bug on the matter should probably happen.
<pitti> infinity: right, I was going to forward it to Debian
 * pitti uploads for now
<infinity> pitti: Can you do me a favour and copy and paste the above conversation into the bug, so context doesn't get lost the next time someone wants to look into it?
<infinity> I need to pretend I'm sleeping.
<pitti> infinity: yes, I will
<pitti> infinity: so, good night!
<infinity> pitti: Oh, and rejecting.  Please add aarch64 to your static list.
<infinity> pitti: We should probably at least support all the arches in the archive, after all. :)
<pitti> infinity: I guess that's not the literal value?
<pitti> ack
 * pitti still has trouble grepping for what "all" does, even greppign for "arm-linux" is rather unhelpful
<infinity> 'aarch64*-*-linux*)' is the case.  aarch64-linux-gnu should work.
<pitti> infinity: thanks; doing a test build with that, and reuploading
<infinity> pitti: Grepping your build log for aarch64-linux-tdep.o should probably show if it's being built and linked in.
<pitti> infinity: still, I want to test it; it might be that aarch64 is the very thing that breaks armhf, after all
<infinity> pitti: Could be.  That would be a shame.
<infinity> But indeed not implausible, if aarch64 was a cargo-cult from arm, and linking both arm.o and aarch64.o ends up overloading some rather useful symbol.
<pitti> infinity: *phew*, build with aarch64 still works
<infinity> pitti: I was almost hoping it wouldn't, as we would have found our culprit. :P
<infinity> pitti: But yay.
<pitti> uploaded
<pitti> submitted to Debian
<infinity> Tempted to say we probably want to update to 7.6.1 too, but it might be a bit late to validate that.
<infinity> It looks like almost entirely bugfixes, some of which looks nice.
<infinity> Actually, no almost about it, it's nothing but bugfixes.
<infinity> Maybe I'll mull that over in the morniing.
<infinity> But I see no mention of your bug, so it's probably still an issue.
<pitti> infinity: you could keep it in -proposed for a few days and send a call for testing?
<infinity> pitti: https://sourceware.org/bugzilla/show_bug.cgi?id=15415 in particular is a bug that drives me batty and is fixed in 7.6.1
<ubottu> sourceware.org bug 15415 in gdb "gdb resolves symbolic links when passing argv[0]" [Normal,Resolved: fixed]
<infinity> pitti: Yeah, I'll give some thought to an update tomorrow.  And ping you to test a build with and without 'all' for curiosity, though I expect it to be broken still.
<cjwatson> ogra_: Generally when something is broken I prefer fixing it over arguing whether it should still be there.  The latter can be done separately. :-)
<ogra_> cjwatson, yeah, i just wasnt aware it is still there :)
<ogra_> i'll file  a removal bug
<zyga> hey, supposedly there is a bug somewhere around mounting nfs on boot that affects 12.04, what would be the best way to try to debug that?
<zyga> I use a few nfs mounts on my box, including /home and a few with bootwait
<zyga> my boot success rate is about 30%, the rest fails on one of the remote volumes not mounting (and basically hanging the box on plymouth)
<xnox> zyga: and you are not hitting bug #1217041 ?
<ubottu> bug 1217041 in initramfs-tools (Ubuntu Saucy) "initramfs-tools: please include separated nfs modules" [Undecided,Fix released] https://launchpad.net/bugs/1217041
<zyga> looking
<xnox> zyga: ah, if you do succeed it's probably not that.
<zyga> xnox: no, I'm on 3.2 here
<zyga> xnox: I found too many issues with backported kernels overall and I've decided to stick with 3.2
<xnox> zyga: in that case mountall debug output would be useful. In saucy it's as easy as booting with "--debug" in the kernel cmdline, but in precise you need to modify mountall.conf job to add "--debug"
<zyga> so generally, i have a freenas box with a bunch of nfs shares and a 12.04 desktop wired together, the network is flawless, no packet loss or anything, networking is via network manager (but I tried with static for the same effect)
<zyga> xnox: ok, let me try that
<zyga> xnox: if I get a hang, what can I do to look at logs or just poke around?
<zyga> xnox: I recall M or S used to work but I don't see those anymore (maybe it's just not displayed)
<xnox> zyga: those key-combos should work. pressing Esc should show boot messages (or boot without quiet). Plus will you have a local /var available? in that case logs will be saved in /var/log/upstart/mountall.log.
<zyga> ok, it seems like it has hanged again, I see (after hitting esc on the early boot screen)
<zyga> local 2/2 remote 0/3 virtual 11/11 swap 0/0
<zyga> xnox: could it be a bug in my nfs setup? like /home/ and /home/zyga/source being both mounted in the wrong order/causing stalls
<zyga> xnox: note, I cannot use either M or S to jump to any console,
<xnox> zyga: stgraber recently had a problem, how does your fstab look like?
<zyga> xnox: yeah, /var is local
<zyga> xnox: I'll try to pastebin it in a sec, I cannot tell from memory
<xnox> zyga: stgraber did a bind-mount by UUID, instead of proper LVM names.
<zyga> xnox: also the output from mountall/upstart is very confusing -- I see 'mount /home [495] zakÅczone normalnie' (finished normally), then, 'mounted event handled for /home' but then, confusingly 'local 2/2 remote 0/3 ...' (as if nothing remote was mounted yet)
<zyga> xnox: I don't use LVM here, just a small SSD with large nfs mounts
<zyga> so still hanged, no way to get to a shell, should I just reboot?
<zyga> xnox: fstab http://paste.ubuntu.com/6178860/
<zyga> xnox: no mountall logs as far as I can see
<zyga> xnox: modified mountall.conf http://paste.ubuntu.com/6178865/
<xnox> zyga: i usually do without "--daemon" to get logs.
<zyga> ah, ok
<zyga> xnox: should I also remove 'expect daemon' theh?
<xnox> zyga: yes.
<zyga> ok, trying again
<zyga> xnox: rebooted ok, no mountall logs in /var/log/upstart
<xnox> =/ hm.
<zyga> http://paste.ubuntu.com/6178893/ mountall.conf just to be sure
<jodh> zyga: try changing /etc/init/tty6.conf to specify 'start on startup' so that you can login to a shell. I wonder if mountall is crashing (ls /var/crash/? )
<zyga> jodh: thanks, worth checking!
 * zyga reboots to try again
<zyga> ok, given the tty now, I'll reboot till it hangs
<zyga> jodh: so mountall isn't crashing
<zyga> I'm in a shell now, with the boot hanged as before
<zyga> network is up and working
<zyga> http://pastebin.com/f5xxu3Xu
<zyga> that's ps aux
<jodh> zyga: Still no mountall.log? What does /var/log/boot.log show?
<zyga> jodh: no mountall.log, nope
<jodh> zyga: ah - you need to change mountall.conf to include "console log".
<zyga> jodh: doh :) right, I'll patch that
<zyga> quick question, how can I change early boot to english so that everyone can read it?
<zyga> jodh: boot.log http://pastebin.com/tkMD5qxz
<zyga> ok, rebooting
 * zyga thinks of a magic key sequence that starts tty6 
<zyga> jodh: ^^ :)
<zyga> ok, stuck again
<zyga> inspecting logs
<zyga> jodh: so _no_ mountall logs again, no idea why though
<zyga> mountall is _not_ running
<zyga> jodh: initctl list -> http://paste.ubuntu.com/6178962
<zyga> note that I have my pastebin conf and that home has mounted
<zyga> I actually wonder why it is stuck, it seems _everything_ is mounted now
<zyga> mount -> http://paste.ubuntu.com/6178964
<zyga> xnox, jodh, any idea on why it's not proceeding now? I'm looking at initctl list and I have no idea what might be wrong
<zyga> jodh: having commented out 'expect daemon' from /etc/init/mountall.conf, and removed '--daemon' from 'script' below, should that job work okay?
<zyga> jodh: I just noticed that mountall.conf has 'console output' already with a funny comment above ti
<zyga> jodh: my console log was _above_ the pre-existing console output so we probably didn't get any logs because of that
<xnox> zyga: do you get logs without "console output"
<zyga> xnox: checking now, I'll reboot again
 * xnox should check how i used to get logs from mountall
<zyga> (it's quite interesting why the failure rate is now 100%)
<zyga> rebooting
<zyga> xnox: I think we'll get logs now
 * zyga would like to switch to platform team for a cycle and work on mir early boot and upstart-and-friends verbose development boot monitoring support
<zyga> xnox: mountall.log \o/
<zyga> mountall.log <- http://pastbin.com/F7tBU1mi
<zyga> (note, I type-copy each pastebin URL, if they don't work please tell me)
<jodh> zyga: that pb doesn't work for me.
<zyga> http://pastebin.con/RzNZHRz1
<zyga> jodh: I think I made a typo in pastebin.com above (forgot one 'e'), this is a fresh one now
<xnox> http://pastebin.com/RzNZHRz1
<zyga> how do I switch locale to C.UTF-8 or something like that?
<xnox> zyga: that seems to show everything is ok.
<zyga> xnox: so indeed I have all the things mounted
<zyga> xnox: but ... no desktop
<zyga> xnox: fallback graphics is curious
<xnox> well then =)
<zyga> could it be the case
<zyga> that fallback graphics kicks in somehow
<zyga> (because of nfs boot delay)
<zyga> and somehow stops my normally working graphics?
 * xnox installed nvidia by accident (i have intel) and that breaks dekstop / lightdm. Also installing ubuntu-touch / surface-flinger breaks things.
<zyga> udev-fallback-graphics.log is full of vesafb insertion errors
<zyga> xnox: I don't have those installed here
<xnox> zyga: anything interesting in lightdm logs?
<zyga> I've adde manual to fallback grapics
<zyga> xnox: aww, I just rebooted, IIRC lightdm didn't start though
<zyga> xnox: (I moved all old logs aside and i dind't see any lightdm logs this time)
<xnox> zyga: they are under /var/log/lighdm/*
<zyga> ah
<xnox> *lightdm
<zyga> ok, cleared logs and trying again
<zyga> and it does hang each time now
<zyga> I wonder if I made it worse
<zyga> or are we just lucky for debugging
<zyga> xnox: lightdm doesn't start at all, no logs
<zyga> xnox: upstart/plymount-ready-startup.log has just one line "Terminated"
<zyga> jodh: so why does mountall.log claim that remote 0/3 is mounted: I have many more filesystems _and_ they are mounted
<xnox> zyga: well at the end it claims "local 2/2 remote 2/3 virtual 11/11 swap 0/0"
<zyga> xnox: now it claims 0/3
<xnox> if that's a full pastebin that is, and there is nothing that was after.
<xnox> hm
<zyga> I keep rebooting after changing something to see if it helps
<jodh> zyga: can you remove "--verbose" from mountall.conf as it's overriding "--debug" I think.
<zyga> xnox: http://pastebin.com/W3BxKFSY
<zyga> jodh: ok
<zyga> rebooting
 * zyga wants to rewrite mountall into rust/go/python
<zyga> C is great but after a few years in python C feels like middle ages :/
<zyga> jodh: http://pastebin.con/iuv4XtEv
<xnox> zyga: *shrug* all of those are too heavy and too big that early in the boot process.
<zyga> xnox: heavy? big?
<zyga> xnox: python, yeah, rust/go
<xnox> zyga: and with libnih, C looks quite neat.
<zyga> xnox: and python would be easier to maintain probably (if having access to all glibc stuff wasn't a probleM)
<zyga> anyway
<zyga> xnox: true
<zyga> xnox: libnih is very nice
<zyga> hey, note that I seem to randomly get pastebin.com pastebin.ubuntu.com, it's still a random mount or not here
<jodh> zyga: looks like you fstab is invalid - you have specified "1" the fsck field for /home/zyga/source, but "1" is reserved for the root FS. Change it to "2" (or "0" like the rest).
<zyga> and it's mounted now (/home)
<zyga> oh
<zyga> cool
<zyga> jodh: fixed, trying again
<zyga> what are the last two fields for?
<zyga> dump and pass
<zyga> (I used 0 this time)
<jodh> zyga: man fstab
<zyga> ah
<zyga> ok, same result
<jodh> zyga: last pb also invalid
<zyga> jodh: com not con, it should work, sorry
<zyga> jodh:
<zyga> \o/ desktop up, after a slight delay
<zyga> let's retry
<jodh> zyga: try commenting out the nfs entries in fstab starting with /home/zyga/source to see if they are causing the problem.
<zyga> jodh: ok, rebooting, commented out 'source' and switched locale to C.UTF-8
<zyga> jodh: could the wrong value of pass cause the problem?
<zyga> mountall.log (nothing mounted yet) pastebin.com/rmsTYkf1
<zyga> jodh: desktop up, everyting got mounted
<zyga> jodh: mountall.log just a moment later, pastebin.com/q21qQrbW
<rbasak> pitti: any opinion on an FFe for subversion for bug 1209493? This is to enable libapache2-svn again after it got dropped from the Apache 2.4 transition. It just got an NMU upload to DELAYED/5 to Debian and the diff looks sensible (presumably we'd want to wait for it to land first, certainly).
<ubottu> bug 1209493 in subversion (Ubuntu) "libapache2-svn missing in saucy" [Undecided,Confirmed] https://launchpad.net/bugs/1209493
<zyga> rebooting, I'll keep trying to see if I can hang it
<cjwatson> Some days I hate optipng
<pitti> rbasak: sounds good to me (although please note that I don't have formal u-release powerrs)
<rbasak> pitti: understood. Thanks!
<pitti> rbasak: but it was obviously a temporary dropping of the package, so bringing it back seems right if it builds now
<rbasak> Perhaps I misunderstand what we do with optipng, but where it is effective, can we send the optimised png back upstream? And then perhaps keep a list of hashes for pngs that we already know are optimised.
<jodh> zyga: great. Please can you raise a bug on this (with details of when this stopped working if possible).
<zyga> jodh: hmm, wait, I'm not yet sure what the problem is, I can only report that I had a problem and commenting out that nfs share (and fixing pass value on it) made it go away
<doko> pitti, I'm fine with it. I think that was introduced by lool some time ago. but then we need aarch64-linux-gnu too in this list
<zyga> jodh: let me reboot a number of times again to check if it's the same
<pitti> doko: yes, infinity already brought that up, and I added it
<zyga> jodh: also, I'd like to get that share back there, I mean, if it's the root cause the I can manage but I don't know that yet
<pitti> doko: thanks
<jodh> zyga: that's prolly enough for now if we can recreate the bug with a setup similar to yours. When did this problem first start? Has a recent update caused the breakage?
<zyga> jodh: no, it was bugging me ever since I started using nfs about a year ago
<zyga> jodh: I was just not rebooting
<zyga> jodh: I didn't have 'bootwait' before
<zyga> jodh: and I manually started mounting after (rare) reboots
<zyga> jodh: the only thing I made now (recently) was to put /home on nfs
<zyga> jodh: but that's the equivalent of bootwait
<zyga> jodh: and I had that for a while earlier after reading mountall to find out about it (I don't think it is documented)
 * zyga thinks he spoke too soon, rebooted, it seems to have hanged (no changes made)
<zyga> http://paste.ubuntu.com/6179062
<zyga> yup, stuck
<jodh> zyga: upstart appends to its logs files. would be clearer if rotate/delete the existing files each boot.
<zyga> jodh: ah, true, thanks
<jodh> zyga: unclear what the problem is atm, but please raise the bug as slangasek is the nfs guru.
<zyga> ok
<zyga> thanks for the help jodh, xnox!
<zyga> jodh: on mountall?
<xnox> zyga: nfs and mountall =)
<xnox> zyga: bug against mountall.
<zyga> jodh: https://bugs.launchpad.net/ubuntu/+source/mountall/+bug/1233610
<ubottu> Ubuntu bug 1233610 in mountall (Ubuntu) "boot process hangs very often when NFS shares are used" [Undecided,New]
<zyga> jodh: does that look good?
<jdstrand> pitti: it is used, we are just horrible at keeping it up to date. I saw the change, we'll update the branch
<rbasak> If a package provides a daemon, would it be considered a requirement that the daemon is listening (in this case on a Unix socket) when the package postinst finishes? I have a race with another package that depends on this, and it seems that the daemon is taking a little while longer to start up.
<xnox> rbasak: well, does it have an upstart job?
<cjwatson> I don't know about a requirement but I would consider it good software engineering.  I suggest that you fix the upstart job to wait properly
<cjwatson> (You might find "expect stop" useful)
<rbasak> This is libvirt-bin starting libvirtd. It does have an upstart job.
<rbasak> I'm not sure how to amend the upstart job though. I think it's waiting until the daemon forks, so upstart considers it "started".
<cjwatson> Like I say, "expect stop" is handy
<rbasak> I'm patching libvirt with a sleep to test that hypothesis now, as it's a bit tricky to reproduce
<cjwatson> You need to arrange to run without forking to use that, but it lets you cause upstart to consider the job started at the exact point of your choosing
<cjwatson> With a patch to the daemon, typically, but a trivial one
<rbasak> Ah - I see. So the daemon needs to send SIGSTOP to pid 1?
<cjwatson> No
<cjwatson> The daemon needs to send SIGSTOP to itself
<cjwatson> Pid 1 will send it SIGCONT once it's noticed
<rbasak> I get it - thanks. This would be an Ubuntu-only patch, then?
<cjwatson> It's fairly crude, but effective :)
<cjwatson> Could be pushed to Debian
<cjwatson> This is of course assuming there isn't some other way, but if it doesn't listen until after it daemonises ...
<rbasak> Wouldn't it break the daemon using another init system? I guess I'd need a command line option to enable that. Would you consider such an option mandatory for an Ubuntu patch?
<xnox> rbasak: you can check if there is UPSTART_JOB in the environment ;-)
<rbasak> xnox: that feels even worse! :)
<rbasak> Thanks for the discussion. I'm investigating the code in more detail now.
<xnox> jodh: shouldn't upstar texport UPSTART_EXPECTS_STOP in the environment, when launching expect stop jobs?
<rbasak> It looks like there's code in libvirtd to not exit the foreground (pre-fork) process until the second child has start listening on the socket. But my understanding of upstart's docs is that it waits for the second fork only with "expect daemon". So I guess I need a script stanza that does daemonize but then kill -STOP $$ or something instead of an exec, and then "expect stop" instead?
<rbasak> Hmm. But then upstart won't be tracking the correct pid.
<cjwatson> rbasak: I used an environment variable when I did this in openssh
 * rbasak looks
<cjwatson> rbasak: It's not in the archive yet, but http://anonscm.debian.org/loggerhead/pkg-ssh/openssh/trunk/revision/3578
<cjwatson> sshd's upstart job already arranges not to fork
<cjwatson> not on startup anyway
<cjwatson> rbasak: with the code in libvirtd you describe, maybe "expect daemon" is all you need
<cjwatson> rbasak: that pattern isn't a totally unusual one, and should be manageable; "expect stop" is for when the daemonising isn't quite lined up with "ready to operate"
<rbasak> cjwatson: thanks. I'll use that as a model. libvirt-bin already uses "expect daemon". I think the problem is that on the fork itself, we aren't at "ready to operate". The code signals instead by the first process exiting. But I think that upstart uses the second fork instead of additionally wait()ing on the top level process.
<rbasak> Would there be any harm if upstart also waited on the top level process for "expect daemon" or "expect fork"?
<zyga> slangasek: ping?
<smoser> mvo, if you have some time, i'd appreciate thoughts on bug 1233486
<ubottu> bug 1233486 in software-properties (Ubuntu) "add support for 'cloud-archive:' like 'ppa:' but for cloud archive" [Undecided,New] https://launchpad.net/bugs/1233486
<smoser> if there is someone more appropriate to request from let me know that too
<mvo> smoser: sure, I should find some time to look at this today - btw, what ever happended to the by-hash requirement for apt? is this still a issue or was this solved in a different way?
<smoser> its still an issue.
<smoser> rbasak, has just not gotten around to fixing it.
<smoser> i think the biggest reason that it becaame much less problematic was that canonical IS changed a setting in the mirrors that made squid happier.
<smoser> but i dont recall the details of that.
<rbasak> I would still like to fix it. But I find working on apt very time consuming, needing me to disappear in a corner for a week at a time, and I haven't had time to do that recently :(
<rbasak> That part of apt's source is very spaghetti-like.
<smoser> rbasak, be nice :)
<rbasak> I've filed bug 1228210.
<ubottu> bug 1228210 in uvtool "libvirt-bin upstart job considers service "started" before it is ready" [High,New] https://launchpad.net/bugs/1228210
<rbasak> I've written up everything I know right now and I'd appreciate comment.
<mvo> rbasak, smoser thanks for the update and yes, its unfortunately relatively ugly code that deals with that part in apt
<rbasak> mvo: yeah it's unfortunate. I don't mean to criticise anyone specifically there - it's quite obvious how it's come about - a pile of needed features (security, compression, etc) without anybody having the time to refactor it.
<smoser> rbasak, i knew you weren't *actually* being mean, and i think mvo did too.
<mvo> yeah, no worries :)
<rbasak> Phew :)
<mlankhorst> Can someone accept mesa, xorg-server and glamor-egl? A few bugs popped up after the introduction of egl and after some testing I believe those are fixed now with the uploads. :)
<diwic> zequence-work, ping, do you have upload rights for ubuntu-studio packages?
<smartboyhw> diwic, zequence-work and OvenWerks are trying to get upload rights, but they currently don't.
<diwic> ok
<xnox> diwic: i did a few uploads for ubuntu-studio lately. what's up?
<cjwatson> slangasek: Could you please merge multistrap to make pdebuild-cross installable in saucy?
<diwic> xnox, wanna sponsor a ftbfs ?
<xnox> diwic: do you have URL?
<infinity> diwic: Wouldn't sponsoring something that builds be better? :)
<diwic> xnox, http://pad.lv/1233685
<ubottu> Launchpad bug 1233685 in ardour (Ubuntu) "Ardour FTBFS on saucy" [Undecided,New]
<diwic> infinity, nah, I don't think you have enough work already. :-)
<cjwatson> bigon,kenvandine,dholbach: Is there any point in keeping the meta-telepathy source package in the archive?  It has never been in Debian, has no reverse dependencies, seems to attract bugs that should live somewhere else, and apparently telepathy-devel-gtk has been uninstallable since lucid without anyone noticing or caring
<diwic> xnox, hold it
<diwic> xnox, actually, it still fails, when you start it. *facepalm*
<dholbach> cjwatson, no, very likely not - I don't know anyone using it - it stems from a time when the telepathy stack was just a 5-10 not-very well interconnected pieces of software
<dholbach> cjwatson, shall I file a bug for that?
<cjwatson> Please
 * kenvandine agrees
<kenvandine> i forgot it even existed
<dholbach> cjwatson, bug 1233702
<ubottu> bug 1233702 in meta-telepathy (Ubuntu) "Please remove meta-telepathy from the archive" [Undecided,New] https://launchpad.net/bugs/1233702
<dholbach> thanks for bringing it up
<bigon> cjwatson: +1
<cjwatson> removed, thanks
<dholbach> great
<diwic> xnox, ok, so the ardour interface seems to start as it should. So probably an improvement after all, compared to not building at all. But there are more linker failures to sort out too...
<slangasek> zyga: hi, so what's the symptom you're experiencing with nfs?
<slangasek> cjwatson: ack
<zyga> slangasek: hey
<zyga> slangasek: I've tried to do my best to describe it in a bug report, let me pull it up
<zyga> slangasek: https://bugs.launchpad.net/ubuntu/+source/mountall/+bug/1233610
<ubottu> Ubuntu bug 1233610 in mountall (Ubuntu) "boot process hangs very often when NFS shares are used" [Undecided,New]
<mlankhorst> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.10 Beta 1 released | Archive: frozen | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<mlankhorst> bb
<slangasek> xnox: more useful than a /var/log/mountall.log from a successful boot would be one from a failed boot...
<slangasek> er, sorry
<slangasek> zyga: more useful than a /var/log/mountall.log from a successful boot would be one from a failed boot...
<jamespage> doko, any chance you could do the honours on bug 1213915
<ubottu> bug 1213915 in ceph (Ubuntu Saucy) "Please demote ceph-mds and ceph-fs-common to universe" [High,New] https://launchpad.net/bugs/1213915
<rbasak> xnox: do you know of a bug or blueprint to track EXITED in upstart, please? If not, should I add a wishlist bug for that? I figure that if something is planned then a minimal workaround in the meantime would be best, which in this case could be a simple wait-for-the-socket in uvtool-libvirt.postinst.
<zyga> slangasek: I'll provide one to the same bug report as soon as I can, we have an important release today
<xnox> rbasak: combination of https://bugs.launchpad.net/upstart/+bug/530779 and https://bugs.launchpad.net/upstart/+bug/406397
<ubottu> Ubuntu bug 530779 in upstart (Ubuntu Precise) "init: does not wait for parent to exit when following forks" [Medium,Triaged]
<ubottu> Ubuntu bug 406397 in upstart "init: job stuck with expect fork/daemon when parent reaps child" [Medium,Triaged]
<xnox> slangasek: what's the new mechanism that keybuk keeps on talking in those bug reports?  This - http://netsplit.com/2011/02/09/the-proc-connector-and-socket-filters/ ?
<rbasak> xnox: thanks!
<jodh> xnox: the proc connector is a netlink facility, but it doesn't work in containers.
<xnox> jodh: i'm not sure what netlink is, and define containers - doesn't work in lxc?
<slangasek> xnox: you mean "proc connector"?  It's... proc connector :)
<jodh> xnox: kernel socket thing. yes, it fails in lxc.
<slangasek> fails in lxc> boo
<slangasek> even with user namespaces?
<jodh> slangasek: haven't tried that.
<slangasek> well, they're fairly new AIUI
<xnox> slangasek: well keybuk in those bugs doesn't say that he was planning to use "proc connector", only some random commenter said that.
<jodh> xnox: https://lists.ubuntu.com/archives/upstart-devel/2011-August/001707.html
<xnox> jodh: ah, thanks. That's from before my time =)
<xnox> jodh: `* Introduce "expect exit <n>" syntax.' sounds highly unreliable, if there is a variable amount of exits.
<slangasek> xnox: ah, misread your original question and didn't look at the bugs, sorry.  Yes, I think proc connector was his long-term vision for fixing this problem
<slangasek> xnox, jodh: yeah, I don't like 'expect exit <n>'.  People can fix their code to daemonize sensibly, or not at all + SIGSTOP.
<jodh> xnox: the link was primarily for you wrt the proc connector; we're not now planning to implement 'expect exit' :)
<jodh> slangasek: ack
<xnox> slangasek: with respect to tracking exits, we'd need to build a tree of all forked processes (and forks of thereof) and monitor both FORK and EXIT and mark off in the the tree those that exited, and then what? -> for expect fork, take the first fork that is still running after the parent has exited? -> for expect daemon, take the first double fork that is still running after the parent has exited? and if there are no such declare defeat.
<slangasek> xnox: I don't think you actually need a tree; you just track parent + child, and if the child exits before the parent, you scratch that pid off the list and wait for the next child
<pitti> yay, lots of autopkgtest failures due to uninstallable X on amd64
<pitti> jibel: ^ FYI; can retry tomorrow morning, or if you are still around later tonight, maybe you can
<pitti> plars: ^ or you
<xnox> slangasek: well, what if the child[2] is the one that ultimately does the double fork? for "expect fork" yeah one can use list(parent, child1, child2, child3) and simply take the first still alive child after parent has exited.
 * xnox somehow thinks for "expect daemon" we need "grand-children"
<plars> pitti: is there a process you normally follow for identifying when it's ready to retry, and which ones to retry?
<slangasek> xnox: we can assume a daemon has certain characteristics, such as the fact that the "grandparent" doesn't exit until its currently lead child is the one that's going to fork again to give us the daemon
<pitti> infinity: you could keep it in -proposed for a few days and send a call for testing?http://people.canonical.com/~ubuntu-archive/testing/saucy-proposed_probs.html stops spitting out a gazillion xorg packags
<pitti> WTF
<pitti> infinity: ^ sorry about that, that was an utter paste fail
<slangasek> xnox: we don't need to support all crazy combinations of fork+exit, only the ones that make sense for a daemon - and for other cases, we just need upstart to not get wedged
<pitti> plars: as soon as http://people.canonical.com/~ubuntu-archive/testing/saucy-proposed_probs.html stops spitting out a gazillion xorg failures
 * pitti waves good night
<pitti> hmm, we are down to two amd64 builders, of which one is offline :/
<slangasek> rbasak: ah, nice post on upstart-devel, are you the one who triggered this current discussion? ;)
<xnox> slangasek: I see, i keep fearing that "leading child" is "pre-warm cache long task" which eventually dies after the parent has exited, with the second child (untracked) which did the double fork.
<rbasak> slangasek: thanks. Yes. I was chasing a race and wasn't aware of the previous discussion on this.
 * pitti bumps https://launchpad.net/ubuntu/+source/xorg/1:7.7+1ubuntu5/+build/4970241 but it seems it doesn't even get an ETA
<pitti> anyway, waaay past my EOD time, cu all
<xnox> slangasek: yes, rbasak triggered this irc -> email -> irc discussion.
<slangasek> xnox: it's possible that such things exist, but I don't see any way to make that work with 'expect daemon' anyway - how is upstart supposed to know that child[1]->grandchild[1][0] is the real daemon, and child[0] is the long task, instead of child[0] being the daemon still starting up and grandchild[1][0] being the task which happens to have double-forked?
<slangasek> we have to have some assumptions
<rbasak> I found https://blueprints.launchpad.net/upstart/+spec/return-pid-from-exec when I was googling earlier. Did that prompt any further discussion, and could it be useful for the really obscure cases?
<rbasak> (as a generic catch-all)
<rbasak> Effectively allowing complex cases to deal with the required logic themselves
<xnox> slangasek: well, in that case doesn't this reduce to: keep tracking forks as we do + track parent (patient0) exit => declare started when we found our fork + patient0 has exited?
<slangasek> xnox: yes
<cjwatson> pitti: The one that's disabled isn't actually amd64, it's just temporarily faking it so that we still see the amd64 queue length even when all the builders are assigned to i386 to clear the test rebuild queue there faster.
<cjwatson> pitti: I've given amd64 another builder for a bit, but the non-test-rebuild saucy queues are still strongly imbalanced (i386: 75, amd64: 16) so I think 6:2 is about as much towards amd64 as we ought to go for now
<cjwatson> pitti: And the problem isn't the amd64 queue anyway, it's the build failure on i386 ...
<cjwatson> Hmm, unexplained abort in the test suite
 * cjwatson retries it in the hope that it might stick
<cjwatson> pitti: https://launchpad.net/ubuntu/+source/xorg/1:7.7+1ubuntu5/+build/4970241 is arm64, not amd64
<cjwatson> pitti: arm64 isn't going to build for a while :-)
<cjwatson> pitti: I've scored that back down - it's not appropriate for it to be second in the arm64 queue
<cjwatson> (For avoidance of doubt, if you aren't involved in the arm64 bootstrap, please leave its build scores alone)
<cjwatson> Though I realise it was a mistake here
<cjwatson> There we go, xorg-server/i386 looks happier now on a retry
<jibel> pitti, adt jobs fixed after a retry.
<stokachu> stgraber: http://paste.ubuntu.com/6181286/, am i missing something to allow my image to be mounted within lxc under precise?
<stokachu> stgraber: http://paste.ubuntu.com/6181297/ the bottom portion shows the output failure from within lxc
<stgraber> stokachu: I don't think your problem is with apparmor but instead with you not allowing loop devices in the container config
<stokachu> stgraber: in my lxc.customize parameter ive setup "aa_profile", "lxc-container-default-with-loops"
<stokachu> stgraber: should i be adding something else to that?
<stokachu> stgraber: i found your post about it http://www.mail-archive.com/lxc-users@lists.sourceforge.net/msg03673.html
<stgraber> stokachu: did you add the lxc.cgroup.devices.allow lines?
<stokachu> stgraber: cgroup.devices.allow = b 7:* rwm and cgroup.devices.allow = c 10:237 rwm
<stokachu> stgraber: was that all i needed?
<stgraber> should be
<stokachu> ok lemme kill this container and try once more
<stokachu> stgraber: sweet! it worked :D:D
<stokachu> stgraber: im not finding much documentation on lxc+pxe boot, is that something that isn't supported?
<slangasek> stokachu: lxc+pxe <blink>?
<slangasek> lxc is a container; it doesn't get its own kernel; what would lxc+pxe mean?
<stokachu> ah sorry the guests would not be lxc
<sarnold> a friend is curious if there's a path forward for this packaging request: https://bugs.launchpad.net/ubuntu/+bug/1231114
<ubottu> Ubuntu bug 1231114 in Ubuntu "[needs-packaging] python-bsdiff" [Wishlist,New]
<cjwatson> It'd need to get re-maintained and back into the Ubuntu development series first, preferably by way of renewed maintenance in Debian, before there's any chance of having it in a stable Ubuntu release
<sarnold> cjwatson: thanks :) probably it isn't the answer he'd like to hear, but .. porting from python 2.ancient to newer doesn't sound like fun unless you -need- that package. Thanks!
<cjwatson> Porting to 2.7 probably isn't that horrible
<cjwatson> Indeed that's stated in the bug
<cjwatson> We like to have Python 3 support, but it isn't yet a requirement for archive inclusion, neither in Debian nor in Ubuntu
<cjwatson> So I don't think that's the point - it needs somebody taking care of the package enough to cancel out the reasons it was removed from Debian in the first place
<sarnold> so many packages, so little time..
#ubuntu-devel 2013-10-02
<smoser> hey. roaksoax uploaded maas today to saucy. can I get get an ACK on that to release pocket ?
<Noskcaj> Is there any way to tell what packages in main are O or RFA in debian?
<pitti> Good morning
<pitti> wow, no cjwatson on IRC
<stgraber> yeah, I suspect his home internet went down again. He disconnected a while back with a ping timeout and hasn't reconnected on IRC or been heard from since.
 * zyga updated bug 1233610 with logs from failed boot
<ubottu> bug 1233610 in mountall (Ubuntu) "boot process hangs very often when NFS shares are used" [Undecided,New] https://launchpad.net/bugs/1233610
<dholbach> good morning
<ion> that
<Noskcaj> Will ubuntu have a Powerpc image next cycle since Qt5.2 should work on PowerPC?
<rbasak> I'd like to pull a delayed upload out of Debian ftp-master.d.o/deferred, but only the .changes file exists. Other packages in that queue have source packages, just not this one. Any ideas? It's subversion in http://ftp-master.debian.org/deferred/
<cjwatson> You'll have to ask the Debian uploader.
<cjwatson> Or a Debian ftpmaster
<rbasak> Thanks. Out of interest, why is it different from the other packages there? Is it something the uploader decides? He pasted the patch in the bug, so I can use that. I'm just wondering for future reference.
<cjwatson> I don't know
<cjwatson> I know of no uploader-accessible control for this
<cjwatson> A Debian ftpmaster might be able to figure it out; perhaps it's a bug
<rbasak> If you don't know then I figure it's worthwhile asking then. Thanks.
<xnox> rbasak: which package?
<rbasak> xnox: subversion
 * rbasak has asked in #debian-ftp
<rbasak> cjwatson, xnox: in case you're interested, it was because the upload involved (re-)adding "new" binaries, causing the whole thing to be hidden.
<cjwatson> OK
<jamespage> rbasak, I've got a similar one - http://ftp-master.debian.org/new/python-lesscpy_0.9j-2.html
<cjwatson> I'd actually thought of that but I had incorrectly dismissed the idea on the basis that deferred wouldn't yet know about the binaries
<jamespage> :-(
<cjwatson> Which is of course nonsense in Debian
<rbasak> I wanted it to re-add libapache2-(mod-)svn so the reason I looked is exactly the reason I can't get it. No matter - I have other options, or can just wait.
<jamespage> cjwatson, I need to pull that new version of lesscpy into Ubuntu Saucy, but its stuck in Debian NEW due to a new binary package
<pkern> cjwatson: delayed weren't actually dak parsed. deferred is.
<jamespage> is there a precendent/good way of doing that?
<cjwatson> jamespage: ask the uploader for a copy of the package
<cjwatson> pkern: Yeah
<jamespage> cjwatson, and sign and upload that to saucy?
<cjwatson> jamespage: Or give an ftpmaster chocolate
<cjwatson> (Debian ftpmaster that is)
<cjwatson> jamespage: Yes.  If it can be fast-tracked into Debian and synced, though, that's better
<cjwatson> jamespage: Decrement the version if you upload it to saucy directly
<cjwatson> jamespage: i.e. append ~ubuntu1
<rbasak> Oh. Does that mean that subversion will also get stuck in NEW after the delay?
<cjwatson> Then we can sync the real version later and have it properly linked to the Debian one in the DB
<cjwatson> I believe so
<cjwatson> Although subversion is pretty high-profile so it wouldn't surprise me if it were processed rather quickly
<jamespage> cjwatson, OK - I can pull it directly from the debian git repository if need be
<ricotz> doko, hello, maybe you remember this one https://bugs.launchpad.net/ubuntu/+source/libx11/+bug/1163805 -- i am hitting this building the current libx11 master in a ppa
<ubottu> Ubuntu bug 1163805 in libx11 (Ubuntu Raring) "libx11 ftbfs in raring (building the docs)" [High,Invalid]
<ricotz> https://launchpadlibrarian.net/152123093/buildlog_ubuntu-saucy-i386.libx11_2%3A1.6.2%2Bgit20131002.18a5278b-0ubuntu0ricotz_FAILEDTOBUILD.txt.gz
<doko> ricotz, and?
<ricotz> doko, sorry, i was hoping you have an idea why this happened/happens?
<ricotz> doko, doesnt seem to be a toolchain problem though
<doko> no. didn't look. it's only one of the outstanding ftbfs
<ricotz> doko, i see
<sergiusens> jodh, ping
<jamespage> rbasak, just uploaded that nagios/apache2.4 cgi fix
<jamespage> (beat you to it)
<cjwatson> yolanda: openerp-desktop seems to have been uninstallable ever since it was first introduced in quantal, because it depends on openerp-core which doesn't exist.  Could you investigate?
<tjaalton> doko: mlankhorst said it could be due to a bug in w3m, and I've requested a sync from debian which has a newer patched revision and the changelog claims it fixes some segfaults
<tjaalton> synced w3m that is
<mlankhorst> oh perfect
<mlankhorst> I'll retry the libx11 build then
<tjaalton> well the sync needs to be processed first :)
<xnox> cjwatson: openerp-core was attempted to be included multiple times but it was kept on getting rejected (mainly because it's massive and embedds a lot of 3rd party python & javascript projects)
<tjaalton> but i think it should be safe to sync since it's already in testing since august
<cjwatson> yolanda,xnox: In that case perhaps openerp-desktop should be demoted to saucy-proposed until such time as openerp-core is in; it's not wrong in itself but we shouldn't expose it to users until it's installable, IMO
<mlankhorst> tjaalton: lies, I'll just backportpackage it from sid and retry building in the ppa :P
<tjaalton> mlankhorst: of course :)
<xnox> cjwatson: agree. I kind of gave up on openerp packaging, didn't have spare time and in the mean time it's moved on to a next major series.
<yolanda> cjwatson, i can take a look
<xnox> yolanda: are you still packaging openerp?
<cjwatson> yolanda: Has the third-party-embedding situation with openerp-core improved significantly?
<yolanda> cjwatson, xnox, i haven't touched openerp since i packaged it first time, i think
<yolanda> cjwatson, what do you mean with third-party-embedding?
<cjwatson> 13:20 <xnox> cjwatson: openerp-core was attempted to be included multiple times but it was kept on getting rejected (mainly because it's massive and embedds a lot of 3rd party python & javascript projects)
<cjwatson> yolanda: ^- that
<xnox> yolanda: it hasn't made it into the ubuntu archive proper yet https://launchpad.net/ubuntu/+source/openerp-core
<xnox> cjwatson: hm. bad rename? https://launchpad.net/ubuntu/+source/openerp6.1 provides openerp6.1-core
<yolanda> well, they deployed a new version, openerp 7, and it's totally different
<xnox> yolanda: shouldn't then openerp-desktop depend on openerp6.1-core instead of openerp-core?
<yolanda> xnox, cjwatson, correct files are openerp6.1, openerp-desktop and openerp-core are not valid
<cjwatson> yolanda: Should openerp-desktop simply be removed, or is it worth updating?
<yolanda> openerp6.1-full does the same as openerp-desktop
<yolanda> so openerp-desktop can be removed
<rbasak> jamespage: thanks!
<cjwatson> yolanda: OK, for tracking, please file a bug on openerp-desktop with reasoning, and subscribe the ubuntu-archive team
<yolanda> ok
<cjwatson> sconklin: I may have to cancel some of your PPA kernel builds for a buildd upgrade happening soon.  If I do then I'll retry them afterwards
<cjwatson> (I don't recall whether you get mailed about cancelled builds)
<zyga> slangasek: hey
<smoser> anyone know how to run the test suite for software-properties ?
<smoser> in https://code.launchpad.net/~smoser/software-properties/shortcut-refactor/+merge/188500 i've busted something, but i can't get it to run
<smoser> http://paste.ubuntu.com/6183814/
<pitti> smoser: hm, that seems to be the correct command; the autopkgtest uses exactly this and succeeds (https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-software-properties/)
<smoser> pitti, i'm embarrased to ask. but is there a way for me to run the same stuff sans the vm launch ?
<cjwatson> There's an LXC runner somewhere in the pipeline
<cjwatson> Or you can do it with adt-virt-schroot but you don't get network isolation
<pitti> smoser: no, I meant to say "python setup.py test" is supposed to just work
<pitti> smoser: (and it does here)
<pitti> apt-get source, python setup.py test, success
<pitti> smoser: same with sudo (it skips some tests as non-root)
<sconklin> cjwatson:  I didn't see any email. This is a production week for us, what are the time frames for canceling/retrying the builds?
<cjwatson> sconklin: I already retried them
<cjwatson> so they should restart within a few tens of minutes
<sconklin> ack, thanks
<cjwatson> sorry but it's impossible to have the build farm entirely clear and I've been trying to get hold of a sysadmin for this upgrade since Friday ...
<smoser> pitti, ok. so i'm doing something really stupid then,
<smoser> apt-get source software-properties.
<smoser> cd software-properties-0.92.26
<smoser> python setup.py test
<smoser> http://paste.ubuntu.com/6183992/
<dobey> smoser: missing build-depends?
<smoser> dobey, no. i have them.
<cjwatson> sconklin: Of the five builds in question, two built before the upgrade, two are building now, and one is due to start in 8 minutes.
<sconklin> cjwatson: ack, thanks
<zyga> slangasek: around?
<larsu> doko: hi! how are you? I've just found a gcc regression and hear you're the one who cares about them :)
<doko> larsu, just one?
<larsu> doko: haha ya. I've just found the list of regressions online. Crazy!
<larsu> doko: what do you advise? File an upstream bug?
<infinity> sconklin: FWIW, I mentioned the upgrades in another channel you're in a half hour before you poked Colin. :P
<doko> larsu, well, a launchpad bug first please
<sconklin> infinity: fwiw I'm in a number of channels and unless you type my nick, I probably won't see it
<larsu> doko: will do
<smoser> ok. i'm clearly doing *something* stupid (this is nothing new).
<smoser> I run this on a fresh cloud instance (saucy)
<smoser> http://paste.ubuntu.com/6184053/
<smoser> out.log looks like this:
<smoser> http://paste.ubuntu.com/6184063/
<smoser> which is exactly what i'm seeing here.
<smoser> pitti, ? anyone. i' realize i'm  probably doing something terribly stupid, but i'd appreciate someone pointing it out ot me.
<smoser> i'll also note that 'test_lp' likely references 'tests/test_lp.py'
<infinity> smoser: Well, it kinda looks like the build-deps don't include the packages required to run that test.  Just sayin'.
<smoser> infinity, so then adt-pkg-test is doing something else to fix it .
<smoser> right?
<infinity> smoser: Well, the adt test installs software-properties itself.
<infinity> smoser: (And, in fact, all the packages produced by the source)
<infinity> smoser: Which, in turn, depends on all those missing modules.
<smoser> infinity, thank you.
<smoser> infinity, ugh. so
<smoser> sudo apt-get install python-software-properties python3-software-properties software-properties-common software-properties-gtk software-properties-kde
<smoser> did not solve my problem.
<infinity> smoser: You still get all the same failed imports?  Really?
<smoser> yes
<smoser> infinity, http://paste.ubuntu.com/6184127/
<pitti> smoser: do you actually have tests/test_lp.py?
<smoser> yes
<smoser> $ ls -l tests/test_lp.py
<smoser> -rwxrwxr-x 1 ubuntu ubuntu 3945 Jul 30 11:48 tests/test_lp.py
<ubottu> Ubuntu bug 3945 in Launchpad itself "Support debtags in Launchpad for products and packages" [Low,Triaged] https://launchpad.net/bugs/3945
<smoser> i suspect that the issue is the name 'tests' is conflicting with something else
<smoser> i'll let anyone interested in helping into the node to poke around
<smoser> but this is what i've done http://paste.ubuntu.com/6184138/
<smoser> (recently aded the install of packages)
<rbasak> smoser: is this a namespace conflicts that needs a from __future__ import absolute_import? I've not looked in detail at all - it just has a whiff of that.
<smoser> rbasak, i'm not familiar with that. but i do think its a namespace conflicts.
<rbasak> I'm not sure what you're doing, but when you mentioned the name "tests", it makes me suspicious.
<xnox> smoser: python3 setup.py test ?
<xnox> vs python2....
<smoser> xnox, same thing actually. almost identical
<xnox> unless you have tried that already.
<xnox> =(
<smoser> http://paste.ubuntu.com/6184392/
<sil2100> Hi again! Anyone from the SRU team free for https://bugs.launchpad.net/unity/+bug/1043627 analysis? Thanks!
<ubottu> Ubuntu bug 1043627 in nux (Ubuntu Raring) "[SRU] Add XIM Support to Nux" [Undecided,Confirmed]
<zyga> jodh: ping
<jodh> zyga: hi
<zyga> jodh: is there a way to peek at, say, signal data intercepted via upstart-dbus-bridge?
<jodh> zyga: upstart-monitor
<zyga> jodh: I want to capture network manger StateChanged signal and trigger some scripts when that happens
<zyga> jodh: I mean in the job file
<zyga> jodh: can it go to a variable or something like that
<jodh> zyga: it already does: man dbus-event
<zyga> thanks, let me check those!
<zyga> jodh: so I should use ARG0... ARGN to filter on the values packed into the signal I want, correct?
<jodh> zyga: yes. Note that only bools, ints, strings and object paths are encoded though.
<zyga> ok, that's good enough
<zyga> cool
<zyga> I guess this will work
<zyga> I'll show you what I did in a second ^_^
<zyga> jodh: I cannot see dbus events with upstart-monitor, do I need to do something to be able to see them?
<zyga> jodh: and related to that, can I inspect ARG0 in my script section? or is that just for event matching?
<xnox> zyga: try --system bus?
<jodh> zyga: ah - you need to actually create a job that specifies "start on dbus" since otherwise the upstart-dbus-bridge won't bother proxying the signals into upstart as events. You can change that behaviour if you wish by running the bridge with '--always'.
<zyga> ah, thanks
<zyga> yeah, I thought that, I'm just writing my job and it wasn't ready to be placed there
<zyga> jodh: do I need to restart something for upstart-dbus-bridge to notice that I'm using dbus stanza? I just don't see any events (on dbus side)
<zyga> jodh: alternatively, do I need to specify each field (including SENDER?)
<zyga> ohhh
<zyga> I'm dumb
<zyga> 'dbus' vs 'start on dbus'
<zul> mterry:  ping cherrypy3 should be good to go https://bugs.launchpad.net/ubuntu/+source/cherrypy3/+bug/1229778
<ubottu> Ubuntu bug 1229778 in cherrypy3 (Ubuntu) "[MIR] cherrypy3" [High,Incomplete]
<mterry> zul, will look in a bit
<mterry> zul, thanks
<zul> mterry:  thanks
<mterry> zul, approved, thanks so much
<zul> mterry:  thanks
<zyga> damn
<zyga> upstart-dbus-bridge CLOBBERS PATH
<zyga> WHY
<zyga> :/
<zyga> I know why but it just sucks
<stgraber> zyga: this got fixed with the last upload
<stgraber> which is apparently stuck on autopkgtest...
<stgraber> xnox: http://10.98.0.1:8080/view/Saucy/view/AutoPkgTest/job/saucy-adt-upstart/
<zyga> stgraber: oh, so what is it being set to now?
<stgraber> zyga: OBJPATH IIRC
<zyga> stgraber: does it change how matching is done as well?
<stgraber> ok, just confirmed, it's indeed called OBJPATH now so you'll need to change your start conditions to use that (if you were filtering on PATH= before)
<zyga> stgraber: thanks, since that's an incompatible change, is this announced/documented somehow?
<stgraber> zyga: sorry don't have much more details, I just noticed that when going through the package uploads this morning
<zyga> thanks
<stgraber> zyga: I don't think so, the documentation was updated (manpage) but that's apparently about it...
<slangasek> zyga: not advertised widely, following the principle of "if you were relying on the previous behavior it didn't work anyway for obvious reasons"
<zyga> slangasek: well, I just patched DBUS_PATH=$PATH; PATH="..."
 * zyga suspects that dbus-file-bridge is broken :/
<slangasek> zyga: why's that?  It's being used successfully in various places
<zyga> slangasek: first, it sends create event for reasons beyond my understanding if the file already exists there
<zyga> slangasek: second, it does not seem to send modify event when the file changes, but this might be just me doing something wrong (still checking)
<zyga> slangasek: and I suspect that it's not looking at jobs being redefined, do I need to restart the machine for upstart to note that my job uses 'file' ?
<slangasek> zyga: expected behavior, if the file exists when first started you get an initial notification of its existence as a 'create' event
<zyga> slangasek: ah, then it must have eluded my reading of the man page
<slangasek> looking at jobs being redefined> you mean, the file bridge detecting that a job definition has changed?
<slangasek> I think that's supposed to work
<zyga> yes
<slangasek> you don't have any overlayfs in the mix, do you?
<zyga> slangasek: nope
<zyga> slangasek: nothing fancy, just stock 13.10
<slangasek> zyga: wrt bug #1233610, it would be interesting to know if this is reproducible with the nfs-common from quantal
<ubottu> bug 1233610 in mountall (Ubuntu) "boot process hangs very often when NFS shares are used" [Undecided,New] https://launchpad.net/bugs/1233610
<zyga> slangasek: I'll try, is this in backports?
<slangasek> zyga: 1:1.2.6-3ubuntu2 fixes a bunch of race conditions; the intent is to SRU it into precise now that mountall has cleared the SRU queue, but I haven't had a chance yet
<slangasek> (cf. https://bugs.launchpad.net/ubuntu/precise/+source/nfs-utils/)
<slangasek> zyga: not in backports, and shouldn't be; best bet for testing is just to manually install it
<zyga> slangasek: ok, I'll give it a try
<slangasek> zyga: the filesystems not being correctly tagged 'remote' also looks like a mountall bug, possibly one that's been fixed in saucy only; so if quantal nfs-common doesn't fix it, you may want to test with the newer mountall too
<zyga> slangasek: thanks, I'll try both
<zyga> slangasek: as for upstart bugs, I suspect that I'm either not using dbus syntax correctly or that dbus events are simply not ever forwarded, the only case that I see, is when I run upstart-dbus-bridge --always manually
<zyga> I'm using this:
<zyga> start on dbus INTERFACE=org.freedesktop.NetworkManager PATH=/org/freedesktop/NetworkManager SIGNAL=StateChanged
<slangasek> zyga: so still using PATH= ? maybe you want to upgrade to a version that uses OBJPATH, to be sure
<slangasek> zyga: is this a system-level job or a user-level job?
<zyga> slangasek: system level, let me upgrade to check if that changes
<zyga> slangasek: hmm, upstart is not in my upgrade list, is it still in some other place -proposed/
<stgraber> zyga: it's still in -proposed due to failing autopkgtest
<zyga> ah, right
<zyga> ok
<slangasek> stgraber: is the ADT failure the same as bug #1089159?  Seems hard to check now, since the jenkins frontend is currently unhappy
<ubottu> bug 1089159 in upstart (Ubuntu) "ADT test-suite failure" [Medium,Confirmed] https://launchpad.net/bugs/1089159
<stgraber> ...with missed reboot in utmp file
<stgraber> BAD: wrong value for utmp->ut_tv.tv_usec, got unexpected 487301
<stgraber> 	at tests/test_utmp.c:990 (test_write_runlevel).
<stgraber> /bin/bash: line 5: 15378 Aborted                 (core dumped) ${dir}$tst
<stgraber> FAIL: test_utmp
<stgraber> slangasek: ^ that's the current failure
<stgraber> slangasek: http://10.98.0.1:8080/view/Saucy/view/AutoPkgTest/job/saucy-adt-upstart/ARCH=amd64,label=adt/81/console works here (QA VPN)
<stgraber> (works as in, I can access the page showing me the test failure)
<zyga> so, new upstart installed
<zyga> start on line changed to...
<zyga> start on dbus INTERFACE=org.freedesktop.NetworkManager OBJPATH=/org/freedesktop/NetworkManager SIGNAL=StateChanged
<zyga> and still nothing in upstart-monitor or in a log (I just log all instances of this job being started)
<zyga> stgraber: remeber when I reported that on 12.04 pastebinit has '/usr/bin/env python' and sent a patch to fix that
<zyga> stgraber: it's still broken on saucy :/
<zyga> stgraber: you said you have a python3 version handy that fixed that
<zyga> slangasek: so about dbus-upstart-bridge, with this job, http://paste.ubuntu.com/6185493/ I see nothing in upstart-monitor, either docs are wrong or this just dones't work
<stgraber> zyga: I do, in a branch somewhere, I should probably look into that at some point... pastebinit is one of those, couple hours a year kind of project for me (since it mostly just works)
<zyga> stgraber: yeah, I know how that feels
<stgraber> zyga: the python3 branch is basically a rewrite to drop configobj and use much cleaner, readable python, though so far I haven't found the time to finish it...
<zyga> now if I start upstart-dbus-bridge --always I do see events, smells like a bug IMHO
<zyga> stgraber: cnf feels exactly like that
<stgraber> zyga: also, I usually hack on my personal project on the plane when traveling which doesn't work too well for pastebinit as most of the pain is interfacing with all the random servers :)
<zyga> stgraber: do you think it's possible to land that fix I sent you?
<zyga> grepping dbus in /etc/init shows that nothing is using this feature (start on dbus)
 * zyga files a bug on upstart
<mlankhorst> can someone drop libx11 from proposed? there's a bug in w3m somewhere which causes a FTBFS for the documentation, no idea how to workaround it yet :/
<mlankhorst> tempted to just drop the .txt documentation
<zyga> https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/1234393
<ubottu> Ubuntu bug 1234393 in upstart (Ubuntu) "upstart-dbus-bridge never forwards events without passing --always" [Undecided,New]
<stgraber> mlankhorst: just upload a fixed package, no need to remove it from proposed
<mlankhorst> I have no idea what the fix is yet :/
 * zyga calls it a day
<slangasek> stgraber: so I haven't wrapped my brain around what that test failure means... is that something you have time to dig into yet today and get upstart unstuck?
<slangasek> zyga: I have no hands-on experience with the dbus bridge, sorry
<slangasek> zyga: bug report is best :)
<stgraber> slangasek: kinda busy trying to finish the sourceforge -> github migration for LXC upstream (big backlog of patches). I may look into upstart later tonight if I find some time though. (I suspect xnox or jodh may be way more efficient at figuring that one out, though I agree it'd be better if we could have it fixed before the UK morning)
#ubuntu-devel 2013-10-03
<tjaalton> what dictates that :all builds are run on i386 and not on, say, amd64?
<Noskcaj> tjaalton, tradition
<tjaalton> makes sense, but would it then make sense to let amd64 build handle it?
<tjaalton> that would at least fix the libx11 build failure, where w3m crashes on i386 building docs :)
<tjaalton> though not enough of a reason to switch of course
<xnox> slangasek: stgraber: re: upstart-adt, i've seen that test-failure on very fast machines, at the time i was suspecting that libnih time resolution is no longer precise enough for the test in question, but I didn't dig too deep into it.
<xnox> jodh: ^ maybe we should finally fix https://jenkins.qa.ubuntu.com/job/saucy-adt-upstart/81/ARCH=amd64,label=adt/artifact/results/ ?
<jodh> xnox: looking at it now...
<xnox> https://jenkins.qa.ubuntu.com/job/saucy-adt-upstart/81/ARCH=amd64,label=adt/artifact/results/log/*view*/  BAD: wrong value for utmp->ut_tv.tv_usec, got unexpected 487301
<seb128> xnox, hey, are you looking at https://bugs.launchpad.net/ubuntu/+source/ubuntu-wallpapers/+bug/1216223 ?
<ubottu> Ubuntu bug 1216223 in ubuntu-wallpapers (Ubuntu) "Wallpapers for saucy salamander are being modified the wrong way, worsening their quality" [Medium,Confirmed]
<seb128> (I wonder if that's something we should fix before release)
<Laney> I mailed the guy who gave us the compressed versions
<Laney> but he didn't get back to me
<seb128> Laney, is that somebody from our design team?
<Laney> seb128: I don't know who it is
<Laney> it was on the mail you forwarded to me
<Laney> might have CCed you on my enquiry
<seb128> yeah, just found the bug back
<seb128> bug->email
<seb128> mpt, ^ do you know who in design could help on that?
<mpt> seb128, jnick_tait
<seb128> mpt, thanks
<xnox> seb128: thanks for the ping. I don't know how we usually get the wallpapers committed to the branch. Cause there is nothing in the package build that changes quality, and if we didn't take the best available images from flickr that's sad, and/or do we manually resize/crop them at all?
<Laney> some guy did some adjustments to make the size smaller
<seb128> xnox, I've no idea what the process is or what happened to them
<xnox> =/ i see.
<Laney> I think there was a size budget of 5M or so
<xnox> Laney: i understand a size budget on the default wallpaper, but not the community ones.
<Laney> why?
<Laney> they're installed by default too
<xnox> Laney: well it's memory mapped, so a huge default wallpaper will hinder default benchmarks and somesuch. The rest is just prettiness and we should take highest resolution images we can, think of cinematic iMac displays with huge resolution.
<seb128> xnox, the budget was to spare CD size when we still had that target
<seb128> not sure it still makes sense nowadays, though it's good to keep some control there
<seb128> otherwise we are going to drift
<Laney> I'm not aware that we have just let it go completely
<cjwatson> tjaalton: Historically we've found that more arch all builds have actually worked on i386.  The correlation isn't perfect
<tjaalton> cjwatson: ah, ok
<xnox> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.10 Beta 1 released | Archive: frozen | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: xnox
<xnox> slangasek: another nfs/mountall bug #1234613
<ubottu> bug 1234613 in mountall (Ubuntu) "NFS shares are not mounted at boot" [Undecided,New] https://launchpad.net/bugs/1234613
<zyga> jodh: hey, I filed a bug on upstart and upstart-dbus-bridge yesterday, have you had a chance to see it?
<jodh> zyga: I cannot recreate the problem you describe. As I say, create a job that specifies "start on dbus" and the bridge will start emitting events which will be visible at that point using upstart-monitor.
<zyga> jodh: which version of upstart were you running?
<jodh> zyga: version in saucy
<zyga> jodh: I created a job as described in the bug report
<zyga> jodh: and I only saw the stream of events after I started the bridge manually with --always
<jodh> zyga: as I say, I cannot recreate that behaviour.
<zyga> hmm
<zyga> jodh: is there any chance that your environment is somehow modified and that is concealing the problem, I'm running a fresh install of saucy and I can just reproduce that bug over and over
<jodh> zyga: identified your problem - bug updated.
<zyga> jodh: this bug? https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/1234393
<ubottu> Ubuntu bug 1234393 in upstart (Ubuntu) "upstart-dbus-bridge never forwards events without passing --always" [Undecided,Invalid]
<jodh> zyga: yes
<zyga> hmm
<zyga> so how can I get system dbus events?
<zyga> can I?
<ari-tczew> xnox: can you for me sponsor something @main?
<zyga> jodh: so does that mean that it's not possible to listen to signals on the system bus from system jobs?
<jodh> zyga: no, it simply means we don't start an instance of the dbus bridge connected to the system bus at the system level.
<zyga> jodh: well, why don't we?
<xnox> ari-tczew: can I has url/link?
<zyga> jodh: and is the solution to have a job that runs that that my other job needs to depend on?
<xnox> zyga: what system dbus events are you listening on?
<zyga> xnox: I wanted to listen to network manager events
<xnox> zyga: more specific?
<zyga> xnox: but that's not relevant really, it's about if that feature is available or not, is there a reason why this is restricted to session bus?
<zyga> xnox: StateChanged
<ari-tczew> xnox: https://code.launchpad.net/~ari-tczew/ubuntu/saucy/iptables/lp-1228525-1134554-1187177/+merge/187859
<xnox> zyga: system-wide events we already have "net-device-added|changed|down|removed|up"
<zyga> xnox: that's not the same
<zyga> xnox: and I don't seem to see 'down' events when I disable my network from nm (but I do see the associated network manager dbus signal)
<xnox> that's weird, i would have expected for you to see them.
<zyga> xnox: is there a reason why we're not running the system level dbus-upstart bridge or is this just an oversight?
<zyga> xnox: I see up events though
<xnox> zyga: we had it, and then removed. As far as I we figured, both dbus system & session events are only useful in user-session jobs. You are the first one to be using it in a system job.
<xnox> zyga: why are you using a system job? do you have to be root?
<zyga> xnox: yes
<zyga> xnox: well, it's very powerful, no need to have a silly daemon to lurk for that signal
<zyga> xnox: unless there's a security issue I think it's just as valid as the session bus, user bridge
<xnox> zyga: problem is that when we start system-dbus bridge on system level, those events are replayed to the session-init's =/
<zyga> hmm?
<zyga> I'm not quite sure I understand
<jodh> zyga: we don't run that a dbus bridge at the system level is security-related: see https://code.launchpad.net/~jamesodhunt/upstart/upstart-dbus-bridge/+merge/161772/comments/382554
<zyga> ah
<zyga> hmm
<zyga> well that's too bad
<zyga> I'll think about a workaround
<zyga> jodh: is there a bug open on that?
<jodh> zyga: not that I'm aware of; if you think there is a good reason to run that bus at the system level, feel free to raise a bug.
<zyga> jodh: I've filed https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/1234653
<xnox> zyga: well, you just need to add system level dbus-bridge job, and then you can add yours jobs on top of it.
<ubottu> Ubuntu bug 1234653 in upstart (Ubuntu) "upstart-dbus-bridge --system is not started on boot" [Undecided,New]
<xnox> zyga: jodh: strange thing is there is "net-device-up IFACE='eth0' LOGICAL='eth0' ADDRFAM='NetwokManager' METHOD='NetworkManager'" yet there is no matching "net-device-down" upstart event from network-manager.
<zyga> xnox: yeah, I can confirm that
<zyga> xnox: but
<xnox> when eth0 went down, from network-manager.
<zyga> xnox: could it be possible that nothing is listening to that so it's not being sent somehwo?
<zyga> somehow
<zyga> xnox: as for your comment, are you saying that I can just run the bridge myself as a separate job (not part of default install)
<xnox> zyga: i created "start on net-device-down \n exec env" and it wasn't run.
<xnox> zyga: yeap. =)
<zyga> xnox: won't that have the security issue that we described by jodh above?
<xnox> zyga: you need that bridge, so start it ;-)
<zyga> xnox: still it will work :) I'll give that a TRY
<zyga> try
<zyga> caps
<xnox> zyga: sure it will, but that's your choice ;-)
<zyga> http://paste.ubuntu.com/6187673/
<zyga> modified session job, I'll give it a try
<zyga> yeah, it works like a charm now
<xnox> jdstrand: slangasek: psivaa is reporting that today's desktop daily is failing SecureBOot certificate validation:
<xnox> $ sbverify --cert microsoft-uefica-public.pem /mnt/EFI/BOOT/BOOTx64.EFI
<xnox> warning: data remaining[1230256 vs 1355656]: gaps between PE/COFF sections?
<xnox> PKCS7 verification failed
<xnox> 139756278539968:error:21075075:PKCS7 routines:PKCS7_verify:certificate verify error:pk7_smime.c:342:Verify error:certificate has expired
<xnox> Signature verification failed
<xnox> jdstrand: can it be that certs in lp:qa-regression-testing/notes_testing/secure-boot/keys are out of date?
<ari-tczew> cjwatson: I'm encouraging one maintainer in Debian to get our delta (use B-D libtiff-dev rather than libtiff4-dev) applied there, as well. However, he has to get an extra reason to. is there a documentation/discuss for?
<xnox> ari-tczew: this http://release.debian.org/transitions/html/libtiff5.html
<cjwatson> ari-tczew: Short / more readable version of the above: it means that when the libtiff5 transition starts in Debian, his package will only need a binNMU (which can be done in bulk by the release team) rather than a coordinated upload
<cjwatson> There's only a single provider of libtiff-dev at any one time, so it's fine to build-depend directly on it without additionally stating a real alternative
<ari-tczew> cjwatson: ok, so I'll write that and additional he doesn't need to update B-D version every time - is it ok?
<cjwatson> Right
<ari-tczew> cjwatson: ok thanks
<psivaa> xnox: jdstrand: slangasek: the shim signature verification happens with today's *both desktop and server images..
<xnox> psivaa: "happens" as in passes or fails?
<psivaa> xnox: fails
<psivaa> sorry
<cjwatson> That's expected, same shim
<cjwatson> I mean, I'd be very surprised if they differed :)
<psivaa> ok :), was thinking if that'd indicate cert expiry
<ari-tczew> tumbleweed: I didn't know where should do I to report a bug to ubuntu-sponsorship-miner, so I'm writing here: since we upload things to *-proposed, your script recognizes syncs als sru.
<tumbleweed> ari-tczew: ah, that wouldn't suprise me
<ari-tczew> tumbleweed: is it possible to get a small whish there? counting search result, like: Sponsorships: 123
<xnox> slangasek: psivaa: precise 12.04.2 and raring are also failing sbverify in the same way (expired cert)
<ari-tczew> xnox: should do I update d/changelog @iptables?
<xnox> ari-tczew: nah, it's ok.
<psivaa> xnox: thanks for checking.. we dont have this test for other releases than the dev release
<xnox> TheMuso: do we want bug 1231367 and bug  1231365
<ubottu> bug 1231367 in at-spi2-atk (Ubuntu) "Sync at-spi2-atk 2.10.0-1 (main) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/1231367
<ubottu> bug 1231365 in atk1.0 (Ubuntu) "Sync atk1.0 2.10.0-2 (main) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/1231365
<xnox> psivaa: but precise-daily should have been running this?!
<cjwatson> it might've had a later sig from the last point release?
<psivaa> xnox: no, precise daily uses different script for the test. may be we should update that
<xnox> psivaa: i thought static-iso-validation.py thing is generic enough to run against precise images as well.
<xnox> (it has many guards and checks for things that are only application to e.g. precise or quantal and up and etc)
<psivaa> xnox: yea i think we have two versions of them :) one of which does not have this test
<xnox>  /o\
<psivaa> xnox: i'll try and update that
<ari-tczew> xnox: did you upload iptables to saucy-proposed?
<xnox> ari-tczew: check the queue.
<xnox> ari-tczew: you know where, right?
<ari-tczew> xnox: if you mean https://launchpad.net/ubuntu/saucy/+queue then I don't see or have wrong URL
<cjwatson> ?queue_state=1
<ari-tczew> ahh unapproved
<xnox> ari-tczew: drop down "unapproved" click apply.
<ari-tczew> ok got it
<xnox> =)
<ari-tczew> freeze...
<ari-tczew> xnox: don't mind pm speaking?
<tedg> stgraber, So we've got an issue where it seems that, randomly, some upstart jobs can't connect to dbus.
<tedg> stgraber, When we get crash signatures they don't seem to have DBUS_SESSION_BUS* in their environment.
<tedg> stgraber, Even if they're "start on started dbus"
<tedg> stgraber, Do you have any idea how that could happen?
<guest560139> hello
<guest560139> i just read the following article:
<guest560139> http://www.phoronix.com/scan.php?page=news_item&px=MTQ3NTU
<guest560139> and i like the suggestion at the end of it:
<guest560139> "Matthew additionally suggests as an option Canonical just drop XMir entirely and focus their resources on the Mir-based Unity 8 desktop."
<guest560139> so, any chance you could do that? just drop XMir entirely and focus on pure Mir and Unity 8?
<smartboyhw> OK, weird, but I'm seeing the latest 5 blueprints in https://launchpad.net/ubuntu/ about the same thing
<sconklin> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.10 Beta 1 released | Archive: frozen | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: xnox, sconklin
* smartboyhw changed the topic of #ubuntu-devel to: Ubuntu 13.10 Beta 2 released | Archive: frozen | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: xnox, sconklin
<smartboyhw> (It's Beta 2 certainly;))
<cjwatson> I wish I could restrict blueprint registration to developers
<smartboyhw> cjwatson, Ubuntu Members maybe
<cjwatson> Maybe
<cjwatson> I used to try to garden the list of Ubuntu blueprints, but it's just been a total mess for a long time because people think it's a good way to make random feature requests
<cjwatson> And various well-meaning bug triagers have been encouraging that behaviour
<seb128> cjwatson, I use to try to keep on top of the launchpad bug reports :p
<cjwatson> Yeah :)
<seb128> that seems the same sort of fighting windmills
<cjwatson> At this point it would be about a month of work doing nothing else just to get the Ubuntu blueprint list vaguely reasonable
<smartboyhw> cjwatson, :(
<cjwatson> (Not that I don't think users should be able to make feature requests or anything, but blueprints are an awful way to do it)
<smartboyhw> We should have a big big note on blueprint registration pages that says "If you want to make feature requests, please report a bug. We can only accept blueprints which are worked on." (That sort of thing, you guys write the wordings)
<cjwatson> I'd rather just ACL it
<smartboyhw> cjwatson, ACL it then (to ~ubuntu-members please, community people should still be able to use blueprints)
<cjwatson> The thing that makes it hard is that any ACL we come up with would have to apply sensibly to projects too
<tedg> stgraber, I've tried to start collecting data in a bug 1234731
<ubottu> bug 1234731 in dbus (Ubuntu) "DBus jobs not setting environment variables" [Undecided,Confirmed] https://launchpad.net/bugs/1234731
<cjwatson> The members slot might not be terrible, but it'd require discussion and probably argument, and I have so many other things to do ...
<smartboyhw> cjwatson, maybe I should spark the discussion?
<xnox> cjwatson: i wonder if that's spamming (~8 equivalent blueprints) or failure to find/realise the blueprint was filed =)
<smartboyhw> xnox, I saw 244 proposed blueprints filed for the "sprint" that the registrant has set up
<cjwatson> xnox: it's probably confused good faith
<cjwatson> *very* confused good faith
<cjwatson> smartboyhw: you could file an LP bug at least
<smartboyhw> cjwatson, sure, will do later
<cjwatson> ta
<Laney> mlankhorst: which xorg-server is good?
<mlankhorst> all of them
<mlankhorst> erm what exactly do you mean specifically? :P
<Laney> there are two
<Laney> https://launchpad.net/ubuntu/saucy/+queue?queue_state=1&queue_text=
<mlankhorst> erm tjaalton uploaded
<tjaalton> yes, delete the older one
<Laney> oh indeed
<tjaalton> git merge fail, or lack thereof
<Laney> they have the same date in .changes
<tjaalton> uh
<tjaalton> drop both then and I'll reupload
<Laney> hang on
<smartboyhw> cjwatson, xnox Bug 1234738 for you guys
<ubottu> bug 1234738 in Launchpad itself "Blueprint Registration should have been able to set ACLs" [Undecided,New] https://launchpad.net/bugs/1234738
<Laney> tjaalton: tell me the sha256sum of the .dsc
<tjaalton> a5b80eaf11c98aef6c4b130fcd907b35a0163cbf965464dcba3be40e8ee2f71e
<Laney> doesn't match
<tjaalton> huh
<cjwatson> smartboyhw: thanks
<Laney> https://launchpadlibrarian.net/152224844/xorg-server_1.14.3-3ubuntu1_source.changes https://launchpadlibrarian.net/152225662/xorg-server_1.14.3-3ubuntu1_source.changes
<tjaalton> ok drop both then?
<Laney> ok
<tjaalton> in fact I have an additional change that fixes a crasher with few dupes
<Laney> done
<tjaalton> uploading a refreshed version
<tedg> jodh, So I'm looking at this url-dispatcher crash file, and what's weird to me is that there isn't an UPSTART_JOB env var set.  Does that seem odd to you if it was started by Upstart?
<jodh> tedg: are there any upstart variables?
<jodh> tedg: certainly sounds like it was not started by upstart :)
<tedg> jodh, No, there aren't: https://jenkins.qa.ubuntu.com/job/saucy-touch_ro-maguro-smoke-music-app-autopilot/101/artifact/clientlogs/_usr_lib_arm-linux-gnueabihf_url-dispatcher_url-dispatcher.32011.crash/*view*/
<tedg> jodh, It's parent PID is upstart...
<tedg> jodh, And the shell is weird as well.
<jodh> tedg: you're printing environ from the core file right?
<tedg> jodh, I believe apport grabs it from proc in the crash files.
<jodh> tedg: don't rely on the apport header for the env - it only shows a small (safe) subset of variables.
<tedg> jodh, Ah, okay.
<cjwatson> Damn, I had forgotten just how quickly sagari builds stuff - libreoffice in 1h20m
<tedg> To get more I need to get to that core then...
<jodh> tedg: yup
<cjwatson> Although I notice that libreoffice's build times radically improved in 4.1.2
<cjwatson> Though on powerpc, not on amd64
<tedg> plars, Do the crash files from the autopilot tests get uploaded to daisy?
<tedg> If a crash file is created, but never uploaded to daisy, does it really exist?
<plars> tedg: no, I don't think it does
<tedg> plars, Can it?
<plars> tedg: pitti worked on some stuff to make that possible a while back but I had issues with it last time I tried to integrate it. It hasn't been a huge issue so far I don't think but if it important, I can prioritize fixing that
<plars> tedg: but it's not going to be something that happens today, for instance, so for now you do have the crash file at least
<tedg> plars, I don't think it is critical, but it would be nice.
<plars> tedg: ack
<tedg> plars, Perhaps ev can add something to errors to note when it's recreated with a know machine ID in the QA lab.
<tedg> Those would be probably more reliable results.
<ev> tedg: couldn't we just look up the reports by machine ID?
<plars> tedg: I'll see about talking to pitti tomorrow (he's eod by now I think) and get unstuck on it as soon as possible
<tedg> ev, We could, I was more thinking a little canonical logo or something on the crash listing to highlight it.
<ev> cute
<plars> tedg: given the hoops necessary to jump through for getting these things uploaded at the moment, I think you can just assume that anything touch on there is one in the lab once we get it working
<tedg> jodh, So I do have UPSTART_SESSION, but I don't have UPSTART_JOB
<tedg> Wait, show environment, doesn't seem to show the core's environment.
<tedg> Bother
<jodh> tedg: print environ
<tedg> jodh, That just gives me a big negative number.
<tedg> Guessing the core doesn't have?
<jodh> tedg: try 'print ((char**)'environ@@GLIBC_2.0')[0]'
<tedg> Hmm, no symbol table.
<tedg> I guess I need debug packages
<Laney> ev: Pinged you while you were away, but I guess it got lost â want to check about whoopsie on touch
<Laney> wrt. system-settings - the toggle doesn't work; I guess it needs a pkla to authorise the action
<Laney> the diagnostics toggle, that is
<Laney> but more broadly, do we have whoopsie working on the images atm?
<ev> Laney:  yes, lost much IRC data while on holiday
<Laney> no worries
<Laney> hope you had a good time ;-)
<ev> Laney: yes, presumably needs pkla
<ev> and yes, it is working on the images
<ev> we just don't have armhf retracers deployed yet
<ev> but we're receiving data
<ev> and thanks, sure did!
<jodh> tedg: how easy is it for you to reproduce the problem? You could try the procenv re-exec trick if it's relatively easy: http://upstart.ubuntu.com/cookbook/#determining-why-your-service-fails-to-start
<tedg> jodh, Nearly impossible to recreate :-/  Everytime we think we have someway it "fixes" itself on that machine.
<jodh> tedg: ie change your job to specify "exec procenv --file=/tmp/procenv.log --exec -- hud...". Rather than --file you can specify --output=syslog or --output=stdout, etc.
<jodh> tedg: ok :(
<tedg> Sadly, this crash file is the best thing that's happened this month for this bug.
<seb128> tedg, can you make the apport hook collect the full /proc/pid/environ?
<jodh> tedg: can't we rig a system to auto-reboot constantly checking for the required condition?
<tedg> seb128, Trying to get debug symbols to see if I can grab it.
<tedg> seb128, If not, yes.
<tedg> jodh, Good idea, really it'd just be "any crash files" now :-)
<Laney> ev: ok, pkla appreciated then :P
<Laney> there's efforts to make sure everything visible in the UI works
<seb128> tedg, what are you looking for in that env?
<tedg> seb128, There was a theory that the session bus address wasn't getting propagated.
<tedg> I'm printing it now.
<seb128> tedg, ok, I've it as well
<seb128> but if you have it you probably don't need me ;-)
<seb128> tedg, jodh: http://paste.ubuntu.com/6188605/
<tedg> This does seem more sane overall
<tedg> jodh, What's the "JOB" variable for?
<seb128> tedg, how did you print it? I've been hacking around, but I would be happy to learn the "clean way" :p
<tedg> seb128, I did "print environ[0]" and incremented until I got to NULL
<seb128> tedg, ok
<seb128> tedg, p (char *)*environ@80
<seb128> tedg, that's better :p
<tedg> seb128, You're scary :-)
<seb128> lol
<tedg> Seems like there should be a way to do NULL terminated lists.  But I dont' know it.
<seb128> right
<seb128> @<len> works though
<udevbot> Error: "<len>" is not a valid command.
<seb128> you just get a bit of noise at the end
<jodh> tedg: that's the event variable that that was set when your job started (recall that 'start on starting foo' actually means 'start on starting JOB=foo').
<jodh> tedg: whereas UPSTART_JOB is "self".
<tedg> K, so that makes sense.
<tedg> I wonder if we're just starting faster than DBus can be ready?
<jdstrand> xnox: all the keys in qrt are 13 years or more before being expired
<slangasek> jdstrand: so the issue we're seeing is that the certificate embedded in the shim data itself, which chains from Subject: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Corporation UEFI CA 2011 to the key actually used for signing (subject=/C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/OU=MOPR/CN=Microsoft Windows UEFI Driver Publisher), is expired
<slangasek> at least, that's how it appears
<slangasek> the other possibility is that we're verifying the expiry on Microsoft Windows UEFI Driver Publisher, but it's not actually in the verification chain
<slangasek> difficult to extract this information with the available tools :/
<jdstrand> slangasek: ah, that was going to be my next question, if the embedded cert was expired
<slangasek> so I think this is probably a bug in sbverify
<slangasek> xnox: ^^
<slangasek> xnox: what command did you run on bug #1234649 that managed to show you the full certificate details in one go? :)
<ubottu> bug 1234649 in shim-signed (Ubuntu) "UEFI shim verification against microsoft-uefica-public.pem fails with 20131003 saucy images" [Undecided,New] https://launchpad.net/bugs/1234649
<slangasek> ah, -text -print_certs
<lamont>  /usr/lib/python2.7/dist-packages/gobject/constants.py:24: Warning: g_boxed_type_register_static: assertion 'g_type_from_name (name) == 0' failed
<lamont> why does saucy hate me so?
<xnox> slangasek: yeap, all in the bug, i figured it's a convenient place to document stuff.
<tedg> jodh, Is there a way to make the dbus job not register as "started" until it listens on the socket?
<xnox> tedg: hm, we can do post-start script where it checks the socket?
<xnox> tedg: we do wish kernel could report to upstart when listen was called on the socket.
<tedg> xnox, That works for me... I guess we can try to connect in a loop...
<tedg> "Are we there yet?"
<xnox> tedg: that.
<ev> Laney: where should the pkla live? I don't see any in ubuntu-system-settings
<xnox> tedg: i'm not proud of my address, and no post-code envy, but here is an example from mysql daemon that does post-start check: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/saucy/mysql-5.5/saucy/view/head:/debian/mysql-server-5.5.mysql.upstart
<Laney> ev: what's it going to say?
<tedg> xnox, K, trying to think of something silly we can do...
<ev> Laney: presumably allow on com.ubuntu.WhoopsiePreferences since we don't have a password dialog (to my knowledge) for auth_admin?
<ev> but we don't want that going to the desktop image
<Laney> ev: yeah, I mean are you going to do it for the admin group or what?
<ev> Laney: yeah, I imagine that would be sufficient.
<xnox> tedg: dbus-send to succeed to upstart?!
<jodh> tedg: once you can recreate the problem, I wonder if it is worth tweaking the session dbus.conf job to "expect fork" and "--fork" like the system dbus job already does. That may give a "more correct" started event time.
<Laney> ev: but you don't want it on the desktop?
<Laney> I don't know what package would be good then
<Laney> ogra_ might be able to help
<ev> Laney: I guess we could do it for the desktop if we're restricting it to the admin group, actually
<xnox> jodh: oh, yeah, one must use --fork or daemon with dbus, or patch it to do sigstop, otherwise dbus is declared as started ahead of time.
<tedg> jodh, Why would that be more correct?
<Laney> ev: if that, then probably policykit-desktop-privileges
<Laney> is on the device
<ev> cool, I'll have a look
<ev> thanks
<xnox> tedg: dbus forks after it starts to listen, thus expect fork with --fork will make sure started is emitted only after dbus is ready.
<tedg> Oh, let's do that!
<xnox> tedg: i'll upload it, shall I ?
<tedg> xnox, Please!
<tedg> xnox, bug 1234731
<ubottu> bug 1234731 in dbus (Ubuntu) "DBus jobs not setting environment variables" [Undecided,Confirmed] https://launchpad.net/bugs/1234731
<xnox> stgraber: i blame you for our day of chasing dbus ^
<xnox> =))
<xnox> ogra_: ^^^^^
<tedg> xnox, I've updated the bug with the end of the IRC conversation
<xnox> ack.
<xnox> tedg: hm. so i've upgraded and rebooted, there are still 3 session dbus'es started: one by session upstart, one by at-spi2 a11y, one done by "dbus-launch --autolaunch=f07f2326128b8865ee7446354f0f2bcd --binary-syntax --close-stderr"
<xnox> the last one is a little bit interesting
<tedg> Yeah, the first two I'd expect
<tedg> Who's its daddy?
<xnox> tedg: better, who's is it's environ. UPSTART_JOB=update-notifier-crash =)
<xnox> bang bang, I shot you down.
<tedg> xnox, Interesting that it'd start it's own bus, could it not see the current session bus?
<xnox> tedg: nope, since it's start on file event.
<xnox> tedg: and the semantics we agreed for the .crash file is such that on each boot they are re-emitted =/
<tedg> xnox, Ah
<xnox> tedg: which is ahead of dbus, so it should do "pre-start exec start dbus"
<tedg> xnox, It's almost like dbus needs to be "start on starting starting"
<xnox> =)))))
<slangasek> jodh: bug #1234743 - so upstart-monitor is out for phone debugging because it depends on gtk; what's the best way for cking to get debugging information about what events upstart is spending its time on?
<ubottu> bug 1234743 in upstart (Ubuntu) "init on samsung galaxy nexus is busy and consuming memory when playing an mp4" [High,New] https://launchpad.net/bugs/1234743
<stgraber> slangasek: initctl log-priority debug and look at whatever log file is used to record upstart's output (equivalent of ~/.xsession_errors on a desktop install)?
<stgraber> slangasek: do you know anything about a udev rule that'd currently make the active session user have write access to pretty much all of /dev?
<stgraber> slangasek: I just noticed that my user has write access to /dev/sda and that scares me a bit
<stgraber> slangasek: (then I checked and I can't find a single file in /dev I don't have write access to... switching to another VT reverts that ACL, so it looks like some logind/udev thing)
<slangasek> stgraber: um.  that's certainly a bug.
<slangasek> yeah, would be related to logind
 * stgraber tries a guest session to see how scary that bug is
<stgraber> oh wow
<stgraber> http://paste.ubuntu.com/6189025/
<stgraber> so that's insanely scary
<cjwatson> holy crap
 * cjwatson runs away for dinner before accidentally getting dragged into this
<xnox> jodh: slangasek: is it evil to use wait-for-state in usersessions? bug 1234841
<ubottu> bug 1234841 in upstart (Ubuntu) "crash reports pop-up ahead of desktop loading, or atleast dbus being available" [High,Confirmed] https://launchpad.net/bugs/1234841
<slangasek> xnox: if you can avoid it, that would certainly be better.  Are you trying to instantiate the system service from the user session...?
<xnox> slangasek: no, crash reporter is an instances job starting on file events. On inital login, if there are .crash reports, all of the crash dialogs are launched before anything else.
<xnox> slangasek: so i cannot do " and started dbus"
<slangasek> xnox: shouldn't that be fixed by starting dbus before the file bridge?
<xnox> slangasek: yet, if crash dialog script is executed ahead of dbus, it autolaunches one.
<xnox> slangasek: could do. it does seem like it's most wise to make "started dbus" our session startup event to be honest.
<xnox> slangasek: but filebridge doesn't need dbus =/
<xnox> only crash-reporter needs it, which may or may not be installed (well it is on ubuntu desktop)
<slangasek> xnox: what's the downside of making file-bridge start after dbus?
<slangasek> we already assume all user sessions have dbus, right?  So an artificial ordering constraint just means certain jobs will start a little later
<slangasek> I think that's way better than pulling wait-for-state into the mix
<xnox> slangasek: the downside will be that update-notifier-crash, unicast-local-avahi, update-notifier-release - are started later, and/or miss (modified, deleted events) [the latter doesn't matter as they only match on create at the moment)
<xnox> but yeah, it's more lightweight than adding wait-for-state.
<slangasek> xnox: right, I don't think we really need to care about triggering jobs on file modifications / deletions that happen before the session is even fully started
<xnox> slangasek: ack. i'll do that then.
<ari-tczew> is there any bug-fixed statistic?
<ari-tczew> in the past was a page with bug fixed per e-mail address, but I didn't find it now
<xnox> ari-tczew: there are some, but they are vague, as launchpad doesn't track bug-fixed per-package-version. So sometimes it's hard to tell if the bugs were fixed in current dev release, or a clean-up of bugs was done (e.g. 'oh this was fixed for years')
<stgraber> for anyone who read my messsage earlier about /dev being writable for any logged in user, the cause was a broken udev rule in the adb package, fixed with: https://launchpad.net/ubuntu/+source/android-tools/4.2.2+git20130218-3ubuntu15
<INdek> hey, i want to improve my coding skills and i thought about contributing to the ubuntu project would be a good idea, how do i start
<robru> jdstrand, ping
<robru> jdstrand, I'm heading out for lunch, but in case you're around: https://bugs.launchpad.net/ubuntu/+source/unity-webapps-qml/+bug/1206268/comments/35
<ubottu> Ubuntu bug 1206268 in webbrowser-app (Ubuntu) "[MIR] unity-webapps-qml" [Undecided,In progress]
<jdstrand> robru: ack. I'll respond in the bug
<barry> doko: https://launchpad.net/ubuntu/+archive/test-rebuild-20130917/+build/5014145
<barry> doko: is that still a problem?  (built fine locally in sbuild with both --arch amd64 and i386)
<chiluk> hey guys unmodified mysql sources  get a build failure from tests failing.. is there a trick to make it build?  Clearly launchpad can get it to build.
<lamont> after saucy's brasero says that it's 100% don buring the data disk, and that it's "creating image checksum", I find myself wondering what it's been doing for the last several minutes
<chiluk> mdeslaur.. I can't build the mysql that you checked in for precise using pbuilder or sbuild... a few testcases are failing... do you have any insite on what needs to happen to get it to build?
<lenios> chiluk, you mean the mysql package source or the mysql sources?
<lenios> mysql source package would be the correct term, though
<chiluk> the mysql-5.5 sources that get pulled by pull-lp-source mysql-5.5 precise can not be built into binaries using sbuild or pbuilder
<lenios> you mean 5.5.34?
<chiluk> i in particular am running pbuilder-dist precise build mysql-5.5_5.5.32-0ubuntu0.12.04.1.dsc
<chiluk> lenios no the sources that are currently in ubuntu archive are versioned mysql-5.5_5.5.32-0ubuntu0.12.04.1.dsc
<lenios> 5.5.32-0ubuntu0.12.04.2 is available
<lenios> i don't see why you woudn't be able to build
<chiluk> ok lenios now try building the dsc file that you grabbed.  it doesn't build.
<chiluk> lenios why don't you just try it..
<chiluk> and if you get it to work let me know how you did it.
<chiluk> because it's not building for me or another person I know.
<chiluk> if you figure out what is going wrong for us let me know
<chiluk> or better yet create a patch .
<infinity> chiluk: Which kernel are you using to build?  Note that the buildds run precise.
<chiluk> running on precise
<chiluk> hmm I am running the 3.11 kernel.
<infinity> chiluk: (Testing here on saucy now to see, but if it fails tests on saucy and not precise, I'm assuming the kernel is to blame)
<chiluk> infinity that's a really good insite.
<chiluk> I'll reboot to something much earlier.
<chiluk> infinity, they build takes forever..
<chiluk> you are in for a world of hurt fyi
<infinity> chiluk: Given that it built on all arches on the buildds only two months ago, if it does fail now due to a userspace change, shouldn't be hard to track down.  But the kernel's the most likely culprit.
<chiluk> that's a good check
<chiluk> it's failing trying to pull cores
<infinity> chiluk: You consider 58 minutes "forever"?  Kids these days. :)
<chiluk> seriously man you aren't that much older than me... I just age more gracefully
<infinity> Ouch.
<chiluk> also on my machine it's more like 4 hours till it hits the failure
<chiluk> also the test don't seem to be multi-threaded, and are heavily IO dependent
<infinity> chiluk: multicore machine where you neglected to export DEB_BUILD_OPTIONS="parallel=$(nproc)" before running sbuild?
<chiluk> infinity that's in my bashrc.
<infinity> (58 minutes on the x86 buildds, I expect just shy of 2h on my laptop)
<chiluk> the tests aren't multi-threaded
<chiluk> maybe my hard drive is just crap.
<chiluk> it's building on a spinning disk
<infinity> So are the buildds.
<infinity> And my laptop. :P
<chiluk> I think I'll put the pbuilder builddir in tmpfs
<infinity> I do build in tmpfs though, yes.
<chiluk> I bet that's it.
<lamont> infinity: the buildds are taking full advantage of the cciss caching, though
<infinity> Anyhow.  I expect my test on a saucy kernel will also fail.
<chiluk> my hard drive is just pegged
<infinity> lamont: Only roseapple and allspice.
<lamont> oh
<infinity> lamont: The other x86 buildds have much slower cheap SATA.
<chiluk> the build is not the slow part
<chiluk> it's all the tests
<lamont> ah
<infinity> chiluk: Anyhow, I'm into the testsuite now on 3.11 to see if my system agrees with yours.  If you try on a 3.2 kernel, that would be nice.
<chiluk> yeah going to cancel my build.. add tmpfs and reboot into 3.2... I hope it still works.
<infinity> chiluk: Depending on the failure, it could be just a broken test that does something newer kernels don't like, or an actual bug we should fix in the package to work sanely on newer kernels.  I guess we'll see.
<lenios> i don't see why the kernel would create such a difference
<infinity> lenios: Depends on what test is failing...
<chiluk> infinity
<chiluk> mysql-5.5_5.5.32-0ubuntu0.12.04.1.dsc
<chiluk> fuck damn cp/paste
<chiluk> worker[1] Trying to dump core for [mysqltest - pid: 7596, winpid: 7596]
<chiluk> worker[1] Trying to dump core for [mysqld.1 - pid: 7504, winpid: 7504]
<chiluk> worker[1] Trying to dump core for [mysqld.2 - pid: 7507, winpid: 7507]
<chiluk> rpl.rpl_innodb_bug28430 'mix'            [ fail ]  timeout after 900 seconds
<chiluk> my world for a mouse and middle click
<chiluk> that's one of the tests that's failing
<infinity> chiluk: Curious.
<jono> hi everyone
<jono> FYI: UDS dates announced on ubuntu-devel
<jtaylor> is it a virtual uds or a real one? neither the mail nor the page make that easy to find out
<jtaylor> hm 2pm-8pm probably means virtual
<infinity> chiluk: So, back to the drawing board on that theory.  mysql-5.5/precise just built fine here in a precise sbuild w/ saucy kernel.
<infinity> chiluk: http://lucifer.0c3.net/~adconrad/mysql-5.5_5.5.32-0ubuntu0.12.04.1_amd64.build
<infinity> chiluk: And also only took an hour.  Your hardware hates you. :P
<chiluk> yes it does.
<chiluk> I swear I was a tester in another life
<chiluk> infinity as you seem to be the only one I know that can actually successfully build can you attempt building any of the patches available here? http://bugs.launchpad.net/bugs/1121874
<ubottu> Ubuntu bug 1121874 in mysql-5.5 (Ubuntu Raring) "MySQL launch fails silently if < 4MB of disk space is available" [Medium,Triaged]
<chiluk> I was asked to take a look at why it wasn't building by stokachu,
<bdmurray> seb128: could you update bug 1075923 with SRU information?
<ubottu> bug 1075923 in gvfs (Ubuntu Raring) "nautilus hangs copying large directories from a samba share" [High,In progress] https://launchpad.net/bugs/1075923
<seb128> bdmurray, oh, sure, sorry about that
<bdmurray> seb128: no problem
<seb128> bdmurray, I though about it after upload the other day, and then got busy and forgot about it
<chiluk> infinity crazy question do you have jumbo frames enabled?
<seb128> bdmurray, done
<infinity> chiluk: If that's something I have to do manually, probably not.
<chiluk> it is.
<chiluk> it's a stab in the dark
<chiluk> but it tends to shoot me in the foot often.
<chiluk> it's the sacrifice I make for 120mb/sec to my nfs server
<seb128> ev, could you look at https://bugs.launchpad.net/activity-log-manager/+bug/1198681? it's high ranked on the saucy issues on e.u.c
<ubottu> Ubuntu bug 1198681 in activity-log-manager (Ubuntu) "gnome-control-center crashed with SIGSEGV in on_properties_changed()" [Medium,Confirmed]
<ev> seb128: will do in the morning
<seb128> ev, thanks
<ev> sure thing
<sconklin> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.10 Beta 2 released | Archive: frozen | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: xnox
#ubuntu-devel 2013-10-04
<Noskcaj> Is there an FTBFS list for arm64 yet?
<slangasek> Noskcaj: no, and you shouldn't expect one any time soon
<Noskcaj> ok
<slangasek> because a /failed/ to build from source list implies sufficient resources to /try/ to build from source :)
<DzAirmaX> hey ;Ã $
<DzAirmaX> how are you guyz today ?
<DzAirmaX> Can someone give me some infromation about the MOTD update system ? I noticed it was delayed on the 13.10 distrib ....
<DzAirmaX> I noticed the displayed info was delayed from 1 login, so for example I will have the system info from the last login and not the actual one
<rbasak> DzAirmaX: look into pam_motd
<DzAirmaX> rbasak : how am I supposed to look there sir ?
<rbasak> DzAirmaX: I don't know. I'm just giving you a keyword to help with your googling.
<rbasak> I hope that helps.
<xnox> zyga: ha, nice. Did you see deb-squid-proxy-client? http://blog.surgut.co.uk/2013/03/avahi-apt-cacher-ng-sbuild.html essentially there is a way to advertise apt-proxies and automatically use them.
<xnox> zyga: i use that on my laptop, chroots, sbuild, etc. Thus when I am at home it uses my main proxy, when on the go, it uses one if available.
<zyga> xnox: nope, looking
<xnox> zyga: it's been improved since apt-cacher-ng now ships the avahi config.
<xnox> zyga: so that step is not needed.
<zyga> xnox: ait is avahi based
<zyga> xnox: it is avahi based
<xnox> zyga: yes, avahi is required on the host. So I bypass that for sbuild, by checking & setting apt-proxy url at chroot setup.
<xnox> zyga: avahi is pre-installed on desktops.
<xnox> (chroot setup, meaning each time sbuild/schroot is invoked via it's hooks scripts)
<zyga> xnox: while I really like the concept of avahi it is really not reliable enough IMHO, it's often filtered out in corporate networks and even at home, it easily fails to work on wifi due to silly packet loss
<xnox> zyga: true, and due to e.g. routers by the UK ISPs often not allowing wifi clients to access LAN/ethernet clients and etc.
<zyga> xnox: plus, my solution is really more robust, it updates each time the network changes
<xnox> zyga: yeah, it is. In deb-squid-proxy-client, a python script is executed each time apt-get is invoked which is less than ideal performance wise.
<zyga> xnox: one improvement I could see is for apt-proxy-setup to discover generic mDNS advertised proxies and pick one as an option
<xnox> hm.... interesting.
<zyga> xnox: and I'd like to have a way to maybe fallback to fully offline local apt-cacher-ng when offline
<xnox> i've never used mDNS advertised proxies (well, to my knoweledge at least)
<zyga> xnox: it's just 0.1 :)
<zyga> well mDNS is avahi
<xnox> zyga: fallback to local apt-cacher-ng when offline would be cool.
<zyga> xnox: I'm doing this because we're sprinting next week
<xnox> by pick the /actual/ fast desktop proxy when on "home" network. Yeah, that needs config files.
<zyga> xnox: and I really want to have my stuff and not have to fiddle with it
<zyga> xnox: well, if that proxy is advertised it would also be picked up
<zyga> xnox: I meant mDNS apt-cacher-ng proxy
<zyga> xnox: I think I'll do the offline proxy first to have something to do on the plane
<zyga> (the proxy would only start when needed too, which is great about upstart)
<zyga> xnox: but I'll look at setting up avahi discovery for apt-cacher-ng in a generic network
<zyga> xnox: I was thinking about that earlier and I worried that there might be security issues, it it okay to use any random mirror?
<zyga> xnox: I think it is but I wasn't 100% Sure
<cjwatson> apachelogger: +  * Change all maintainer scripts to use sh -e rather than explicit set -e.
<apachelogger> cjwatson: a voice in my head told me to do that :O
<cjwatson> apachelogger: that's so backwards :)  explicit set -e is better because it means that it isn't a gotcha for people debugging your script with "sh -x <blah>" - I change everything I maintain to use explicit set -e whenever I notice sh -e
<cjwatson> (not a reject or anything but I think this change is misguided)
<infinity> That's not quite as backward as the part where we later ignore all errors anyway.
<apachelogger> cjwatson: true, but sh -e is so elegant ^^
<cjwatson> apachelogger: but wrong :)
<apachelogger> pff :P
<cjwatson> (well, less helpful)
<apachelogger> I'll commit a revision to that if it makes you happy
<infinity> Is kubuntu-default-settings intentionally being installed in ways where dependencies aren't set up yet, or is the whole thing just really misguidedly weird?
<cjwatson> apachelogger: should the referenced bugs be reassigned to kubuntu-settings?
<apachelogger> infinity: I have no idea, latter sounds reasonable
<cjwatson> (they're on kubuntu-default-settings right now, so won't be closed by this upload)
<apachelogger> cjwatson: yes
<infinity> apachelogger: As a general rule, postinst should be able to expect that their deps aren't broken.  I find this whole "assume the world might be broken and just echo harmlessly to the terminal" thing a bit odd.
<infinity> apachelogger: If there are known error conditions here, could we fix the buggy packages?
<infinity> (And if there aren't known bugs here but rather just paranoia, you've effectively undone the whole point of "set -e")
<cjwatson> I tend to agree, but it's also fairly harmless as-is.  Minded to accept unless infinity objects
<infinity> cjwatson: Well, it looks like this was already done (or started) in the previous upload, so meh.
<apachelogger> infinity: they aren't known, that is the problem....
<infinity> cjwatson: But I'd still like to have the talk/argument.
<cjwatson> at least one is
<cjwatson> bug 1005555 is a configuration error probably caused by copy/pasting from some stupid website
<ubottu> bug 1005555 in kubuntu-settings (Ubuntu) "package plymouth-theme-kubuntu-logo 1:12.04ubuntu4 failed to install/upgrade: el subproceso instalado el script post-installation devolviÃ³ el cÃ³digo de salida de error 2" [Undecided,New] https://launchpad.net/bugs/1005555
<cjwatson> it'll break something else later anyway
<cjwatson> oh, and ditto bug 1044690
<ubottu> bug 1044690 in kubuntu-settings (Ubuntu) "package plymouth-theme-kubuntu-logo 1:12.04ubuntu4 failed to install/upgrade: installed post-installation script alt iÅlemi Ã§Ä±kÄ±Å durumunda hata dÃ¶ndÃ¼rdÃ¼:: 127" [Undecided,New] https://launchpad.net/bugs/1044690
<cjwatson> they are not your problems
<apachelogger> right, neither of the called things in postinst are actually fatal
<cjwatson> and it really doesn't particularly help to ignore them - the whole upgrade will probably still fail when people have scribbled nonsense over config files
<infinity> Uhm, yeah.  If things like update-grub or update-initramfs fail, people have a broken system, full stop.
<cjwatson> but I agree that it doesn't make much difference either way in this case
<infinity> The warm fuzzies produced from kubuntu-default-settings installing won't help.
<cjwatson> Indeed.  They're logically triggers, though.
<cjwatson> (accepted)
<infinity> Well, triggering those sort of solves the problem (or, rather, moves it to the package where it runs), which is fine.
<infinity> But it seems to be an overreaction to "|| true" the world.
<cjwatson> Yeah.
<infinity> Like, if those update-alternatives calls explode, that legitimately means that kubuntu-whatever won't have installed correctly.  Which is exactly when a postinst is meant to fail.
 * infinity shrugs.
<cjwatson> Right.  I would say you should
<infinity> I need sleep more than I need to lecture on the Internets, though. :)
<cjwatson> er
<cjwatson> apachelogger: Right.  I would say you can reasonably || true on the things that are logically triggering other packages, but that you should not || true the things that are actually entirely part of your own package (like the update-alternatives).
<DzAirmaX> I noticed the motd update from motd.dynamic is not enforced as each login on the 13.10
<DzAirmaX> someone has encoutered the same pb ?
<apachelogger> cjwatson: ultimately I'd have it simply print a message but still exit in error as the entire point is to reduce bug triage work. alas, with release coming up I'll take ||true as immediate workaround.
<cjwatson> apachelogger: For the triggers, I'd reluctantly agree, but for things that are actually functionality of your own package I do not agree that reducing bug triage work is sufficient reason to ignore errors
<apachelogger> mhh, I guess you are right.
<apachelogger> cjwatson: I put a todo down for 14.04 to look at it in detail
<cjwatson> ta
<cjwatson> right, better get back to verifying apt SRUs
<seb128> xnox, hey, just as fyi, I assigned https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/1200775 to you (apturl not working in saucy)
<ubottu> Ubuntu bug 1200775 in update-manager (Ubuntu) "apturl-gtk crashed with AttributeError in __init__(): 'InstallBackendAptdaemon' object has no attribute 'connect'" [High,Confirmed]
<seb128> xnox, it seems to be due to https://code.launchpad.net/~dylanmccall/update-manager/dialogs-refactor/+merge/164673 and you are the one that approved the merge it seems
<xnox> seb128: ack. will look into this later today.
<seb128> xnox, thanks
<seb128> xnox, I commented on the mp as well, maybe Dylan is around/wanting to look at it
<TJ-> Can we get some love for a critical ifupdown issue, bug #1235169
<ubottu> bug 1235169 in ifupdown (Ubuntu) "Fails to read files in /etc/network/interfaces.d/" [Critical,New] https://launchpad.net/bugs/1235169
<rbasak> How long as interfaces.d been around. OOI, has this ever worked?
<TJ-> rbasak: Since April
<lool> cjwatson: getting a manpages upgrade error; would it be fs corruption?  dpkg: erreur de traitement de /var/cache/apt/archives/manpages_3.54-1ubuntu1_all.deb (--unpack)Â : impossible de crÃ©er un lien symbolique de secours pour Â«Â ./usr/share/man/man4/ptmx.4.gzÂ Â»: Aucun fichier ou dossier de ce type
<lool> cjwatson: file /usr/share/man/man4/ptmx.4.gz
<lool> /usr/share/man/man4/ptmx.4.gz: unreadable symlink `/usr/share/man/man4/ptmx.4.gz' (No such file or directory)
<lool> ls -l /usr/share/man/man4 is full of: lrwxrwxrwx 1 root root     0 aoÃ»t   1 15:36 zero.4.gz ->
<lool> empty file, I guess it's not pointing at anything
<lool> this is on btrfs
<cjwatson> lool: looks like it
<lool> ok
<lool> I might have run out of battery a while ago
<lool> but not particularly while upgrading
<lool> so kind of sad
<rbasak> TJ-: so is this a regression from Raring, or a new feature that doesn't work? What is the justification for it being Critical?
<rbasak> TJ-: is there some essential thing that depends on this feature?
<rbasak> TJ-: or is it the default now or something?
<TJ-> It's a new feature since April, the default interfaces created by the postinst script writes the directive, but installing interface files in that directory fails to work
<TJ-> I hit it earlier whilst configuring a 13.10 server with multiple interfaces
<TJ-> So if you follow the guidance, it'd fail to bring up any network.
<TJ-> I've just implemented a patch to fix it, I'm testing it now
<smartboyhw> cjwatson, hmm, ardour3 sync build-failure on armhf and powerpc because of a header which only exists in amd64 and i386....
<smartboyhw> Any ideas as to what I can do?
<smartboyhw> (Note that the package failed to build in Debian's armhf and powerpc)
<smartboyhw> s/Debian's/Debian archive archs/
<cjwatson> Well, it's not fatal for using ardour3 in Ubuntu Studio
<Laney> Find out why it's passing -DBUILD_SSE_OPTIMIZATIONS
<cjwatson> I think it might actually be FPU_OPTIMIZATIONS
<cjwatson> FPU_OPTIMIZATION, rather
<cjwatson>         if bld.env['FPU_OPTIMIZATION']:
<cjwatson>             testcommon.source += [ 'sse_functions_xmm.cc' ]
<cjwatson> ifneq (,$(findstring amd64,$(DEB_BUILD_ARCH)))
<cjwatson> DEB_MAKE_NOOPT_FLAGS := DEBUG=no FPU_OPTIMIZATION=yes
<cjwatson> endif
 * Laney got that from the debian bug
<cjwatson> That should maybe be ifeq (,$(findstring i386,$(DEB_BUILD_ARCH))) instead since that code ain't gonna work on non-x86
<cjwatson> Er, wait, I have my negatives backwards
<cjwatson> Is DEB_MAKE_NOOPT_FLAGS actually being passed to anything?
<cjwatson> It doesn't seem to be a recognised CDBS variable
<cjwatson> Also check whether FPU_OPTIMIZATION=no works properly or if it needs to be unset
<cjwatson> Anyway those are the general paths you probably want to look at
<cjwatson> Looks like the build target is set wrongly
<smartboyhw> cjwatson, :(
<smartboyhw> Anyhow, at least it works for x86 and amd64
<smartboyhw> (Good enough for us)
<cjwatson> I'm afraid I've run out of interest for debugging waf nonsense, you'll have to sort the rest out yourself :)
<smartboyhw> cjwatson, sure
<cjwatson> never been a fan of choose-your-own-adventure build systems :)
<smartboyhw> cjwatson, agreed, I love dh:P
<smartboyhw> cjwatson, so ardour3 won't auto-migrate to -release right?
<cjwatson> smartboyhw: Nothing's stopping it that I know of
<cjwatson> smartboyhw: Architecture support only has to not regress; if you don't build on an arch you've never built on before, that's fine
<cjwatson> smartboyhw: https://wiki.ubuntu.com/ProposedMigration
<smartboyhw> cjwatson, nice wiki page, let me bookmark
<seb128> cjwatson, you mentioned gnome-control-center-unity being newer in raring-updates than saucy ... do we have a tools to list such problems? it seems like that if that happened to that one we might as well have other sources in the same case
<cjwatson> seb128: I've never wired it up to a proper report or anything but it's easy to generate with lp:~cjwatson/+junk/suite-diff
<cjwatson> xnox: libboost1.53-dev should set its primary alternative to libstdc++-4.8-dev (which exists) rather than libstdc++6-4.8-dev (which doesn't).  Was going to just fix in Ubuntu but I noticed the changelog appears to include a matching change from you in Debian experimental (though apparently not actually uploaded there).  Would you mind fixing in both?
<cjwatson> xnox: This is part of why libc++ is showing up in http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.txt
<seb128> cjwatson, thanks for the script, there is a few listed out of g-c-c-unity
<seb128> fwlogwatch: 1.2-2ubuntu0.13.04.1 > 1.2-2
<seb128> kdeadmin: 4:4.10.5+repack-0ubuntu0.1 > 4:4.10.4-0ubuntu1
<seb128> kdenetwork: 4:4.10.5+dfsg1-0ubuntu0.1 > 4:4.10.4-0ubuntu1
<seb128> ubufox: 2.7-0ubuntu0.13.04.1 > 2.6-0ubuntu1
<seb128> chrisccoulson, ^ ubufox is newed in raring-updates than saucy
<seb128> Riddell, ScottK: ^ you might be interested by the KDE ones (newer in raring-updates than saucy, can create upgrade issues)
<chrisccoulson> seb128, ah, i'll fix that
<seb128> chrisccoulson, thanks ;-)
<cjwatson> fwlogwatch looks like it should just be copied forward - security update
<cjwatson> I'll do that
<cjwatson> sarnold: ^- FYI.  I don't think you should rely on new versions coming from Debian in this kind of situation - better to copy the security update forward from raring if versions were previously identical between raring and saucy (no need for a separate upload)
 * cjwatson runs "copy-package -s raring-updates --to-suite saucy-proposed -b fwlogwatch"
<seb128> cjwatson, thanks
<xnox> cjwatson: =/ sorry about that. yeah, let me fix that in debian & ubuntu then.
<cjwatson> Thanks!
<psivaa> slangasek: re: bug #1234649 i see the tool is now fixed in saucy, but our test servers are still using precise with sbsigntool:0.6-0ubuntu1~12.04.1
<ubottu> bug 1234649 in sbsigntool (Ubuntu) "UEFI shim verification against microsoft-uefica-public.pem fails with 20131003 saucy images" [Medium,Fix released] https://launchpad.net/bugs/1234649
<psivaa> slangasek: any plans to backport it?
<xnox> psivaa: slangasek: yeap, i was planning to get it SRUed to precise, quantal & raring.
<psivaa> xnox: ack, thank you
<Riddell> seb128: those are newer in raring-updates than saucy because they have been removed in saucy so I don't think it's a problem
<cjwatson> Riddell: No, they're in saucy
<cjwatson> Riddell: They wouldn't have been reported if they'd been removed
<cjwatson> Riddell: It looks like the binaries have (at least partially - didn't check them all) been supplanted by other sources, but the old source packages were never removed
<marcoceppi> For packagining, I have a source tarbal and I want to update the the package contents with that tarbal and bump the package version. is there a command to do the unpacking of the tarbal in to the already fetched apt-source package?
<Riddell> cjwatson: ah gotcha
<Riddell> marcoceppi: #ubuntu-packaging I think if nobody answers here
<mitya57> marcoceppi: in bzr trees you can do bzr merge-upstream, otherwise you can unpack the tarball and copy debian/ to new location
<Laney> uupdate
<smartboyhw> uupdate is the greatest thing;P (followed by bzr merge-upstream)
<marcoceppi> the upstream is in a ppa, so I'm not sure if that will work
<smartboyhw> Laney, if I update a flavour meta package (ubuntustudio-meta here) that includes a new package, that does require a FFe right? (Or do we need UIFe as well?)
<smartboyhw> (A new package included in seeds, to clarify)
<slangasek> xnox, psivaa: I don't think an SRU is justified for this issue; I think the test server should work around it by either pulling the saucy version, or using faketime.
<slangasek> this is not a user-affecting issue, the only place we're using sbverify is for testing - and in any case, the you can't push an SRU right now because there's currently one in the queue, so chances are there'll be a fixed shim binary from MS by the time the SRU completes
<xnox> ok.
<xnox> slangasek: sbverify is part of our validation and security regression testing. and it's not like you can update the shim on the released 12.04.2, and .3
<slangasek> xnox: yes, but why would we be retesting those released images?
<xnox> slangasek: true. i see.
<slangasek> anyway, faketime :)
<xnox> psivaa: do you want me to write faketime patch for utah static validation such that it starts passing?
<xnox> psivaa: or simply upload new sbverify to the same place as utah is.... which is also not in the ubuntu archive =) but in a ppa.
<psivaa> xnox: i could try and pull the saucy version first to see if that works
<TJ-> What's the procedure to revert one or more debian/patches/ prior to a "bzr bd -- -S" ?  I've tried simply commenting them out in "debian/patches/series" but of course quilt still has them applied to the source.
<xnox> TJ-: quilt pop -a; edit debian/patches/series; quilt push -a; bzr add .pc; bzr bd -S
<cjwatson> quilt pop -a, comment them out in debian/patches/series, and then "quilt push" and "quilt refresh" if necessary
<cjwatson> snap, ish :)
<xnox> TJ-: note, -S is a valid bzr bd option, to do source build.
<TJ-> xnox: Thanks! I was missing the "bzr add .pc" step!
<Laney> codesearch reindexing takes ages
 * Laney wahs
<TJ-> xnox: I must be missing something, "bzr bd -S" errors with "[Errno 2] No such file" for a ".pc/$PATCH_NAME/target.file". I can't much about reverting quilt 3.0 patches either, aside from Barry Warsaw's struggles with the same thing in 2010/2011 in the mailing list. All suggestions gratefully accepted
<xnox> TJ-: commit, since you removed files.
<TJ-> s/can't much/ can't find much/
<xnox> TJ-: then build will succeed.
<TJ-> xnox: OK, presumably also the updated changelog?
<xnox> yeah, commit everything
<TJ-> xnox: thanks, that sorted it. Doing this on a minimal server install without my dev tools and scripts so its painful
<sarnold> cjwatson: thanks re: fwlogwatch advice :)
<smoser> slangasek, you are usually useful with my queries for things like this: https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/1235231
<ubottu> Ubuntu bug 1235231 in cloud-init (Ubuntu) "ci-info: eth0 not reliable in latest saucy images" [Medium,Confirmed]
<slangasek> smoser: can you distill the bug for me, please?  What is the race you're seeing?
<smoser> slangasek, basically data written to /dev/console goes to /dev/null
<smoser> or some other unrecoverable location
<smoser> and we'd like it not to.
<smoser> see the upstart job, it basically does 'for i in $(sed 1 1000); do echo i=$i && sleep .2 ; done'
<smoser> and expects that I that data should get to /dev/console (well, the other side). but it does not.
<slangasek> smoser: ok, so it's a question of the /output/ of this line
<smoser> right.
<smoser> it just gets swallowed up. i suspect by plymouth.
<slangasek> ok; I'm not aware of any recent changes that could account for this
<smoser> and to be fair, onthe raring test i just ran it swallowed up a buncch of it too, but just less, and the cloud-init info got there.
<smoser> well https://launchpadlibrarian.net/152522624/manifest-changes-alpha3-to-beta1.diff
<smoser> is the image contents diff
<smoser> between "working enough" and "not working".
<slangasek> smoser: yeah, and there have been no changes to packages that *should* impact console behavior this cycle, unless perhaps there's something that changed in the kernel itself
<sarnold> do the retracers need a kick?
<smoser> also on other boots we still do get the data. its clearly race conditiion related.
<smoser> heres a canonistack instance log http://paste.ubuntu.com/6193370/
<smoser> well, see line 741
<slangasek> smoser: right, so I suspect that nothing has fundamentally changed, it's just that things have moved around to where the race is more likely to be hit now
<smoser> err.. maybe line 1163 boot.
<smoser> right.
<slangasek> smoser: so the boot at line 1163 looks to be outputting fairly reliably from your test, but misses the first 13 iterations?
<smoser> well, it'd be really nice if content written to /dev/console got to the device hooked up on the other side of /dev/console. (just like that is true for /dev/sda).
<smoser> slangasek, yeah. once you start getting output, you sem to get it.
<smoser> it just gets lost until some point.
<slangasek> what's the value of /proc/cmdline here?
<smoser> [    0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-3.11.0-11-generic root=LABEL=cloudimg-rootfs ro console=tty1 console=ttyS0
<slangasek> ok
<slangasek> so you know that kernel writes to /dev/console are not reliable?
<slangasek> this is a kernel issue
<slangasek> is it possible the write itself is failing?
<smoser> i dont think its kernel.
<smoser> i think its plymouth.
<smoser> i can make sure the writes are returning success if you'd like.
<slangasek> I think you should check that
<smoser> and that is a good idea
<slangasek> there's no dmesg output past the mount of the root filesystem; has that been diverted somewhere else, or is there just no more to see?
<slangasek> it certainly could be plymouth, it's just hard to diagnose this without timestamps
<slangasek> ok, I've convinced myself that plymouth is the most likely culprit
<smoser> slangasek http://paste.ubuntu.com/6193435/
<smoser> that is after doing:
<smoser>  for x in /etc/init/plymouth*.conf; do sudo mv $x $x.dist; done
<slangasek> ok
<slangasek> smoser: so is there ever a case where cloud-init is installed where you would have an interactive console and care about actually interacting with plymouth?
<slangasek> it may be that the right thing to do here is just to create /etc/init/plymouth*.override on all the cloud images and forcibly disable plymouth on the grounds that it serves no purpose
<slangasek> (and cloud-init may be the package in which to do that)
<utlemming> slangasek, smoser: we do have the run a cloud-image locally under KVM, and then there are the Vagrant images that cloud image diratives.
<utlemming> slangasek: mostly developer use cases
<slangasek> utlemming: right, but such use cases do exist
<utlemming> slangasek: yes, those use cases exist
<slangasek> I'm trying to figure out how to solve this without causing regressions for other cases; we really need a hard specification on where we expect plymouth to spit what output (which we are currently lacking) and refactor things to work correctly across all the install types... that's not gonna happen for 13.10
<slangasek> so that leaves "hack out plymouth" as the best option I can think of
<slangasek> utlemming: oh, but if these are still cloud images, you still would never be interacting with plymouth
<slangasek> because you might have a console, but it's only for staging, no?
<utlemming> right...we just need a console
<slangasek> so you e.g. wouldn't actually care about typing in the passphrase for unlocking a disk, or telling mountall to skip a missing disk :)
<utlemming> yeah....exactly
<utlemming> so in thinking about it, drop it
<slangasek> utlemming: and cloud-init isn't something that users might install on their host system for testing?
<utlemming> only if they want the most useless desktop ever
<lifeless> I think we'd very much want to dissuade them from installing it
<lifeless> but
<lifeless> openstack will get two-way consoles at some point
<utlemming> oh...
<lifeless> I don't think it's true to say it's going to be just output indefinitely
<utlemming> actually, no we can't drop it
<slangasek> utlemming: cloud-init itself wouldn't break the desktop, would it?  if there are no options set it ought to be a no-op?
<utlemming> cloud-init is an aggressive package...it wants a datasource and would delay the boot
<slangasek> heh
<utlemming> add ~2 minutes or more to the boot
<slangasek> well, ok then
<slangasek> so we can fairly safely say that having cloud-init override plymouth is probably not going to make things worse
<utlemming> probably not
<smoser> when cloud-init is instlaled, you're quite likely to end up with a 2 minute boot. with annoying timeouts.
<smoser> lifeless, disabling plymouth doesn't mean non-interactive console
<smoser> it means non-interactive console during boot
<smoser> its still possible to put a getty on /dev/ttyS0
<smoser> and openstack does have 2 way consoles in that respect now. (via vnc).
<lifeless> smoser: cool
<lifeless> smoser: so my point was that entering a password for luks in the cloud is viable in that setup
<smoser> only moderately.
<smoser> that is a use case, you're right.
<smoser> but realisitcally... yoiu're uber paranoid at that point
<smoser> and without a lot of benefit
<lifeless> yeah
<lifeless> agreed
<smoser> as someone as direct access to your memory
<smoser> hey... i'll beg again.
<smoser> anyone able to take a review of https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1233486
<ubottu> Ubuntu bug 1233486 in software-properties (Ubuntu) "add support for 'cloud-archive:' like 'ppa:' but for cloud archive" [Undecided,New]
<smoser> mvo basically said "ok", but i'd like to upload to saucy, and would appreciate someone else's eyes on that.
<goodwill> quick question, I am looking for the revision which the PPA build bots is building in the build log and I am failing to find it ... where is such information kept
<cjwatson> goodwill: you mean of a recipe or something?  might be helpful to link to the build in question
<goodwill> cjwatson: https://launchpadlibrarian.net/139863041/buildlog_ubuntu-precise-amd64.nginx_1.4.1-1ppa1~precise_UPLOADING.txt.gz
<infinity> goodwill: A link to the build is more useful than a link to the log.
<cjwatson> goodwill: I don't quite understand the question, then.  The builder is given a source package, whose version is right there in the URL.  If there's a version control system behind it, the builder doesn't know about it.
<goodwill> hmmm
<cjwatson> In the case of recipes, then there's a bzr revision, indeed, but that package wasn't built using a recipe.
<goodwill> https://launchpad.net/~nginx/+archive/stable/+build/4577421
<goodwill> I see
<goodwill> yeah it was not clear what revision was pulled
<cjwatson> So for instance in the build log linked from https://launchpad.net/~numix/+archive/ppa/+recipebuild/553593 you can pick apart the generated source package version to see that that was bzr revision 82.
<infinity> goodwill: Well, what revision of *what*?  It wasn't autobuilt from a VCS, it was manually uploaded by a person.
<cjwatson> Right, a source package like that nginx one may not even have a proper version control system behind it at all.
<goodwill> I see
<goodwill> this explains a few things
<goodwill> I though that nginx is built from the sources in the launchpad code
<cjwatson> But you can download the source package and look at it.
<cjwatson> Poke around in https://launchpad.net/~nginx/+archive/stable
<sarnold> I think the retracers are dead, this bug is five hours waiting for a retrace: https://bugs.launchpad.net/ubuntu/+source/unity-tweak-tool/+bug/1235353
<ubottu> Error: ubuntu bug 1235353 not found
<psusi> cjwatson, I notice that update-grub spews a *ton* of debug output into syslog in saucy... did you leave an extra debug flag on by accident?
<cjwatson> No, that's probably os-prober which has done that forever.
<psusi> really?  I know it has been fairly verbose, but now there are screen fulls of lines that say debug and end up echoing the entire contents of any and all other grub.cfg files found.. I didn't think it was quite that chatty before
<cjwatson> That's os-prober and yes it has been.
<psusi> oh... ok
<cjwatson> It makes more sense within d-i.
<psusi> yea... makes sense for the install logs... just a bit verbose going into syslog on a running system
<ScottK> cjwatson: Your scripts for newer in raring-updates than saucy doesn't seem to take into account epochs or something because both kdeadmin and kdenetwork are false positives.
<cjwatson> ScottK: No, they're really not.
<cjwatson> ScottK: They're pointing out duplicate (old) binaries in saucy due to old sources that apparently haven't been removed.
<ScottK> Right.
<ScottK> I see it now.
<ScottK> Thanks.
<cjwatson> (What they don't take into account is the presence of binaries that are both older and newer in saucy ... but that's a fixable bug anyway :) )
<cjwatson> I mean I consider that a thing to fix in the archive rather than in my script
<ScottK> Yeah.  I'll remove the stale sources.
<sarnold> older-and-newer? :)
<cjwatson> Adam and I were just talking about going through the list of whines from the publisher's domination pass, which would fix this in bulk
<cjwatson> sarnold: If there are multiple sources that claim to build the same binary, all versions will be kept around until the older sources stop claiming that
<cjwatson> You could view this as a misfeature or you could view it as an early warning system: it's pointing out that if you were to do an upload of the one that builds older versions, it would (I think) fail to upload due to version conflicts
<ScottK> Removed both the old ones.
<cjwatson> Thanks
<sarnold> cjwatson: aha, I think I get it, thanks :)
<ScottK> The main problem with it was me misreading rmadison output.
<ming> i use bzr branch got lp:chinese-calendar source,edit something and want to upload these source to my ppa.Every time the files can upload successfully ,but i alway got a reject email soon.Is there any people know what's the problem?
<ming> the error is like this:Rejected:
<ming> File <UPLOADED_FILE> already exists in <LOCATION>, but uploaded version has different contents.
<ming> See more information about this error in https://help.launchpad.net/Packaging/UploadErrors.
<ming> but i download the orig.tar.gz from the launchpad,how can it has difference with itself?
<cjwatson> What exact URL did you download chinese-calendar_0.8.0.orig.tar.gz from?
<ming> https://launchpad.net/chinese-calendar/+download
<ming> this page
<cjwatson> No, don't do that.  It must be from the Ubuntu archive
<cjwatson> https://launchpad.net/ubuntu/+source/chinese-calendar/0.8.0-0ubuntu1
<cjwatson> Also, you should not version your package 0.8.0-0ubuntu2 - that might conflict with a later version in the Ubuntu archive
<cjwatson> You probably want to use something like 0.8.0-0ubuntu1ppa1 instead.  See https://help.launchpad.net/Packaging/PPA/BuildingASourcePackage#versioning
<ming> oh... thank you!!
<ming> And can you tell me how do you get this page:https://launchpad.net/ubuntu/+source/chinese-calendar/0.8.0-0ubuntu1
<cjwatson> I started at https://launchpad.net/ubuntu/+source/chinese-calendar which is a pattern I use all the time and have memorised
<ming> search in any page?
<cjwatson> You could also get to it by searching from https://launchpad.net/ubuntu
#ubuntu-devel 2013-10-05
<ming> got it! Thanks very much.
<cjwatson> no problem
<psusi> anyone know if there is a way to have a .desktop file run a program as root that works both in gnome and kde?
<jtaylor> psusi: something via pkexec?
<psusi> jtaylor, it seems that kde doesn't require a polkit authentication agent be installed, so if one isn't, it doesn't work
<jtaylor> don#t know then
<psusi> I'm not sure *why* kde depends on the polkit libs, but not an authentication agent....
<psusi> it seems like it should
<ming> why my ppa has no key under "Technical details about this PPA"?https://launchpad.net/~anywnztj/+archive/test-for-uk
<sarnold> ming: maybe LP waits until a package is built and downloadable?
<sarnold> ming: it might be an hour or three hours before your packages are built, note the PPA build status sidebar: https://launchpad.net/builders/
<ming> I don't know. It's my first time to use ppa.
<ming> wow, what display in this page is cool.
<ming> dispaly Signing Key now .Thanks.
<sarnold> ming: cool! I was wrong, the package still isn't built, but you've got a key. hehe. :)
<ming> another question, how to use bzr download source code and build my own branch ? I know use "bzr branch " can download the source code and then use "bzr push" to upload the code i have changed to the launchpad again, but in this way the revision number is not 1 while someone tell me if I build my own branch ,the revision number should begin with 1, so the question is how to do this ? just "rm -r .bzr" after i use "bzr branch" and "bzr init"?
<slangasek> ming: I think "someone" told you wrong
<slangasek> there's no reason to wipe out the existing .bzr directory and create your own
<ming> you can see this project.https://code.launchpad.net/chinese-calendar
<ming> same revison has different things.
<slangasek> that's... not a good thing
<ming> I think maybe different people do different things so let them independent?
<ming> I viewed what every people upload ,one is .cpp and one is .ui and so on.
<alkisg> How can I get a test case for triggering whoopsie? It appears that a segmentation fault isn't enough to trigger the "send error report" dialog...
<Noskcaj> alkisg, Can't you just run "ubuntu-bug PACKAGE" ?
<alkisg> Noskcaj: thanks but I want to test when whoopsie is invoked automatically and when not...
<Noskcaj> ok, i'm out of ideas
 * alkisg found `bash -c 'kill -SEGV $$'` in some launchpad bug report, but that doesn't trigger whoopsie either
<alkisg> ...sorry, yes it does, so it's my system that's misconfigured. Thanks!
<alkisg> (it does ==> on another, cleaner system)
<Noskcaj> kirkland, roaksoax: What happened to the indicator for testdrive?
<alessander> !list
<ubottu> alessander: No warez here! This is not a file sharing channel (or network); read the channel topic. If you're looking for information about me, type Â« /msg ubottu !bot Â». If you're looking for a channel, see Â« /msg ubottu !alis Â».
<TJ-> Anyone recall the udev rules for persistent-net.rules, and whether, in the past, they would use transient temporary names to achieve renaming when if-names were to be shuffled (e.g. eth3 > eth0, eth0 > eth1, etc) ?
<soren> TJ-: I don't understand the question. Changes aren't applied immediately. Only upon rediscovery (ie on reboot). So why would temporary names be needed?
<TJ-> soren: With 13.10 the 70-persistent-net.rules fail because the kernel has already assigned names when udev tries to rename the interfaces. The SIOCTLSIFNAME call returns -EEXIST
<TJ-> soren: bug #1235162
<ubottu> bug 1235162 in systemd (Ubuntu) "Regression: Persistent net names via /etc/udev/rules.d/70-persistent-net.rules fail" [High,Triaged] https://launchpad.net/bugs/1235162
#ubuntu-devel 2013-10-06
<ming> any way to let the revision begins with  1 except I delete the .dzr directory after i get the source code with "bzr branch" ?
<slangasek> ming: no, and as I mentioned the other day, that's the wrong goal.  The only way to get a different revision 1 is to /not share history/, which is contrary to the purpose of a distributed VCS
<infinity> ming: I can't fathom why you'd WANT to reset the revision to 1.
<ming> I am looking for a job and "they" ask me to do something to test me.
<infinity> ming: If you're looking for a job with someone who wants you to remove history and attribution from code you fork, you might want to look for a better job.  Just sayin'. :P
<slangasek> except that based on the branches ming linked to earlier, I suspect this is related to UbuntuKylin
<slangasek> so I think we might want to address these strange branch management practices... :)
<ming> Yes, you are right...
<infinity> Indeed we might, then.
<ming> I send an email to one of them, they say don't need to delete .bzr.
<ming> I am interesting in open source things. In china, it's hard to get a job like this.
<ming> but in the project page you can see they have different revison  all begin with 1,how they did it without remove .bzr directory?
<infinity> Example branch?
<ming> https://code.launchpad.net/chinese-calendar
<infinity> It looks like instead of branching, people sometimes bzr export, then push it as a new branch, or similar.  Which is something approaching insane.
<infinity> Since one can't then consolidate those branches.  And you lose all the history.
<infinity> So, yeah, as slangasek says, perhaps someone should address this practise, not continue it.
<sarnold> (but might make some amount of sense if all N people working on the chinese calendar are actually competing against each other rather than cooperating on its construction)
<infinity> sarnold: It's a project with a free license, and only one "official" version in the archive.  Competition aside, they can clearly still yank each other's code, and only one trunk gets uploaded.
<infinity> So, making merging back and forth harder just seems gratuitously silly. :P
<sarnold> especially if the winner and the winner's code is intended to be merged back in..
<ming> Maybe they think of something else...
<ming> â¬another question ,how to build a deb and when user  install it, an icon displays on user's desktop ? Maybe you think this looks strange too. But for Chinese user,it's a good thing...
<infinity> ming: If every package did that, users would have hundreds of icons on their desktop.  What makes yours more important?
<infinity> ming: (This is why our current design just plain doesn't do that at all)
<ming> I know you people think like this.
<ming> but for China user, if there is no icon on desktop,they will can't find the software...
<infinity> ming: So, you're implying that every piece of software installed in a default install (like I said, hundreds of applications) should have an icon on the desktop?
<ming> of course not.
<infinity> We do highlight a select few productivity apps (libreoffice, firefox..) and put them in the launcher by default as a hint.
<infinity> Kylin could, of course, hand-pick a few different defaults (and may well do so, I've never installed it and looked).
<ming> Maybe WPS office and something else.
<smartboyhw> JackYu, ^
<infinity> But individual packages adding themselves to the desktop or launcher leads to the "my application is more important than yours, so I get to be prominent" madness that, if taken to its obvious conclusion, leads to hundreds/thousands of icons.
<ming> I agree with you as well, but...
<ming> Now I should know how to do.
<ming> some important software maybe will do like this to help people use their computer easily.
<ming> To common user, they will be confused if there is no icon after they installed the software.
<JackYu> ming, maybe you cloud add a Desktop Entry.
<ming> i know this.
<ming> it's a .desktop file.
<ming> Are u the Administrator of UbuntuKylin Members ?
<ming> He named JackYu, too.
<ming> I hava some ideas now. I am reading Debian Policy Manual .
<JackYu> ming, as far as I know, there is no requirement for revision starting from 1.
<ming> JackYu, maybe the man I asked mad a slip of the tongue while I think too much about this.
<JackYu> ming, should be that:). It's strange...
<JackYu> ming, what's you LP id?
<ming> JackYu, it's anywnztj.
<ming> What's wrong?
<JackYu> ming, nothing, just a look:).
<ming> JackYu,:-))
<JackYu> slangasek, infinity, sarnold, smartboyhw, hi, the UbuntuKylin test dose NOT require the revision restarting from 1. Furthermore, it is not a good answer if doing like that:).
<smartboyhw> JackYu, heh heh heh
<JackYu> sorry for the delayed reply, I'm in a conf:(
<smartboyhw> Conf on Sundays, baed
<smartboyhw> *bad
<maxiaojun> seems like debian is no longer a frontier for foss packaging?
<maxiaojun> for example https://help.ubuntu.com/community/InternetRelayChat mentions hexchat
<maxiaojun> fedora and opensuse have hexchat in repo, not the case for debian and ubuntu
<brainwash> maxiaojun: bug 995018
<ubottu> bug 995018 in xchat (Ubuntu) "[needs-packaging] HexChat" [Wishlist,Triaged] https://launchpad.net/bugs/995018
<smartboyhw> There is actually a ITP bug in debian too
<smartboyhw> Just that nobody touched it
<smartboyhw> maxiaojun, ^
<maxiaojun> seems like debian is no longer a frontier for foss packaging?
<infinity> ...
<infinity> Because one thing you want packaged isn't?
<maxiaojun> examples are many, i just hit this one today though
<infinity> As it's always been in Debian, things get packaged when someone who's using it wants to package it.
<infinity> I don't use it, therefor I wouldn't package it.
<maxiaojun> maybe those want a unix-ish "desktop" still use debian, other desktop users don't
<maxiaojun> ubuntu has many desktop users, but when people want something packaged, the answer is 'hey, go to debian first'
<tumbleweed> maxiaojun: that's because packages that are only in Ubuntu tend to go unmaintained
<infinity> Someone does appear to be maintaining hexchat packages in a PPA, at least.
<infinity> https://launchpad.net/~gwendal-lebihan-dev/+archive/hexchat-stable
<infinity> And quite actively so.
<maxiaojun> tumbleweed: same thing for debian
<tumbleweed> maxiaojun: no, in Debian packages have maintainers
<tumbleweed> it's their job to keep a package in shape
<maxiaojun> tumbleweed: zombie maintainers are many
<tumbleweed> sure, but at least we know to remove the package, when the maintainer has been gone for a while
<maxiaojun> tumbleweed: really?
<tumbleweed> yes
<tumbleweed> also, it's not like it's any harder to do things in Debian, and you get more users for free
<maxiaojun> debian stuck with texlive 2009 for ~3 years? have you removed it?
<tumbleweed> maxiaojun: um, I don't know what makes you think that
<tumbleweed> http://packages.qa.debian.org/t/texlive-base.html
<maxiaojun> it seems ok now
<maxiaojun> but don't you find it strange that u 12.04 has texlive 2009?
<infinity> Not really.
<tumbleweed> not particularly. texlive is huge & crazy
<infinity> Debian had moved on to 2011 at that point, but I chose not to do the transition in the middle of an LTS cycle.
<cjwatson> sometimes there are good reasons too.  groff was at an old version for a long time, but it wasn't because I was inactive
<infinity> New versions aren't always the right answer to everything.
<cjwatson> by just pointing at versions without looking at the backstory, you're basically cherry-picking headlines over substance.
<infinity> Erm, aren't we upstream for software-properties?
<cjwatson> Pretty sure we are yes
<infinity> We sure are.
 * infinity rejects smoser's upload.
<maxiaojun> ok, i admit that i didn't check changlog for texlive
<maxiaojun> http://ftp-master.metadata.debian.org/changelogs//non-free/r/rar/rar_4.2.0-1_changelog
<infinity> smoser: Can you commit a sane version number to lp:software-properties and reupload?
<maxiaojun> this one is a real example, rar 4.0b2 4.0b3 broken for many languages that are non-English/non-ASCII/non-OEM-encodable for ~ 2 years
<infinity> Okay, massive props for patches with ASCII art in them.
<infinity> http://launchpadlibrarian.net/152578059/libwacom_0.7-1_0.7-1ubuntu1.diff.gz
<maxiaojun> another good example is ibus-* packages, do you think LI Daobing, as a maintainer, still cares even a little bit?
 * infinity goes to bed before maxiaojun decides to point out any packages he maintains.
<maxiaojun> I'm not criticizing LI Daobing. I'm criticizing the so-called maintainer system. Basically LI was an advocate of IBus at 2009-2010, made many initial packages. And he didn't do anything after 2010. While he is still listed as maintainer.
<maxiaojun> http://packages.ubuntu.com/search?keywords=tegaki
<maxiaojun> Have you found that  tegaki-zinnia-traditional-chinese comes so late? because LI didn't package it. And no one bothered to fix this.
<maxiaojun> in fact it is not fixed in debian still http://packages.debian.org/search?keywords=tegaki
<maxiaojun> tumbleweed: you still advocate for the maintainer system?
<smartboyhw> maxiaojun, I advocate for the team maintainer system...
<tumbleweed> infinity: double plus good? :P
<maxiaojun> many debian teams look zombie or half-zombie
<tumbleweed> maxiaojun: but you can join them, if you want to help. teams almost always welcome any newcomer
<maxiaojun> btw, is eglibc dead or I'm just to lucky to observe http://www.eglibc.org/ down?
<melodie> hi
<achernya> Hello. Can I help you?
<melodie> hi achernya nice of you. I was looking if I could see seb128 but he does not seem to be here now
<melodie> here it says he was the last to work on the package: http://changelogs.ubuntu.com/changelogs/pool/main/l/lightdm/lightdm_1.2.3-0ubuntu2.3/changelog
<melodie> and I meet with an issue with the latest lightdm version : however I'm not sure only lightdm is concerned, there is libgobject which goes along
<melodie> I meant liblightdm-gobject-1-0
<melodie> is the Ubuntu project going to use systemd instead of upstart?
<tumbleweed> unlikely
<melodie> how come I've seen packages containing the "systemd" chain character, in the installed packages?
<tumbleweed> I don't quite understand that, but I assume you're seeing some of the things that we do use, from the systemd source
<melodie> I am in a wonder about it, also because the gui application for configuring the services in Ubuntu has been broken and left as is in Ubuntu since several years now. :[
<melodie> I am looking forward to finding a way to point to some threads which source this statement
<melodie> gn
#ubuntu-devel 2014-09-29
<Mirv> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: Feature Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: Mirv
<pitti> Good morning
<pitti> zul: here now, I was on holiday on Fri
<Mirv> good morning
<thopre01> Hi there. Is it possible to create a backport for an unsupported release of Ubuntu (say 11.04 for instance)
<thopre01> ?
<TheMuso> thopre01: It may be technically possible, but it wouldn't be done for an unsupported release.
<thopre01> TheMuso: Ok, that was my question
<thopre01> Thanks
<thopre01> Backports can be done for LTS right?
<Mirv> thopre01: LTS or any normal release. at the moment only 12.04 LTS and 14.04 LTS are supported as 14.10 is not out yet.
<thopre01> Mirv: Sure. That's what I thought. Thanks both of you
<dholbach> good morning
<Mirv> morning dholbach
<dholbach> hi Mirv
 * Mirv happy to be able to do more during patch pilot as a MOTU
 * dholbach hugs Mirv
<Laney> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: Feature Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: Mirv, Laney
<pitti> Laney: hey
<pitti> Laney: I did a few syncs already, currently looking at the libgweather updates, and I'll take the three langpack-locales ones
<Laney> 'kay
<Mirv> pitti: so hmm, syncing new micro releases don't need FFe?
<pitti> bug fixes only -> no new features
<Mirv> right, so if the new micro release is sufficiently bug fixes only
<Mirv> I could have done a couple of those then
<pitti> Mirv: MP status> ah, I see "merged" and "rejected" too, must be a matter of being an uploader for that package or not?
<Mirv> the minitube for example does seem a bit more than just bug fixes (adding some unity & gnome 3 action)
<pitti> Mirv: I set https://code.launchpad.net/~filip-sohajek/ubuntu/utopic/silversearcher-ag/fix/+merge/232369 to rejected now, to avoid confusion
<Mirv> pitti: well I'm MOTU now so I should have been a possible uploader for that
<Mirv> pitti: maybe it's still something core-dev vs. motu that gives you those extra options, even in a case of universe package
<pitti> Mirv: yeah, maybe
<Mirv> that might be a bug, though
<pitti> Laney: looking at libchamplain sync now, then I'll stop
<Laney> pitti: okay, I'm distracted by an upgrade failure anyway
<Mirv> I'll look at grace
<Mirv> dholbach: there seems to be multiple active piloters today, possibly reshuffling calendar could make sense
<Mirv> at least I can be freely moved around
<dholbach> Mirv, there's always different piloters scheduled on a day
<Mirv> dholbach: sure, I just think on some days there are less active ones (no-one does @ pilot in etc)
<Laney> Mirv: just assign yourself to a bug when you take it for sponsoring
<Mirv> that makes sense
<dholbach> Mirv, yes, that's right, but it's a bit hard to anticipate who might be active and who isn't
<Laney> also I've been slacking
<Laney> lemme come back in 10 minutes :)
<Laney> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: Feature Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: Mirv
<dholbach> Mirv, if you have a look at http://wiki.ubuntu.com/UbuntuDevelopment/CodeReviews?action=raw you can see a table that's commented out, which I use as a basis for the schedule
<ara> infinity, hi! when you are around, could you please have a look to these pending packages on the precise queue, please? https://launchpad.net/ubuntu/precise/+queue?queue_state=1&queue_text=fglrx
<ara> infinity, they fix an important bug and they have been in the queue for 3 weeks now
<ara> infinity, thanks!
<Laney> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: Feature Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: Mirv, Laney
<Mirv> dholbach: oh, interesting, so Lane_y just happens to patch pilot today, not by schedule. cool.
<Laney> I always move myself around
<Laney> and try to keep the PP calendar entry accurate
<Mirv> I've been also slacking waiting for the MOTU application to be handled, so I should probably do some extra shifts
<pitti> smoser, infinity: wolfe-0[3456] seem AWOL; any idea what's going on?
<pitti> or is that due to lamont's VPN reorg?
<mlankhorst> pitti: https://jenkins.qa.ubuntu.com/job/utopic-adt-qtcreator-plugin-ubuntu/ARCH=amd64,label=adt/267/console how is that test spawned?
<mlankhorst> just running qtcreator-launch directly works for me..
<pitti> mlankhorst: check in its debian/tests/<testname>; but the current versions do succeed, so apparently this got fixed in the meantime?
<mlankhorst> it happens because of mesa
<mlankhorst> which is weird.. there is no GLX there..
<pitti> mlankhorst: xvfb does support it if you use 24 bit depth
<pitti> (with llvmpipe)
<mlankhorst> what's the default depth?
<pitti> 8 with xvfb-run
<pitti> (so you have to explicitly add a -screen)
<mlankhorst> hm weird it does run it with 1024x768x24
<mlankhorst> qemu: terminating on signal 15 from pid 59347
<pitti> mlankhorst: as I said, the recent test runs did succeed; #267 is likely from an older version?
<mlankhorst> pitti: no the newer mesa is deleted from the archive
<mlankhorst> I want to reproduce the failure so I can investigate it
<pitti> ah, or that
<pitti> mlankhorst: http://d-jenkins.ubuntu-ci:8080/job/utopic-adt-qtcreator-plugin-ubuntu/278/ ran two days ago, was a newer mesa removed over the weekend?
<pitti> mlankhorst: I can re-run the test manually if it helps
<pitti> (still not sure what you are trying to do)
<mlankhorst> yeah
<mlankhorst> pitti: I want to debug why glx creation was failing with mesa 10.3
<mlankhorst> but I see the test is run with qemu, how is it invoked?
<pitti> mlankhorst: http://packaging.ubuntu.com/html/auto-pkg-test.html#executing-the-test describes how we run tests in CI
<pitti> mlankhorst: but if you have the deps installed, merely running debian/tests/qtcreator-launch shoudl actually reproduce that as well
<pitti> mlankhorst: perhaps what happesn in that test is that it doesn't wait for Xvfb to sufficiently start up
<pitti> it's not using xvfb-run, but Xvfb directly
<mlankhorst> yeah
<mlankhorst> well that oculd be possible
<mlankhorst> but it was working before, so unless it changes the timing..
<mlankhorst> it looks more like some kind of interaction with llvmpipe or something
<mlankhorst> oh there we go, can reproduce it with those instructions, thanks :)
<mlankhorst> adt-run -s --setup-commands 'apt-get install -y python-software-properties; apt-add-repository -y ppa:canonical-x/x-staging; apt-get update' qtcreator-plugin-ubuntu --- qemu adt-utopic-amd64-cloud.img
<pitti> mlankhorst: ah, nice! note you can add -s to get a shell after the test failure
<pitti> mlankhorst: then you can ssh into the VM (it prints the commands for that) and investigate
<mlankhorst> yeah
<lamont> pitti: I added another net to the vpn, but legacy or new should work the same..
<lamont> pitti: still an issue?
<mlankhorst> ok got something, goodie :)
<mlankhorst> name of display: :100
<mlankhorst> Error: couldn't find RGB GLX visual or fbconfig
<pitti> lamont: yes, it is; but it might very well be that the host (wolfe-XX) itself is down
<pitti> lamont: I can't reach it from home (through batuan), nor can the CI lab talk to it
<mlankhorst> weird.. same test in my chroot works..
<pitti> lamont: so I'll wait for smoser/infinity to have a look at the wolfe host
<lamont> pitti: ok.  I'm not actually here until 2.5 hrs from now -- there shouldn't be anything about the vpn, other than several batuan vpns were restarted friday -- reconnect would recover if needed
<pitti> lamont: I'm not using VPN there, I just use batuan as a ProxyCommand (as advised back then)
<pitti> (for ssh)
<lamont> yeah - legacy is 100% unaffected, other than me restarting most of the vpns on batuan
<pitti> lamont: ack, thanks for the heads-up
<lamont> fwiw, I believe that the new vpn should get you to everywhere you can go legacy -- if not, scream soon
<lamont> (unrelated to the restarts, but I had a productive weekend)
<lamont> afk
<Mirv> pitti: I wonder if you could bookmark yuning's https://code.launchpad.net/~yuningdodo/ubuntu/trusty/usb-creator/usb-creator.lp1361474+lp1300361-recreate-udisks-client/+merge/232852 for evaluation at some point?
<Mirv> I can do some testing if wanted with various combos, but I can't upload it anyway
<pitti> Mirv: is that actually a backport to trusty, or does that need fixing in utopic, too?
<Mirv> pitti: it's a backport of 0.2.62/utopic and one line from 0.2.60/utopic
<Mirv> two lines, that is
<pitti> Mirv: ah good, thanks
<Laney> mitya57: do you know what happened to https://code.launchpad.net/~saiarcot895/ubuntu/trusty/openscenegraph/armhf-support/+merge/230835 ?
<Laney> I see it in trusty/rejected
<rbasak> Laney: I think it was intentionally rejected so the contributor could add a fix for bug 1339264 as well, which I think he's now done and updated the MP.
<ubottu> bug 1339264 in openscenegraph (Ubuntu) "Missing FreeType support in 14.04 LTS package" [Undecided,Confirmed] https://launchpad.net/bugs/1339264
<Laney> rbasak: ta
<pitti> jodh: hey James! FYI, you can apt-get install systemd-sysv now, all tasks in bug 1351306 are done now
<ubottu> bug 1351306 in upstart (Ubuntu) "Cannot uninstall upstart and install systemd-sysv" [Low,Fix released] https://launchpad.net/bugs/1351306
<jodh> pitti: nice - thanks!
<Mirv> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: Feature Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: Laney
<smoser> pitti, whats up?
<pitti> smoser: wolfe-0[3456] are unreachable
<pitti> smoser: is the VM host down, or just the VMs themselves, or is it a networking problem?
<smoser> i'll check
<pitti> smoser: unreachable from both my home as well as the QA lab (jenkins)
<smoser> pitti, ok. wolfe (host) is down. i will get it back up today. i'd like to update firmware while its down though (even though that is unplanned)
<smoser> unless you want to insist otherwise.
<pitti> smoser: nah, I don't meddle with how you manage this machine :) (and I don't have any idea about that hw anyway :) )
<pitti> smoser: thanks!
<smoser> pitti, no. i was just asking if you wanted it up immediately
<pitti> smoser: nah, it's not that urgent
<camako> pitti, is the new umockdev (0.8.8-1) going to be released on rtm and trusty also?
<pitti> camako: I can copy it to RTM if you need; we don't normally put new upstream releases into stable Ubuntu releases, so for trusty we'd rather do an SRU with some fixes
<pitti> camako: but at the same time nothing in trusty needs the new umockdev?
<camako> pitti, ack about the rtm... As for trusty, Mir, as it stands, can work under trusty, and we 'd like  to keep it this way, if possible. So when the (Mir) MP requiring this umockdev fix lands, some of our unit tests will be failing on trusty.
<pitti> camako: https://launchpad.net/ubuntu-rtm/+source/umockdev/0.8.8-1
<camako> pitti, thanks... So do I need to do anything to get the binaries incorporated on my end or will this do it?
<pitti> camako: that'll do for RTM; for trusty, if you want this, you can negotiate with the SRU team if they'd accept a backport in trusty-updates
<pitti> camako: or, if you only need a single fix (or two) from 0.8.8, we can backport that
<camako> pitti, ok will do.. thanks for your help
<camako> pitti, I only need the fix abt O_TMPFILE that I sent a few weeks ago..
<tkamppeter> pitti, hi
<pitti> camako: ah, because there were a lot more Mir triggered changes
<tkamppeter> pitti, bug 1355136 seems to be stuck. Should it not get fixed any time soon?
<ubottu> bug 1355136 in xubuntu-meta (Ubuntu) "Add recommends printer-driver-brlaser package in -desktop installations" [High,Confirmed] https://launchpad.net/bugs/1355136
<pitti> tkamppeter: wow, quite incredible that ubuntu-meta has not been uploaded *a single time* in utopic
<tkamppeter> pitti, this would mean that every new package introduction on the way from Trusty to Utopic was handled by dependencies in regular packages.
<pitti> tkamppeter: or that any seed change hasn't become active
<pitti> tkamppeter: I'm rebuilding it now, let's see what the fallout is
<pitti> tkamppeter: uploaded
<tkamppeter> pitti, thanks.
<seb128> could somebody from the SRU team copy the trusty/verified SRUs with > 1 week to -updates?
<seb128> there are a  bunch of 10 to 12 days old verified items in there
<ara> infinity, ping
<bdmurray> sarnold: I've found a fair number of bugs w/ modified sbin/start-stop-daemon. What do you think is the next step?
<pitti> jodh: progress on bug 1374521 and a question to you
<ubottu> bug 1374521 in systemd (Ubuntu) "networking.service races with kernel interface detection, ifup@.service is not being triggered" [Undecided,In progress] https://launchpad.net/bugs/1374521
<cjwatson> bdmurray,sarnold: check installer logs; my guess is that many of these are due to installs that failed in the middle of the bit where start-stop-daemon is replaced with a dummy script, but which were perhaps far enough along for people to muddle along and use them as a real system
<jodh> pitti: yeah, we'd thought of that, but stgraber has reservations about that approach
<pitti> jodh: btw, congrats -- you made the boot so fast to outperform the kernel :)
<bdmurray> cjwatson: got it, thanks
<pitti> jodh: (honestly -- it's nice that this works so fast now!)
<jodh> pitti: just don't tell lennart :)
<stgraber> pitti: Ubuntu doesn't use allow-hotplug, starting to support it would require a lot of updates all over the place, so I really would rather not do that now
<pitti> stgraber: what do you mean with "ubuntu doesn't use"? Ubuntu's d-i on server?
<pitti> (our ifupdown obviously supports and documents it)
<stgraber> pitti: I mean none of our ifupdown scripts know use that ifupdown class
<stgraber> s/use //
<pitti> stgraber: which scripts? (I'm learning a lot today :) )
<stgraber> pitti: bridge-utils, vlan and ifenslave mostly
<stgraber> pitti: all the scripts which ship udev hooks and have to figure out whether the thing that just showed up is the base for an interface defined somewhere in /e/n/i
<pitti> stgraber: ah, you mean these look for "auto" interfaces
<stgraber> yep
<stgraber> they use ifquery and list auto interfaces
<pitti> so I guess we need to also call ifup --allow=auto then and live with ifup being called twice
<pitti> (or actually three times)
<stgraber> that's fine, it's actually what we already do today. The networking job which just does an ifup -a is a catch all in case the event bringup didn't happen.
<infinity> pitti: Hey, did anyone have a poke at wolfe for you?
<infinity> pitti: Without looking, I'm going to assume it's the same problem that host has always had.
<stgraber> so in most cases ifup will already have been called at the time the device appeared, then again when hitting the catch all
<pitti> infinity: smoser was, and updating firmware and do other admin things while he's at it
<stgraber> but since ifupdown isn't entirely stupid, it knows it's already been brought up and doesn't actually do anything
<infinity> pitti: Oh, shiny.  With any luck, one of those things might magically fix it.
<infinity> (Not that I'm holding my breath)
<pitti> stgraber: right, it's not going to actually break anything, it's just some unnecessary calls
<smoser> pitti, how important are the system syou had there?
<smoser> hm.. pitti see private query
<pitti> smoser: well, we don't block on ppc64el test results, but it'd still be nice to get autopkgtest results for that platform
<pitti> smoser: I'm happy to move to other systems, of course
<pitti> jodh: ok, need to stop for today; I got the ifup@.service triggering fixed, I'll adjust it to also cover "auto" interfaces then
<pitti> stgraber: thanks for the heads-up
<pitti> jodh: i. e. I'll upload tomorrow morning, after proper testing
<jodh> pitti: great, thanks. chat then.
<Riddell> LocutusOfBorg1: you did the cmake merge? was there any reason for that?
<bdmurray> tinoco: on which release does the fix for bug 1316125 work for you?
<ubottu> bug 1316125 in autofs (Ubuntu Trusty) "Autofs leak file descriptors when reloaded (-HUP) and daemon may stop working on high # of shares/reloads" [Undecided,Fix committed] https://launchpad.net/bugs/1316125
<tinoco> bdmurray: precise
<bdmurray> tinoco: its helpful to identify that in the bug so the SRU team knows which release can have the package released to -updates.
<tinoco> bdmurray: makes total sense, want me to update it with all releases tested ?
<bdmurray> tinoco: yes, please
<tinoco> i can provide output based on testcase (since it is straight forward)
<tinoco> bdmurray: will get back to you as soon as its ready
<tinoco> bdmurray: updating bug .. will finish precise and saucy in a bit
<tinoco> trusty ready
<tinoco> bdmurray: tks!
<tinoco> bdmurray: done
<hallyn> slangasek: hi - no hurry on this, but i've uploaded the new cgmanager release for jessie to https://mentors.debian.net/package/cgmanager - which has the listkeys which stgraber will eventually want.  not expecting it to hit utopic or anything so as i say no hurry, but if you get a chance to look+sponser that'd be great
<slangasek> hallyn: as you prefaced this with "no hurry", probably best if you send me an email, otherwise it will surely fall off my radar :-)
<hallyn> slangasek: will do, thanks
<jtaylor> bdmurray: I can't see the error report you are refering to in bug 1358870 whats it about?
<ubottu> bug 1358870 in python-numpy (Ubuntu Trusty) "update numpy to 1.8.2 in trusty" [Undecided,Fix committed] https://launchpad.net/bugs/1358870
<bdmurray> jtaylor: http://pastebin.ubuntu.com/8460854/
<jtaylor> bdmurray: thats harmless, there are no changes to f2py in numpy 1.8.2
<jtaylor> it just throws an exception if you give it invalid fortran
<jtaylor> which triggers appoart apparently
<jtaylor> I guess it needs a whitelist
<bdmurray> jtaylor: okay, thanks for looking
<jtaylor> whats https://errors.ubuntu.com/problem/5e17937e252e97cc744a4a8e89a0bc2ea8dace02 about?
<jhenke_> hi, does anybody knows about problems with the de archive mirror (de.archive.ubuntu.com)? I got BADSIG errors and after clearing the lists in /var/lib/apt/lists now apt is complaining about hash mismatch (on 14.10)
<sarnold> jhenke_: the .de mirror was giving people some problems last week or two weeks back, so it's been checked recently and given a clean bill of health... could you remove all your /var/lib/apt/lists/* and then re-run apt-get update?
<bdmurray> jtaylor: package:python-numpy:1:1.8.1-1ubuntu1:subprocess new pre-removal script returned error exit status 127
<infinity> sarnold: He said he did that.
<jhenke_> sarnold just did that, now apt complains about hash mismatch
<sarnold> infinity: gah. I so suck a reading.
<infinity> jhenke_: A mismatch could just be bad timing on your part (started apt-get update in the middle of a mirror pulse)... Try again and see if it still hates you?
<sarnold> and writing apparently.
<sarnold> jhenke_: it seems a great many hash sum mismatches filed in launchpad come from dying hardware; check also your dmesg for errors from your drives
<infinity> jhenke_: That mirror should be pulsed every 4h, but for a short window, there's a chance that you start your update with the old dists/ tree (and, thus, the old Releases file), and then dowload a new Packages file that doesn't match.
<jhenke_> sarnold it is a VM so I rule out hardware malfunction (as the host OS is just running fine)
<infinity> But it's also possible the mirror is dying/slow, and needs another poke with a stick.
<jhenke_> infinity just retried, same hash mismatch
<infinity> jhenke_: Fun, kay.
<jhenke_> W: Fehlschlag beim Holen von http://de.archive.ubuntu.com/ubuntu/dists/utopic/main/source/Sources  Hash-Summe stimmt nicht Ã¼berein
<jhenke_> (sorry got de lang pack installed)
<infinity> jhenke_: Can you report it on #ubuntu-mirrors?  And, for now, I'd advise switching to gb.archive.ubuntu.com and see if that clears it up.
<jhenke_> infinity will do, thanks
<infinity> jtaylor: Only one report, and pretty much no info to go by, could be anything.
<infinity> jtaylor: And probably not numpy's fault.
<infinity> bdmurray: Is there no way we can, at the very least, get the apt/dpkg terminal log for auto-submitted dpkg errors like that?
<infinity> bdmurray: They're completely useless with no log.
<infinity> bdmurray: (And I'd rather just drop them on the floor than have useless noise I can't debug)
<bdmurray> infinity: we should be able to get the dpkg terminal log file
<infinity> bdmurray: That would be hugely helpful.  In cases like the numpy one jtaylor pointed out, with a single submission, it's probably not a bug in the package at all, but a local issue.  But one can't really know without seeing the output.
<infinity> (Well, one can't always know when seeing the output either, but it's a start)
<infinity> The part where it's saying it can't run the *new* prerm script is a hint that the system might just be fundamentally busted, since it only tries that after the *old* one fails somehow.
<bdmurray> slangasek: the fix for bug 1351137 should mean that crashes are reported by default because /var/lib/apport/autoreport is created correct?
<ubottu> bug 1351137 in apport (Ubuntu) "ubuntu-system-settings-wizard does not create /var/lib/apport/autoreport on first boot" [Critical,Fix released] https://launchpad.net/bugs/1351137
<slangasek> bdmurray: yes, that's what it /should/ mean
<bdmurray> slangasek: it works for me but the default whoopsie test is failing because /var/lib/apport/autoreport doesn't exist...
<bdmurray> http://ci.ubuntu.com/smokeng/utopic/touch_stable/mako/63:20140929:20140923/10741/default/1751732/
<nadrimajstor> Is pattern [ x"$foo" != x"" ] still needed/in use ?
<cjwatson> nadrimajstor: POSIX shell doesn't need the leading x and can manage just fine with [ "$foo" ], but some other shells need it in corner cases where the expansion of $foo might be a test operator; notably Solaris was really late to switch to a Korn-flavoured shell for /bin/sh rather than its very old traditional Bourne shell, and only did so in Solaris 11.  As a result the habit is still quite widespread among people who care about ...
<cjwatson> ... portability to other Unix systems.
<slangasek> or those who cargo-culted from people who care about portability to other Unix systems ;)
<cjwatson> Some of us did both. :-)
<infinity> Heh.
<cjwatson> Certainly habits like this take a very long time to die out, if they ever do.
<infinity> I gave up on that construct as a conscious protest against Solaris /bin/sh
<cjwatson> The autoconf documentation is kept fairly well up to date with which workarounds are needed for which systems.
<cjwatson> infinity: I only discovered literally just now while sanity-checking my draft answer to nadrimajstor that they'd finally fixed /bin/sh in Solaris 11
<infinity> cjwatson: I wasn't aware that they finally got with the times in 11.  What do they ship as /bin/sh now?
<cjwatson> ksh93
<infinity> How modern.
<cjwatson> http://docs.oracle.com/cd/E23824_01/html/E24456/userenv-1.html
<cjwatson> You were expecting zsh?
<infinity> I was expecting ash or bash.
<infinity> Since they've shipped bash in /usr/xwhatever for eons.
<cjwatson> ksh93 probably isn't an awful choice, at least.  Sure better than the Bourne thing.
<infinity> Anything's better than their old shell.
<infinity> I'd just taken it as a given that I couldn't write shell scripts that behaved on Solaris without the first snippet being -x /usr/whatever/bash && exec /path/to/bash $0
<cjwatson> I think they already had ksh lying around somewhere too.
 * nadrimajstor Can I rephrase my question :)
<infinity> nadrimajstor: Did you want a new answer? :)
<cjwatson> Sure, maybe you didn't want a dissertation on archaic shells :)
<infinity> nadrimajstor: The short answer to your question is "no, no one needs x$foo = x anymore"
<nadrimajstor> infinity: Thank you.
<cjwatson> I gave you the longer version because you said "/in use". :-)
<infinity> test -z "$foo" is much saner.
 * nadrimajstor also likes cjwatson answer
<cjwatson> Technically, nadrimajstor was asking about [ x"$foo" != "" ], whose modern version is simply [ "$foo" ]
<infinity> And, indeed, the other workaround for Solaris, if you use full paths (don't), cause they had a /bin/test that wasn't as braindead as the sh builtin.
<infinity> cjwatson: [ is test.
<infinity> (You know this, mind you)
<cjwatson> [ -n "$foo" ] (or test -n "$foo") works as well but is unnecessary
<cjwatson> infinity: Yes, I was quibbling about -n vs. -z.
<infinity> Oh, sure, I got my test backward, cause I forgot the example.
<cjwatson> And the lack of necessity of -n. :-)
<infinity> Wait, when did [ and test move to /usr/bin?
<cjwatson> The autoconf documentation is a fantastic catalogue of people clearly having had very bad days.
<cjwatson>      Within a command
<cjwatson>      substitution, 'echo 'string\c'' will mess up the internal state of
<cjwatson>      ksh88 on AIX 6.1 so that it will print the first character 's'
<cjwatson>      only, followed by a newline, and then entirely drop the output of
<cjwatson>      the next echo in a command substitution.
<infinity> Fallout from Fedora's /usr merge, or has that been broken for years?
<cjwatson> $ schroot -c lenny-i386 which test
<cjwatson> /usr/bin/test
<infinity> Years it is.
<cjwatson> Presumably on the theory that in practice you can just use your shell's builtin.
<infinity> Not that it matters, since we ship shells with sane builtins.
<infinity> But it still feels wrong.
<nadrimajstor> Can anyone point me to some guidelines on providing default confs and symlinking to /etc ?
<nadrimajstor> Oh... Crucial part... I'm making a native 3.0 .deb without source.
<maxb> nadrimajstor: I think you might need to explain "default confs and symlinking to /etc" a bit more
 * nadrimajstor is a bit confused about pre|post and inst|rm
<infinity> nadrimajstor: Symlinking out of /etc is generally a sign you've done something wrong.  The two ways (excluding fancy things like ucf) that one provides a default config file are either to (a) ship it in /etc as a conffile, or (b) ship it in /usr/share/<package> and copy it to /etc on first install in the postinst (and never again).
<infinity> nadrimajstor: The first is the preferred method for something whose default mostly works and only needs the occasional tweak by the admin, the second is probably better if your config file is more of a template that you expect people to heavily mangle and never look like yours again.
<ari-tczew> cjwatson: ping on bug 1234612, any plans there?
<ubottu> bug 1234612 in memtest86+ (Ubuntu) "Please merge memtest86+ 5.0.1 release from Debian - memtest86 in Ubuntu 14.04 LTS is 2 years old (v4.2.0)!" [Low,Confirmed] https://launchpad.net/bugs/1234612
<nadrimajstor> infinity: I have a specific need to remove conf file upon package removal. :(
<cjwatson> ari-tczew: I have no plans and don't think I should be the blocker, but it also seems like a change that should be made near the start of a release cycle rather than towards the end; it takes a while to shake out bugs there.
<infinity> nadrimajstor: Right, so you do that in postrm, if you manually copied it there in postinst.
<infinity> nadrimajstor: If it's a shipped conffile, it'll be removed automatically on package purge, if you manually place it in /etc, you need to manually remove it in posrtrm when $1 is "purge".
 * nadrimajstor off to use newly gained knowledge 
<cjwatson> infinity: Coincidentally I just saw a link to http://www.in-ulm.de/~mascheck/various/shells/ ...
<infinity> cjwatson: Dear god, http://www.in-ulm.de/~mascheck/various/shells/ksh_versions.html
<cjwatson> More detail than anyone not already having an absolutely terrible day needs.
 * nadrimajstor will pretend that he did not see the content of that page
<infinity> cjwatson: Thankfully, all my days are terrible, so this can't hurt.
<cjwatson> http://www.in-ulm.de/~mascheck/bourne/  search for 2014 ...
<darkxst> tracker autopkgtest failure looks like adt-run itself blew up, way before even getting to the tests
<cjwatson> darkxst: Yeah, I've seen a couple of those.  Retried, thanks
#ubuntu-devel 2014-09-30
<ted> So, multi-arch question. How do I find out the arch I'm installing for in postinst ?
<ted> I want to set one of my binaries to be setuid, but I don't know where it is.
<pitti> Good morning
<LocutusOfBorg1> Riddell, I honestly don't even remember :
<LocutusOfBorg1> some patches were dropped and some new patches more robust are used instead
<LocutusOfBorg1> but I agree that now we are too late in the release cycle
<pitti> mlankhorst: since yesterday https://jenkins.qa.ubuntu.com/job/utopic-adt-ubuntu-system-settings-online-accounts/237/ARCH=i386,label=adt/console consistently crashes again, this seems to coincide with moving to llvm 3.5?
<mlankhorst> huh weird
<mlankhorst> I tested it locally on i386
<mlankhorst> but yes seems to be the same bug
<mlankhorst> I'm pretty sure I did run that test manually, and also tested a full piglit run
<mlankhorst> hm seems to have been on my macbookpro
<mlankhorst> I'll try my other laptops, see what cpu extensions are needed to trigger it
<mlankhorst> doko_: ping?
<mlankhorst> doko_: do we have anyone working on llvm?
<pitti> mlankhorst: it only seems to happen on i386, amd64 works
<pitti> mlankhorst: that's a run in trusty's QEMU, FTR
<mlankhorst> yeah
<mlankhorst> hm my oldest laptop is unaffected
<ara> cjwatson, hello! I know it is not your SRU duty today, but I have been pinging other SRU members lately without luck :(
<ara> cjwatson, we have been waiting for 3 weeks for these uploads to move to precise-proposed: https://launchpad.net/ubuntu/precise/+queue?queue_state=1&queue_text=fglrx
<ara> cjwatson, and it solves a critical issue with fglrx in 12.04.5 affecting many systems
<ara> cjwatson, I would appreciate if you could have a look to it
<mlankhorst> pitti: yeah, I only seem to hit it in qemu now
<seb128> cjwatson, hey, https://code.launchpad.net/~tj/ubuntu/trusty/grub-installer/lp1354730/+merge/230222 is in the sponsoring queue for a while, do you think you could have a look?
<seb128> Riddell, hey, do you think you could have a look to https://code.launchpad.net/~filip-sohajek/ubuntu/utopic/kile/fix-for-1360709/+merge/232247 ?
<Riddell> seb128: gotcha
<doko_> mlankhorst, no
<seb128> Riddell, thanks
<jodh> pitti: hi - I noticed the upstart upload. Please could you sync your changes to the bzr branch (there will be a changelog conflict I think as I'd prepared a change :)
<pitti> jodh: whoops, sorry; doing
<jodh> pitti: np, thanks.
<pitti> jodh: should I push --overwrite for clean history, or just commit on top?
<mlankhorst> doko: I'm just guessing, but it seems that from the information that llvm generates some invalid code based on arch
<jodh> pitti: could you recommit once the conflict is resolved so that my changes are still pending?
<pitti> jodh: yes, sure
<pitti> jodh: I mean if you would mind bzr pull --overwrite, for clean history
<pitti> jodh: or whether I should commit on top (clean pull, but wrong history)
<jodh> pitti: oh - I guess overwrite should be ok as long as your branch was only 1 commit behind the ubuntu one?
<pitti> jodh: done; please bzr pull --overwrite
<jodh> pitti: thanks
<pitti> mlankhorst: we already had that error before and reverted LLVM back to 3.4 due to it; why did it come back now?
<mlankhorst> no idea, don't completely understand what is going on
<mlankhorst> pitti: hey how do I pass -cpu host for qemu to adt-run?
<pitti> mlankhorst: you can do adt-run ... --- qemu --qemu-options "-x -y -z" your_image
<pitti> mlankhorst: however, I never did that; using an i386 image is enough to reproduce it
<mlankhorst> doesn't work for -cpu host
<pitti> mlankhorst: ah sorry, option parser quirk: --qemu-options="-x -y -z"
<pitti> e. g. qemu --qemu-options='-cpu Opteron_G4' adt-utopic-amd64-cloud.img
<mlankhorst> ah
<cjwatson> ted: $DPKG_MAINTSCRIPT_ARCH
<cjwatson> ara: maaaaaybe.  I'm *very* unfamiliar with fglrx and they can be subtle reviews
<cjwatson> seb128: will look
<seb128> cjwatson, thanks
<seb128> mlankhorst, hey, could you review https://code.launchpad.net/~ubuntu-multiseat/xorg-server/trusty-matchseat/+merge/234316 ?
<mlankhorst> looks sane
<mlankhorst> but needs a sru template
<Laney> might be better to type that into the mp ;-)
<seb128> yeah, please comment on the merge request
<mlankhorst> done
<seb128> thanks
<seb128> I added https://wiki.ubuntu.com/StableReleaseUpdates as a pointer as well
<cjwatson> pitti: please can you remember to copy to 14.09-proposed rather than to 14.09?
<cjwatson> slangasek: you too :)  if you need to force something past proposed-migration, there are hints for that
<pitti> cjwatson: I thought I did -- what did I do wrong this time?
<pitti> cjwatson: I copied umockdev to -proposed and the langpacks are dput (and thus should land in -proposed automatically)
<cjwatson> pitti: probably left out --to-suite=14.09-proposed for cgmanager
<pitti> $ copy-package -y --from ubuntu -s utopic --to ubuntu-rtm --to-suite 14.09-proposed umockdev
<pitti> cjwatson: oh, that must have been ages ago, before your first warning
<cjwatson> pitti: yeah I think your recent uploads are fine - ogra was citing you as an authority for it being OK to copy things directly to 14.09 :)
<cjwatson> ah yes it was ages ago, sorry for the noise
<pitti> cjwatson: no worries :)
<pitti> yeah, it definitively makes sense to go via -proposed
<mlankhorst> doko / infinity: I found a small testcase to reproduce the issue, https://mblankhorst.nl/etc/llvmpipe.bc -- compile with llc-3.5 -o - llvmpipe.bc . works with llvm:amd64, fails with llvm:i386
<mlankhorst> llc-3.4 works on i386
<Mirv> mlankhorst: "LLVM ERROR: Do not know how to split the result of this operator!" bug #1360241 would look like being back https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/job/utopic-adt-ubuntu-system-settings-online-accounts/lastBuild/ARCH=i386,label=adt/console
<ubottu> bug 1360241 in llvm-toolchain-3.5 (Ubuntu) "[Regression] "LLVM ERROR: Do not know how to split the result of this operator!" in executing Ubuntu UI Toolkit tests on x86" [Undecided,Confirmed] https://launchpad.net/bugs/1360241
<Mirv> and that failing prevents qtbase from moving to -release pocket
<Mirv> oh, funny, repeating also the fact that it'd look like being discussed already here
<doko> mlankhorst, can you reproduce this with unstable? and if yes, file a bug report?
<doko> and mention this is a regression
<mlankhorst> sec
<mlankhorst> doko: yeah happens there too, but i'm bisecting now
<mlankhorst> lot easier now that my testcase no longer involves mesa
<ockham> do any packages share packaging with debian though they are named differently there? like e.g. firfox/iceweasel, or thunderbird/icedove? or is packaging completely independent from debian in those cases?
<maxb> Just look at the packagings you're interested in and compare them?
<ockham> those examples i gave don't seem to share packaging. are there possibly any other ones?
<mlankhorst> why is it important to you?
<pitti> jodh: ah, new systemd with fixed ifup@ just made it into utopic
<jodh> pitti: nice :)
<pitti> Mirv: you should ask the release team to ignore the failure to promote qtbase-opensource-src ; it's quite clearly a regression in llvm, not in qtbase
<pitti> zul: did you see the FTBFS of https://launchpad.net/ubuntu/+source/python-swiftclient/1:2.3.0-0ubuntu1 ?
<zul> pitti:  yeah havent gotten to it yet
<pitti> cjwatson: I think you synced https://launchpad.net/ubuntu/+source/celery/3.1.12-2, which is depwaiting on python3-kombu; i. e. we need to merge the new kombu from sid (or perhaps sync, didn't check yet); are you on it, or should I give a hand?
<pitti> (trying to clean up -proposed a bit)
<ahasenack> hi guys, I had this error in a package build on launchpad:
<ahasenack> fr: /build/buildd/qemu-2.0.0+dfsg/tcg/tcg.c:1693: tcg fatal error
<ahasenack> any clues? I'm *not* building qemu :)
<ahasenack> https://launchpadlibrarian.net/186090122/buildlog_ubuntu-trusty-armhf.landscape-client_14.08%2Bbzr788-0ubuntu0~ubuntu14.04.1_FAILEDTOBUILD.txt.gz
<ahasenack> scroll to the bottom
<ahasenack> same for arm64
<ahasenack> well, sort of same, I'm not sure what happened here: https://launchpadlibrarian.net/186090111/buildlog_ubuntu-trusty-arm64.landscape-client_14.08%2Bbzr788-0ubuntu0~ubuntu14.04.1_FAILEDTOBUILD.txt.gz
<ahasenack> but it's also in the i18n section
<ahasenack> transient error?
<cjwatson> pitti: 2014-09-17.log:17:17 <cjwatson> jamespage: would you mind merging kombu?  needed for new celery version I synced into -proposed, which in turn is needed to fix a build failure
<cjwatson> 2014-09-17.log:17:20 <jamespage> cjwatson, yes ok
<pitti> cjwatson: ah, thanks
<jamespage> cjwatson, ok so I suck
<pitti> jamespage: are you still on it, or do you need a hand?
<jamespage> sorry - I'll get to it today
<pitti> jamespage: ack, thanks
<cjwatson> ahasenack: threads involved on your end?
<ahasenack> cjwatson: it's just a build, and it worked on utopic and precise
<cjwatson> ahasenack: anyway you're basically screwed for the moment.  https://bugs.launchpad.net/launchpad-buildd/+bug/1350435
<ubottu> Launchpad bug 1350435 in launchpad-buildd "tcg.c:1693: tcg fatal error" [High,Triaged]
<cjwatson> ahasenack: you might get lucky on a retry
<ahasenack> cjwatson: that seems to be it, thanks
<cjwatson> ahasenack: or you can see if you can dig into that bug any more, if you have some time ...
<Mirv> pitti: ok
<jamespage> cjwatson, pitti: merged, tested and uploaded
<jamespage> apologies for the lag
<jamespage> ...
<pitti> jamespage: wow, that was fast; thanks :)
<pitti> jamespage: and, FWIW, yay py3 :)
<jamespage> pitti, indeed - I noticed that's been done now which is good
<jamespage> maybe openstack on py3 for 16.04 ? well you never know
<ockham> mlankhorst: mostly because of https://bugs.launchpad.net/bugs/545778 as there are icowl-i10n-* packages in debian, and i wondered if they could just be modified in debian to also cater for ubuntu
<ubottu> Launchpad bug 545778 in mozilla-thunderbird (Ubuntu) "lightning-extension is not localized" [Medium,Triaged]
<mlankhorst> I think that would be possible even with different packaging
<chrisccoulson> pitti, are you around?
<pitti> chrisccoulson: I am
<chrisccoulson> hi pitti! So, I keep getting asked why renderer crashes in our browser don't get processed by apport. it turns out that it's because we hit this code path: http://bazaar.launchpad.net/~apport-hackers/apport/trunk/view/head:/data/apport#L276
<chrisccoulson> renderer's have their own PID namespace, but the sandbox also chroot's to /proc/self (so there's no apport)
<cjwatson> infinity: Can I upload http://paste.ubuntu.com/8466066/ to glibc?  It fixes the phone x86 emulator, which has just gone over the global dlopen limit in question.
<chrisccoulson> is there any way we can fix this? :)
<pitti> chrisccoulson: I don't have a quick answer/idea about this, I'm afraid; this code path is for containers, it doesn't handle this kind of mini-chroot/namespace yet
<pitti> chrisccoulson: if there's a way to tell this apart from a real chroot or container, we can certainly fix it; but we don't want to try and build reports from containers/chroots without apport
<chrisccoulson> pitti, I'm not sure of the best way to tell it apart from a real container. It has no /sbin/init, if that helps
<infinity> cjwatson: Did Carlos commit that upstream?
 * infinity looks.
<pitti> chrisccoulson: chroots don't need to have /sbin/init either
<infinity> cjwatson: He sure didn't.  Grr.  Anyhow, if that's blocking you Right Now, go ahead, otherwise I can queue it up for my next upload.
<mlankhorst> infinity: almost done bisecting the llvm issue
<chrisccoulson> pitti, actually, the /proc/$pid/root symlink in left dangling in these processes. Perhaps you could use that?
<pitti> chrisccoulson: possibly; I think stgraber might have an idea, he's rather familiar with namespaces
<slangasek> cjwatson: mm? what did I copy to to 14.09 instead of 14.09-proposed?
<slangasek> ah, ubuntu-touch-meta... sorry about that
<mlankhorst> infinity: for the love of god.. I think I found it..
<mlankhorst> $ llc-3.4 -march=x86 -mcpu=generic ../../llvmpipe.bc -o -
<mlankhorst>         .file   "../../llvmpipe.bc"
<mlankhorst> LLVM ERROR: Do not know how to split the result of this operator!
<mlankhorst> bisect seems to point towards removal of cpu features detection..
<mlankhorst> and confirmed it by setting -mcpu=generic
<mlankhorst> on llvm-3.4
<mlankhorst> so the fix is setting the cpu to native in llvmpipe
<mlankhorst> no idea how yet, but meh
<cjwatson> infinity: Right, the emulator not working is a pretty terrible blocker, so I've gone ahead and uploaded; thanks
<mlankhorst> infinity: I'm pretty sure llvm commit 6bb00df864ea4e2f74f47c088b65baaff962cca5 is the reason why llvmpipe is now failing on qemu
<mlankhorst> aka https://llvm.org/svn/llvm-project/llvm/trunk@206094
<mlankhorst> and this is also why llvmpipe is only failing on qemu, because it compares the vendor strings, which is only changed if you use -cpu qemu32
<mlankhorst> I'll see if I can make a hack for it to revert
<infinity> mlankhorst: That's a 404.
<infinity> mlankhorst: But this is also why I never use qemu with the silly "QEMU CPU" thing, but instead emulate a Core2 or something.
<infinity> mlankhorst: This isn't the first bit of software that checks the cpuid registers for AuthenticAMD or GenuineIntel.
<infinity> *cough*glibc*cough*
<pitti> jamespage: erk -- https://launchpad.net/ubuntu/+source/kombu/3.0.21-2ubuntu1/+build/6421574
<pitti> jamespage: oh, that's just a binary promotion to main, doing now
<jamespage> pitti, oh - that looks lie a binary promotion
<jamespage> pitti, snap!
<jamespage> thanks
<mlankhorst> pitti: can you emulate something saner?
<mlankhorst> else I'll probably hack the autodetection crap back into llvm
<mlankhorst> doko: ^
<pitti> mlankhorst: define "something saner"? i. e. which cpu?
<pitti> mlankhorst: yeah, not a big problem to change it
<mlankhorst> infinity: what's minimum for ubuntu, coreduo or something?
<mlankhorst> anyway I'll try to fix llvm tomorrow morning :)
<pitti> mlankhorst: so, just tell me the -cpu I should be using
 * pitti needs to leave now, guest arrived
<mlankhorst> coreduo or something? just a temporary workaround, I'll try to fix the real thing tomorrow
<pitti> mlankhorst: ack
<mlankhorst> do you have a bug for tracking?
<rbasak> barry: around? Are you the right person to ask for help with dh_python2?
<rbasak> I'm not sure if I'm hitting a bug, or whether I'm using it wrong.
<barry> rbasak: possibly :)
<infinity> mlankhorst: Minimum for i386 is i686 w/ cmov.
<rbasak> I end p with a successful run but failure with the generated postinst/prerm
<barry> i mean, i'm definitely around :)
<rbasak> It's a bit of a special case. A package that ships Python stuff in /usr/lib/<package> but nothing else.
<infinity> mlankhorst: So, basically, Pentium Pro.
<rbasak> So we want to byte-compile them on postinst, that's all.
<barry> rbasak: hmm, interesting
<rbasak> I end up with "pycompile -p  /usr/lib/<package> -V 2.7" in the postinst, which makes no sense.
<rbasak> (and that fails)
<rbasak> AFAICT, I need to not have the -p in this case, but the -p is part of the template that dh_python2 uses.
<rbasak> The prerm is even worse. "pyclean -p"
<rbasak> This is from just:
<rbasak> override_dh_python2: dh_python2 --compile-all
<rbasak> (with a newline in the middle - paste error)
<rbasak> (and a tab. etc)
<rbasak> barry: any thoughts? Am I doing something wrong here? For just the byte-compile bit, I'm wondering if it's better to arrange to call pycompile/pyclean directly and ditch dh_python2.
<barry> rbasak: sorry, i'm in 2 conversations atm
<rbasak> np
<barry> rbasak: man dh_python2 seems to say that --compile-all won't pass -p
<rbasak> barry: /usr/share/debhelper/autoscripts/postinst-pycompile seems to be where it's coming from.
<rbasak> which contains: pycompile -p #PACKAGE# #ARGS#
<barry> rbasak: i wonder if this is a bug in dh_python2
<barry> rbasak: fwiw, i've never had to do this, so i don't have an immediate answer
<rbasak> barry: OK, thanks.
<barry> rbasak: i would suggest getting on #debian-python (OFTC) and asking p1otr
<rbasak> barry: I wondered if it is because I'm not specifying DIR_OR_FILE (because AIUI it defaults to looking in /usr/lib/<package> which is what I want)
<rbasak> But even in that case -p would be forced by the template.
<rbasak> OK, I'll hop over to #debian-python - thanks.
<barry> rbasak: that's what it looks like, indeed
 * barry will keep an eye on that conversation
<pitti> stgraber, kees, mdeslaur, slangasek: reminder: TB meeting in 5 mins (infinity sent his apologlies)
<mdeslaur> pitti: yep, thanks
<pitti> mlankhorst: yay, ubuntu-system-settings-online-accounts is back to green; thanks for tracking this down!
<mlankhorst> pitti: I will try to fix llvm autodetection tomorrow, but at least it's not urgent any more now :)
<bdmurray> dannf: https://code.launchpad.net/~dannf/ubuntu/utopic/flash-kernel/moonshot-updates/+merge/223845 looks merged to me. Is that right?
<ahasenack> ad
<hallyn> feh.
<roaksoax> arges: ping
<roaksoax> arges: i've noticed that some SRU bugs that had already been verified were changed from verification-done to verification-needed. I'm guessing this is because there was na upload on top of the original one
<roaksoax> arges: however, given that these were already verified, why are they being marked verificaiton-needed again
<doko> mvo, https://bugs.launchpad.net/ubuntu/+source/command-not-found/+bug/1306682
<ubottu> Launchpad bug 1306682 in command-not-found (Ubuntu) "recommend to use python3 when python is not found" [Undecided,New]
<arges> roaksoax: can you point me at a specific bug?
<mvo> doko: thanks
<roaksoax> arges: e.g. https://bugs.launchpad.net/maas/+bug/1315154
<ubottu> Launchpad bug 1315154 in maas (Ubuntu Trusty) "[SRU] doesn't support booting ppc64el hardware" [High,Fix committed]
<arges> roaksoax: so when you uplaoded the last maas update you must have referenced this old bug, so the script goes through and marks each one referenced as fix commited and asked for verifciation
<arges> roaksoax: or whomever uploaded the last maas update
<dannf> bdmurray: yeah, it was - thanks for marking it as such
<doko> barry, "no longer have an i386 machine on which to test" are you serious?
<doko> you can create i386 chroots
<barry> doko: yes.  iirc the problem was *not* reproducible in chroots.
<barry> i think i had to use a physical 32 bit machine to reproduce it and all my old ones are dead.  but i think i scrounged up a 32 bit laptop.  trying to see if i can get ubuntu installed on it
<mapreri> I lack bug supervisor ability, could someone pleas set https://bugs.launchpad.net/bugs/1375445 as whishlist (and in the meantime re-set the status as triadged and tell that wlee753159 user to do not mess with bugs (there are also at least one other bug he touched badly, but I'll deal with it on my own)). TIA
<ubottu> Launchpad bug 1375445 in xkeyboard-config (Ubuntu) "No phonetic Russian layout for azerty keyboards" [Undecided,Incomplete]
<Bluefoxicy> hum
<Bluefoxicy> defunct.
<Bluefoxicy> 26472 ?        00:00:00 chromium-browse <defunct>
<Bluefoxicy> Can someone load up chromium and use the mouse wheel gratuitously on maps.google.com to zoom in and out?
<Bluefoxicy> I want to see if anyone can reproduce destroying the browser (or your desktop--save everything, you may need a hard reboot)
<bdmurray> slangasek: at one point in time you were working on improvements to whoopsie_upload_all right?
<sladen> there is something buggy that happens with OSM when doing that in Friefox
<Bluefoxicy> sladen:  my work-around is to use firefox
<Noskcaj> Can someone retry python-swiftclient? It's building fine in a chroot locally
#ubuntu-devel 2014-10-01
<kokoye2007> Hello
<slangasek> bdmurray: that's still https://code.launchpad.net/~vorlon/ubuntu/utopic/apport/lp.1354318, which is tied up in a question between ev and pitti about whether we're getting premature inotify regardless of umask settings
<bdmurray> slangasek: I didn't see that question and started a new branch based on yours but not using a .new report file per pitti's concerns.
<slangasek> bdmurray: yes, I'm not sure ev has actually raised the point with pitti, though I asked him to do so... maybe a highlight will help :)
<pitti> Good morning
<pitti> slangasek, bdmurray: yeah, I'm still not convinced that a full rewrite instead of appending is better in any way; it's a lot more expensive and just changes the failure mode instead of improving them
<slangasek> pitti: so ev claimed to me that the current approach was giving problems with inotify behavior
<pitti> slangasek: i. e. the final close() and/or chown() doesn't trigger an inotify event any more?
<slangasek> pitti: I believe ev's assertion was that the inotify happens too early.  But we shouldn't play telephone
<pitti> yeah, let's wait until he comes online
<pitti> apw: thanks for tracking down bug 1375805
<ubottu> bug 1375805 in systemd (Ubuntu) "Lightdm fails to start in VirtualBox " [High,Fix committed] https://launchpad.net/bugs/1375805
<dholbach> good morning
<mlankhorst> morning!
<mardy> pitti: hi! Is it a good idea to add -dbg packages to the projects I maintain, or do we have a different policy?
<pitti> mardy: they are redundant in Ubuntu as we autuomatically build -dbgsym packages for everything
<pitti> mardy: so don't bother
<mardy> pitti: OK, thanks
<apw> pitti, i was lucky to have a persistant tester :)
<pitti> dpm, wgrant: an hour ago or so I approved/cleaned up  the POTs on https://translations.launchpad.net/ubuntu-rtm/14.09/+source/oxide-qt/+imports -- I don't need to do anything with the POs, right? they'll be auto-imported eventually?
<dpm> pitti, exactly. Once the .pots are approved and imported, the .pos will be too
<pitti> thanks
<seb128> pitti, do you plan a langpack update in rtm?
<pitti> seb128: it's cron'ed; https://translations.launchpad.net/ubuntu-rtm/14.09/+language-packs will get another update tomorrow
<seb128> pitti, ok, great, thanks :-)
<pitti> seb128: if weekly isn't enough, we can certainly ask wgrant to produce two every week?
<seb128> pitti, weekly is enough, I saw none on https://lists.ubuntu.com/archives/rtm-14.09-changes/2014-September/date.html but I guess for some reason they don't appear on -changes?
<pitti> seb128: correct; language-pack-* is filtered out for ACCEPTED mails, changes@ etc
<seb128> k, makes sense
<pitti> seb128: https://launchpad.net/ubuntu-rtm/+source/language-pack-touch-de/+changelog
<seb128> pitti, thanks
<seb128> weekly seems fine to me
<seb128> is jenkins.qa.ubuntu.com down?
<pitti> seb128: apparently, yes; d-jenkins works fine
<seb128> where is the right place to let people know in they case they don't? #is?
<pitti> seb128: yes, in particular retoaded
<Laney> it did load for me, but it was s-u-p-e-r-s-l-o-w
<seb128> Laney, it's spinning for over 5 minutes for me
<seb128> that's not usable, I'm still going to let #is know
<Laney> needs attention either way
<seb128> yeah
<mlankhorst> doko_: ping?
<seb128> Laney, pitti, #is restarted it, back to normal
<pitti> seb128: cool, thanks
<seb128> yw!
<Laney> great
<flexiondotorg> Laney, Thanks for uploading the update xzoom to Debian and Ubuntu.
<Laney> flexiondotorg: no worries
<wwlzhuzhu> Hi everyone, I am trying to add a net samba printer, I try to see the windows computer from Places net,I can. But from printer manager i can  not accesss trough  examine. I am on ubuntuMATE beta2
<doko> mlankhorst, pong
<mlankhorst> so it seems llvm detects qemu32 as pentium2, which disables the sse extensions, causing the llvmpipe breakage
<doko> mlankhorst, but why are these needed by llvmpipe?
<doko> mlankhorst, how comes qemu into the game?
<mlankhorst> doko: things were already broken before it seems, but with the change to 3.5 to no longer autodetect features it started to show..
<doko> mlankhorst, lp_screen.c explicitly checks for sse2
<doko> so why did that work before?
<mlankhorst> because we passed an empty string to cpu/feature flags
<mlankhorst> which meant 'autodetect all capabilities please'
<mlankhorst> this is no longer supported in 3.5
<mlankhorst> and llvm::sys::gethostcpuname() returns 'pentium2'
<nrbrtx> Dear all! I can't understand why Ubuntu does not have an init script for saving and restoring display backlight level. I have prepared one (see bug 1270579 ), it works on my laptops as expected.
<ubottu> bug 1270579 in sysvinit (Ubuntu) "Ubuntu should have an init script for saving/restoring backlight level on laptops" [Medium,Confirmed] https://launchpad.net/bugs/1270579
<doko> mlankhorst, that would be correct, as we build for i686. but where is qemu32 called? can't you specify a target cpu?
<mlankhorst> you can specify a target cpu, but llvm detects it as a generic pentium2, without sse support or anything..
<mlankhorst> it can be overridden partially, but setting all the feature flags manually will be a bit of a pain
<mlankhorst> still, i probably should :/
<ted> bdmurray, Do you know what tool generates this list: http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-s-incoming-bug-tasks.html
<pitti> apw: oh right, you forgot the debian/rules bit
<pitti> apw: http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?h=ubuntu&id=0c114f9497ca8771c96229e6ccc59544f7cd6c0b
<pitti> apw: that was my original commit until I saw your upload
<nrbrtx> Am I understand correctly, that Ubuntu Utopic has screen backlight save/restore on via systemd?
<apw> pitti, yeah ... just fixed it ... stupid test box has that file as a "conf" file from the old days ... and if you had gotten their first it would have been fixed first time ... grr
<pitti> apw: urgh, conffile? oh blergh, this is an upstart job, not an udev rule, right
<pitti> apw: no worries :)
<apw> pitti, i know, but somehow apt has it down as one of those ...
<apw> pitti, anyhow this time the builders are working so i was able to get a reliable test before upload, though it matches yours exactly
<pitti> and yeah, init scripts/jobs really should not be conffiles, but be treated as code; they are the #1 offender in /etc for cleaning it up
<mlankhorst> doko: http://paste.debian.net/123989/ untested, but would something like this work?
<mlankhorst> hm seems to! D
<mlankhorst> *:D
<mdeslaur> doko: can I expect a twisted sync?
<mlankhorst> doko: the paste I linked above fixes the crash in the test for me. Would this be a sane way to deal to have some form of autodetection?
<mlankhorst> it should at least match llvmpipe's idea of the cpu caps to llvm
<bdmurray> pitti, slangasek: I wonder if ev's concern stemmed from incomplete reports appearing in the error tracker due to bug 1360417.
<ubottu> bug 1360417 in apport (Ubuntu Trusty) "thread_collect_info can leave out information in .crash files" [Medium,Fix released] https://launchpad.net/bugs/1360417
<bdmurray> ted: yes, I know what tool generates that list
<ted> bdmurray, Will you tell me? :-)
<bdmurray> ted: https://code.launchpad.net/~arsenal-devel/arsenal/2.x see the rls-mgr folder
<doko> mdeslaur, no, but there is an upload in the unapproved queue
<doko> mlankhorst, maybe guard this for ix86?
<slangasek> ev: ^^ can you provide some more detail on your whoopsie_upload_all / inotify concern?
<mdeslaur> doko: cool, thanks
<ev> slangasek: sure, looking now
<ev> I believe my concern was that the report would appear to whoopsie via inotify before it had the correct permissions. Whoopsie would try to read this, fail, and put it in a queue for two hours later.
<ev> This doesn't appear to be the case, looking at Martin's MP
<ev> whoopsie isn't looking for .new files, so it will only act on the report after the rename, after it has the right permissions
<ev> slangasek: err your MP :)
<ev> ohhh
<ev> your MP introduces the .new behaviour
<ev> so this makes more sense now
<slangasek> ev: ok, I thought you had expressed a concern that things were /already/ appearing to whoopsie before they had the correct permissions
<ev> I was looking at a bug that asac was encountering at the time. I believe your MP will fix it.
<slangasek> ev: pitti has claimed that the inotify only happens once the file is readable
<slangasek> ev: right, and pitti wants me to not use the .new
<ev> oh boo
<slangasek> so what was the bug, specifically?
<ev> well, we could have a unit test for this sort of thing
<pitti> ev, slangasek: no, I'm fairly sure the inotify happens already on creation; I wondered if there's another inotify event on close() or chmod(), so that we can wait until teh file becomes readable
<slangasek> ok
<slangasek> pitti: so it's speculation on your side that this works in a non-racy manner? ;-)
<mitya57> Is it normal when a package in universe depends on a package in multiverse?
<slangasek> mitya57: no, it's disallowed by policy
<pitti> slangasek: well, it's a question :)
<slangasek> ok
 * mitya57 files a bug then (the package in question is ubuntu-emulator)
<slangasek> so, notwithstanding the increase in disk writes, I'm sure that my MP is non-racy wrt inotify
<pitti> slangasek: but according to the manpage, inotify can do this (subscribe to IN_CLOSE_WRITE)
<pitti> or even better, IN_ATTRIB (and then checking if it's readable)
<pitti> that's the thing which we are actually looking out for
<pitti> as it has permissions 000 during writing
<slangasek> pitti: ok, well I gather that this isn't what's being done today
<pitti> hmm, grepping whoopsie for "inotify" gives no results
<slangasek> ev: where does the inotify watching happen for this?  no references to 'inotify' in the whoopsie source
<pitti> oh, glib -- GFileMonitor?
<pitti> bingo
<slangasek> ok
<pitti> so I suppose we want G_FILE_MONITOR_EVENT_ATTRIBUTE_CHANGED
<pitti>         if ((event_type == G_FILE_MONITOR_EVENT_CREATED) ||
<pitti>             (event_type == G_FILE_MONITOR_EVENT_ATTRIBUTE_CHANGED))
<pitti> and the first one should be dropped (or there shoudl be at least an additional check that the file is readable)
<pitti> oh wait
<slangasek> pitti: the first one is necessary for offline notifications of files already created when whoopsie starts
<pitti> this is the monitor for the .upload stamp
<pitti> that looks fine
<pitti> in fact, whoopsie isn't concerned about the completeness of .crash files at all; apport writes the stamps, and whoopsie is only looking for .upload
<pitti> sorry, so this was a red herring, whoopsie looks fine
<ev> yeah, damn
<pitti> we only need to ensure to write the .stamp file after the .crash file is completely written and readable
<slangasek> ev: so is there not actually a bug here?
<pitti> which again is contained in whoopsie-upload-all
<ev> I don't believe so, no
<slangasek> ok
<slangasek> bdmurray: ^^ so I think this should unblock you regarding your fix to my branch to not do the .new handling
<pitti> and AFAICS the current version already does that
<bdmurray> slangasek: okay, thanks
<bdmurray> pitti: the fix for bug 1354571 will prevent uploading of incomplete core dumps right?
<ubottu> bug 1354571 in apport (Ubuntu) "apport-retrace ignores warnings from gdb" [Medium,Fix released] https://launchpad.net/bugs/1354571
<pitti> bdmurray: yes, this was specifically adjusted in w-u-a as well
<pitti> i. e. not just with UnreportableReason
<bdmurray> pitti: okay, I think I'll SRU this to Trusty to reduce the work load for the error tracker then
<brainwash_> xnox: hey, have you already been pinged by the xubuntu team re bug 1375893 ?
<ubottu> bug 1375893 in ubiquity (Ubuntu) "Black background to Try/Install Dialogue" [Undecided,Confirmed] https://launchpad.net/bugs/1375893
<brainwash_> you've fixed the ubiquity wallpaper problem some months ago, back then it showed the debian background
<Noskcaj> mitya57, Anything i still need to do for bug 1372224
<ubottu> bug 1372224 in tortoisehg (Ubuntu) "[FFe] sync tortoisehg 3.1.1-1 (universe) from Debian unstable (main)" [High,Triaged] https://launchpad.net/bugs/1372224
<AMDCeleron> !ops
<ubottu> Help! Channel emergency! mneptok, Hobbsee, cjwatson, mdz, lamont, Keybuk, or thom!
<AMDCeleron> !ops
<doko> Logan_, are you this logan? http://bugs.python.org/issue18096
<doko> slangasek, infinity: did you make progress with the cross-toolchain-base packages?
<slangasek> doko: I've gotten a successful build of the arm64 one, but I understand that there's still some more work needed for any of the biarch cross-compilers; also the packaging has drifted between the various targets and badly needs to be resynced... that's currently backburnered for me
<doko> slangasek, ok, once you have the arm64 case, I can have a look at the biarch stuff
<slangasek> well, I think infinity wanted to look at it from the glibc side
<doko> ahh, nice
<infinity> I'm looking at it, yes.
<infinity> Have some patches from helmut to toss in, and then some test building to see the state of things and where it now breaks.
#ubuntu-devel 2014-10-02
<Bluefoxicy> so
<Bluefoxicy> my ubuntu system got all hacked.
<Bluefoxicy> And sent spam everywhere.
<Bluefoxicy> Apparently something sent a bash exploit that wget an executable to /tmp and ran it as an exploit.
<Bluefoxicy> I distinctly recall a conversation here about the correct usage of $XDG_RUNTIME_DIR and about how /tmp doesn't need to be non-executable.
 * Bluefoxicy tea.
<JanC> Bluefoxicy: doesn't really matter whether it was executable or not with that exploit
<Bluefoxicy> JanC:  you'd have to find a writable path.
<Bluefoxicy> JanC:  the classic noexec hole--/lib/libc.so /tmp/elf--is also closed:  can't mmap PROT_EXEC
<JanC> Bluefoxicy: if you can execute an existing binary + parameters remotely, then you can run arbitrary Perl, Ruby, Python etc. code
<Bluefoxicy> true.
<Bluefoxicy> That suggests filing a bug with an interpreter:  if the file is not executable and on an exec-mounted partition, don't execute.
<JanC> it's only one of many attack vectors
<Bluefoxicy> You've never used caulk, have you?
<JanC> anyway, this is probably more on-topic in -hardened
<JanC> BTW: a default Debian/Ubuntu doesn't have bash as /bin/sh, which probably did more to block this exploit than any fancy security tool did in other distros where it is...
<Logan_> doko: nah, that's not me :P
<Noskcaj> cjwatson, Since you were the last uploader, it seems mpv needs a second rebuild. bug 1376388
<ubottu> bug 1376388 in mpv (Ubuntu) "Rebuild mpv against libav11" [Undecided,New] https://launchpad.net/bugs/1376388
<cjwatson> Noskcaj: uploaded
<Noskcaj> :)
<pitti> Good morning
<infinity> pitti: What's with autopkgtest testbeds being killed? :/
<infinity> pitti: See glibc (both amd64 and i386).
<pitti> infinity: yep, just noticed
<pitti> infinity: I bumped the timeout for glibc to 5 h and restarted
<infinity> pitti: Thanks to my not ridding the archive of eglibc, and that passing, I'm letting linux in with a hint. :P
<pitti> infinity: the usual test timeout is 10.000 s (i. e. some 2.5 hours)
<pitti> infinity: usually builds happen with build timeout, but as glibc isn't using "build-needed", but instead calls dpkg-buildpackage in the test, the test timeout applies
<pitti> infinity: it should work now, 5 hours ought to be enough (if not, I'll bump it again)
<infinity> pitti: I'm not using build-needed because you told me not to. ;)
<infinity> (I used to...)
<pitti> infinity: yes, I know; just explaining why this now causes the timeouts
<infinity> Heh.
<pitti> infinity: for the build-needed approach I need to think about some optimizations that avoids copying the entire build tree out and back into a new VM
<pitti> but that's a bit tricky, as usually after a build we want a fresh and clean testbed for running the test
<infinity> pitti: Could /home or /build or whever you do your building be a separate filesystem that you just umount from VM A and remount in VM B (and then zero out when doing a full reset)?
<pitti> infinity: with qemu I'm using 9p (shared fs between guest and host), and initially it was doing exactly that
<pitti> infinity: problem is, it's unbearably slow for lots of little files :(
<pitti> infinity: and accessing qemu disk images from outside without root privileges seems impossible
<pitti> exchaning data with qemu is a painstakingly difficult process, I bit into my table more than once
<infinity> pitti: Ahh, but my suggestion isn't, strictly speaking, accessing from the outside. ;)
<infinity> pitti: It's just mounting /home (or /build or wherever) as disk2.img, /dev/sdb perhaps, and wiping that selectively inside the guest, instead of always resetting it to pristine.
<pitti> infinity: we don't need to wipe that (the build tree is the bit that we want to keep), we need to wipe the entire system around it to get rid of installed build deps
<infinity> pitti: Right, but I'm assuming right now you reset the whole system to pristine.
<pitti> so currently it copies the build tree outside (or puts it into the shared dir), rebuilds the VM, and copies it back in
<infinity> pitti: With two disk images (system and build), you can select to reset A, but not B, or both.
<pitti> which works with all runners (not just QEMU)
<infinity> No reason the same concept wouldn't work with Xen or lxc as well.
<pitti> we use that concept, just not with disk images but with shared directories
<pitti> which translate to 9p for qemu, bind mounts for schroot/lxc, etc.
<infinity> Which you said was slow and crap. :)
<pitti> for ssh there is no such concept, so it's tar | sss | tar
<infinity> Hence my suggestion.
<pitti> well yes, but it's the best we have
<infinity> raw disk images outperform pretty much any other option when qemu is in play.
<infinity> For lxc, sure, simple bind mounts into an FS that doesn't suck are the best.
<pitti> using another disk image for stuff that the outside controller doesn't need to peek into would work, but it's a lot of work to implement
<pitti> infinity: and of course we are not going to use the qemu runner in production for very long any more :)
<infinity> pitti: Because we're switching to Xen?
<infinity> *hopeful look*
<pitti> the four poor machines that we are running them on are totally overloaded, we are moving to bootstack
<pitti> and that's not even taking into account the ~ 4000 new autopkgtests that are going to hit soon (perl, ruby)
<infinity> Oh, kay, I assume from the name that bootstack is yet another qemu-based openstack.
<pitti> it is
<infinity> So, it may need mangling to solve similar problems as it's built out and given use cases.
<infinity> pitti: How much do I have to bribe you to make bootstack have both a KVM and a Xen region, so we can see what breaks where (and, more interestingly, actually stress test Xen before a customer who demands it calls us out for ignoring it)?
<pitti> infinity: you can bribe me a lot, but it won't have much effect -- I'm not managing bootstack, nor have I ever used xen
<pitti> infinity: so while I'd appreciate getting a beer, you might be better off investing it to ev :)
<infinity> pitti: Whose baby is this particular stack?
<infinity> Ahh, CI.  Kay.
<pitti> I was more or less told "bootstack is the new cool kid in town", after {canoni,prod,scaling,dev}stack and maybe a few others :)
<infinity> ev: I'm sending you motorcycles and beautiful women and non-alcoholic beverages.
<pitti> for most tests an LXC based stack would actually be fairly nice
<infinity> ev: (Allow six to eight weeks for delivery)
<pitti> damn.
<dholbach> good morning
<pitti> infinity: there goes a green glibc again :)
<ev> infinity: lol
<ev> infinity: bootstack isn't mine: http://www.ubuntu.com/cloud/bootstack
<ev> so IS Projects / CTS are the people you're after.
<ev> that said, we have a bootstack
<pitti> ev: there, no motorbike for you!
<ev> :(
<ev> can't I have one anyway?
<ev> for being such a great guy
<ev> infinity: ps. I'd much rather we focus these efforts on scalingstack/prodstack, such that we can drive dep8 tests over such arrangements
<ev> anytime people try to stand up CI-ish infrastructure on a non-IS-managed resource or puts lots of manual process around the tests, a part of me dies.
<davmor2> ev: if your really good you might build up to a motorized unicycle
<ev> :)
<directhex> how much of a Problem(tm) are circular build-deps in Ubuntu?
<rbasak> directhex: I had a circular dep problem with php5 last cycle. If there's a way to break the loop, then an archive admin can do it, but it's a manual process AIUI.
<rbasak> If older versions are in the archive and the build deps are happy with those, then everything continues just fine (I think)
<directhex> rbasak: i need to introduce a circular dep chain, i was looking for proposed alternatives, if available
<doko> pitti, any idea about the aria2 autopkg test failure?
<doko> what happened on Sep 30?
<AnAnt> Hello, is there a channel to talk to Canonical ?
<doko> jibel, ^^^
<ogra_> doko, https://launchpad.net/ubuntu/utopic/+source/glibc/2.19-10ubuntu2 ?
<pitti> doko: that std::length_error thing? I have no immediate idea, I'm afraid
<pitti> well yes, that new glibc certainly coincides date-wise
<jibel> doko, no idea, I cannot reproduce locally in the test env upgraded to -proposed.
<doko> cjwatson, ^^^ ?
<pitti> but the previous run was 11 days before that
<pitti> aah, wait
<pitti> there's another thing
<pitti>   run-autopkgtest: run QEMU with -cpu core2duo to fix crash with llvm 3.5 due to CPU detection
<pitti> that was done to work around a regression in llvm 3.5 which caused xvfb to crash
<halfie> hi, is subversion package broken in Ubuntu 14.04.1 LTS release? I can't do "svn co" anymore. "svn co" from Fedora / KNOPPIX VM works fine though.
<pitti> so our VMs now claim to be a core2duo instead of this "QEMU CPU" thingy
<doko> mlankhorst, ^^^ shouldn't that fix the mesa thing too?
<pitti> so with QEMU CPU we break llvm3.5/mesa, with core2duo we break aria2
<pitti> is there any processor which all of our sofware likes? :-)
<pitti> or should we revert the -cpu core2duo now? I think mlankhorst was working on a fix for that, I'm just not sure in which package
<doko> pitti, jibel: is it known that the qemu change breaks aria2?
<pitti> doko: see above ^ I'm fairly sure it's that, unless the new glibc broke something too; but if jibel can't reproduce it with the default -cpu, it's most likely that
<mlankhorst> doko: yeah that was the workaround I suggested )
<jibel> pitti, I tried with -cpu core2duo and it works too but I'm on utopic
<pitti> jibel, doko: I get the aria2 failure on alderamin both with the default CPU and with core2duo
<doko> mlankhorst, ahh, and no source change in mesa?
<mlankhorst> yeah
<pitti> which again seems to speak against the -cpu change as the trigger
<jibel> pitti, did you change the proxy configuration on the 30th?
<jibel> pitti, if I unset proxy env var the test passes
<pitti> doko, jibel: seems to be the proxy
<pitti> jibel: ah, snap (just tried the same)
<pitti> jibel: no, way before that, but aria2 didn't run for a while
<pitti> so, aria2 does not respect $no_proxy
<pitti> or rather, it does read it, but crashes upon it
<jibel> pitti, right. did you change the proxy configuration between Sept. 19th and now :)
 * doko curses changing test environments ...
<pitti> so, I'll file a bug with upstream/debian about that and upload a workaround for aria2
<pitti> $ no_proxy=127.0.0.1 aria2c -d . http://localhost:8080/foo
<pitti> trivial to reproduce the crash
<doko> mlankhorst, https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1371636  is there anything you do specially in the package? or is this a non-issue?
<ubottu> Launchpad bug 1371636 in Mesa "[2.24.51.20140918-1ubuntu1 regression] - /usr/bin/ld: .eh_frame_hdr refers to overlapping FDEs" [Medium,Confirmed]
<mlankhorst> doko: build the debian branch of mesa..
<mlankhorst> it happens when linking opencl specifically
<doko> ok
<mlankhorst> iirc llvm-3.4 works, but llvm-3.5 had the breakage
<mlankhorst> just when linking though
<pitti> doko, jibel: filed as debian bug 763760, uploaded workaround
<ubottu> Debian bug 763760 in aria2 "aria2: Crashes on $no_proxy" [Normal,Open] http://bugs.debian.org/763760
<arges> caribou: can you sponsor my patch for bug 1324544 for trusty? thanks!
<ubottu> bug 1324544 in makedumpfile (Ubuntu Trusty) "makedumpfile: kdump-config load fails with vmlinux kernel (vs. vmlinuz)" [High,In progress] https://launchpad.net/bugs/1324544
<arges> caribou: its attached as trusty-v2.debdiff
<caribou> arges: ok, will do in a few min
<bdmurray> pitti: when I was working on some apport stuff I noticed bug 1376374. Perhaps we could set MarkForUpload = False and then write that to the report?
<ubottu> bug 1376374 in apport (Ubuntu) "whoopsie-upload-all will run hooks on a corrupt crash file multiple times" [Undecided,New] https://launchpad.net/bugs/1376374
<infinity> pitti: '-cpu host' is the sanest CPU option.
<infinity> pitti: qemu's feature masking emulation is sketchy.
<infinity> pitti: The aria2 failure *could* be that glibc's running some assembly to correctly detect the real CPU, then using the features it knows should be there in its string functions, then breaking because core2duo is restricting access to an instruction.
<infinity> pitti: Because we detect CPU models correctly (ie: according to Intel/AMD docs), not by braindead parsing of /proc/cpuingo
<infinity> s/ingo/info/
<mlankhorst> doesn't qemu restrict cpuid too?
<mlankhorst> else maybe -cpu native should be used?
<mlankhorst> erm -cpu host
<beuno> ev, if you're bored at some point, could you approve my email in moderation for ubuntu-devel-discuss?
<beuno> I'm not sure why it says I'm not suscribed (maybe I used my @ubuntu address)
#ubuntu-devel 2014-10-03
<guest-lkajdf_431> Hi. I'm sorry but I ain't gettin no love on #ubuntu; and, frankly, this may be a more technical problem than anyone there can handle right now (dunno). If it's wrong for me to ask here just let me know - I just thought I'd give it a shot.
<guest-lkajdf_431> http://www.computercorrect.com/2010/operating-systems/linux/ubuntu/ubuntu-10-04-10-11-touchpad-quitting/
<guest-lkajdf_431> ^ That is the closest thing I can find to my situation (sounds just like what I'm going through) - but it is talking about older versions of ubuntu. I need to be sure that the soln is for current ubu 14
<guest-lkajdf_431> I have not installed ubu 14 on that lappy yet. I found this out when going into "try ubuntu" to test for just such things
<guest-lkajdf_431> sorry, ubu = ubuntu (it's my pet name for it)     ;)
<sarnold> guest-lkajdf_431: when I run gconf-edit, I see a /desktop/gnome/peripherals/touchpad/ path but no touchpad_enabled setting...
<sarnold> guest-lkajdf_431: no idea if that should exist beforehand or not. that bit seems plausible.
<sarnold> guest-lkajdf_431: but I don't see any /apps/gnome_settings_daemon/ paths
<sarnold> guest-lkajdf_431: .. and I'm not finding anything in there that looks related. Again, I don't know if they should exist before being modified or not.. but that half of the solution doesn't look promising
<tarpman> that stuff has all moved into gsettings long ago...
<guest-lkajdf_431> sarnold: tarpman: thx
<guest-lkajdf_431> any suggestions for a proper way to fix the issue?
<guest-lkajdf_431> sorry I gotta go for now
<pitti> infinity: the -cpu thing was a red herring; it was aria2 crashing on $no_proxy
<seb128> wgrant, hey, do you know how launchpad translations import work?
<seb128> wgrant, more specifically https://launchpadlibrarian.net/186404505/buildlog_ubuntu-utopic-i386.evolution-data-server_3.12.6-0ubuntu3_UPLOADING.txt.gz generated a tarball for translations
<seb128> wgrant, but https://translations.launchpad.net/ubuntu/utopic/+source/evolution-data-server/+imports doesn't seem to want to import any out of the template
<seb128> wgrant, https://launchpad.net/ubuntu/utopic/+upload/8030046/+files/evolution-data-server_3.12.6-0ubuntu3_i386_translations.tar.gz is the generated tarball from the build, looks fine to me
<seb128> not sure why it's not making it up to the import queue
<Noskcaj> Laney, Could i have a testimonial for MOTU or gnome-packageset? https://wiki.ubuntu.com/Noskcaj
<Noskcaj> seb128, Also, could i have one from you
<Laney> Noskcaj: maybe, I'll have to look at your recent work
<Laney> I think you should get your old sponsors to refresh their wording
<Noskcaj> thanks. I'm not going to be on irc much till the day, so please reply via email if it's later
<wgrant> seb128: Packages that share translations with upstream don't accept PO imports, it seems.
<wgrant> seb128: I guess because there's no way to merge them; new translations from upstream would be clobbered by an SRU, for example.
<seb128> wgrant, urg, why is sharing enabled for those, it shouldn't since they are GNOME projects
<seb128> wgrant, thanks for pointing that out
 * seb128 drops the sharing
<seb128> wgrant, I guess we need another upload to import them after unsetting the sharing?
<seb128> Noskcaj, ok
<Noskcaj> ty
<seb128> Noskcaj, did you get motu yet?
<Noskcaj> seb128, no? meeting is monday
<Laney> no, you need to give a week
<seb128> Noskcaj, that was a question, you should know if you are motu or not?
<seb128> that seems like a first step before gnome pkgset upload rights
<Noskcaj> Laney, I've been on the wiki agenda for the meeting for a few weeks
<Laney> I saw the email today
<Noskcaj> seb128, Did not know that, i though they could be went for at the same time
<seb128> Noskcaj, they could
<seb128> I'm just asking to know if you got ack for motu yet or not
<seb128> my impression was still that you were not always responsive for issues you create
<seb128> so I'm unsure you are ready to be recommended for a set like gnome
<Noskcaj> seb128, With the exception of python-wsme, which is an ungodly mess, i think i am
<seb128> it would be nice if you tried to focus on resolving the problem you create before working on syncing more new stuff
<Noskcaj> Laney, I forgot to send it, because holidays
<seb128> like recently I had to revert your libgtop upload where the soname changed and you didn't rename the package accordingly
<Noskcaj> seb128, Excluding that package, i do
<Noskcaj> seb128, My only other bad upload, and i've since improved my package testing, as my current laptop can actually test stuff
<Noskcaj> *bad upload this cycle AFAIK
<seb128> Noskcaj, what about https://bugs.launchpad.net/ubuntu/+source/xchat-gnome/+bug/1272455 ? you screwed it, people had to revert, the bug is assigned to you and you are happily ignoring it since january
<ubottu> Launchpad bug 1272455 in xchat-gnome (Ubuntu) "multiple issues with git20131003" [High,Confirmed]
<Noskcaj> and i've fixed libgtop in debian svn following your changes
<Noskcaj> seb128, old laptop, me being lazy and trusting debian, i'm not sure how i'm meant to continue with that
<seb128> Noskcaj, well, step one would be to comment on the bug to say that
<seb128> rather than ignore it
<seb128> Noskcaj, then, it should be easy to build/test again that version and see if you can reproduce the issues described
<Noskcaj> brb, need dinner
<seb128> enjoy!
<wgrant> seb128: Another upload or a copy.
<seb128> wgrant, thanks
<Noskcaj> seb128, There's a few new git changes to make xchat-gnome a bit more stable, i'll try and get it sorted soon
<nrbrtx> Dear all! I can't understand why Ubuntu does not have an init script for saving and restoring display backlight level. I have prepared one (see bug 1270579 ), it works on my laptops as expected. The 14.10 use systemd, which has systemd-backlight@.service for doing this out the box.
<ubottu> bug 1270579 in sysvinit (Ubuntu) "Ubuntu should have an init script for saving/restoring backlight level on laptops" [Medium,Confirmed] https://launchpad.net/bugs/1270579
<seb128> Noskcaj, thanks
<seb128> Noskcaj, I don't especially care about xchat-gnome/we downgraded, it's just an example of work you created/where you didn't follow up after creating issues
<seb128> Noskcaj, imho you should try to focus a bit more on quality and a bit less on getting new stuff in
<Noskcaj> Will do
<caribou> arges: patch sponsored
<cjwatson> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: Feature Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: Laney, cjwatson
<Laney> wow
<Laney> how long have I been piloting ...
<Laney> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: Feature Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: cjwatson
<cjwatson> pitti: do you have any thoughts on the sanity of https://code.launchpad.net/~xnox/ubuntu-seeds/platform-init/+merge/225850 ?
<cjwatson> doko_: could you please look at https://code.launchpad.net/~abone/ubuntu/utopic/bash/fix-1358827/+merge/231417 ?  it looks right to me ...
<infinity> pitti: Really?  What an odd error message for that.
<arges> caribou: thanks
<caribou> arges: np
<cjwatson> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: Feature Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<stokachu> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: Feature Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: stokachu
<LocutusOfBorg1> have a nice weekend
<trifort> stokachu: can I ask a quick question about canonical employment
<stokachu> trifort, im not equipped to answer those questions, thats more for our human resources department
<trifort> stokachu: okay, thanks for your time. happy coding.
<doko> mlankhorst, one last try to switch mesa to 3.5 now?
<mlankhorst> erm isn't it on 3.5 now?
<infinity> mlankhorst: Did you find your code generation issue?
<mlankhorst> infinity: no but I guess it's because llvmpipe was generating sse2 instructions while llvm selected a cpu without sse2 support
<infinity> mlankhorst: Sure, that's a reasonable assumption, but also something we need to fix, as Ubuntu i386 definitely supports CPUs without sse2 (or, indeed, without sse at all)
<mlankhorst> infinity: yeah but i guess if no sse2 is supported things will work correctly because llvmpipe won't emit code using it
<infinity> mlankhorst: Err, what?
<infinity> mlankhorst: I'm not sure I followed your logic there. :)
<mlankhorst> infinity: well with the autodetect logic in llvm removed, llvm's autodetect logic no longer matches llvmpipe's autodetect logic
<tzero> Hello, I'm trying to package a cmake-built application that requires an override_dh_auto_configure. it looks like the original dh_auto_configure creates a build directory, changes to it, and runs the cmake $OPTS .. successfully, but in my overridden one, the pwd is reset after every command. Is there another step, or am I just doing something wrong?
<tzero> also, I could work around it using subshells, e.g. (cd builddir;  cmake ..)
<tzero> but that seems less-than-optimal
<sarnold> tzero: every line of a makefile is executed in a new shell; perhaps add ; \ or similar at the end of each line? or a cd ... ; prefix before each line?
<tzero> sarnold: ah, cool. that's expected then
<sarnold> tzero: there may yet be a better solution :) might not hurt to hang around a bit
<tzero> sarnold: the "default dh_auto_configure makes it look like each command is run in one shell, and my overridden one has "uglier" output
<sarnold> hmm
<dobey> tzero: what exactly are you trying to accomplish by running extra commands in an override_dh_auto_configure?
<dobey> tzero: if additional things need to be done at configure time, why aren't they beng done as a result of cmake being run?
<tzero> dobey: there are two; the first being that I have to regenerate some protobuf-c headers, and the second is just a define that I tried unsuccessfully to put in DEB_CMAKE_EXTRA_FLAGS
<tzero> I agree, a patch to upstream is probably in order for at least the former
<dobey> yes if something needs to be regenerated at configure time, it should be done by a rule in CMakefiles.txt
<dobey> https://bazaar.launchpad.net/~ubuntuone-control-tower/unity-scope-click/trunk/view/head:/debian/rules
<dobey> that might be helpful for seeing a workaround if DEB_CMAKE_EXTRA_FLAGS doesn't work for you (although depending on how you override dh_auto_configure, it might be appropriate that it doesn't work)
<tzero> is the '--buildsystem cmake' the key there?
<tzero> right now my override is just a list of shell commands as they would be run in the normal build tree
<tzero> that might be sufficient until I can get a patch or two in upstream's next release
<dobey> well the --buildsystem cmake might not be necessary; it's there in this file for historical reasons at this point (used to have multiple build systems in the tree)
<dobey> the "dh_auto_configure -- -DFOO" is the important part for you
<tzero> oh neat. that knocks off 8 lines of debian/rules :)
<tzero> so, after a couple small PRs, this should be ready to go. Thanks a bunch!
<smoser> slangasek, you able to tell me what i did wrong: https://bugs.launchpad.net/cloud-init/+bug/1377308
<ubottu> Launchpad bug 1377308 in cloud-init (Ubuntu) "booting cloud image without initramfs broken" [High,Triaged]
<smoser> what i'm confused by is that somehow /run gets omunted on lxc container 100% of the time. but on kernel-only boot it seems to fail 100% of the time. and stgraber says that lxc is not mounting /run for me.
<doko> pitti, jibel: how much RAM have the amd64 autopkg test machines configured?
<stokachu> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: Feature Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<slangasek> smoser: so if you're booting with an initramfs, /run will always be mounted before the 'mounted' event for / is emitted
<smoser> correct.
<slangasek> smoser: if you're booting without an initramfs, I would have thought this was still the case, but I'm not sure it's guaranteed
<smoser> but that is *not* the case in lxc.
<smoser> whihc is what was confusing me.
<slangasek> oh?
<smoser> i could not reproduce in lxc. and stgraber says that lxc isn't mounting /run for me.
<smoser> so /sbin/init is clearly running before /run is mounted
<smoser> i ran lxc containers , literally thousands, and never saw failure.
<slangasek> right
<smoser> i think also related to lack of 'ro' on the command line.
<slangasek> ah, yes
<slangasek> or more likely, to whether the filesystem is mounted ro when init starts
<slangasek> if lxc is giving you rw root at the start, then the mounted MOUNTPOINT=/ may come earlier
<slangasek> er, oh; you said this problem was *not* reproducible in lxc, meaning that /run was mounted earlier in lxc?
<smoser> in lxc , /run should not be mounted early.
<smoser> i would thikn in lxc , its basically guaranteed that / is mounted rw at the start
<smoser> but maybe that is wrong. maybe it is rw there.
<smoser> well, there went that theory. booted image of amd64 with 'ro' and no 'ro' and neither hangs.
<smoser> (with no initramfs)
<slangasek> mm?  does that mean the bug is not reproducible?
<smoser> not for me on amd64
<smoser> it was reported (and i saw it and collected those logs) on arm
<smoser> AArch64
<smoser> so this is just more odd now.
<fomenko_> hello
<fomenko_> can anybodey see me?
<sarnold> fomenko_: loud and clear :)
<sarnold> it's just beyond end of the work day for most people..
<fomenko_> i search for ubuntu developer
<fomenko_> I have very big problem with ubuntu library architektur and search for projects that can fix this problems, and I found it, and I want that ubuntu have this technologie
<fomenko_> on this site are the new technologie http://nixos.org/
<fomenko_> I like the idea in this technologie but I want use ubuntu
<fomenko_> and not switch to NixOS
<infinity> fomenko_: I'm not sure that "I want Ubuntu to be NixOS but still be Ubuntu" will get much traction.
<fomenko_> no
<fomenko_> I mean the technologie of NixOs
<infinity> Yes...
<fomenko_> please visit the site and read
<infinity> I know all about NixOS.
<fomenko_> and why not in Ubuntu this technologie?
<infinity> Suggesting that Ubuntu completely change its package and config management isn't something particularly feasible.
<fomenko_> but if ubuntu not do it, I do it and make my own ubuntuNixOs, you dont need konkurent and I dont need so much work
<infinity> You're planning to repackage literally everything we ship?
<fomenko_> no
<fomenko_> just use the technologie, but not using the exakt technologie from NixOs
<fomenko_> it is just the idea of NixOs
<infinity> fomenko_: The basic idea behind Nix (compartmentalised packages, with duplication of private dependencies) sort of goes against everything we do.
<fomenko_> but it is very big trobbel behind this libs
<fomenko_> you need the newes Ubuntu to use the newest software, because of the dependencys
<infinity> fomenko_: Nix "solves" that by having multiple copies of each library in a private directory.  You can do that on Ubuntu just fine too.
<infinity> I don't recommend it, but you can do it if you have to.
<infinity> Ultimately, you'll suffer from the same issue they do, which is that security updates become a nightmare.
<fomenko_> microsoft do it, and all things work fine
<sarnold> "work fine" -- objection :)
<fomenko_> and if microsoft solve this issju, why ubuntu cand do it?
<infinity> Yes, Microsoft does it with winsxs, and it's also a security (and drive space!) nightmare.
<fomenko_> jes, but it works
<fomenko_> and ubuntu works not
<infinity> I had a 120G SSD whose winsxs directory was 80G.  Not sure this is a solution. ;)
<sarnold> a great many windows programs ship known-vulnerable shared libraries with their gigantic bloated installers -- you wind up with dozens of versons of libaries on your system, one from each horrible program, and some get fixes (the ones intsalled by microsoft components) and the rest don't get fixes...
<sarnold> infinity: ouch :)
<infinity> sarnold: Yeah, it's pretty ridiculous.
<infinity> sarnold: Bad timing on Microsoft's part, IMO.  They dreamt up the winsxs solution literally a year or so before people started switching from spinning disks to SSDs and all their hard drives shrunk.
<infinity> sarnold: So, the "disk is cheap" argument went sailing out the window.
<sarnold> infinity: .. and we were all pushed towards ssds because the software was getting so bloated that we desperately needed faster load times :)
<fomenko_> and why not develop a special datasystem that make only the changes of the libs binarry insert or overlayed, so we can save a lot of sapce, but all works
<sarnold> see also: 80 gig winsxs directories
<fomenko_> and why not develop a special datasystem that make only the changes of the libs binarry insert or overlayed, so we can save a lot of sapce, but all works
<infinity> fomenko_: Why not just install a newer version of the library you need instead of having 17 copies of it?
<infinity> fomenko_: Or build the software you want against the older library you have?
<infinity> Neither of these is a problem.
<fomenko_> because other programs need the older versions -_-
<infinity> Only if the older version is also an older SONAME.
<infinity> In which case, you have the old Ubuntu one installed, and the new one you wanted, and they don't clash.
<fomenko_> and not all software are up to date and not all software are open sorce -_-
<infinity> Because we're not Windows, "dll hell" doesn't exist in Linux, and you can have your cake and eat it too.
<fomenko_> in linux are dependency hell
<fomenko_> and linus torwald have tell this is a very big problem in linux, but NixOs technologie solve the problem
<infinity> nixpkg solves the problem by creating another one.
<infinity> It's a question of which problem you want to have.
<infinity> We'd rather have the "problem" of having a reliably secure system.
<fomenko_> I dont want install every jear a new version of my ubuntu, I just want use it, but I cant use it because if I want a new software I need the new dependencys, but if I install it I just cant use my other software, it is a very no go
<infinity> fomenko_: You realise with something nix-like, you wouldn't magically get all the new deps you need, right?  You'd still need to either build or install them, and they'd, in turn, have their own new deps that need building or installing.
<infinity> fomenko_: So, you wouldn't technically "install a new OS", but you'd have, effectively, several new OSes installed for every application.
<infinity> At the end of the day, I'm at a loss as to what you think you've gained.
<infinity> Except and excuse to buy a bigger RAID array.  Which is always nice, I guess.
<infinity> s/and/an/
<fomenko_> I think it is hopeles, I just try make somethink like a script that use all the dependencies from older ubuntu release and unsable release and I solve the problem I hope
#ubuntu-devel 2014-10-04
<fomenko_> or make my own distro
<fomenko_> I dont know, but something must change in linux dependency problem
<fomenko_> good night
<guest28798> Hi. I was here yesterday and also #ubuntu both yesterday and right now. No one seems to be turning up for the problem I'm havintg and I desparately need a soln. I'm a comp sci majot about to look for a job in web dev and ubuntu is the only system I know well enought to do what I need (coding/code example to apply for jobs). Please, if anyone can help (I know this isn't a support channel but I'm stuck and I neeeeed a soln some-ho
<guest28798> w). Please advise what do I do to find a soln. I cannot even install ubuntu w/ this problem what it is.
<guest28798> comp sci major
<guest28798> some-how
<guest28798> I have to go eat - back in 30 or 40 min
<infinity> guest28798: It generally helps if you tell people what your problem is, rather than pleading for help but leaving out the details. :P
<guest28798> Infinity, you still there?
<guest28798> I'm on a borrowed computer chatting so may not be able to be on here very much longer. I have the hp pavillion dv6000 (circa 2007). Neither the keyboard nor the mouse work at all when I fire up the ubuntu 14 installation cd in it. I think I can plug in a usb keyboard and have some input to do the install but what do I do for a permanent fix so I can ultimately use the keyboard and mouse on the laptop?
<guest28798> something in gsettings? I really don't know.
<guest28798> Starting to fear I'll have to figure it out myself. Either no one know or noone cares. If I do, eventually, figure it out,
<guest28798> If I do I'll post the soln so we all have one. This problem is all over the internet (in various forms) going back at least 78
<guest28798>  7 years but no soln for current relases of ubuntu after it changed from using gnome settings to gsettings
<guest28798> And what really is the reason for some problems I see that go on for years with no soln? Don't make sense. Gives a person the impresion that ubuntu just doesn't care about some things/peple/probs
<infinity> Guest49899: I'm afraid I know nothing of old HP Pavillions, sorry.
<infinity> Err, wrong "Guest".
<LeartS> Hi guys! I'm not sure this is the right channel to ask: I proposed a backport of evince utopic to trust, now I'm trying to test it using backportpackage. I would like to build it *not* in a chroot, as that would mean downloading all of gnome etc. Is there a way to do this?
#ubuntu-devel 2015-09-28
<sarnold> pitti: 1500193 is 14 hours without a retrace, are the retraces blocked by the recent lcy01 issues?
<pitti> Good morning
<NikTh> Hello, any kernel maintainer here, or a How To build *only one* flavor in a kernel package that is building via Launchpad (PPA) and configured via Git ?
<pitti> sarnold: no, they just crash often because some ddeb download issues from LP; I'm hand-holding them
<RAOF> NikTh: Pretty sure you could delete whichever of debian.master/control.d/vars.{generic,generic-lpae,lowlatency} you didn't want.
<NikTh> RAOF: I'm missing something here. I have did what you say, but maybe I need to alter some scripts ? I don't know. Check (when you have time) a build fail here: https://launchpadlibrarian.net/218918782/buildlog_ubuntu-trusty-amd64.linux_4.2.1-999.2015Sep26_BUILDING.txt.gz
<NikTh> RAOF: My propose is to minimize the building time, by removing any not required flavors(generic-lowlatency..etc).
<NikTh> RAOF: I have removed some files from debian.master/config , debian.master/control.d/, also modified debian.master/rules.d/amd64 and i386 (skipabi, skipmodules, flavors)  but apparently something is missing
<RAOF> Strange error, and I'm not deeply familiar with the kernel build system.
<RAOF> NikTh: It might be quicker to just not bother restricting flavours; the whole kit and caboodle is a ~1hr build...
<NikTh> RAOF: No prob , thanks for trying to help :) Any other suggestion is welcome. I'm testing various changes local with 'pbuilder' now. Still getting the same error.
<RAOF> NikTh: I'd probably edit debian/rules.d/0-common-vars.mk to set AUTOBUILD=true (which will mean you can drop most of your other changes). That and deleting the control.d/vars.$FOO might be all you need?
<NikTh> RAOF: 4-5 hours, not 1hr , from what I've seen. It's OK, packages are not building in my laptop but in a virtual launchpad builder, but it would be better if I could reduce this time and get rid of not required flavors (generic-lowlatency..etc) :)
<NikTh> RAOF: I will try this ASAP. Thanks !
<dholbach> good morning
<seb128> hey dholbach
<dholbach> salut seb128
<SergioEDuran1> Hello
<SergioEDuran1> I want to make some requests for you (for Ubuntu Willy
<SergioEDuran1> )
<SergioEDuran1> Here I will send you a paste of my bash sesion trying to install Minetest
<SergioEDuran1> http://paste.ubuntu.com/12599522/
<SergioEDuran1> and here what I got when trying to install libleveldb1
<SergioEDuran1> http://paste.ubuntu.com/12600703/
<SergioEDuran1> here we need to edit the Minetest packages to adapt them to the new dependencies names
<SergioEDuran1> what do you say friends?
<SergioEDuran1> I think its important to keep all the packages present on the Ubuntu's official repos up to date not only on the app's version, even on the dependencies of the apps
<SergioEDuran1> no?
<SergioEDuran1> hello Laney
<SergioEDuran1> I saw something bad?
<SergioEDuran1> :(
<SergioEDuran1> I am trying to keep the Ubuntu's repo's packages up to date
<SergioEDuran1> that is all :)
<SergioEDuran1> dear admins
<SergioEDuran1> somebody could help me?
<Laney> SergioEDuran1: Ubuntu's minetest has the correct dependency - does apt-cache policy minetest show it as coming from a PPA?
<SergioEDuran1> Laney it is from the official Ubuntu's repos
<SergioEDuran1> http://paste.ubuntu.com/12599522/
<Laney> No
<SergioEDuran1> http://paste.ubuntu.com/12600703/
<Laney> Depends: minetest-data (= 0.4.12+repack-2ubuntu1), libc6 (>= 2.15), libcurl3-gnutls (>= 7.16.2), libfreetype6 (>= 2.2.1), libgcc1 (>= 1:4.1.1), libirrlicht1.8, libjsoncpp0v5, libleveldb1v5, libluajit-5.1-2, libopenal1 (>= 1.14), libsqlite3-0 (>= 3.5.9), libstdc++6 (>= 5.2), libvorbisfile3 (>= 1.2.0), libx11-6, zlib1g (>= 1:1.1.4)
<SergioEDuran1> you can check the paste :)
<SergioEDuran1> I have not used any Minetest ppa
<Laney> Maybe run the command I gave you so we can see which minetest it is trying to install
<SergioEDuran1> Ok
<SergioEDuran1> here it is Laney
<SergioEDuran1> http://paste.ubuntu.com/12600910/
<Laney> "apt-cache policy minetest" please
<SergioEDuran1> Ok
<SergioEDuran1> I saw the problem, solved :)
<SergioEDuran1> and why not packaging GNOME 2048?
<ubottu> Gnome bug 2048 in general "Miscount of no of emails in Clock and Mail Notify Applet" [Normal,Resolved: duplicate] http://bugzilla.gnome.org/show_bug.cgi?id=2048
<SergioEDuran1> gnome-2048
<SergioEDuran1> hehehehehe
<SergioEDuran1> and maybe adding gnome-2048 gnome-taquin and hitori to the gnome-games Laney
<SergioEDuran1> ?
<SergioEDuran1> friends
<SergioEDuran1> I am here again
<SergioEDuran1> I have sleeped a little bit
<SergioEDuran1> so... what do you think about including GNOME  2048 on Ubuntu 15.10 as part of the GNOME games?
<ubottu> Gnome bug 2048 in general "Miscount of no of emails in Clock and Mail Notify Applet" [Normal,Resolved: duplicate] http://bugzilla.gnome.org/show_bug.cgi?id=2048
<Odd_Bloke> infinity: wgrant: cjwatson: What's the canonical way of finding the architecture that I'm building for in a livecd-rootfs (binary) hook?
<cjwatson> Odd_Bloke: $LB_ARCHITECTURES (why it's plural I'm not quite sure)
<cjwatson> hm let me just check it gets that bit of environment
<Odd_Bloke> cjwatson: I don't _think_ it does.
<cjwatson> Odd_Bloke: ok, just use dpkg --print-architecture then
<cjwatson> Indeed, we use that in a few places in hooks
<Odd_Bloke> OK, cool.
<NikTh> RAOF: Unfortunately this gave me the same error. I'm trying now same thing but in addition I have modified debian.master/rules.d/amd64.mk and i386.mk to exclude generic and lowlatency from 'Flavors = ' line.
<NikTh> Oh, and also I have remove config.flavor.generic and lowlatency from 'configs' folder.
<jbl> anyone knows if ubuntu implements cpu shielding (cgroup cpuset) with systemd?
<seb128> cyphermox, that has no working retrace but it's high ranked on wily e.u.c, https://errors.ubuntu.com/problem/e72162eedbbe2652de316ee8653c35ee9b3ddebe
<seb128> so might be worth investigating
<seb128> wpa_supplicant segfault, seems to have started with 2.4
<cyphermox> yeah, I know :(
<cyphermox> just, no retrace and already complicated bugs with one
<seb128> bdmurray, do you know why https://errors.ubuntu.com/problem/56d2e995b3803bec644316604eb9cad22270532c claims "
<seb128> The following packages are missing debug symbols: libtrust-store2" where http://ddebs.ubuntu.com/pool/universe/t/trust-store/ seems to have those?
<Riddell> pitti: kcoreaddons looks blocked on regressions in knewstuff and khtml but there's no failures that I can see
<pitti> Riddell: indeed; I'll deal with this
<Riddell> pitti: some similar ones, kio and ki18n on kdelibs4support
<pitti> Riddell: kwin, ktexteditor, and kdepim-runtime look real to me, but your's indeed not
<pitti> Riddell: I'll check again in a bit, most stuff shold be right now
<bdmurray> seb128: I don't and will look into it some more.
<seb128> bdmurray, thanks
<NikTh> RAOF: We got it :-)
<NikTh> RAOF: Thank for you valuable help !
<Riddell> pitti: now for kcoreaddons it seems all is good but it still says not considered and I'm unsure why http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#kcoreaddons
<Riddell> pitti: also kwindowsystem has ktextwidgets as regressions but there is none http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#kwindowsystem
<pitti> Riddell: yup, currently doing the next iteration (sorry, at sprint, not much bandwidth)
<pitti> Riddell: so a big bunch now landed
<pitti> Riddell: http://autopkgtest.ubuntu.com/packages/k/kdepim-runtime/wily/amd64/ seems real, the rest is fixed (or covered by your force-*)
<Riddell> pitti:  kdepim-runtime just got uploaded so maybe that fixes it
<pitti> Riddell: FYI, I by and large know what's wrong in britney wrt. the false "regression" results, will fix after the sprint
<dgadomski> hey pitti, I need to backport some stuff from Debian's ifupdown (to fix bug #1337873). How can I offer the changes if the Ubuntu ifupdown package format does not support quilt? Is there Ubuntu git tree for ifupdown?
<ubottu> bug 1337873 in ifupdown (Ubuntu) "Precise, Trusty, Utopic - ifupdown initialization problems caused by race condition" [Undecided,In progress] https://launchpad.net/bugs/1337873
<pitti> dgadomski: it's a native package, just apply it inline
<pitti> dgadomski: and attach debdiffs to the bug
<dgadomski> pitti: alright, thanks!
<smb> slangasek, stgraber, So I just wanted to bring up again that we are looking for a vic...volunteer aa who could do the final parts to let dpdk (bug 1487538) into wily. Note that the PPA version linked in the bug is behind by 2 commits (visible in git) that arges made when sponsoring.
<ubottu> bug 1487538 in Ubuntu "Add dpdk to wily universe" [Wishlist,New] https://launchpad.net/bugs/1487538
<slangasek> smb: I can probably take a look at that today, once my web browser decides it's also willing to come back from vacation
<NikTh> If someone can confirm this : bug 1500216
<ubottu> bug 1500216 in unity-control-center (Ubuntu) "Installing/Updating language support failed with "org.freedesktop.DBus.Error.NoReply" message" [Undecided,New] https://launchpad.net/bugs/1500216
<smb> slangasek, cool. thank you and good luck. things always break when one isn't looking
<infinity> slangasek: I have a bit (understatement) of context on dpdk, but would be much happier if you did the NEW review, since you're picky about different things than I am.  Feel free to waste time on our call today discussing it, though.
<jamespage> slangasek, infinity: openvswitch-dpdk is also in the queue, depends on dpdk - it will pass its autopkgtests but only if the default cpu level if bumped via qemu options...
<jamespage> needs sse3
<seb128> dpm, pitti, wgrant, gedit.mo seems to be missing from the current wily langpacks (at least for de and fr), do you have any idea why?
<seb128> dpm, pitti, wgrant, looks fine the most recent update dropped quite some translations :-/
<seb128> $ debdiff language-pack-gnome-de_15.10+20150922_all.deb language-pack-gnome-de_15.10+20150924_all.deb
<seb128> Files in first .deb but not in second
<seb128> -rw-r--r--  root/root   /usr/share/locale-langpack/de/LC_MESSAGES/eog.mo
<seb128> -rw-r--r--  root/root   /usr/share/locale-langpack/de/LC_MESSAGES/evolution-3.16.mo
<seb128> -rw-r--r--  root/root   /usr/share/locale-langpack/de/LC_MESSAGES/file-roller.mo
<seb128> etc
<dpm> seb128, no idea. Let me look at the template
<seb128> dpm, thanks
<dpm> seb128, hm, I cannot see anything obvious. Last template update was on 2015-08-12
<dpm> priority seems correct
<seb128> dpm, there are like 10 of those which vanished in friday's update
<dpm> I'm looking at the content of language packs to see if they are in the export that's used as the source of the packages
<dpm> well,, downloading atm
<seb128> same here
<seb128> but they are 258M for the 22 and for the 24
<seb128> so it doesn't look like the content changed
<seb128> well, I'm speaking about the tarballs export on https://translations.launchpad.net/ubuntu/wily/+language-packs
<dpm> yeah
<sarnold> pitti: oh, that's a shame about the retracers; I hadn't noticed any issues in a long time so I thought you'd nailed down the worst of the issues.. I hadn't realized this whole time it was hand-holding
<sarnold> pitti: thanks for doing a good job on the retracers :) like I said, I hadn't noticed anything in a while..
<seb128> dpm, the pos are in the launchpad export, so it's something in the job that build the langpack sources from the export, do we have logs for that?
<dpm> seb128, I can confirm that too, I can see at least gedit.po in the export. langpack-o-matic can probably tell us more, pitti should know if we've got any logs
<seb128> right
<smoser> $ sudo ifup eth0
<smoser> sudo: unable to resolve host ubuntu
<smoser> dhclient: error while loading shared libraries: libirs-export.so.91: cannot stat shared object: Permission denied
<smoser> Failed to bring up eth0.
<smoser> that make any sense to anyone ?
<smoser> stgraber, ^ ?
<stgraber> hmm, would guess apparmor
<stgraber> anything in dmesg?
<sarnold> what's libirs-export.so.91?
<smoser> stgraber, good guess. http://paste.ubuntu.com/12604024/
<smoser> now, i guess some background on the possible luser error here.
<smoser> i grabed root-lxd.tar.xz for wily
<smoser> put it into a ext4 file system. then tried booting it with kernel, initramfs from maas ephemeral
<stgraber> do you have overlayfs in that mix?
<smoser> and
<smoser>   root=/dev/vda ro console=ttyS0 overlayroot=tmpfs init=/bin/bash
<smoser> yes.
<stgraber> oh, so it's yet another case of apparmor blowing up on overlayfs
<smoser> maybe
<smoser> but in an odd way
<stgraber> kinda surprised we've not run into that one with the desktop image
<smoser> because most certainly this works in maas booting maas ephemeral images.
<smoser> so there might be some luser error in the mix.
<smoser> but i dont know wht it woudl be.
<smoser> the first error i saw was just that networking-online never fired.
<stgraber> smoser: so one thing I notice in there is that none of the names contain a leading /
<stgraber> smoser: which may explain why apparmor can't resolve the paths, though I'm not sure what you may have done on your side to cause that slight difference
<smoser> hm.
<sarnold> I think it's the overlayroot=tmpfs that did it
<smoser> nah
<smoser> that path works
<sarnold> but this bug suggests the usual "attach_disconnected" workaround for files not visible in the process's namespace may not be sufficient for overlayfs: https://bugs.launchpad.net/apparmor/+bug/1408106
<ubottu> Launchpad bug 1408106 in AppArmor "attach_disconnected not sufficient for overlayfs" [Critical,In progress]
<smoser> odd though..
<smoser> it doesnt seem like i'm doing anything that maas doesnt do in its installation of wily
<jjohansen> nah, well sort of its overlayfs use of clone_private_mount
<smoser> and that is known working (at least as of a few days ago)
<jjohansen> sarnold: that depends, it is sufficient for regular file accesses, it is not sufficient if the denial is in a mount, or pivot_root
<sarnold> jjohansen: how about this?   < smoser>   root=/dev/vda ro console=ttyS0 overlayroot=tmpfs init=/bin/bash
<stgraber> my current recommendation is to turn apparmor off in any environment where / is on overlayfs, so live media, maas and any relevant installer
<smoser> sarnold, yea, i ditched that though, that was only for debugging.
<sarnold> smoser: ah, sorry for confusing the issue
<smoser> yeah. good eyes though
<stgraber> that's very much of a selinux-sounding answer to the problem, but fact is, this is a problem affecting random paths in a bunch of cases and it'd be really annoying if $RANDOM_SRU starts breaking things because we were depending on something which isn't actually supported
<jjohansen> sarnold: won't fix the apparmor bit, the current work around is using the attach_disconnected flag in the profile
<jjohansen> but if it is failing in a mount (not this case) there is no work around, besides making the affected code unconfined
 * jdstrand notes that we hope to re-engage with overlayfs upstream next month (ie, after current sprint that is in progress) and see what's what
<stgraber> jjohansen: is there a way to set attach_disconnected for every single profile on the system without having to mangle them all?
<stgraber> because with / being on overlayfs, it's potentially every single apparmor profile that would run into this and I'm really not sure we want to change them all to set attach_disconnected
<jjohansen> stgraber: no
<stgraber> so attach_disconnected isn't really an option then
<octoquad> Hi, would someone mind looking at this patch in the next pilot run? https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1385868 does this perhaps need to be fixed upstream?
<ubottu> Launchpad bug 1385868 in samba (Ubuntu) "Samba logrotate script uses invalid argument to /etc/init.d/nmdb" [Medium,Confirmed]
<bdmurray> seb128: it looks to me like the Packages file at http://ddebs.ubuntu.com/dists/wily/main/binary-armhf/ is missing libtrust-store2
<bdmurray> pitti: it looks to me like the Packages file at http://ddebs.ubuntu.com/dists/wily/main/binary-armhf/ is missing libtrust-store2 - probably among other things
<bdmurray> pitti: wily/main/binary-amd64/ is missing it too
<bdmurray> seb128, pitti: I reported bug 1500557 about it.
<ubottu> bug 1500557 in ddeb-retriever "Packages file(s)? for wily out of date" [Undecided,New] https://launchpad.net/bugs/1500557
<cyphermox> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: feature freeze | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-vivid | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: cyphermox
<ypwong> Does Wily image now support 32-bit UEFI on x64 processor?
<seb128> bdmurray, thanks for investigating
<brendand> what's the 'correct' way to get the arch-specific part of /usr/lib/${arch}/...
<brendand> dpkg-architecture -q DEB_HOST_MULTIARCH is certainly one way
<brendand> hmm, the phone doesn't have dpkg-architecture installed... unfortunate
<sarnold> do we have perl on the phones? that' sjust a 9k perl script..
<sarnold> it feels like a useful enuogh thing to include
<slangasek> sarnold: we have perl-base; we should not have perl; and dpkg-architecture is part of dpkg-dev which has other baggage
<sarnold> slangasek: oh :/ I didn't think to check where it comes from..
<brendand> slangasek, so any other way to work that out than dpkg-architecture?
<TJ-> brendand: is coreutils installed? /usr/bin/arch
<brendand> TJ-, that's only part of it
<brendand> TJ-, in fact i'm not sure that's related to it at all
<brendand> on the phone `arch` is "armv7l"
<brendand> but i'm looking for something that gives "arm-linux-gnueabihf"
<TJ-> that comes from the libc build triplet doesn't it?
<brendand> TJ-, i guess so
<slangasek> brendand: no good way to check this at runtime, no, sorry
<slangasek> brendand: you can indeed have your own local table that maps architectures to paths, but there's nothing that does this mapping for you
<bipul> Hi
<brendand> slangasek, is there any reason 'armv7l' might not map to 'arm-linux-gnueabihf'?
<bipul> Hello, I am new to bug fixing. I would love to fix and patch bugs
<TJ-> Could you rely on the binutils package? It installs files under /usr/bin/ with the triplet encoded in the filename
<bipul> But i am unable to get how to start and where to start?
<TJ-> bipul: see https://wiki.ubuntu.com/Bugs
<slangasek> brendand: you might have a 64-bit kernel, and then you don't get 'armv7l' at all but 'aarch64'?  so the more reliable check for "what architecture am I on" is "dpkg --print-architecture"
<cjwatson> brendand: the correct way to get the multiarch path is to calculate it at package build time and embed it in your package
<cjwatson> (which may require making your package architecture: any)
<cjwatson> and then you can use dpkg-architecture at build time
<brendand> cjwatson, the particular use-case here is to find the path of a binary during a test
<brendand> cjwatson, so it will be well after build time
<cjwatson> brendand: I stand by my advice
<cjwatson> brendand: not saying you need to be able to construct the entire path of the binary in question at build time, but you can embed the multiarch bit; or else question why a binary that's needed outside of implementation details of its package is in a multiarch path with no non-multiarch-dependent way to get at it ...
<infinity> brendand: Err, "find the binary of a path at runtime"?
<infinity> brendand: If that relies on the triplet, you've failed to do something correctly, IMO.
<infinity> brendand: Could you elaborate on the problem, rather than the proposed solution?
<infinity> s/binary of a path/path of a binary/
<infinity> But I'm not dyslexic...
#ubuntu-devel 2015-09-29
<cyphermox> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Archive: feature freeze | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-vivid | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<smoser> hey, wonder if anyone has thoughts on https://bugs.launchpad.net/ubuntu/+source/openhpi/+bug/1488453
<ubottu> Launchpad bug 1488453 in openhpi (Ubuntu) "Package postinst always fail on first install when using systemd" [High,Confirmed]
<smoser> need some systemd help there.
 * smoser has to go to bed but will read scrollback and any comments on bug would be appreciated.
<dx> hey what's the easiest way to get a package removed from trusty? it's extremely buggy, it has always been, and i don't want to continue supporting it for the next few years
<dx> bug is https://bugs.launchpad.net/ubuntu/+source/bitlbee/+bug/1315550 which seems to be considered closed just because it's fixed in vivid
<ubottu> Launchpad bug 1315550 in bitlbee (Ubuntu) "Current 14.04 bitlbee build using broken OTR (fixed in nightlies)" [Undecided,Fix released]
<dx> tl;dr removing "bitlbee-plugin-otr" from trusty will fix my headaches and that bug. would be really appreciated
<Unit193> Looks like you'd first thought about or tried SRU'ing.
<dx> indeed. but i don't know enough about the procedures to go through all that. i'd rather just have it removed
<dx> only now we got another complaint about this bug, probably the first one in months
<ScottK> Because of the way the Ubuntu archive works, removal is effectively not possible.
<dx> dammit
<dx> i really wish the bug was bad enough to fit in the category of security issues.
<ScottK> If you know how to fix it, attach the patch to a bug, explain what's going on and subscribe the ubuntu-sponsors team to the bug.
<ScottK> All the distro specific specific bureaucracy they should be able to handle.
<dx> there are several bugs (i think three of them, two critical, one not so much), is it okay if i submit a single patch with the three of them?
<Logan> yes
<infinity> dx: We don't remove packages.  The best you could do for removal would be to replace it with an empty package, which would be a harder SRU to get through than just fixing the bugs.
<dx> attached patch, subscribed ubuntu-sponsors team
<dx> i hope that's enough. thanks everyone.
<pitti> seb128: langpacks> sprint this week, sorry -- can you take this up with William?
<seb128> pitti, hey, I can try ... do we have logs from the langpack-o-matic work?
<seb128> pitti, the launchpad export includes the .po
<pitti> sarnold: I did add a more permanent "fix" now -- they should be okay now?
<seb128> so something is wrong in the export to source package processing
<pitti> seb128: yes, they are all in log/
<seb128> log from what machine?
<seb128> or people page?
<seb128> pitti, or do you mean I should try a local build?
<pitti> seb128: macquarie, can you ssh there?
<seb128> pitti, seems like I can
<seb128> what dir/user should I lookfor?
<pitti> seb128: /srv/language-packs.ubuntu.com/log
<seb128> pitti, nothing useful in there :-/
<seb128> pitti, I'm going to try a local build
<dholbach> good morning
<seb128> pitti, did you see https://bugs.launchpad.net/ddeb-retriever/+bug/1500557 ?
<ubottu> Launchpad bug 1500557 in ddeb-retriever "Packages file(s)? for wily out of date" [Undecided,New]
<pitti> seb128: no, not yet; sprint..
<seb128> pitti, right, sorry
<pitti> seb128, bdmurray: is that a big blocker? I thought we download the ddebs directly from LP in this case?
<seb128> pitti, I don't know, bdmurray was investigating why some of the e.u.c retracing were failing
<seb128> but maybe the cause is different
<seb128> pitti, also langpack-o-matic doesn't generate buggy langpacks locally, is there any way you can kick a rebuild on the server side to see if that was a one time off issue?
<pitti> seb128: that is highly unlikely, unless there was an exception in the log or so
<seb128> so I don't understand
<pitti> seb128: did you run ./cron.daily ? or how did you build?
<seb128> the build from the 22 was good and the one from the 24 is missing like 10 files
<seb128> pitti, ./cron.daily wily
<pitti> ack
<seb128> the logs have no mention of e.g de/gedit
<pitti> find wily/ -name eog*
<seb128> but the .po is in the launchpad export tarball, it should be mentioned as copied or skept
<pitti> sources-update/ has eog for only a handful of langs
<seb128> right
<pitti> but all of the -base packages have it
<seb128> why is the question
<seb128> same for gedit, file-roller, etc
<Laney> speaking of langpacks, there's a few of them out of date in wily vs vivid - https://udd.debian.org/~laney/less.txt
<Laney> why's that?
<pitti> seb128: you didn't build against existing -base packages, or did you?
<seb128> pitti, I probably didn't, though I did copy a gedit.po in sources-base/... otherwise it was skipping it
<pitti> Laney: they either fell through the "at least 5% translated" barrier or they actually didn't get new translations in wily yet
<seb128> and it did copy gedit.po in sources-update
<pitti> seb128: right; you can't build -base packages from a Launchpad delta export
<Laney> pitti: should I just copy up the SRUs?
<pitti> seb128: but I don't see how a file from the existing update packs would get removed -- langpack-o-matic only ever adds files to existing files
<Laney> at least some of them are sitting in vivid-proposed though
<pitti> Laney: oh, because we did a -base refresh in vivid, but not in wily
<pitti> actually we did
<pitti> Laney: so maybe when we got the first wily export a lot of translations weren't imported into wily yet; I can only speculate
<pitti> Laney: I propose I'll request a full export, we rebuild wily langpack -bases from scratch, and we remove the obsolete pacakges
<Laney> I don't know about langpacks, so I defer to you. :)
<Laney> I put a note to re-run this query in 1 week and see what's still out of date then
<pitti> Laney: thanks
<pitti> seb128, Laney: next export shold happen Thursday
<seb128> pitti, it's a bit puzzling to me
<seb128> let's see what happens then
<Laney> It's not just -base packages that are listed there btw
<pitti> Laney: right; but easier to investigate this from a full export/build
<Laney> ok
<TJ-> Is there anyone about that deals with building the grub-efi signed core.img, that can discuss adding additional modules to support the LUKS-encrypted GRUB root-fs scenario?
<didrocks> barry: hey, when you get some time, do you mind looking at a regression due to python 3.4.3 which is breaking proxies with requests? bug #1500768
<ubottu> bug 1500768 in python3.4 (Ubuntu) "python3.4.3 SRU break requests" [Undecided,New] https://launchpad.net/bugs/1500768
<seb128> hum, does anyone know why some of the recent uploads in wily are missing from the wily-changes list?
<seb128> like the aptdaemon upload from yesterday evening
<LocutusOfBorg1> hi, does anybody know how to give dm for Debian from Ubuntu?
<LocutusOfBorg1> $ dcut dm
<LocutusOfBorg1> No host dm found in config
<Laney> LocutusOfBorg1: I think you need dput-ng for this
<LocutusOfBorg1> Laney, but it seems to be not working
<Laney> that message indicates you have dput, not dput-ng
<LocutusOfBorg1> dput.exceptions.InvalidConfigError: Error with config file profiles/debian - Required field 'incoming' is missing
<LocutusOfBorg1> I also tried dput-ng of course
<cjwatson> seb128: looking
<seb128> cjwatson, thanks
<LocutusOfBorg1> oh well, I might have screwed up my config files
<seb128> cjwatson, the recent rhythmbox upload is another example
<cjwatson> Oh, hah, I bet I forgot to get PackageUploadNotificationJob added to the celery feature rules
<cjwatson> Maybe.  Checking further
<cjwatson> Ah, in fact it would have worked but there's a missing DB user
<cjwatson> seb128: https://rt.admin.canonical.com/Ticket/Display.html?id=85100
<cjwatson> It should catch up with the missing notifications once that's fixed
<seb128> cjwatson, thanks
<cjwatson> Thanks for letting us know, I hadn't looked over the OOPS report in a while :-/
<cjwatson> oh, it's not even on the oops report.  how helpful.
<LocutusOfBorg1> Laney, the trick was "dcut ftp-master dm"
<LocutusOfBorg1> I was trying with -c but unsuccessfully
<Laney> I remember constructing the file manually the only time I did DM manipulations
<Mirv> I must say I'm happy with the new (opt-in) Launchpad bug e-mail footer tags, makes life better for a puny GMail user
<Mirv> (https://launchpad.net/~/+edit -> Include filtering information in email footers)
<cjwatson> Mirv: \o/
<NikTh> seb128: 1500216 invalid ?
<seb128> NikTh, yes, wily-proposed is not meant to be used, those issue can be hit there
<NikTh> seb128: Thank for all the valuable help , disentangled quickly with this one. :-)
<seb128> NikTh, yw!
<NikTh> RAOF: Hi, I don't know if you saw the messages the other day, but...success ! mostly because of you. The first step was AUTOBUILD=true indeed , also some other removals (config/ vars/) and finally comment out a line in the debian/rules , because it messed up the binaries names.
<NikTh> Check the binaries here: https://launchpad.net/~nick-athens30/+archive/ubuntu/trusty4-dev/+packages (48mins build time).
<NikTh> Check the binaries here (generic and lowlatency exist) : https://launchpad.net/~nick-athens30/+archive/ubuntu/trusty4/+packages (4h+ build time).
<smoser> pitti, i wonder if you have thoughts on bug 1488453
<ubottu> bug 1488453 in openhpi (Ubuntu) "Package postinst always fail on first install when using systemd" [High,Confirmed] https://launchpad.net/bugs/1488453
<smoser> basically, the sysvinit job that is there would exit success even though the daemon would exit non-zero when marked explicitly as UNCONFIGURED.
<pitti> smoser: I posted my initial answer to the bg
<pitti> bug even
<smoser> we'd have to patch it to make exit code specific for this scenario.
<pitti> just sent a followup comment
<pitti> smoser: ah, it doesn't already? how unfriendly
<pitti> well, anything which will tell you whether it failed or is just unconfigured
<smoser> i said that in my comment, there are other reasons it exits 8
<smoser> which, yeah, is silly.
<pitti> if it's configured and really fails, you don't want to silently ignore that
<smoser> right.
<smoser> we could look at the output
<smoser> but then thats assuming that its not localized
<smoser> i couldn't find a condition that seemed sane.
<doko> tvoss: https://bugs.launchpad.net/ubuntu/+source/qtubuntu-media/+bug/1500859
<ubottu> Launchpad bug 1500859 in qtubuntu-media (Ubuntu) "hard coded dependency on non-existing version of runtime library" [Critical,Confirmed]
<smoser> pitti, if i did '--no-start', then that woudl break the case where user installs their desired config, and then the package, right? as it woudlnt start.
<pitti> smoser: right
<pitti> smoser: or dh_installinit --error-handler=true
<pitti> smoser: (or something slightly more advanced than true if you want)
<tvoss> doko, ack and noted down
<smoser> so upstart trusted the exit code of the init script. systemd is finding the daemon process and noticing it fails.
<smoser> pitti, thank you for your help
<seb128> mdeslaur, hey, if tzdata updates go through security, does it mean bugfixes for issues created by those updates should go through security pocket as well?
<mdeslaur> seb128: yes. talk to infinity, he's the one that takes care of tzdata and copies it to -security
<mdeslaur> seb128: what is the issue?
<seb128> mdeslaur, thanks
<seb128> mdeslaur, bug  #1473533, I just backported the upstream fix to wily
<ubottu> bug 1473533 in python-tz (Debian) "CountryNameDict function trying to parse UTF-8 iso3166.tab as US-ASCII" [Unknown,New] https://launchpad.net/bugs/1473533
<barry> didrocks: yep, will look
<seb128> basically pytz tries to read the tzdata files as ascii
<seb128> and some got converted to utf8 in 2015e
<seb128> which leads to an encoding error
<seb128> test case is "import pytz; pytz.country_names"
<mdeslaur> ah, yuck :)
<shadeslayer> Hi
<shadeslayer> I've been following https://wiki.ubuntu.com/X/EGLDriverPackagingHOWTO to ship some custom egl implementation, however it seems like the system egl libs are prefered over my custom ones in my custom folder
<shadeslayer> So I added my libs at the top using LD_LIBRARY_PATH, is there a better way of achieving this?
<seb128> infinity, ^ see pytz/tzdata discussion
<seb128> there is a corresponding fix in the wily unapproved queue
<shadeslayer> ok so I think it's because my arm-linux-gnueabihf_EGL.conf path gets loaded *after* arm-linux-gnueabihf.conf
<shadeslayer> so if I simply ship another config which is loaded before arm-linux-gnueabihf.conf it'll work
<smoser> pitti, ok. so almost by accident, i realized that just adding a systemd service fixes the problem
<kenvandine> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Archive: feature freeze | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-vivid | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: kenvandine
<seb128> kenvandine \o/
<doko> seb128, https://launchpad.net/ubuntu/+source/wxwidgets2.8/2.8.12.1+dfsg2-2ubuntu2
<seb128> doko, your sentence lacks a verb
<seb128> and maybe words
<doko> this should have been a library rename, but I don't care. in any case, could you do no-change rebuilds (lacking depite any verb)
<seb128> no change rebuilds of what?
<doko> rdeps=
<seb128> yeah, it should, but debian wontfixed it
<doko> ?
<seb128> well, I tested the rdepends and they seem to work
<seb128> include amule which is what the report was against
<doko> I would appreciate a sane solution, not just testing one specific binary
<pitti> smoser: ah, I thought it already had one -- so the .service does something magical to detect whether it's configured or not?
<smoser> pitti, no
<seb128> doko, ok, I can do rebuilds
<smoser> its kind of a bug i think. its wierd.
<doko> seb128, ta
<seb128> yw
<smoser> when the /etc/init.d/openhpid script is called via systemd, it must exit failure, and dh_installinit not like that
<smoser> but when there is a systemd job and it fails start, then that must not get raised to dh_installinit
<smoser> as it doesnt fail the install
<smoser> note, that the behavior of systemd with openhpi.service file is the same behavior we had on trusty with upstart + sysvinit script
<smoser> in that install is fine, but 'status' will show it did not start.
<smoser> does that make sense?
<smoser> pitti, thanks again for your help. could you take a quick sanity check on the systemd job i'm considering
<smoser>  http://paste.ubuntu.com/12612654/ . its copied rom the fedora one
<pitti> smoser: hmm; this could need some cleanup
<pitti> smoser: but aside from that, this should fail similarly, once the forked process ends?
<ogra_> infinity, i need to add name resolution to an initrd (dont ask ...), for that i apparently need to copy_exec libnss_dns|files and libresolv ... (plus creating nsswitch.conf) ... is there any way that prevents me from having to hand the triplet in the path to copy_exec ? (i would like to avoid ending up with a giant hook script)
<smoser> pitti, well, yes. it does fail, 'systemctl status' shows the failure
<smoser> but the install succeeds.
<smoser> ie, the bug is that the package fails install
<smoser> by design it doesnt start until configured, but it should still install :)
<pitti> smoser: oh, because starting it doesn't wait for that, I see
<pitti> smoser: so sort a happy accident
<smoser> right. but the same happy accident that happened in upstart
<smoser> what i dont understand actually is why the sysvinit script does not cause the same behavior.
<smoser> as it is run via the systemd-sysv-generator
<smoser> so, my feeling is that this gives us the same "working" scenario we've had since 10.04, and thus its acceptable.
<smoser> but if you have suggestions on how to make the systemd job better, i'm interested in that.
<smoser> http://paste.ubuntu.com/12612758/ <-- debdiff
* Laney changed the topic of #ubuntu-devel to: Archive: feature freeze, user interface freeze, final beta freeze | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-vivid | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: kenvandine
* Laney changed the topic of #ubuntu-devel to: pilot
* Laney changed the topic of #ubuntu-devel to: Archive: feature freeze, user interface freeze, final beta freeze | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-vivid | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: kenvandine
<Laney> oops
<system0x01> Linux. Python. How to read current speed DVD/CD form /dev/sr0 at copy files?
<smoser> pitti, does the systemd file look ok generally ?
<pitti> smoser: (in hangout, bbl0
<smoser> k
<pitti> smoser: it looks okay, but a bit crufty
<smoser> if you have suggestions i can take them.
<pitti> smoser: After=syslog.target should be dropped (that doesn't even exist, and is early-boot stuff)
<pitti> smoser: should use /run, not /var/run
<pitti> smoser: and ideally it would avoid using "forking" and run the process in the foregroud
<smoser> pitti, i think the pid file must be compile time
<smoser> or otherwise int he source. ie, the config doesnt specify it
<pitti> smoser: but /var/run is a symlink to /run, and you might have /var on NFS
<pitti> that also isn't relevant for late boot stuff
<pitti> but it's something which we should get rid of long-term (using /var/run)
<pitti> smoser: i. e. dropping the PID file and using the default Type=simple and running stuff in the foreground is usually better
<pitti> (both in upstart and systemd)
<pitti> as you can properly capture/log the output, errors, etc.
<pitti> of course that might be the very thing to bring back that install error :)
<smoser> ok. i'll give that a test.
<bzoltan_> cjwatson: Are you OK with the changes on the click MR now? https://code.launchpad.net/~bzoltan/click/add_overlay_ppa/+merge/272428
<cjwatson> ew
<cjwatson> um, let me suggest something a bit less ugly
<cjwatson> ok, suggestion in the MP now
<bdmurray> pitti: I need to double check but I think if apport doesn't think the package exists in the apt cache then it won't check Launchpad.
<pitti> wow, I'm getting "wily/proposed accepted" mails for stuff I uploaded a week ago
<caribou> did someone just upload makedumpfile (1.5.5-2ubuntu1.4) to trusty-proposed ?
<caribou> LP: #1469054 is by far not complete, apw was supposed to review it
<ubottu> Launchpad bug 1469054 in makedumpfile (Ubuntu Trusty) "Unsupported kernel warning while running makedumpfile" [Medium,Fix released] https://launchpad.net/bugs/1469054
<caribou> oh, wait, just don't bother about that noise
<caribou> that's another upload that I did a while ago
<cjwatson> pitti: Looks like IS just dealt with my ticket to sort out upload notification jobs, which have been broken for a while
<cjwatson> caribou: ^- probably applies to yours as well
 * caribou goes back under his rock & hide
<caribou> cjwatson: well, thanks then. I'm not that crazy
<caribou> cjwatson: especially since this one of the few packages I have upload rights for :-)
<pitti> cjwatson: ah, thanks
<bdmurray> caribou: that doesn't you aren't crazy
<cjwatson> cjwatson@carob:~$ rsync loganberry.canonical.com::launchpad-production-logs/process-job-source-groups.log . | grep --count 'Running.*PackageUploadNotificationJob' process-job-source-groups.log
<cjwatson> 874
<caribou> bdmurray: :) sure, they're not mutually exclusive
<cjwatson> and indeed I could actually hear the evidence of that working because my local mail server's disk is a little noisy and was processing the resulting large batch of -changes mail :-)
<didrocks> tdaitx: hey, do you have a minute to discuss bug #1441487?
<ubottu> bug 1441487 in jayatana (Ubuntu) "Running any Java program produces messages in the terminal, while rendering many Java applications broken" [Critical,Triaged] https://launchpad.net/bugs/1441487
<cjwatson> seb128: ^- that dealt with the missing wily-changes mails you were asking about, BTW
<seb128> cjwatson, yeah, I noticed the emails, thanks for getting the issue resolved!
<smb> slangasek, Did you try to ping me yesterday. Recently xchat just dies in a heap after playing the highlight sound first start in the morning. Naturally taking all info with it
<hallyn> slangasek: hey - why is edk2 in multiverse again?
<tdaitx> didrocks, yeah, I just read the bug report
<didrocks> tdaitx: so, I don't get the crash on menus as some are reporting for instance on android studio/intellijâ¦
<didrocks> tdaitx: however, it seems that the fact the openjdk prints the first line "Picked up <â¦>" is making a lot of program crashing
<didrocks> (not eclipse, not intellij, not jetbrain, but others?)
<slangasek> hallyn: crazy Intel licensing on the FAT driver
<didrocks> as most of program are reading their output it seems to determinate with java -version the java versionâ¦
<slangasek> smb: I responded to your dpdk request (which is still sitting in front of me for review)
<didrocks> tdaitx: do you understand the same? It seems that unfortunately openjdk output isn't tunable
<slangasek> smb: I got as far as 'License: BSD+GPLv2+LGPLv2' in debian/copyright ;)
<hallyn> slangasek: :)  right, thanks
<slangasek> smb: you correctly note that the license here is BSD+GPL, but you don't reproduce the BSD license in debian/copyright, which is a requirement of the BSD license
<tdaitx> didrocks, right, I am looking at those links in the bug report, will take a look at openjdk in a minute
<didrocks> tdaitx: thx! I've emailed jayatana upstream about the crash (that I didn't get), I can see script doing java -version | grepâ¦ :/
<didrocks> tdaitx: FYI, on the openjdk bug: https://bugs.openjdk.java.net/browse/JDK-8039152
<smb> slangasek, hm... nobody else was mentioning that before... from where does one take that?
<tdaitx> didrocks, right, so they can't disable the message since it would be considered a security vulnerability, there is also no way to output it somewhere else because the "options logic" in openjdk has not been run yet... it is unlikely they will 'fix' this
<didrocks> tdaitx: ok, I understand the rationale. I'm thus inclined to SRU a removal of this env variable export for the session (that will still let the user exporting it)
<didrocks> tdaitx: waiting for some feedback on my last comment on it, any chance you are working with java upstream to get proper global menu support for both Unity and gnome shell (same protocole)
<didrocks> quite weird that java apps don't export their menu (and for developer tooling, it's annoying)
<smb> slangasek, That part is long enough ago that I do not recall it fully but I thought I went somewhere which had examples of what licence text to repeat in the copyright file and that had gpl but somehow nothing usable for bsd...
<bdmurray> pitti: yeah, its try: debsym = cache[dbgsym_pkg] ... except KeyError: 'no debug symbol found'
<slangasek> smb: "Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer [...]" so we do consider this satisfied by /usr/share/common-licenses/BSD, but then debian/copyright needs to point to /usr/share/common-licenses/BSD and not just /usr/share/common-licenses/GPL
<pitti> infinity, mdeslaur, slangasek, kees, stgraber: TB meeting reminder
<mdeslaur> pitti: ack
 * slangasek nods
<tdaitx> didrocks, I haven't tested it, but as far as I have seen other jvms (IBM, Oracle) also output it before the usual "version" info - I have seen other bug reports for those jvms when JAVA_TOOL_OPTIONS is set
<tdaitx> didrocks, thus I don't believe it is something we can get openjdk to "fix"
<didrocks> tdaitx: ok, so the only solution is that we work with swing and other java toolkit to get proper exported menu
<didrocks> (upstream)
<didrocks> in GS and Unity
<tdaitx> of course, tools shouldn't be parsing the java -version in such a way, not something we can get everyone to fix =)
<didrocks> tdaitx: well, I'm not surprised that exists ;)
<tdaitx> didrocks, indeed, the correct solution is to work with swing to get the menus to work on unity
<didrocks> tdaitx: I know that the desktop team has no java expert and fundation no unity expert, maybe our manager should align to give some time for a co-working project :)
<tdaitx> didrocks, I'm not working with java upstream on it, I will check if there was ever a discussion on the 2d-dev ML about this
<didrocks> tdaitx: yeah, if you can dive into the ML to see if at least, that was discussed somewhereâ¦ that would be a great start!
<seb128> slangasek, hey, is the patch from bug #1439769 on your list of things to look at/get reviewed for wily?
<ubottu> bug 1439769 in update-manager (Ubuntu Vivid) "various linux packages being marked as manually installed, still prevents 'apt-get autoremove' from doing the right thing for kernels" [Critical,Triaged] https://launchpad.net/bugs/1439769
<didrocks> tdaitx: on my side, if I don't see any objection by tomorrow morning, I'm going to SRU removal of the env var
<seb128> slangasek, should ubuntu-sponsors be subscribed?
<smb> slangasek, ok, so like that http://paste.ubuntu.com/12613637/ or only with the "On Debian..." part?
<chiluk> infinity, do you know who's responsible for rebuilding http://archive.ubuntu.com/ubuntu/dists/trusty-proposed/main/installer-amd64/current/images/netboot/ubuntu-installer/amd64/initrd.gz  ?
<chiluk> the sfc network module was recently added to the nic-modules .udeb... and it needs to be rebuilt against at least -63 ..
<chiluk> it looks to currently be against -61
<chiluk> slangasek ^^ do you know who owns rebuilds http://archive.ubuntu.com/ubuntu/dists/trusty-proposed/main/installer-amd64/current/images/netboot/ubuntu-installer/amd64/initrd.gz
<xnox> chiluk: any of cyphermox infinity arges kernel-team foundations-team
<chiluk> xnox... kernel-team, and arges were a no-go.
<chiluk> infinity, and foundations-team appear to be awol..
<cyphermox> I'm here.
<xnox> chiluk: do it yourself? =)
<chiluk> no perms.
<xnox> chiluk: i can sponsor =) har har =)
<xnox> cyphermox: can you rebuild d-i in trusty proposed, against proposed deps?
<xnox> please, as per chiluk request above.
<cyphermox> sure.
<cyphermox> chiluk: is there a bug for this?
<chiluk> cyphermox, it needs to be rebuilt at least against -63..
<chiluk> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1481490
<ubottu> Launchpad bug 1481490 in linux (Ubuntu Vivid) "Add sfc to nic-modules udeb" [Undecided,Fix released]
<chiluk> I just started looking at it a few minutes ago.
<arges> cyphermox: so the abi bump will cause the udebs to be updated with the additional modules. ( ijust found my notes on how to do this btw)
<cyphermox> yes
<chiluk> cyphermox are you going to be able to twiddle the right bits for me?
<cyphermox> yes
<chiluk> thanks
<cyphermox> chiluk: is -65 ok? If we're to rebuild, might as well pick the latest.
<doko> Riddell, there are a bunch of kde packaages not migrating, pleaes see update_excudes
<chiluk> cyphermox, -65  is sitting in trusty-updates so that should be fine.
<cyphermox> yeah.
<cyphermox> there isn't one in proposed at all
<chiluk> yep.
<chiluk> so -65 for both should be acceptable.
<chiluk> cyphermox any idea when it should be available in the archives?
<cyphermox> chiluk: depends on the SRU team :)
<cyphermox> it would be in proposed once reviewed.
<cyphermox> chiluk: it's in the queue now, arges or someone else can review it.
<arges> cyphermox: ok will do today or tomorrow
<arges> cyphermox: did you upload for vivid, or is that not necessary?
<cyphermox> arges: it wouldn't be the same changes, that's for sure
<cyphermox> is there the same issue for vivid?
<arges> chiluk: ^^^ did you check if the current version has the rigth module?
<chiluk> arges ... the change was from no module to having a module
<arges> cyphermox: and also do we typically leave off bug #s for these kinds of uploads?
<cyphermox> there usually are not
<cyphermox> I can certainly re-upload with the bug number
<cyphermox> do you want to reject it so I re-do the upload?
<arges> cyphermox: its fine
<jtaylor> cyphermox: is an sru backport the the grub -21 patch planned?
<cyphermox> jtaylor: yes
<jtaylor> cyphermox: great thanks
<jtaylor> you can ping me for testing if required
<cyphermox> jtaylor: it's in the trusty queue for review by the SRU team already: http://launchpadlibrarian.net/218703135/grub2_2.02~beta2-9ubuntu1.4_source.changes
<cyphermox> as long as we're both indeed talking about the "malformed file" message on boot.
<jtaylor> cyphermox: that patch fixed my malformed file issue
<jtaylor> I currently have trusty grub + this patch installed and it works fine
<cyphermox> yep
<cyphermox> well, it's in the queue.
<smb> slangasek, would the mentioned change by ok and/or are there further things you think should be changed?
<bipul> Where i can get the logs for ubuntu-devel channel?
<sarnold> bipul: http://irclogs.ubuntu.com/
<Unit193> !1984
<ubottu> Official channel logs can be found at http://irclogs.ubuntu.com/ . LoCo channels are now logged there too.
<Unit193> Bah.
<bipul> Unit193, I am new to this channel, and i wanted to learn how to fix bugs
<smoser> pitti, still around ?
<smoser> i'm seeing transient errors where iscsi root i do not get resolvconf updated
<smoser> in wily
<bipul>  bzr dh-make hello-2.7 hello-2.7.tar.gz
<bipul> bzr: ERROR: command 'dh-make' requires argument TARBALL
<bipul> What's wrong here? I was going through the guide, but unable to perform this part..
<brendand> bipul, Usage:   bzr dh-make PACKAGE_NAME VERSION TARBALL
<slangasek> seb128: bug #1439769> I had the impression somehow that Michael was still iterating; thanks for drawing my attention to it, I'll follow up
<ubottu> bug 1439769 in update-manager (Ubuntu Vivid) "various linux packages being marked as manually installed, still prevents 'apt-get autoremove' from doing the right thing for kernels" [Critical,Triaged] https://launchpad.net/bugs/1439769
<slangasek> smb: you want to either reproduce the license or point to /usr/share/common-licenses/BSD, not both
<slangasek> smb: I haven't made any progress yet on reviewing the rest of the packaging, sorry about that
<smb> slangasek, ok. in that case I probably go for the pointer (as that would look less bulky). If you manage to make progress and have additional questions/requests, maybe shoot me an email as that is more reliable. And then I try to add anything before re-uploading. Feel free to reject the current package when you are done.
<slangasek> smb: will do
<smb> slangasek, thanks
<infinity> chiluk: I generally do them.  But it's more than "just rebuild d-i", so I tend to just do the whole thing end-to-end when there's a need.
<infinity> chiluk: Was it -61 or -62 that has the change you need?
<infinity> chiluk: (Sorry for the late response, been sick all day)
<chiluk> infinity, -63 has the change we need..
<infinity> Err, 63... Yeah.  Not braining right now.
<chiluk> infinity, no worries man.. an upload for 3.13.0-65 is sitting in the trusty upload queue
<chiluk> infinity, I uploaded a debdiff for vivid to the bug..
<chiluk> I just based the vivid debdiff against latest in -updates, but iirc -23 was minimum necessary
<infinity> cyphermox: I'm going to reject that d-i in the trusty queue and do a more complete job.
<infinity> chiluk: So, this needs fixing in vivid too?  Mmkay.
<infinity> chiluk: Bug # again?
<chiluk> infinity, well vivid would be appropriate since that's how we usually fix stuff.
<infinity> chiluk: It's appropriate if people need the fix in vivid, yes. :P
<chiluk> infinity https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1481490
<ubottu> Launchpad bug 1481490 in debian-installer (Ubuntu Vivid) "Add sfc to nic-modules udeb" [Undecided,In progress]
<chiluk> infinity, yes people need it in vivid as well.
<infinity> chiluk: Closing the wily task, it should be fixed there already.  I'll bang out the other two, if you're willing to verify.
<chiluk> yeah I didn't open the wily task... you are probably correct
<chiluk> infinity, I am willing to verify, and I have a user that will verify as well.
<cyphermox> infinity : more complete job? What did I miss?
<infinity> cyphermox: All the other kernels.
<cyphermox> Yay
<chiluk> yeah I'm actually wondering about utopic as well because of hwe-u
<infinity> cyphermox: But also, d-i SRUs in LTSes are "special", in that you simultaenously break CD builds when you upload d-i, so there's some timing and fallout preparation. ;)
<infinity> chiluk: Did this fix go into lts-u?  It obviously went into lts-v if it went into v.
<cyphermox> infinity :good to know, we should discuss this more
<chiluk> infinity, checking
<cyphermox> infinity: oh, I see now, indeed, hwe- kernels :/
<infinity> cyphermox: And keystone.
<infinity> cyphermox: SO MANY KERNELS.
<chiluk> infinity, hmmm wasn't pushed into hwe-u..
<cyphermox> Zomg kernels
<chiluk> let's just stick with trusty, and vivid for now.
<infinity> cyphermox: Anyhow, my 'rgrep | xargs sed'-fu is muscle memory at this point, I'll just fix it up.  Unless you want the practice.
<cyphermox> I can practice next time. I get the idea
<infinity> chiluk: Well, we'll bump them all in d-i regardless, but you should get the fix committed to lts-u and let us know if you need another d-i $later.
 * cyphermox was going to script it for next time 
<infinity> chiluk: I don't do them for every kernel bump, but I do them when there's a good reason to be back in sync.
<chiluk> i'm not sure why ogasawara didn't drop it into lts-u... is there even a way to netboot using an lts-u kernel?
<chiluk> maybe that's why..
<infinity> cyphermox: update-kernel-version $old_abi $new_abi is almost as much typing as "rgrep -l $old_abi | xargs sed -i -e "s/$old_abi/$new_abi/g', which is why I never bothered scripting. :P
<chiluk> although I guess maas would get broken if you depended on the sfc module for your primary networking
<infinity> chiluk: Yes.
<infinity> chiluk: http://cdimage.ubuntu.com/netboot/trusty/
<cyphermox> infinity the goal would be to not pass an abi version if it can be determined otherwise
<chiluk> alright I'll harass the kernel  team for lts-u stuff.
<infinity> cyphermox: Trickier, since sometimes you want the updates kernel, sometimes the proposed kernel, but I guess you could pick a default and have an argument to switch.
<infinity> cyphermox: A better goal would, perhaps, be to determine kernel versions in debian/rules and not hardcode them at all.  Overridable, of course, when you want to explicitly build against something that's not $latest.
<cyphermox> Yeah
<infinity> cyphermox: But I'd rather not introduce more deltas like that until we can sit down and waste a few months of our sanity on merging with debian.
<cyphermox> Of course
<infinity> chiluk: Added a linux-lts-utopic task to the bug.  When we turn around the d-i fix, which will close the d-i/trusty bug, feel free to reopen the d-i/trusty task with a note that it needs re-fixing for lts-u, once that lands.
<chiluk> alright... I responded to the original kernel bug on the kernel-team mailing list.. I expect we'll be revisiting this in 4-6 weeks after it lands in a new kernel.
 * infinity nods.
<infinity> chiluk: We're at the beginning of an SRU cycle right now, you could probably talk bjf or henrix into slipping it in for you if you ask really nicely.
<infinity> bjf: ^
<infinity> ogra_: Does /lib/*/libname.so.6 not do the trick?
<ogra_> infinity, already found my fix http://paste.ubuntu.com/12613208/ ;)
<infinity> ogra_: Possible guarded with a [ -f ] if paranoid.
<ogra_> find ftw :)
<infinity> ogra_: S'pose that works too.  Curious why you need nsswitch in an initrd, but I suspect I don't want to know the answer. ;)
<ogra_> (no idea if it works yet, i havent tested it in an actual initrd ... but all files end up wheer they should during update-initramfs)
<ogra_> well, i need a working resolv.conf
<sarnold> infinity: iscsi or nfs root?
<ogra_> i doubt thats possible without a minimal nsswitch.conf
<infinity> sarnold: Those both clearly already work, so nope.
<ogra_> infinity, or would libresolv alone work ?
<infinity> ogra_: I'd have to refresh my memory on POSIX (and thus how libc has it split up), but I was fairly sure pure DNS (sans nsswitch) should Just Work with resolv.conf and libc.
<infinity> ogra_: You might be right about needing -lresolv, though.
<ogra_> yeah, I#ll do some real world tests tomorrow
<infinity> ogra_: But nsswitch should be unnecessary.
<ogra_> k
<infinity> ogra_: I could also be entirely wrong.  It's possible nsswitch has become so deeply embedded in the libc resolver that it breaks without it, but I'd actually consider that a bug if it's the case.
<infinity> (The sort of bug that might be unfixable, mind you)
<ogra_> well, stgraber suggested nss :)
<infinity> ogra_: Easy enough to experiment by unpacking your initrd, chrooting in, and deleting files until name resolution breaks. ;)
<ogra_> yeah
<tsimonq2> hello ogra_
<ogra_> hi
<tsimonq2> ogra_: How are you today?
<ogra_> super busy in #snappy :)
<tsimonq2> ogra_: What's new?
<mwenning> happy birthday kentb :-)
#ubuntu-devel 2015-09-30
<dholbach> good morning
<tsimonq2> o/
<doko> Riddell, sitter: fixing kdepim, updating symbols files
<smoser> pitti, did you see i opened and subscribed you to bug https://bugs.launchpad.net/ubuntu/+source/open-iscsi/+bug/1501033
<ubottu> Launchpad bug 1501033 in open-iscsi (Ubuntu) "transient error results in /etc/resolv.conf not populated in iscsi root" [High,Confirmed]
<mardy> seb128: hi! What is your opinion on bug 1453549? Shall we continue waiting for Yorba, or should we create a facebook key for Shotwell in Ubuntu and distro-patch?
<ubottu> bug 1453549 in shotwell (Ubuntu) "Cannot publish to Facebook" [High,Confirmed] https://launchpad.net/bugs/1453549
<seb128> mardy, hey, I mentioned it during the desktop team meeting yesterday
<seb128> willcooke, ^ opinion? I'm unsure you stated one yesterday
<willcooke> seb128, I didnt
<seb128> mardy, I think the consensus was to try to find somebody to get in touch with the unactive maintainers and talk to GNOME about taking over if needed and creating a new key
<seb128> if that fails then make our own
<seb128> mardy, k, I guess willcooke doesn't want to get involved in that and other felt like we should wait more on upstream/GNOME so I guess that's what we are doing...
<mardy> seb128: fine by me
<seb128> mardy, not so much by me, I'm going to wait another week and nag again, would be a shame to get wily out with that bug
<willcooke> seb128, mardy - sorry was otp and didn't read the log properly
<willcooke> Feels like if u/s is not going to get a new key etc arranged in short order then, as seb128 says, it would be bad to go out without that feature.  mardy, do we have a key from OA that we can use?
<mardy> willcooke: not really, I recently registered a key with the same permissions for our Facebook webapp, but it says "Ubuntu Web App"
<mardy> willcooke: we should register one specifically for shotwell
<willcooke> mardy, ack.  Can you remember the process of registering one, and who keeps the credentials and all that sort of thing?
<mardy> willcooke: but if the hidden question is whether I can register a Facebook key for shotwell, then the answer is yes :-)
<mardy> willcooke: the simplest thing is if I register the key myself, and then transfer it to IS
<willcooke> thanks mardy!  I don't think there is any problem with going ahead and registering a key anyway and then if something changes in the next few days we can simply not use it.  seb128 what do you think?>
<mardy> willcooke, seb128: the best scenario would be is Yorba can add me as an admin for their key, so I update it as needed, and then they can remove me when done
<mardy> s/is/if/
<seb128> mardy, did you try to email them directly about that? maybe they would say yes
<mardy> seb128: no, I didn't
<seb128> can you try that?
<mardy> seb128: sure
<seb128> thanks
<mardy> seb128: I wrote to Jim Nelson, let's see
<seb128> mardy, thanks
<seb128> Laney, larsu, ^
<larsu> \o/
<larsu> thanks
<Laney> nice
<kenvandine> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Archive: feature freeze, user interface freeze, final beta freeze | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-vivid | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<kenvandine> whoops :)
<arges> cyphermox: bug 1486931, i'm not completely clear where that patch comes from. Can you make the patch match the upstream commits?
<ubottu> bug 1486931 in ipmitool (Ubuntu Trusty) "[LTCTest][Opal][OP810] ipmitool 1.8.13-1ubuntu0.3 version is still not working for in-band HPM upgrade" [High,In progress] https://launchpad.net/bugs/1486931
<cyphermox> not really
<cyphermox> it's been ported for us from later commits by an upstream developer.
<cyphermox> (comment 5 points out it's from David Wise, he posted it at https://bugs.launchpad.net/ubuntu/+source/ipmitool/+bug/1481780/comments/16)
<ubottu> Launchpad bug 1481780 in ipmitool (Ubuntu Vivid) "ipmitool 1.8.13 needs 2 patches for OpenPower systems" [High,Fix released]
<arges> cyphermox: so the existing patch only had some features? and why wasn't it added as a new patch?
<cyphermox> the previous patch was incomplete in some way. it was missing integration in some other features of ipmitool
<cyphermox> arges: I'm mostly sponsoring this fix for someone else; leitao would know much more about it than I would
<arges> cyphermox: ok. I'll look into it more, and ask questions on the bug if necessary
<cyphermox> arges: alright
<cyphermox> sorry I couldn't be more helpful outright
<arges> cyphermox: its always nice to know where a patch comes from , is it upstream, and if it matches what upstream actually committed etc
<arges> and in this case it wasn't readily obvious, so I'll keep digging
<arges> thanks
<cyphermox> for that, like I said David Wise is an upstream ipmitool developer working for AMI AIUI
<arges> ok makes sense
<cyphermox> I agree perhaps we should list the specific commits this matches
<cyphermox> (but I have no idea which those are)
<arges> yea if i can't find it in 5-10m, i'll just ask on the bug
<cyphermox> ack
<Riddell> pitti: kdeplasma-addons false regression? http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#sonnet
<pitti> Riddell: thanks, will fix
 * arges thanks autoconf for making debdiffs easy to read
<doko> arges, use dh-autoreconf ;p
<arges> doko: unfortunately, I'm reviewing others packages so I don't have control of it
<juliank> arges: you can still encourage it :)
<doko> cjwatson, cyphermox:  o biosdevname: biosdevname-udeb  ... wants to demote. is this ok?
<doko> same for o grub-efi-arm64-signed                                        {grub2-signed}
<pitti> doko: biosdevname demote is okay (I was talking to cyphermox about it)
<pitti> I don't know about grub-efi-arm64-signed
<smb> pitti, can I distract you with an adt question... well I guess I can with the distract part... https://launchpad.net/ubuntu/+source/dahdi-linux/1:2.5.0.1+dfsg-1ubuntu4~14.04.3/+build/7933332/+files/dahdi-linux_2.5.0.1%2Bdfsg-1ubuntu4%7E14.04.3_all.deb
<smb> pitti, Somehow that dkms build is failing but any local run I do is working ok... I wondered whether that testbed could be running somewhere which has external downloads blocked
<smb> Weirdly the build that behaves the same for wily does work, which is a bit odd
<smb> slangasek, and while in whine mode... any luck I may have with dpdk progressing?
<pitti> smb: your URL was for a .deb -- you mean http://autopkgtest.ubuntu.com/packages/d/dahdi-linux/ on trusty?
<smb> pitti, yes the pure trusty run, vivid on trusty would be broken for different reasons right now
<jtaylor> does -fno-stack-smashing not work in 15.10?
<jtaylor> I compiled with that flag but the program still aborts with stack smashed ...
<jtaylor> no-stack-protector I mean
<smb> pitti, Unfortunately the whole package is a bit nasty since the dkms build wgets some firmware on build time. But since it was working for wily I assumed it should be ok for adt testing in trusty, too
<tdaitx> sil2100, are you working on squid3? I have the required patches for building it against libecap2, but I need to transition libecap2
<tdaitx> you cant build squid using libecap3 because we are still running squid 3.3
<sil2100> tdaitx: hey! I could work on that if I'm not getting in your way ;) I just think we can't leave it build-depping on libecap2
<sil2100> tdaitx: I would just like to investigate how much effort would be needed to get it working with libecap3 - if too much, then the only option I see is to pull in the latest squid3 from debian
<sil2100> But as I said, I might be wrong with my reasoning
<tdaitx> sil2100, http://wiki.squid-cache.org/Features/eCAP#line-54
<tdaitx> ops, wrong page
<smb> pitti, anyhow, not super urgent and your day is running as late as mine. :) I am just puzzled why this failed and you got a bit more insight in the physical layout of the testbeds. I would not rule out that both (w and t) runs may have ended up on different hosts with different fw rules in place...
<pitti> smb: sorry, sprint..
<smb> pitti, even worse...
<smb> arges, btw, I pushed the copyright file change up to the git repo, so just in case we get an ok for the rest, you could rebundle the package after pulling from there
<arges> smb: so does that need to get re-sponsored?
<pitti> smb: it fails for me locally as well
<smb> arges, yes but there might also be further changes I do not know of yet
<pitti> smb: but my output is different from https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-trusty/trusty/amd64/d/dahdi-linux/20150923_172802@/log.gz
<smb> pitti, huh... I just did an adt-run and in a vm and both worked
<pitti> adt-run dahdi-linux --- qemu /srv/vm/adt-trusty-amd64-cloud.img
<pitti> smb: is what I ran
<tdaitx> sil2100, found it: http://wiki.squid-cache.org/ConfigExamples/ContentAdaptation/eCAP#Build_eCAP_library
<smb> pitti, if proposed is not enabled it would fail I believe because the status is not without warnings
<smb> pitti, actually arges may just have released the version where I added proper dep-8 code to the updates
<tdaitx> sil2100, maybe you can help me figure out one vtable symbol that is missing from libecap2
<sil2100> tdaitx: ok, so it seems there's more changes required - so I think we need to pull in the latest squid3 version from debian then
<arges> smb: i have not yet
<pitti> smb: ah, I didn't run against -proposed, let me retry
<sil2100> tdaitx: otherwise libecap3 will be forever blocked in -proposed
<tdaitx> sil2100, rbasak was working on that
<smb> arges, yes sorry that was dkms itself which I saw
<pitti> smb: indeed, passes in -proposed
<smb> pitti, ah cool. Som my "plan" right now would be to ask arges to let that version out into the wilds so we can follow up with fixes to handle the vivid lts kernel and try to figure out the odd failure somewhat while that is still waiting in proposed
<pitti> smb: but then it shold have succeeded on the production infrastructure too
<pitti> smb: let's investigate this another time, dinner o'clock..
<smb> pitti, well if that production environment allows external downloads
<smb> but ok dinner o'clock indeed
<pitti> smb: it does, but through a proxy
<pitti> smb: so if the download thingy doesn't respect $http_proxy â lose
<doko> seb128, Laney: could you tell SweetShark that he has to subscribe the release team to his FFE reports?
<rcj> infinity, Can you take a look tzdata/pytz issue we have on trusty -> wily... http://pad.lv/1501456
<ubottu> Launchpad bug 1501456 in tzdata (Ubuntu) "pytz.country_names UnicodeDecodeError exception" [Undecided,New]
<rcj> infinity, it has been silently (our fault) breaking simplestreams image indexing since tzdata version 2015f-0ubuntu0.14.04 (mid-aug)
<Shock> Hello folks. I'm seeing some weirdness with ubuntu updates: I got a warning that I'm installing unsigned packages even though that shouldn't have been the case. I managed to get rid of the error by deleting and re-adding it to software sources,.
<Shock> Is it possible that the ppa key was changed?
<Shock> I got a bit spooked after reading this: https://answers.microsoft.com/en-us/windows/forum/windows_7-update/windows-7-update-appears-to-be-compromised/e96a0834-a9e9-4f03-a187-bef8ee62725e
<mdeslaur> Shock: you probably just needed to refresh your sources list with "apt-get update"
<Shock> mdeslaur: did that
<Shock> several times
<mdeslaur> Shock: hrm, not sure then. perhaps your key went missing
<Shock> mdeslaur: why would it tell me that I'm installing unsigned packages since the packages in the ppa are signed?
<mdeslaur> Shock: because the key was no longer present in your apt keychain for some reason?
<mdeslaur> how did you put the ppa back? manually or with apt-add-repository?
<Shock> mdeslaur: software-sources-gtk
<mdeslaur> Shock: ok, so that reinstalled the key from the ppa
<mdeslaur> well, the ppa key from the keyserver rather
<Shock> mdeslaur: I assume so, but that weirds me out because the ppa has been on my system for a while
<Shock> mdeslaur: and I can see no reason for the key to go missing
<mdeslaur> sorry, I can't either
<Shock> mdeslaur: I also got 404s from two mirrors when doing apt-get update
<infinity> rcj: Oh, fun.
<TJ-> Shock: I often witness that when the package list is out of date, and doing "apt-get update" usually solves it.
<infinity> rcj: The most "correct" answer would probably be to make wily's pytz assume utf-8, and hack backports of tzdata to force the file back to ascii.  Maybe.
<Shock> TJ-: thanks
<infinity> rcj: I consider it broken by design that the file was ever ascii, and extra special that pytz cares, but I suppose we should shoot for maximum compat.
<TJ-> Shock: mirror 404s sometimes happen when there's an archive update in progress, and other times when there's a HTTP proxy in the loop
<infinity> rcj: But I'm actually asleep right now, so I'll form a better opinion on it $later.
<rcj> infinity, okay.  Thanks for the quick look.  I'll defer to $later
<sarnold> Shock: the PPA page on launchpad should have a "technical details about this PPA" drop-down triangle thing that shows the signing key, when you click on the keyid it shows details about when that key was generated
<Shock> sarnold: generated in 2009
<sarnold> Shock: hunh. that's not what I expected. :)
<Shock> sarnold: call me paranoid but I think the "easy" way to compromise a linux system is via a mitm attack on the update system
<sarnold> Shock: I think most common is still people using guessable passwords and allowing ssh to use passwords like it's 1994 :)
<sarnold> Shock: but you're right, it's an easy invitation for code to be downloaded and run..
<TJ-> Shock: how would a MITM attack work?
<mdeslaur> Shock: you can't, packages are cryptographically signed
<mdeslaur> unless you accept to install packages that aren't, but the graphical tools won't allow that
<sarnold> TJ-: the "best" that I think a MITM could do against a PPA is to return old package lists to apt-get update requests to prevent or delay the clients from finding updated packages.
<sarnold> TJ-: I honestly don't know if apt will eventually complain "these package lists are two months old" or ont
<TJ-> sarnold: Yes, I've been wishing for a while all the archive servers use HTTPS, even if mirrors won't/don't. It'd also help minimise the captive-portal/proxy issues
<cjwatson> sarnold,TJ-: https://bugs.launchpad.net/launchpad/+bug/716535
<ubottu> Launchpad bug 716535 in Launchpad itself "Please support Valid-Until in release files for security.ubuntu.com" [Low,Triaged]
<cjwatson> (the thing that needs thought there is that we don't currently republish Release files for stable releases at all, so we need to do something non-trivial about that)
<TJ-> cjwatson: looking at the dates in that report it'd be faster to switch to HTTPS :)
<sarnold> cjwatson: heh, there's always something, isn't there? :)
<cjwatson> TJ-: My understanding is that that would be pretty expensive.
<cjwatson> (Though my understanding is perhaps a couple of years old)
<TJ-> cjwatson: really? in what way? Most organisations that have evaluated it have found that the perceived additional CPU costs are actually relatively small
<cjwatson> TJ-: I'm only going on sysadmin estimates from a while back
<TJ-> I do wonder if the HTTP Headers could be used for the Valid-Until part
<sarnold> TJ-: iff you use https, sure
<TJ-> sarnold: it can be done with HTTP if there's a signature header too
<sarnold> TJ-: wouldn't that require more work server-side? i think those are currently apache boxes behind squids
<TJ-> sarnold: precisely; any solution requires some work somewhere.
<sarnold> true :)
<mdeslaur> cjwatson: the Valid-Until headers are problematic if all you need to do is send files from an earlier ubuntu release, no?
<mdeslaur> and I assume the issue with mirrors is certs, not the extra cpu cost
<elmo> the idea that SSL is "cheap" or even "free" from a CPU perspective is deeply flawed
<elmo> for a site like security.u.c, it would absolutely not work with the current hardware allocation and the cost to beef it up to where it would need to be is significant
<cjwatson> mdeslaur: apt checks Codename (or similar) and will complain if it doesn't match what it expects; the send-files-from-earlier-release attack doesn't work
<mdeslaur> cjwatson: oh! interesting, thanks
<cjwatson> mdeslaur: I ran into this experimentally recently when testing InRelease support :-)
<cjwatson> mdeslaur: Hm, or I may be misremembering what it did.  I should probably recheck before making grand claims
<mdeslaur> cjwatson: I seem to recall this being the issue every time I've discussed it with infinity
<mdeslaur> but I've been known to misremember stuff :P
<tdaitx> slangasek, infinity: I need a hand to figure out what to do with a missing vtable symbol in libecap2 (I'm working on its gcc5 transition), so far I haven't been able to find good documentation on how to decide whether this is ok or why it is now missing
<doko> robert_ancell, just the ppc64el ftbfs left ;)
<doko> tdaitx, please could you paste the issue?
<tdaitx> doko, line 48-49 http://paste.ubuntu.com/12627595/
<doko> tdaitx, libecap already had a soname transition upstream, and none of the rdepends were able to build
<doko> just delete the symbol
<doko> and make sure that the rdepends build
<tdaitx> ok
<tdaitx> doko, thanks
<doko> np
<doko> just CC me, highlight issues like these please
#ubuntu-devel 2015-10-01
<robert_ancell> doko, yeah, I think I have a solution for that, was just waiting to see if upstream agreed http://lists.x.org/archives/xorg-devel/2015-September/047504.html
<FourDollars> Who can help me to change the bugs status of https://bugs.launchpad.net/ubuntu/+source/modemmanager/+bug/1441095? Changing "Trusty" of "network-manager (Ubuntu)" to "In Progress".
<ubottu> Launchpad bug 1441095 in libmbim (Ubuntu Trusty) "novatel: improve probing for Dell branded modems" [High,In progress]
<TJ-> From Fix Released to In Progress ?
<FourDollars> Yes
<FourDollars> Because it is not fixed.
<TJ-> Done
<FourDollars> Can we still fix the bug for wily now?
<FourDollars> TJ-: Thx.
<FourDollars> I have a patch for libmbim (Ubuntu) wily. It is reviewed and approved but still no "Fix-Commited" for wily.
<FourDollars> s/Commited/Committed/
<TJ-> I think you need to ping one of the core devs responsible for getting it out. I suppose beta freeze might be affecting things
<FourDollars> OK.
<pitti> Good morning
<FourDollars> Good morning
<FourDollars> Could you help me to change the bug status of modemmanager (Ubuntu) Trusty of https://bugs.launchpad.net/ubuntu/+source/modemmanager/+bug/1441095 from "	
<FourDollars> Fix Released" to "In Progress"?
<ubottu> Launchpad bug 1441095 in network-manager (Ubuntu Trusty) "novatel: improve probing for Dell branded modems" [High,In progress]
<seb128> FourDollars, done
<FourDollars> seb128: Thx
<seb128> yw
<FourDollars> seb128: There is still no bzr branch for trusty on https://code.launchpad.net/network-manager so I am going to attach the debdiif on https://bugs.launchpad.net/ubuntu/+source/modemmanager/+bug/1441095.
<ubottu> Launchpad bug 1441095 in network-manager (Ubuntu Trusty) "novatel: improve probing for Dell branded modems" [High,In progress]
<seb128> FourDollars, that makes sense
<FourDollars> seb128: Could you help to release the libmbim for wily?
<seb128> FourDollars, oh right, let me have a look
<FourDollars> seb128: thx
<seb128> yw!
<FourDollars> seb128: Could you also help to review other patches for trusty?
<seb128> FourDollars, depending on which components?
<FourDollars> seb128: libmbim, network-manager and modemmanager.
<seb128> FourDollars, n-m/modemmanager you probably want cyphermox
<FourDollars> seb128: https://code.launchpad.net/~fourdollars/ubuntu/trusty/libmbim/1441095/+merge/273015, https://bugs.launchpad.net/ubuntu/+source/modemmanager/+bug/1441095/comments/56 and https://code.launchpad.net/~binli/ubuntu/trusty/modemmanager/lp1441095/+merge/272054.
<ubottu> Launchpad bug 1441095 in network-manager (Ubuntu Trusty) "novatel: improve probing for Dell branded modems" [High,In progress]
<FourDollars> seb128: OK
<FourDollars> seb128: I think the trusty patches of libmbim and network-manager are pretty simple.
<doko> mvo, https://launchpad.net/ubuntu/+source/ubuntu-snappy/1.6ubuntu1
<doko> jamespage, designate (1:1.0.0~b3-0ubuntu1 to 1:1.0.0~rc1-0ubuntu1)
<doko> Maintainer: Ubuntu Developers
<doko> Section: universe/misc
<doko> 2 days old
<doko> python-designate/amd64 unsatisfiable Depends: python-dnspython3 (>= 1.12.0)
<doko> Not considered
<jamespage> doko, urgh - ok lemme fix that up
<jamespage> I thought I already did
<doko>  python-dnspython3 isn't packaged
<jamespage> doko, yes and its for py3 only
<jamespage> doko, the dependency generation script we use needs a tweak
<jamespage> doko, coreycb already fixed that but needed me to sponsor (I forgot)
<doko> willcooke, Laney: I rejected the libreoffice upload, because it discards the changes made in 1:5.0.1-0ubuntu2. There is also no FFE accepted yet. LP: #1495512 is filed, but doesn't have any subscriber
<ubottu> Launchpad bug 1495512 in libreoffice (Ubuntu) "[FFE] LibreOffice 5.0.2" [High,Triaged] https://launchpad.net/bugs/1495512
<Laney> doko: that upload says it is a bugfix release
<Laney> s/upload/bug/
<doko> Laney, then why file a FFE? ;p
<pitti> coreycb: FYI, http://autopkgtest.ubuntu.com/packages/c/ceilometer/wily/amd64/ regressed, so it's stuck in -proposed
<Laney> don't ask me, but it's not relevant as a reject reason
<doko> I gave the reason
<Laney> maybe the other part still stands :)
<pitti> seb128: aptdaemon regressed, it
<pitti> seb128: 's stuck in -proposed, FYI
<seb128> pitti, ?
<pitti> http://autopkgtest.ubuntu.com/packages/a/aptdaemon/wily/amd64/
<seb128> pitti, the uploda that changed a one line to the lintian profile?
<seb128> that seems buggy to me
<pitti> nose.proxy.AssertionError: 'binary-file-compressed-with-upx' not found in 'Lintian check results for /t
<Laney>     self.assertIn("binary-file-compressed-with-upx", trans.error.details)
<Laney> ha
<pitti> seb128: the failed test case does sound related to a lintian change, yes
<seb128> that test was removed from lintian
<seb128> not an aptdaemon issue...
<pitti> ah, so do we need to drop that check from aptdaemon then?
<seb128> urg
<Laney> you need to fix aptdaemon's test yeah
<pitti> did we get a new lintian yesterday? aptdeamon succeeded on Sep 29, and failed yesterday
<seb128> yeah, it seems like a forgot a line
<Laney> assumedly to exhibit a different lintian error so the test still does something
<seb128> pitti, no, but aptdaemon's profile included that test which was not in lintian anymore
<pitti> err no, lintian changed on Aug 17
<seb128> and that lead software-center to claim packages were bad quality
<seb128> let me do another aptdaemon upload to drop the test as well
<pitti> seb128: ah, so the patch dropped it from the aptdaemon code but not its tests?
<pitti> seb128: cool, thanks
<seb128> right
<seb128> local build worked
<seb128> I guess those tests are not done on build
<pitti> seb128: I thought aptdaemon would run its tests during package build too
<pitti> weird
<Laney> seb128: it would be better to change the test to use a different tag instead of dropping it
<Laney> it does check something useful
<seb128> Laney, please do the change if you have an idea how to do it :-)
<Laney> look at one of the tags we are still erroring on and make a deb which has that
<seb128> k, adding to my todo
<seb128> I've 3 or 4 things ongoing though
<seb128> so likely for later this afternoon
<Laney> up to you, but I think it makes sense
<Laney> :)
<seb128> shrug, I wish the new glib would hit wily
<seb128> gedit segfault 3 of 4 timesz
<seb128> that drives me mad
<Laney> already looking
<seb128> thanks
<seb128> pitti, thanks for pointing out the aptdaemon test issue!
<Laney> bleh, we forgot to upload dbus-test-runner
<pitti> seb128: no worries -- emulating the still missing email notifications :)
<Laney> the personal touch is a nice one :P
<pitti> Laney: *puts a cherry on top*
<pitti> seb128: that's colord and dbus-test-runner/ppc64el only, right?
<Laney> I retried those
<seb128> pitti, was that meant for Laney? I'm not aware of those...
<pitti> seb128: I meant what's holding up glib2.0, looking
<seb128> oh ok, Laney is on it
<seb128> FourDollars, libmbim uploaded to wily/trusty
<pitti> dbus-test-runner seems very unstable on ppc, I'll fudge that
<Laney> pitti: retried it already, let's see
<Laney> I pinged ted_g in another channel to review it too
<Laney> (larsu made a fix)
<seb128> cyphermox, hey, could you have a look to bug #1448879 seems like you discarded a patch when syncing the new version
<ubottu> bug 1448879 in network-manager-strongswan (Ubuntu) "[regression] network-manager-strongswan configuration GUI broken" [Undecided,New] https://launchpad.net/bugs/1448879
<FourDollars> seb128: Cool~ Thx a lot. :D
<seb128> FourDollars, yw!
<Laney> pitti: passed that time
<pitti> Laney: ah, your lucky day!
<Laney> is Ted at this sprint you are at? ;-)
<pitti> Laney: do you mean me? no
<Laney> pitti: yeah - oh well
 * Laney is using running.html
<larsu> Laney: just merge it! :P
<Laney> tempted
<larsu> it's been long enough
 * larsu is annoyed by long review times
 * pitti fixes the bug that some armhf results are eternally "in progress" -- go time zones
<Laney> uh?
<pitti> Laney: http://autopkgtest.ubuntu.com/packages/o/oss4/wily/armhf/
<pitti> Laney: look at the two topmost results -- the second one is newer than the first, but it wasn't considered
<pitti> one of the workers was in PDT, and the others in UTC
<pitti> I set it to UTC, but I also just pushed a worker fix to make the swift timestamps UTC
<pitti> so that worker time zones stop mattering
<Laney> ah, and it was storing just a bare time
<Laney> nice
<doko> coreycb, jamespage: looking at the ryu MIR ... may I ask to package python3-ryu as well, and to use python3 in ryu-bin?
<Laney> rbasak: Hey, noticed that mariadb-10.0 is wily < vivid-security
<Laney> ok to copy it up?
<Laney> tseliot: this ^ situation applies to nvidia-346 too
<dholbach> Laney, is the ubuntu-wallpapers upload good to go?
<dholbach> Laney, if yes, do you think you could upload it? I have a bit of a bad connection here
<Laney> OK
<Laney> thanks
<smb> pitti, Hi! To get back to the discussion we had yesterday (if sprint allows), the build of dahdi-dkms would use plain wget for downloads which should honor http[s]_proxy if set. I do not see a real change between the trusty and wily package in that area. Now the details of the failure would be in the dkms log which I have no idea how to get from an environment that fails...
<tseliot> Laney: what situation?
<Laney> tseliot: vivid > wily
<tseliot> Laney: there's no nvidia-346 in wily, we have 352
<Laney> tseliot: it's still in the archive
<tseliot> Laney: yes, but it should be a transitional package provided by 352
<Laney> so the old source packages should be removed?
<tseliot> Laney: yep
<ricotz> hello :)
<Laney> tseliot: any chance you could file that? :)
<tseliot> Laney: doesn't that happen automatically after a while?
<Laney> don't think so
<Laney> unless there's something I don't know
<ricotz> is someone hit by some intltool/gettext failures on armhf builds recently? (qemu crashing while checking for it) happens for vivid and wily builds
<tseliot> Laney: ok, I can file that request
<Laney> thanks
<pitti> smb: hm, don't we export the dkms log as an artifact? if not, we really should
<cjwatson> ricotz: qemu-user-static fails on lots and lots and lots of things
<pitti> smb: bah, seems we really don't
<cjwatson> we're lucky it ever works
<ricotz> cjwatson, I see, so if I retry it it might work at some point?
<ricotz> cjwatson, although it seems pretty consistent and fails all the time afaics
<smb> pitti, that log only exists for dkms builds obviously and in a bit of a complicated path. I guess its hard to squeeze those smarts into a generic thing
<ricotz> cjwatson, just for reference https://launchpad.net/~ricotz/+archive/ubuntu/docky/+build/7992439
<cjwatson> ricotz: well no, I'm saying that if qemu can't do it you may have to give up
<cjwatson> there's a swathe of stuff it just can't manage
<pitti> smb: oh wait -- our generic DKMS runner actually does export the logs, like in e. g. https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-wily/wily/i386/b/bcmwl/20150930_180209@/artifacts.tar.gz
<ricotz> cjwatson, precise and trusty builds works (exactly same source packages)
<cjwatson> ricotz: there may be differences in which syscalls it happens to tickle
<cjwatson> ricotz: or use of threading
<pitti> smb: dahdi-linux has its own debian/tests/, so it's not using the synthesized dkms tests
<cjwatson> ricotz: hopefully we'll have a better system for virtualised armhf builds in a few months
<ricotz> cjwatson, ok, this kind of autotools check isn't that uncommon since it is quite the default and probably hit a lot of other packages too
<jamespage> doko, looking now
<cjwatson> ricotz: *shrug* I'm sorry it's not something we can fix
<cjwatson> ricotz: other than by replacing the existing system relying on qemu-user-static
<ricotz> cjwatson, alright :\, thanks
<cjwatson> ricotz: in some specific cases it *may* be possible to reproduce them locally and pare it down to a test case that could be sent to qemu upstream - but a lot of these come down to "qemu-user-static can't reliably support threaded code", and even for those that don't it's an awful lot of effort
<ricotz> cjwatson, I see
<cjwatson> ricotz: but we have arm64 hardware in place which will be used to build a replacement for the qemu-based builds - once the team working on it is done with building the cloud for power builds, I believe arm is next
<pitti> smb: running dahdi-linux/trusty manually now, then I can ssh in and do stuff for you
<smb> pitti, ah thanks. trying to look at the artifacts you mentioned but getting distracted by brother asking for ubuntu support... :-P
<smb> oh wait missed that was for a different package
<jamespage> doko, urg - no python3-formencode
<pitti> Laney: glib> I filed bug 1501697 to keep track of this
<ubottu> bug 1501697 in Auto Package Testing "britney: don't re-run passed results" [Medium,Triaged] https://launchpad.net/bugs/1501697
<pitti> Laney: i. e. glib is now held because we got a new unity8; that shouldn't re-run already succeeded tests
<pitti> (just FYI)
<pitti> smb: I'm now in a shell with the failed test
<pitti> smb: make.log actually looks fine
<smb> pitti, ok, so can you easily see in the mentioned dkms log whether it is ... oh
<pitti> $ dkms status
<seb128> Laney, pitti, ok, aptdaemon fix uploaded, it was easy, barry added  a patch to the package this cycle that was not needed/wrong with the lintian changes, dropping it and going back to upstream code makes things work
<pitti> dahdi, 2.5.0.1+dfsg-1ubuntu4~14.04.3: added
<pitti> seb128: yay
<pitti> smb: but "added" isn't enough, is it? it shold be "installed" or so
<Laney> pitti: thanks!; seb128: nice!
<smb> pitti, added in that case is bad it should be installed
<smb> pitti, yes
<pitti> find /lib/modules -name '*dadhi*'
<pitti> smb: nothing ^
<pitti> Error!  Build of dahdi_vpmadt032_loader.ko failed for: 3.13.0-65-generic (x86_64)
<smb> pitti, there should be that log file under /usr/src/... that got mentioned.
<pitti> smb: that's on stderr ^ so perhaps another log or so?
<pitti> smb: mentioned where?
<Laney> ah, that reminds me
<smb> pitti, normally in the build error ... though not /usr/src it seems ... /var/lib/dkms/dahdi/2.5.0.1+dfsg-1ubuntu4~14.04.3/build/make.log for some example
<smb> pitti, version numbers may vary of course
<pitti> smb: yes, that's what the stdout says; but tat make.log looks okay
<pitti> smb: ah, no!
<pitti> onnecting to downloads.digium.com (downloads.digium.com)|2001:470:e0d4::ee|:80... failed: Network is unreachable.
<pitti> http://downloads.digium.com/pub/telephony/firmware/releases/dahdi-fwload-vpmadt032-1.25.0.tar.gz
<pitti> smb: wget'ing this file works fine
 * smb wibbles
<pitti> smb: maybe the dkms env gets cleaned so that it doesn't see $http_proxy any more?
<doko> jamespage, well, no surprise for a 2012 package ... but there is https://pypi.python.org/pypi/FormEncode/1.3.0
<pitti> smb: and that got fixed in wily or so?
<smb> pitti, hm... maybe but why not also when it does the wily build
<smb> oh... so dkms
<pitti> smb: /me diffs trusty vs. wily dkms
<smb> pitti, maaaybe ... that would be evil indeed...
<jamespage> doko, yeah - I'm just concerned this will snowball in impact
<jamespage> formencode has a few reverse-depends
<pitti> smb: hm no, there's nothing relevant at all
<pitti> smb: so maybe in dahdi-linux itself
<jamespage> doko, I'll commit my team to the work, but can we defer for wily and do in +1?
<smb> pitti, i try to get that checked
<pitti> smb: I checked ./drivers/dahdi/firmware/Makefile and I can't immediately see a difference either
<doko> jamespage, sure
<smb> pitti, yeah... unlikely the makefile... wonder about the dkms.conf maybe ...
<pitti> smb: no relevant diff
<pitti> smb: is that actually blocking stuff, or more like "I like green"?
<pitti> smb: (it's
<pitti> "always failed", thus sholdn't block stuff?)
 * pitti runs "$ sudo dkms build dahdi/2.5.0.1+dfsg-1ubuntu4~14.04.3
<smb> pitti, kinda. the current upload basically adds dep-8 because I thought its now working and so we can see when we break stuff with hwe kernels
<pitti> smb: I'm heading for lunch, but I let the instance run for a bit
<pitti> smb: if you can think of anything else which you'd like me to try there
<smb> pitti, ok... reminds me to get food as well
<dupondje> where is that cyphermox hiding :)
<seb128> dupondje, likely in his bed, it's only 7am where he lives
<TJ-> Is there a more appropriate channel for dealing with modification of the ISO images?
<pitti> seb128: ah, glib2.0 is in
<pitti> smb: I found a difference
<pitti> smb: in the shell that I get on trusty there are no $*_proxy, but in the wily shell there are
<smb> pitti, sorry otp kinda get back in a bit
<pitti> smb: I'm not done debugging yet, I just excluded dkms and dahdi-linux themselves
<pitti> smb: !
<pitti> smb: the difference is that "sudo -i" uses /etc/environment in wily, but not trusty
<smb> pitti, doh!
<pitti> smb: the testbed has the proxy in /etc/environment, but the vars are unset for root
<pitti> smb: so apparently we changed pam_environment somehow
<pitti> smb: /etc/pam.d/sudo looks identical, though
<dholbach> Laney, thanks for sponsoring
<Laney> dholbach: might be 0.001% of the number of sponsorings you did for me back in the day :)
<Mirv> Laney: not sure if you noticed, but you uploaded "vivid-security" mariadb-10.0 to wily https://lists.canonical.com/archives/wily-changes/2015-October/011123.html
<Laney> Mirv: I copied it
<Mirv> ok then
<smb> pitti, Ok, now back. Sorry I was quite distracted. So maybe it sounds like one option may be to enhance the dkms part of dahdi with sourcing in /etc/environment before the build just in case for the the Trusty part. That should not hurt for "normal" builds outside the adt case either
<seb128> pitti, re glib, great ;-)
<pitti> smb: I was trying to move the env vars to /etc/profile as I source that in the test runner, but it still doesn't work
<smb> pitti, Ah ... ok. Darn.
<pitti> smb: so, I have a feeling that this is solvable somehow, I just don't have enough quiet time here to figure that out
<smb> pitti, Yeah, we could ... erm you and me trying to help, work on this another day/week.
<smb> pitti, The only thing I would avoid this to block is letting the added dep-8 testing upload out of proposed. Because the one that is pending after that would fix some build failure
<pitti> smb: sorry, parse error; you want to release http://people.canonical.com/~ubuntu-archive/proposed-migration/trusty/update_excuses.html#dahdi-linux or not release it?
<smb> pitti, maybe I should switch to German :-P I would release it.
<smb> pitti, I got another upload (not uploaded yet) pending sponsorship when the current one is done
<pitti> smb: can do, it's verified and 7 days
<pitti> smb: released
<smb> pitti, thanks a lot. I'll hassle me favourite sponsor about the follow up :)
<cyphermox> dupondje: hey
<doko> tdaitx, did you intend to keep the old libecap?
<tdaitx> doko, squid 3.3 and 3.4 require libecap 0.20 (libecap2), only squid 3.5 can use libecap 1.0 (libecap3)
<dupondje> cyphermox: hi, did you see my pm? :)
<dupondje> cyphermox: https://bugs.launchpad.net/ubuntu/+source/network-manager-strongswan/+bug/1448879
<ubottu> Launchpad bug 1448879 in network-manager-strongswan (Ubuntu) "[regression] network-manager-strongswan configuration GUI broken" [Undecided,New]
<doko> tdaitx, understood, so you want to remove the libecap in -proposed?
<doko> and not merge squid?
<tdaitx> doko, I agree that merging squid would be preferred, but when I started I was just trying to get the existing one to build, rbasak was working on the merge
<tdaitx> since we don't have the merge yet I decided to finish and post my patches just in case
<doko> ahh, ok, so lets wait
<doko> pitti, could it be that the autopkg tests don't uses parallel builds?
<seb128> dholbach, Laney
<seb128> +Package: ubuntu-wallpapers-wily
<seb128> +Description: Ubuntu 15.04 Wallpapers
<seb128> that should be 15.10
<seb128> bdmurray, pitti, what's the standard way to propose a change against the apport ubuntu packaging vcs? I would like to get review for http://paste.ubuntu.com/12631780/
<pitti> doko: if this requires anything else than "dpkg-buildpackage -us -uc -b", then no; that's just what I'm calling
<pitti> doko: do we need to call it with -j<numcpu>?
<pitti> seb128: Vcs-Bzr: is up to date, so if you want do an MP or just commit (it
<pitti> seb128: 's ~ubuntu-core-dev)
<seb128> pitti, yeah, I've the right vcs, I just didn't figure out where to push
<seb128> usually I push to ~user/project/somebranche
<pitti> seb128: ah, is UbiquitySyslog a str, not a bytearray?
<seb128> pitti, correct
<pitti> seb128: you can use ~seb128/ubuntu/wily/apport/fix-foo
<seb128> k
<seb128> ubuntu/wily/source was the bit I was missing
<pitti> seb128: ah, I see - I think this does some opportunistic decoding when reading a report
<seb128> I knew if was something like that
<seb128> pitti, btw aptdaemon just migrated to wily ;-)
<pitti> seb128: trÃ¨s bien !
<seb128> bdmurray, pitti, k, https://code.launchpad.net/~seb128/ubuntu/wily/apport/str_no_decoding/+merge/273075 for review
<seb128> hum
<seb128> https://code.launchpad.net/~seb128/ubuntu/wily/apport/str_no_decoding/+merge/273076 rather
<pitti> seb128: looks like you branched off trunk, not the wily VCS?
<seb128> pitti, no, it's just the launchpad ui that picked lp:ubuntu/apport as default
<pitti> seb128: ah no, you proposed merging into lp:ubuntu/apport, which is the UDD autogenerated one
<seb128> ^ fixes it
<seb128> right
<seb128> launchpad tricked me :p
<hallyn> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Archive: feature freeze, user interface freeze, final beta freeze | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-vivid | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: hallyn
<cjwatson> pitti: You want DEB_BUILD_OPTIONS=parallel=<number of cores>, as launchpad-buildd does, not -j.
<pitti> cjwatson: ah, good
<pitti> cjwatson: grep -c '^processor\b' /proc/cpuinfo
<pitti> cjwatson: or something more elaborate?
<cjwatson> pitti: http://bazaar.launchpad.net/~canonical-launchpad-branches/launchpad-buildd/trunk/view/head:/sbuild-package#L64 is our code, pretty much that
<pitti> cjwatson: ah, and you clamp it to 1, thanks
<cjwatson> Just in case
<pitti> doko: added that ^ to adt-run now, and restarted bintuils/amd64
<pitti> cjwatson: thank you
 * dholbach hugs hallyn
 * pitti hugs hallyn too, for the same reason (whatever good one it is) and LXC
<pitti> oh, patch pilot I figure :)
<dholbach> :)
<hallyn> \o :)
<cjwatson> pitti: cool
<pitti> meh, I attached it to the wrong place
<seb128> dholbach, thanks for fixing the typo ;-)=
<Laney> pitti: are these akonadi tmpfails you killing the workers?
<pitti> Laney: I retried them
<Laney> just checking
<pitti> Laney: I don't really know what's going on there, the log files don't have an error but adt-run exited with 1
<Laney> I thought it might have been you killing them to deploy the parallel stuff
<pitti> Laney: not sure about the bintuils one running out of space
<pitti> Laney: no, there's no need to restart the workers, that's a change in the autopkgtest tree only
<Laney> the second akonadi/amd64 got ENOSPC too
<pitti> Laney: oh -- that actually smells like the adt-run *host* getting out of spae
<pitti> /dev/vda1       9.9G  3.7G  5.7G  40% /
<pitti> Laney: when it copied down the rather sizable build tree between the test
<pitti> Laney: that also explains akonadi
<pitti> Laney: looks like I should redeploy the adt-run host as a bigger instance
<pitti> but I'm not gonna do this today
<pitti> Laney: we were running linux, bintuils, and glibc at the same time, and they all rebuild themselves
<pitti> so, mystery solved
<pitti> Laney: so please don't retry libo etc. yet, let's retry the big ones (linux etc.) serially
<rcj> stub, can you look at bug #1473533?  I've nominated series for SRU.  I'm happy to scratch my own itch and get those SRUs done, but I can't approve the nominations.
<ubottu> bug 1473533 in python-tz (Debian) "CountryNameDict function trying to parse UTF-8 iso3166.tab as US-ASCII" [Unknown,New] https://launchpad.net/bugs/1473533
<cjwatson> rcj: I've approved the nominations for you.
<rcj> cjwatson, thanks
<rcj> then I can spend time fixing the root issue rather than hacking cloud stream generation code with a "fix"
<Laney> pitti: OK, I'll let you serialise these :)
<Laney> I guess you could use block storage instead of asking for a beefier instance too
<pitti> Laney: ah, does that give me an additional virt disk to mount?
<pitti> Laney: i. e. to not waste additional CPUs/RAM (which I won't be needing), just disk?
<pitti> single-core 2GB is just fine otherwise, just 10 GB disk is too small
<Laney> pitti: indeed
<Laney> I'm sure you can ask for it with juju somehow, just don't ask me how to do it :)
<pitti> Laney: do you happen to have some details... ok
<Laney> hahaha
<juliank> As nothing was moving with regard to syncing the python-apt 1.0 final release since I asked a few weeks ago, I now gone with a bug report in bug #1501805.
<ubottu> bug 1501805 in python-apt (Ubuntu) "Sync python-apt 1.0.0 (main) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/1501805
<juliank> If this does not get done, we'll have the same problems as in vivid with the non-PEP440 version number, amongst other issues
<Laney> juliank: seems sensible, I'm sure it'll get dealt with
 * juliank hopes so, having that weird ~beta3.1 thing will do no good.
<arges> cyphermox: hey for bug 1486931, leitao gave the commits. Do you want to just re-format the patch with updated DEP-3 info and i can review that?
<ubottu> bug 1486931 in ipmitool (Ubuntu Trusty) "[LTCTest][Opal][OP810] ipmitool 1.8.13-1ubuntu0.3 version is still not working for in-band HPM upgrade" [High,In progress] https://launchpad.net/bugs/1486931
<Laney> pitti: https://jujucharms.com/docs/1.24/storage
<cyphermox> arges: k
<pitti> Laney: oh, nice!
<pitti> Laney: ah, seems new in 1.24, we don't have that command yet on wendigo
<pitti> Laney: but anyway, we have a cpu1-ram2-disk50 flavor, that souds fine
<Laney> pitti: ah right, that's a shame
<pitti> Laney: or use nova directly for hot-adding
<Laney> pitti: You probably want it all contained in the charm though?
<Laney> unless you can call nova directly there
<pitti> Laney: https://git.launchpad.net/~ubuntu-release/+git/autopkgtest-cloud/commit/?id=4beddeae66989301a939f2eaa5d3fd63ff825fad
<pitti> Laney: I mean for patching the existing setup without redeploying
<pitti> I just need it to go quiet, then mount /tmp from that storage
<Laney> nod
<pitti> Laney: but I'll redeploy on Monday or so, when I'm not on a sprint
<pitti> Laney: good opportunity to fix bug 1480962
<ubottu> bug 1480962 in Auto Package Testing "autopkgtest-cloud-worker charm does not set ssh key name in worker.conf" [Medium,Triaged] https://launchpad.net/bugs/1480962
<rcj> cjwatson, How do I number the versions when backporting the fix in python-tz?  wily is 2014.10~dfsg1-0ubuntu2.  Would vivid be 2014.10~dfsg1-0ubuntu2~15.04.0 as they would have the same content?
<slangasek> smb: I haven't seen a dpdk reupload yet for the debian/copyright fix, is that pending?
<smb> slangasek, yeah sorry pending me getting my sh... iny things together and pack it up
<slangasek> ok :)
<cjwatson> rcj: https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging has examples
<smb> slangasek, meanwhile you could probably reject it from new if you happen to be looking that direction
<slangasek> smb: done
<smb> slangasek, ta
<rcj> cjwatson, excellent. bookmarked!
<chiluk> infinity any update on the netboot respin for the new kernel?  lp 1481490
<ubottu> Launchpad bug 1481490 in debian-installer (Ubuntu Vivid) "Add sfc to nic-modules udeb" [Undecided,In progress] https://launchpad.net/bugs/1481490
<alkisg> flexiondotorg: hi, we've talked the other day on #ubuntu-devel about an issue with fcitx and Greek keyboard layout
<alkisg> It's still an issue, we can't properly type Greek unless we uninstall fcitx-bin, which is depended upon by ubuntu-mate-core
<alkisg> So the end result is that Greeks can't properly use mate
<flexiondotorg> alkisg, OK, understood.
<flexiondotorg> alkisg, I have a fix for that I believe.
<flexiondotorg> I'll get on it.
<alkisg> flexiondotorg: I tried with beta2, mate and vanilla ubuntu. It happened on mate but not on ubuntu
<flexiondotorg> I think if fcitx is move from -core to the live seed everything will work.
<alkisg> Thank you flexiondotorg
<flexiondotorg> alkisg, The idea of moving fcitx to the live seed is based on me poking through the ubuntu seeds.
<flexiondotorg> alkisg, Question.  - https://ubuntu-mate.community
<alkisg> Let me check if both those flavours behave the same in the live cd...
<flexiondotorg> Oops.
<alkisg> ?
<alkisg> flexiondotorg: ubuntu beta 2 live CD has a whole lot of fcitx packages installed, but it does not have the issue
<alkisg> mate only has fcitx-bin, and does have the issue
<alkisg> I'm wondering if the issue is in ubuntu-mate-core, or of it has something to do with the window manager...
<flexiondotorg> So Ubuntu MATE has the issue in the Live session?
<alkisg> Yes
<flexiondotorg> Oh, bother.
<alkisg> (both in the live and installed)
<flexiondotorg> OK. More thought required.
<flexiondotorg> Worst case, I yanked fcitx from Ubuntu MATE completely.
<flexiondotorg> Or figure out how to work around this issue.
<flexiondotorg> alkisg, Please can you file a bug against Ubuntu MATE describing this problem?
<flexiondotorg> https://bugs.launchpad.net/ubuntu-mate
<flexiondotorg> I'll need a bug reference in any package changes I might have to make.
<FourDollars> cyphermox: Hi. Could you help to review https://bugs.launchpad.net/ubuntu/+source/modemmanager/+bug/1441095/comments/56 and https://code.launchpad.net/~binli/ubuntu/trusty/modemmanager/lp1441095/+merge/272054 for trusty?
<ubottu> Launchpad bug 1441095 in network-manager (Ubuntu Trusty) "novatel: improve probing for Dell branded modems" [High,In progress]
<flexiondotorg> alkisg, Thanks for testing.
<alkisg> flexiondotorg: sure, will do, I'll also test some more
<flexiondotorg> Thank you.
<flexiondotorg> I suspect fcitx is being detected as the default input handler.
<cyphermox> FourDollars: did we not already land this?
<flexiondotorg> But on Ubuntu iBus is probably the default detected.
<cyphermox> oh, I see, it landed in wily
<alkisg> flexiondotorg: here's an interesting test, in the live session: dpkg -r --force-all fcitx; service lightdm restart ==> solves the problem. The dpkg -r ==> to not uninstall ubuntu-mate-core but only fcitx
<FourDollars> cyphermox: Yup, but not include trusty.
<cyphermox> right
<cyphermox> I'll review it a little later, I want to finish other fixes first :)
<alkisg> flexiondotorg: you're probably right, ibus is installed in ubuntu, not in mate
<alkisg> And running on the live session
<FourDollars> Ok. Take your time. Thx in advance.
<flexiondotorg> alkisg, MATE has isn't own input system.
<flexiondotorg> And fcitx is "getting in the way".
<alkisg> flexiondotorg: one of the reasons we want to use mate is because it still respects the xorg settings, while ubuntu doesn't
<flexiondotorg> alkisg, I'll fix it for you :-)
<alkisg> So grp:alt_shift_switch is respected in mate, overriden in ubuntu by ubuntu-settings-daemon
 * alkisg files a bug...
<cyphermox> FourDollars: won't you also need libmbim changes in trusty too?
<FourDollars> cyphermox: Yes, I need it. Just missing.
<cyphermox> FourDollars: do you want to do the merge proposal?
<FourDollars> cyphermox: I thought seb128 had done it.
<FourDollars> cyphermox: I did. Wait a minute. Let me show you the link.
<cyphermox> ok
 * FourDollars is working by a tablet.
<alkisg> flexiondotorg: https://bugs.launchpad.net/ubuntu-mate/+bug/1501832
<ubottu> Launchpad bug 1501832 in ubuntu-mate "fcitx breaks typing Greek composite characters" [Undecided,New]
<FourDollars> cyphermox: https://code.launchpad.net/~fourdollars/ubuntu/trusty/libmbim/1441095/+merge/273015
<cyphermox> oh, great. Looks like seb128 already uploaded that
<FourDollars> Cool.
<pitti> apw: (CC: jibel): how far are we from killing the old dkms jobs? (jibel asked todya)
<apw> pitti, i am waiting confirmation from bjf and smb that they are done with the old and using the new
<smb> apw, confirmed
<apw> (that you have stopped using dkms-matrix and that adt-matrix is supplying what you need; if anythign)
<gQuigs> should I divide this removal request bug up by source pacakge ?  - https://bugs.launchpad.net/ubuntu/+source/glade-3/+bug/1496227
<ubottu> Launchpad bug 1496227 in glade-3 (Ubuntu) "Remove glade-3, libdesktop-agnostic, dockmanager from Archive, 15.10+" [Undecided,New]
<smb> apw, Yep I have not looked back to the old one for a while and concentrated on the new one. You may have noticed some attempts at least to improve stuff with adt/dep-8 :)
<apw> smb, indeed, thought so, but best to be sure :)
<smb> apw, sure-ack
<pitti> apw, smb: cool, thanks
<pitti> jibel: zap it!
<pitti> jibel: and then we can drop a lot of cruft from lp:auto-package-testing :)
 * pitti â food
<hjd> hallyn: Hello. I have to admit I don't know whether sync/feature freeze expection requests fall in under path pilots, but if it does, could you please take a quick look at bug 1500112?
<ubottu> bug 1500112 in haskell-stack (Ubuntu) "missing dependency on libyaml-0-2" [Medium,Confirmed] https://launchpad.net/bugs/1500112
<hallyn> hjd: i can't do ffe's,
<hallyn> thta's a #ubuntu-release thing i think
<hallyn> quesitonwould be how big is the debdiff.  if it doesn't do much beside fix that bug then it shouldn't need ffe
<gQuigs> hmm... it is much cleaner separate ..   now just for dockmanager -https://bugs.launchpad.net/ubuntu/+source/dockmanager/+bug/1501859
<ubottu> Launchpad bug 1501859 in dockmanager (Ubuntu) " Remove dockmanager from Archive, 15.10+" [Undecided,New]
<jibel> pitti, apw \o/
<jibel> thanks!
<hjd> hallyn: The diff should be rather small, but I don't have experience with FFEs and the documentation said that when in doubt, check first. Didn't know there was an #ubuntu-release though, I'll try there. Thanks :)
<infinity> chiluk: Doing it nowish.
<cjwatson> hjd: I'll deal with it, thanks.  No need for an FFE.
<chiluk> thanks infinity
<hjd> cjwatson: Thank you :)
<juliank> barry: I have a fix for the stderr thing in python-apt :)
<barry> juliank: other than Restrictions: allow-stderr? :)
<juliank> barry: Yes, catching the warning and checking it's a deprecation one :)
<juliank> barry: http://anonscm.debian.org/cgit/apt/python-apt.git/commit/?id=91d32c8
<barry> juliank: cool!  if you upload that to unstable, i can resync and drop our delta.  maybe we can even do that before the release team approves my 1.0.0ubuntu1 upload :)
<barry> juliank: lgtm!
<juliank> barry: There are also some fixes by mvo: http://anonscm.debian.org/cgit/apt/python-apt.git/commit/?id=92f7e29f55bc0f4bf7bf9cc78730814700fb2284 and http://anonscm.debian.org/cgit/apt/python-apt.git/commit/?id=598bbabf7a97962426e70233430cda78182b453b pending for 1.0.1
<juliank> I think they're fine too
<barry> +1
<barry> juliank: do you have an eta for 1.0.1 in unstable?
<juliank> barry: I'll do it now
<barry> juliank: awesome, thanks.  as soon as that gets picked up by lp i'll sync it
<barry> juliank: and i think that can be a straight up syncpackage rather than a merge
<juliank> Yeah
<juliank> barry: At some point, I really need to switch the build system over to pybuild instead of the ugly hack from the pre-python3 helper times
<barry> juliank: +1 :)
<hallyn> sforshee: bug 1483796 , you see that perf regression yourself?
<ubottu> bug 1483796 in mutt (Ubuntu) "Terrible performance for ~b/~B searching" [Undecided,New] https://launchpad.net/bugs/1483796
<sarnold> doko: this is reported as a gcc5 issue: https://bugs.launchpad.net/bugs/1501634
<ubottu> Launchpad bug 1501634 in gnupg (Ubuntu) "GnuPG 1.4 requires a patch for GCC 5" [Undecided,New]
<sarnold> the patch inthe second url looks like good old fashioned broken code though, heh
<juliank> barry: meh, dinstall just started on ftp-master.d.o., this will take a while...
<barry> juliank: no worries.  i'm here for several more hours :)
 * juliank not. Just paused the walking dead to do the 1.0.1 release :)
<barry> juliank: wow! that's dedication.  i've been binge watching season 5 on netflix and am about 1/2 through.  i don't know that i'd pause it for that reason. :)
<juliank> Nah, I'll be here for two hours.
<juliank> barry: I started with the series yesterday, and am now at season 2 episode 2, 8 minutes in.
<barry> food, maybe.  sleep, pshaw.  work, hahahah (but don't tell slangasek :)
<doko> sarnold, should that be fixed in gnupg?
<barry> juliank: just call in sick tomorrow and have a great, sleep deprived and freak out filled weekend! :)
<juliank> barry: I'm a student, and I have holidays :)
<barry> juliank: :)
<doko> juliank, enjoy
<juliank> Two semesters left until M.Sc. in CS is complete.
<jrwren> juliank: congrats.
<juliank> Dammit, gbp dch put mvo as the uploader in the changelog...
<juliank> I'm not sure what that tool is thinking
<juliank> It's tagged and uploaded now, so I won't fix it anymore.
<juliank> or wait, I will
<sforshee> hallyn: yes I do
<doko> robert_ancell, https://launchpad.net/ubuntu/+source/xserver-xorg-video-siliconmotion/1:1.7.8-1ubuntu3/+build/7987052
<robert_ancell> doko, yeah, I was waiting to see if that patch I sent to xorg-devel was considered correct
<hallyn> sforshee: and you're using that patch locally?
<robert_ancell> doko, is this a daily poke I get for having something FTBFS? ;)
<barry> juliank: well, 1.0.0ubuntu1 got approved, but i'll still do the syncpackage when it's ready
<doko> robert_ancell, sorry, I'm trying to get this automated ;-P
<robert_ancell> hah
<juliank> barry: OK, sorry about the wrong bug number, BTW, I only noticed this yesterday. Not sure how it slipped in
<sforshee> hallyn: yep, it's much better
<barry> juliank: no worries, but do you remember the correct bug #?
<hallyn> sforshee: i see, it's upstream :)
<hallyn> sforshee: i don't see you having nominated that for trusty,but you said all major releases - should i add trusty?
<juliank> I tagged it fix committed yesterday, let me have a look
<juliank> It's bug #1484470
<ubottu> bug 1484470 in python-apt (Ubuntu) "aptsources.sourceslist or softwareproperties.ppa calling out to system-image-cli erroneously" [Undecided,Fix committed] https://launchpad.net/bugs/1484470
<sforshee> hallyn: I don't think trusty was affected
<hallyn> oh, ok.
<juliank> barry: The wrong number came direct from john apparently, not sure if there was another bug about it
<sforshee> or maybe it was ... my description makes it sound like it is, but my memory says it wasn't
<juliank> where john = John R. Lenton <john.lenton@canonical.com>
<hallyn> sforshee: hm, it's fixed in the unstable package
<hallyn> but i guess it's a bit late for something so drastic
<barry> juliank: ah, cool no worries then
<sforshee> hallyn: mutt in trusty seems fine
<hallyn> not a soothing difference eiterh  226 files changed, 33071 insertions(+), 40447 deletions(-)
<hallyn> so i guess i'll just cherrypick your patch into wily - thx
<juliank> barry: I uploaded 1.0.1 a few minutes ago, BTW
<juliank> Now we only need to wait for dak and its friends
 * juliank is mostly back to walking dead now. But they're just talking in the woods
<infinity> chiluk: And both uploaded/accepted/building.
<infinity> chiluk: If you can turn around verification on that reasonably quickly, that would be lovely.
<infinity> chiluk: And poke me directly when you do, since I need to make seed changes at the same time as d-i is copied, or dailies explode. :P
<infinity> Oh, actually, trusty is building with proposed right now, I guess I need to make those seed changes today.
<infinity> La la la.
<kentb_> mwenning: thanks! (2 days late lol)
<chiluk> ok infinity sorry I missed that earlier I'll verify now-ish.
<chiluk> nm I see that it's still building
<juliank> too many zombies, i'll get bad dreams...
<mwenning> kentb_, :-)
<Unit193> infinity: Get a chance to review some things? ;P
<infinity> Unit193: I feel like that question is a trap.
<infinity> Unit193: Which things?
<Unit193> infinity: cdimage/livecd-rootfs/debian-cd reviews, Openbox debdiff (likely too late, I'm fine dropping it.). :D
<infinity> Unit193: Bug#, MPs, where am I looking?
<infinity> Unit193: (If I had context on this at one point and forgot, sorry, I'm a bit headless chickeny this week)
<infinity> chiluk: trusty-proposed and vivid-proposed should have bits published now, at least for the architecture I suspect you planned to test. :P
<Unit193> infinity: Yes sorry, I thought that might trigger a memory, it's not just me being vague: https://code.launchpad.net/~unit193/ubuntu-cdimage/xubuntu-core/+merge/268167 - https://code.launchpad.net/~unit193/livecd-rootfs/xubuntu-core/+merge/267880 - https://code.launchpad.net/~unit193/debian-cd/xubuntu-core/+merge/267879 -
<Unit193> https://launchpad.net/~unit193/+archive/ubuntu/staging/+sourcepub/5397648/+listing-archive-extra
<infinity> chiluk: 376.1 for vivid-proposed, 318.30 for trusty-proposed.
<chiluk> infinity, ok.. I'll kick off a virt-install net-install.
<infinity> Unit193: Ahh, core, right, that would triggered more flashbacks than "openbox". ;)
<infinity> s/would/would have/
<Unit193> But then you're thinking Snappy! :---D
<chiluk> infinity the dates for the netboot images are still old http://archive.ubuntu.com/ubuntu/dists/trusty-updates/main/installer-amd64/current/images/netboot/ubuntu-installer/amd64/
<infinity> Unit193: So, was this a flavour you intended to release with 15.10?  We tend to try to stick by the rule "if you didn't participate in Beta 2, you don't participate in release".
<infinity> Unit193: If you just want the commits in there to alpha test the whole thing with an eye to being able to release ISOs "officially" for 16.04, there's no reason we have to wait until after release to do that.
<infinity> chiluk: Because you're looking in updates, not proposed.
<chiluk> doh
<Unit193> infinity: If that's the rule, then sure I think we can get this reviewed with XXX in mind.
<infinity> Unit193: Like all rules, it's bendable, but it's a good rule, IMO, in that it makes sure that you had something that was at least half functional and QAable a month before release, and aren't wasting time (yours or others) on trying to fix the world in the last month when you should just be adding polish that that Beta. :)
<infinity> s/that that/to that/
<infinity> Unit193: I'd agree that xubuntu-core, the packageset, is a special case here, because it's a strict subset of things you already need to fix and ship for Xubuntu proper.
<infinity> Unit193: But you'll still need to suck some resources to fix xubuntu-core the ISO product, unless it's magically perfect the first time.
<Unit193> infinity: Right, and we've tested something unofficial a bit, but not using the exact infra so it'll likely be a bit odd.  If it's good enough, or close to it then it might be nice to fix but otherwise that'll come later.
<sarnold> doko: yes, the proper fix is going to be in gnupg
<chiluk> infinity netboot looks to be going along swimingly.. booted fine.. installing now.
<Unit193> infinity: (The Openbox issue was another one I poked you about, though.)
<chiluk> infinity netboot install completed successfully http://paste.ubuntu.com/12635027/  ... additionally I checked for the existence of the sfc module and it was there like we expected...
<juliank> barry: I think I'll turn some warning display on by default for all warnings in the test suite, so such bugs do not happen only during autopkgtests
<barry> juliank: +1
<juliank> That's the second time this happened, which is two times more than I'd like
<barry> juliank: still waiting for LP to pick up 1.0.1
<juliank> barry: Probably happens only after the dinstall run finished, in about 5 hours?
<juliank> or 4 hours
<barry> juliank: yeah, not sure, but that seems likely.  if not tonight, tomorrow
<mdeslaur> infinity: what created the weird dual partition tables on our iso media?
<mdeslaur> s/created/creates/
<infinity> chiluk: So, that tested one of 4 things. :)
<infinity> mdeslaur: xorriso, with a bit of prep.
<infinity> mdeslaur: http://bazaar.launchpad.net/~ubuntu-cdimage/debian-cd/ubuntu/view/head:/tools/boot/wily/boot-amd64
<mdeslaur> infinity: ah, cool, thanks
<TJ-> infinity: re: cdimage - could we switch to the syslinux project's MBR isohdpfx_c.bin instead of isohdpfx.bin at some point, to provide a workaround for several buggy BIOS implementations? bug 277903
<ubottu> bug 277903 in syslinux (Ubuntu) "Missing Operating System [message at boot]" [Medium,In progress] https://launchpad.net/bugs/277903
#ubuntu-devel 2015-10-02
<hallyn> oops
<hallyn> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Archive: feature freeze, user interface freeze, final beta freeze | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-vivid | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<rcj> Could someone with upload rights take a look at bug #1473533 for me?
<ubottu> bug 1473533 in python-tz (Ubuntu Vivid) "CountryNameDict function trying to parse UTF-8 iso3166.tab as US-ASCII" [Critical,In progress] https://launchpad.net/bugs/1473533
<sarnold> rcj: I think the patches should have dep-3 tags added to keep track of where the patch came from, etc. http://dep.debian.net/deps/dep3/
<rcj> sarnold, thank you.  I will fix that up.
<rcj> sarnold, I have updated the patches with dep-3 tags and reattached to bug #1473533.
<ubottu> bug 1473533 in python-tz (Ubuntu Vivid) "CountryNameDict function trying to parse UTF-8 iso3166.tab as US-ASCII" [Critical,In progress] https://launchpad.net/bugs/1473533
<sarnold> rcj: very nice :) thanks
<rcj> sarnold, thank you for taking time to review them
<pitti> Good morning
<pitti> cjwatson: since consolekit has been dead for years and hasn't been a thing on Ubuntu since saucy, could we drop that from ssh? it would finally kick out consolekit from main
<pitti> cjwatson: I'm happy to file a bug about it for tracking etc.
<pitti> cjwatson: for Debian I figure it could enable consolekit support only on !linux?
<pitti> (I guess it might still be used on freebsd/hurd)
<flexiondotorg> The following bug has been raised against Ubuntu MATE - https://bugs.launchpad.net/ubuntu-mate/+bug/1501426
<ubottu> Launchpad bug 1501426 in ubuntu-mate "15.10 Beta 2 fails HTML5 audio test for MP3" [Undecided,Incomplete]
<flexiondotorg> Which can be resolved post-install by installing restricted-extras.
<flexiondotorg> Or gstreamer1.0-libav could be added to the seeds.
<pitti> Riddell: is kshutdown still a thing? if so, could it drop its consolekit dep and use logind only?
<flexiondotorg> I'm seeking policy clarification on whether gstreamer1.0-libav can be provided by default?
<Riddell> pitti: kshutdown can die quite happily
<pitti> Riddell: no reverse deps either; okay, good to remove then?
<Riddell> pitti: go ahead
<pitti> Riddell: yay cleanup Friday :)
<dholbach> good morning
<flexiondotorg> dholbach, Can you see my question from 08:12:51 in your backlog regarding gstreamer1.0-libav?
<dholbach> no
<dholbach> I just came online a few minutes ago
<dholbach> so........ how can I help?
<dholbach> it's also not on http://irclogs.ubuntu.com/2015/10/02/%23ubuntu-devel.html
<StevenK> dholbach: Given that's UTC, it could be in /10/01
<dholbach> no, it's not
<flexiondotorg> The following bug has been raised against Ubuntu MATE - https://bugs.launchpad.net/ubuntu-mate/+bug/1501426
<ubottu> Launchpad bug 1501426 in ubuntu-mate "15.10 Beta 2 fails HTML5 audio test for MP3" [Undecided,Incomplete]
<flexiondotorg> Which can be resolved post-install by installing restricted-extras.
<flexiondotorg> Or gstreamer1.0-libav could be added to the seeds.
<flexiondotorg> I'm seeking policy clarification on whether gstreamer1.0-libav can be provided by default?
<flexiondotorg> dholbach, ^^^^
<dholbach> I don't think it can, but maybe seb128 knows which codecs we can ship be default
<seb128> I've no clue about legal and codecs sorry
<seb128> https://en.wikipedia.org/wiki/Libavcodec#Legal_aspects
<seb128> suggests it's not a safe one
<seb128> I think it's similar to the ffmpeg situation and can't be shipped
<dholbach> thanks for finding that link, seb128
<dholbach> that looks like explanation enough
<seb128> on the mp3 topic, ubuntu-restricted-extras is installed by ubiquity if you check the appropriate box and should install what is needed
<flexiondotorg> seb128, dholbach Thanks.
<seb128> yw!
<flexiondotorg> That's all I needed.
<flexiondotorg> I'll updated the ticket. Ubuntu MATE Welcome has the post-install option for install the required stuff.
<pitti> cjwatson: I created bug 1502045 for tracking the last 4 packages (I removed some obsolete ones and fixed polkit-qt*)
<ubottu> bug 1502045 in tcosmonitor (Ubuntu) "Move from consolekit to logind" [Undecided,New] https://launchpad.net/bugs/1502045
<alkisg> Hi, I'm trying ubuntu-wily-beta2 and there's a regression, in /etc/default/console-setup after installation there's CHARMAP="ISO-8859-15" instead of the goold old UTF-8, is that deliberate or should I be digging into what's causing it + file a bug about it?
<alkisg> That breaks all non-ascii input/output in VTs...
<alkisg> Ah I had already troubleshooted that and filed https://bugs.launchpad.net/ubuntu/+source/console-setup/+bug/1484101
<ubottu> Launchpad bug 1484101 in livecd-rootfs (Ubuntu) "Broken CHARMAP with LANG=C on postinst, affects all installations after 14.10" [Undecided,Confirmed]
<alkisg> The problem is that it's not fixed yet... :-/
<alkisg> Logs from the previous chat here about it: http://irclogs.ubuntu.com/2015/08/12/%23ubuntu-devel.html at 10:42
<alkisg> Could I maybe tag it with `iso-testing` to increase its significance? It should only take 1-2 lines to solve it ....
<dholbach> can anyone upload https://code.launchpad.net/~nhaines/ubuntu-wallpapers/fix-photo-filename/+merge/273192?
<cjwatson> pitti: I'd been thinking about doing that, but I hadn't worked out whether there were any obscure desktop flavours or architectures that needed it - do you think you could investigate that?  I'd ideally much prefer to drop the patch entirely if possible
<lotuspsychje> anyone knows howto list 'latest' packages through apt-cache search?
<jamespage> pitti, morning - we've got to dbus type errors with ceilometer in proposed during autopkgtesting
<jamespage> "adt-run [04:47:20]: test test-services: [-----------------------
<jamespage> Failed to get D-Bus connection: No such file or directory
<jamespage> ERROR: ceilometer-agent-central IS NOT RUNNING"
<jamespage> ppc64el and armhf are impacted - any ideas?
<alkisg> ogra_: the problem is in the 4th line of BuildLiveCD, LANG=C, it should be at least LANG=C.UTF-8
<alkisg> ogra_: could you commit that before the final iso spins are made?
<alkisg> If you grep for LANG inside the sources, you'll see C, C.UTF-8, and en_US.UTF-8.
<alkisg> The two occurences of LANG=C could be replaced with one of the other 2, for consistency, and this will enable us to write things at our terminals again...
<cjwatson> alkisg: BuildLiveCD is dead
<cjwatson> why are you looking at it?
<alkisg> cjwatson: please see https://bugs.launchpad.net/ubuntu/+source/console-setup/+bug/1484101
<ubottu> Launchpad bug 1484101 in livecd-rootfs (Ubuntu) "Broken CHARMAP with LANG=C on postinst, affects all installations after 14.10" [Undecided,Confirmed]
<cjwatson> yes I know
<cjwatson> but it's still dead
<alkisg> We can't type UTF-8 characters after 14.10 anymore
<alkisg> ogra_ told me that that what the live CD were using
<cjwatson> ogra_ is wrong
<alkisg> OK
<alkisg> What is used now?
<cjwatson> it uses livecd-rootfs, yes, but not the BuildLiveCD script
<cjwatson> launchpad-buildd does that part of things now
<alkisg> cjwatson: how should I help with the issue now?
<cjwatson> it would probably be easiest to just change live-build/auto/build in livecd-rootfs
<alkisg> It's just a matter of notifying the correct maintainer, it shouldn't need more than a couple of lines to be fixed...
<cjwatson> I don't think it's necessary to modify launchpad-buildd here, which has a substantially longer rollout procedure anyway
<cjwatson> and please don't use en_US.UTF-8, C.UTF-8 would be the right thing
<alkisg> That remark is for the launchpad-buildd developers, not for me, right?
<cjwatson> I am a launchpad-buildd developer
<alkisg> I don't understand what I'm supposed to do. I see why the issue happens, I'm not using en_US.UTF-8 anywhere...
<cjwatson> I'm referring to your bug comment saying "please use LANG=en_US.UTF-8"
<alkisg> " I think this should be fixed in console-setup, but it's possible that the live CD code may want to use LANG=C.UTF-8 in any case."
<cjwatson> https://bugs.launchpad.net/ubuntu/+source/console-setup/+bug/1484101/comments/1
<ubottu> Launchpad bug 1484101 in livecd-rootfs (Ubuntu) "Broken CHARMAP with LANG=C on postinst, affects all installations after 14.10" [Undecided,Confirmed]
<alkisg> I'm proposing C.UTF-8 twice there
<cjwatson> right, but you also proposed en_US.UTF-8 :-)
<alkisg> Anyway, can I do something more to help in getting this fixed?
<cjwatson> and I'm saying let's not do that bit of it because it's wrong
<alkisg> Only because it was already in the sources
<alkisg> And inside a parenthesis
<alkisg> (or en_US.UTF-8 or whatever)
<cjwatson> Yeah I think that's for some Android-specific reason, possibly
<cjwatson> Or maybe it's just obsolete, anyway, shouldn't be perpetuated
<alkisg> OK, let's not do that bit, np there, I'm certainly not endorsing it,
<alkisg> is there anything that I could do to help with solving that issue?
<cjwatson> I'm just thinking
<pitti> cjwatson: yes, can do: Tasks: of consolekit is scary really, I'll write to the leads
 * alkisg goes on to file yet another issue for a sysvinit compat issue in systemd in 15.10... I'll be around for feedback if I'm needed though... :)
<cjwatson> sigh, quality commit message
<cjwatson> this console-setup behaviour was introduced in a commit saying only "several fixes for FreeBSD"
<pitti> jamespage: the test doesn't run as root, so the d-bus error is likely from systemctl (the test doesn't depend on dbus)
<jamespage> pitti, urgh
<pitti> (systemctl as root works without dbus, but not as user)
<doko> new fun stuff ... http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20151001-wily.html
<cjwatson> alkisg: I think I would rather just fix the console-setup side of things for now, unless you object.  It feels quite late to be changing this in livecd-rootfs for 15.10.
<cjwatson> alkisg: whereas the console-setup change is simple and targeted
<cjwatson> (and I'm doing it now)
<alkisg> cjwatson: no I don't mind at all, I haven't noticed any other related issues
<cjwatson> good, will do that then
<alkisg> Thank you :)
<pitti> jamespage: or we just add dbus to the LXC base images, as it's such a fundamental thing anyway
<jamespage> pitti, ah - so this is lxc vs kvm testing differently then?
<pitti> jamespage: yes, the cloud images have dbus installed
 * pitti runs "adt-run ceilometer --- lxc -s adt-wily" locally to verify
<pitti> jamespage: ah - this test is new in -proposed, so this needs -proposed enabled
<jamespage> pitti, indeed it does
<Saviq> pitti, hey, is there no way to pass options to schroot when doing adt-run?
<pitti> Saviq: no, not at the moment
<pitti> Saviq: people asked for passing options to qemu, so I added that, but so far nobody asked for schroot options
<pitti> (and most often you can do that more generically with --setup-commands)
<Saviq> might just do that then
<Saviq> need to add a ppa
<Saviq> and just got a nice schroot setup script doing that for me
<pitti> jamespage: confirmed, adding dbus makes the test succeed
<pitti> jamespage: (or running the test as root)
<doko> seb128, Laney: is there a gnome freeze exception, i.e. to sync gucharmap to fix the fbfs?
<doko> same for libsoup
<Laney> no
<Laney> cherry-pick them
<jamespage> pitti, ficing up now
<pitti> jamespage: oh
<pitti> jamespage: I just committed an adt-build-lxc fix to install dbus
<pitti> jamespage: it's a rather basic functionality of the OS these days
<jamespage> pitti, agreed - I'll not fix any tests then...
<pitti> jamespage: and I was about to rebuild the production containers and restart the tests
<jamespage> pitti, awesome - thankyou
 * jamespage stands down
<jamespage> well goes back to looking at doko's comments on ryu MIR
<Laney> doko: I'll fix these cases
<pitti> jamespage: done, tests restarted, lunch o'clock kthxbye :)
<jamespage> pitti, ta
<doko> tvoss, https://bugs.launchpad.net/ubuntu/+source/libfriends/+bug/1502094  anyone particular how can organize this?
<ubottu> Launchpad bug 1502094 in unity-scope-home (Ubuntu) "libgee-0.8-dev should be used, libgee-dev will be removed from the archive" [Undecided,New]
<tvoss> doko, hmmm, kenvandine might be able to help
<doko> kenvandine, ^^^
<pitti> jamespage: there we go, all green
<jamespage> pitti, \o/
<caribou> pitti: do you have an example of a package with good autopkgtest tests ?
<caribou> off the top of your head
<pitti> caribou: we have about 3.000 tests -- any particular area?
<caribou> pitti: it's for sosreport, I'm looking for ideas as it only collects data & create a tarball
<seb128> doko, is bug #1502094 something you want to see done for wily?
<ubottu> bug 1502094 in unity-scope-home (Ubuntu) "libgee-0.8-dev should be used, libgee-dev will be removed from the archive" [Undecided,New] https://launchpad.net/bugs/1502094
<pitti> caribou: so I guess your test should call it and then make some assertions about what you would expect in the report (existance of files/keys, particular values)
<caribou> pitti: yeah, that's what I had in mind
<caribou> ok, thanks!
<doko> seb128, I saw that libgee ftbfs, that's the reason I noticed
<doko> didn't check if it would be just a rebuild
<seb128> k, I'm unsure, going to have a look
<seb128> doko, Laney, I think it's fair to sync the new gucharmap, the only commits between the versions are unicode 8 support or translations updates (+1 build fix with old gtk)
<Laney> seb128: yes, I already did it, I said I was fixing them :)
<seb128> Laney, them = ?
<Laney> the ones he pinged about
<seb128> gucharmap and libsoup?
<Laney> yes
<seb128> Laney, I've pinged larsu about ido and I'm handled dirspec and indicators and looking at libgee
<seb128> doko, ^
<seb128> just saying so we don't dup work
<seb128> handling*
<Laney> I fixed json-glib upstream and in debian, will sync later
<seb128> great
<seb128> doko, can you retry xserver-xorg-video-ati|cirrus|mach64|mga on i386, they hit "Temporary failure resolving 'ftpmaster.internal'" issues
<doko> ok
<lotuspsychje> where can i find a list of recent added packages on ubuntu repos
<seb128> doko, xserver-xorg-video-dummy as well
<seb128> doko, danke
<lotuspsychje> http://packages.ubuntu.com/trusty/newpkg?mode=byage
<lotuspsychje> this is the only list i find, but how can a user see more?
<seb128> lotuspsychje, https://lists.ubuntu.com/mailman/listinfo/wily-changes has all uploads, but that's updates as well, not only new packages
<seb128> but it could be useful still
<lotuspsychje> seb128: i have to subscribe for this?
<seb128> there are online archives
<lotuspsychje> ah
<lotuspsychje> seb128: https://lists.ubuntu.com/archives/wily-changes/ this right?
<seb128> lotuspsychje, correct
<lotuspsychje> seb128: nice1 mate thank you!
<seb128> yw!
<lotuspsychje> seb128: and this1 for trusty right: https://lists.ubuntu.com/archives/trusty-changes/
<seb128> correct
<seb128> doko, any chance you could triage/forward upstream https://bugs.launchpad.net/ubuntu/+source/gcc-4.8/+bug/1234218
<ubottu> Launchpad bug 1234218 in gcc-4.8 (Ubuntu) "4.8 doesn't throw -Wreturn-type anymore for wrong returns in macros" [Undecided,New]
<lotuspsychje> great great!
<seb128> doko, and are the test build using a different gcc/toolchain than the archive? because local ido build doesn't hit the test build failure, likely because of that bug ^
<seb128> Laney, does "debian1" makes things sync? I though you needed to use "build1" for that
<Laney> yes :)
<Laney> it's just "not ubuntu"
<seb128> oh ok
<seb128> I though "build" was the special case
<doko> seb128, no, as in the archive. the only changed thing is a disabled pkgbinarymangler to speed up things
<seb128> k, weird
<kenvandine> doko, hmm... libfriends should be dead
<kenvandine> it was for friends-service, which is also dead
<doko> kenvandine, removal bugs would be appreciated
<kenvandine> doko, indeed, i thought that had been done quite a while back
<kenvandine> robru, ^^
<didrocks> barry: hey, did you get anything on the python 3.4 regression? (see my answer a couple of days ago)
<kenvandine> robru, or did you just remove them from the seed?
<barry> didrocks: not yet, but i'm going to look again today
<seb128> doko, can you retry https://launchpad.net/ubuntu/+archive/test-rebuild-20151001/+build/8022636 ?
<roaksoax> pitti: howdy!! i was wondering if there's a ppa for autopkgtest that supports running vivid+ ?
<roaksoax> pitti: howdy!! i was wondering if there's a ppa for autopkgtest that supports running vivid+  on a trusty host?
<roaksoax> pitti: we are having trouble running  aCI on trusty with trusty's autopkgtest
<cjwatson> seb128: done
<cjwatson> doko: cc ^-
<seb128> cjwatson, thanks
<doko> seb128, https://bugzilla.gnome.org/show_bug.cgi?id=753310
<ubottu> Gnome bug 753310 in general "Remove `#pragma GCC system_header` from gmessages.h" [Minor,Resolved: fixed]
<seb128> doko, can you retry  xdg-user-dirs-gtk and xfsdump (mirror issue)
<doko> done
<seb128> thanks
<cyphermox> superm1: how do you feel about splitting fwupd into two binaries, one for the service, and one for the GUI?
<kenvandine> doko, robru: i've filed bug 1502193 to have all the friends packages removed from the archive
<ubottu> bug 1502193 in unity-lens-friends (Ubuntu) "Remove friends from archive" [Undecided,New] https://launchpad.net/bugs/1502193
<doko> kenvandine, checked for rdeps?
<seb128> infinity, bug #1502058 is one for you I guess? One of the change is sunday, "Norfolk moves from +1130 to +1100 on 2015-10-04" so maybe that should be uploaded this week (though I guess norfolk is small so it might not impact a lot of users)
<ubottu> bug 1502058 in tzdata (Ubuntu) "Update to 2015g" [Undecided,New] https://launchpad.net/bugs/1502058
<smb> jamespage, I know its a bit late in the day and the week but just to let you know in case you have not noticed: dpdk is now in wily's universe
<jamespage> smb, so I see - openvswitch-dpdk is queued up behind it - slangasek or infinity - do either of you have that on your AA todo list?
<jamespage> jdstrand, doko: re our later MIR of ryu  - https://bugs.launchpad.net/ubuntu/+source/ryu/+bug/1500950
<ubottu> Launchpad bug 1500950 in ryu (Ubuntu) "[MIR] ryu" [High,Incomplete]
<jamespage> openstack neutron is using the python-ryu ofprotocol library to communicate with openvswitch
<jamespage> which is the bit we need this cycle to support liberty - not the agent process provided by ryu-bin; can we constrain the MIR review on that basis?
<jamespage> promoting python-ryu to main only this cycle
<slangasek> jamespage: yes, it's on mine
<jamespage> slangasek, awesome - thankyou
<jamespage> jdstrand, doko: actually we might be able to defer inclusion for wily - just trying something out
<popey> https://bugs.launchpad.net/ubuntu-mate/+bug/1501426
<ubottu> Launchpad bug 1501426 in ubuntu-mate "15.10 Beta 2 fails HTML5 audio test for MP3" [Undecided,Won't fix]
<popey> I notice that flexiondotorg is told he shouldn't ship gstreamer1.0-libav in Ubuntu MATE - but it ships in Xubuntu 15.10 and Ubuntu Studio 15.10 (the two ISOs I just tried).
<popey> Should we not be consistent between flavours? Are Xubuntu and Ubuntu Studio in a position where they are allowed somehow?
<smoser> pitti, around ?
<smoser> well, if you are around, another requst for looking at bug 1501033
<ubottu> bug 1501033 in open-iscsi (Ubuntu) "transient error results in /etc/resolv.conf not populated in iscsi root" [High,Confirmed] https://launchpad.net/bugs/1501033
<jamespage> jdstrand, doko: ryu requirement was quite soft, so have disable for this cycle
<jamespage> may need to revisit next
<robru> kenvandine: they were removed from the seed only recently after a very long deprecation period due to not wanting to break frameworks.
<kenvandine> indeed
<kenvandine> robru, i filed the bug to have it removed from the archive
<robru> great
<robru> well, sad really
<robru> but ok
<sarnold> pitti: aww, here's another bug with ~12 hours not yet retraced 1502014
<chiluk> hey slangasek I see you are patch pilot for today.. do you have a sec to give me some advice on how to package up my change for  https://bugs.launchpad.net/bugs/1432871
<ubottu> Launchpad bug 1432871 in coreutils (Ubuntu) "`df` shows bind mounts instead of real mounts." [Low,Incomplete]
<chiluk> slangasek, basically I've pushed the requisite changes to upstream coreutils and upstream gnulib.
<chiluk> slangasek, I've also backported that patch to wily... unfortunately .. the 2 patches containing the fix required 5 other patches in order to apply..
<chiluk> slangasek.. so the question is when packaging up the changes, do you want the patches merged into one super patch in debian/patches or would you prefer 7 separate debian/patches each with their own links to the upstream links?
<chiluk> infinity or arges ^^^ may also be able to answer this.
<chiluk> also keep in mind that the requisite 5 patches are all related to supporting processing of /proc/self/mountinfo, which we probably should have had in trusty era.. *(and I'll be doing that backport as soon as it soaks in wily/vivid)
<Unit193> Apt pokepoke: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1486061
<ubottu> Launchpad bug 1486061 in apt (Ubuntu) "Long descriptions missing from apt cache - affects software-center etc" [High,Confirmed]
<slangasek> chiluk: I don't want 7 separate patches if you're only fixing one bug (though others may have different opinions)
<chiluk> that's good with me.. it actually makes it easier.. since some of the patches undo parts of the other patches.. but I included them for completeness
<chiluk> slangasek^^
<chiluk> I'll make sure I reference them in the dep-3 headers.
<slangasek> chiluk: yeah, upstream pointers to the individual commits sounds good to me, but IMHO it's best to have this as a squashed patch
<chiluk> slangasek, ok will do.
<infinity> Unit193: Followed up.
<Unit193> infinity: Thanks muchly, been bothering me. :P
<infinity> Unit193: Amazingly, I hadn't even noticed the bug.  I guess my eye just skips right past the missing info.
<sarnold> I did that to myself a while back, I got tired of translation downloads timing out or whtatever, and only six months later wondered why apt-cache search was much less useful than it had been
<chiluk> slangasek, are you up for some patch piloting?  Can you take a look at https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/1432871
<ubottu> Launchpad bug 1432871 in coreutils (Ubuntu) "`df` shows bind mounts instead of real mounts." [Low,Incomplete]
<sarnold> it'd been long  enough of course that I long since forgotten about the change..
<infinity> sarnold: Oh, the translation hash sum mismatch madness should finally be fixed, FWIW.
<infinity> sarnold: On Canonical-controlled mirrors, anyway.
<sarnold> infinity: yay! is there a quick summary of the fix?
<chiluk> infinity, do you want to take another look at bug 1432871 ??
<ubottu> bug 1432871 in coreutils (Ubuntu) "`df` shows bind mounts instead of real mounts." [Low,Incomplete] https://launchpad.net/bugs/1432871
<chiluk> You rejected my previous change, and now I've gone and done it hopefully right... *(it's upstreamed now).
<Unit193> infinity: I thought about pinging you first with it, but decided I'd bothered you enough.  I'd noticed as there's a few weird new packages I wondered what they did, also noticed as apt has been more lagtastic in wily.
<infinity> sarnold: https://code.launchpad.net/~adconrad/canonical-is-charms/ubuntu-mirror/+merge/267728
<sarnold> infinity: thanks!
<infinity> sarnold: I spent years writing it off as an apt bug or something, so you can blame me for being too stupid to root-cause it ages ago. :P
<infinity> sarnold: But yay, fixed now.
<infinity> chiluk: Upstream's a good start indeed.
<chiluk> infinity, thanks.
<superm1> cyphermox: but there is no GUI that comes with it, it's just got a command line frontend with it
<cyphermox> superm1: sure. ignore me too ;)
<cyphermox> tbh by gui we meant the command-line interface
<cyphermox> it pulls in x libraries due to appstream-glib depending on gdk-pixbuf
#ubuntu-devel 2015-10-03
<sarnold> pitti: hello, 1499070 also appears to need a retrace
<hallyn> slangasek: saw a debian-devel email about "32bit UIDs in the range 65536-4294967293 are reserved for dynamically allocated user accounts."  Curious where that comes from (and if it, as it sounds like, reserves all subuids)
<fabri86live> ciao
<fabri86live> !list
<ubottu> fabri86live: No warez here! This is not a file sharing channel (or network); read the channel topic. If you're looking for information about me, type Â« /msg ubottu !bot Â». If you're looking for a channel, see Â« /msg ubottu !alis Â».
#ubuntu-devel 2015-10-04
<ansgar> Hi, I would like to ask for some packages in universe to be synced from Debian. Currently Ubuntu wily has a RC that I assume was synced manually to fix c++11 issues, but I would prefer if the final release was shipped.
<ansgar> The source packages in question are dune-{common,geometry,grid,istl,localfunctions}. dune-grid-glue would need to be rebuild and dune-{typetree,pdelab} should probably be updated as well (though they still have no new release, just a Git snapshot).
<cjwatson> ansgar: doing
<ansgar> cjwatson: Yay. Thanks!
<cjwatson> ansgar: Done all the syncs - I'll come back and sort out the rebuild later
<cjwatson> doko: Thanks for doing the dune-grid-glue rebuild.  I'd been away from my desk most of the day and hadn't quite got to it yet.
<doko> cjwatson, then any idea why dcmtk isn't migrating?
<cjwatson> doko: Nope.
<cjwatson> Seems to have a bunch of uninstallables resulting from it?
<doko> how much memory have the amd64 buildds configured? insighttoolkit4 finsihed with memory exhausted
<doko> yes, likely
<cjwatson> doko: 4GB IIRC
<doko> can we increase that?
<cjwatson> I'm not sure
<cjwatson> Probably difficult without also decreasing the number of builders
<cjwatson> Please look at making the build more efficient first
<doko> and how many cores? could try to build sequentially instead
<cjwatson> dude just do a procenv build rather than asking me :-)
<cjwatson> the actual configuration files aren't very explicit about what it ends up with and I don't remember how to compute it; I think it's 4 cores but don't quote me on that
<cjwatson> doko: maybe try reducing optimisation for the compilation unit that's failing?  I'm assuming it's gigantic with lots of templates or something
<cjwatson> doko: or split up into multiple compilation units
<doko> cjwatson, it's all swig generated code, and looking at the top output it takes up to 1.8gb. so maybe the sequential build will be good enough
<cjwatson> could be
#ubuntu-devel 2016-10-03
<Odd_Bloke> I'm seeing (Python) socket.getaddrinfo calls which are unsuccessful (i.e. "socket.gaierror: [Errno -2] Name or service not known") take 25 seconds during boot (in cloud-init), where successful ones are near-instantaneous.  I'm not really sure how to proceed in working out what's going on; does anyone have any ideas?
<Odd_Bloke> (More details of my investigation in https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1629797)
<ubottu> Launchpad bug 1629797 in cloud-init (Ubuntu) "cloud-init seems to take most of yakkety slow boot time" [Undecided,New]
<rbasak> Odd_Bloke: any network interfaces configured at that point?
<rbasak> Odd_Bloke: I wonder if the host is dropping DNS requests where on other hosts a "address unreachable" is returned immediately.
<rbasak> In which case perhaps the default or configured nameservers are wrong.
<Odd_Bloke> rbasak: So my assumption is that networking setup is somewhat sensible, because a successful query immediately after a failed one behaves as expected.
<Odd_Bloke> rbasak: How can I check what's configured?  Is /etc/resolv.conf canonical?
<rbasak> Odd_Bloke: it's only roughly canonical. It might point to 127.0.0.1 or something, stuff may not use it (Python is likely to use it though) and processes have to explicitly reload after it changes (unless that has changed in the last few years).
<rbasak> Odd_Bloke: could you perhaps arrange for a tcpdump to be running in the background from an early boot command? Not sure how that could hook in before an interface is up though.
<Odd_Bloke> OK, so it looks like 127.0.0.53 is not in resolv.conf when this resolution is happening: http://paste.ubuntu.com/23269725/
<Odd_Bloke> (127.0.0.53 being systemd-resolved)
<Odd_Bloke> And a `systemd-analyze plot` does show systemd-resolved coming up after cloud-init completes; let's see if I can change that.
<rbasak> Is that the real root cause though?
<rbasak> If it is 169.254.169.254 timing out, then why is that there?
<Laney> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Yakkety Yak (16.10) Final Beta! | Archive: feature freeze | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-xenial | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | reverse-depends/seeded-in-ubuntu broken? http://ubuntuqa.tblwd.org/ | Patch Pilots: Laney
 * Laney quivers at the queue
<Odd_Bloke> rbasak: 169.254.169.254 is the metadata service in EC2 and GCE; that's returned by the DHCP server on GCE where I'm testing.
<Laney> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Yakkety Yak (16.10) Final Beta! | Archive: feature freeze | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-xenial | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | reverse-depends/seeded-in-ubuntu broken? http://ubuntuqa.tblwd.org/ | Patch Pilots:
<Laney> will do that in a minute...
<tsimonq2> argh I missed a pilot /o\
<Odd_Bloke> Checking what I see in resolv.conf on xenial (where this problem is not exhibited).
<tsimonq2> Laney: you still around? can you still sponsor something?
<rbasak> Odd_Bloke: OK, but either GCE should be responding to *all* DNS queries to that address promptly, or cloud-init and/or cloud images should not be configuring the system to send *all* DNS queries there, or cloud-init should arrange not to send generic DNS queries that will timeout there and also make sure the system also does not do so.
<Laney> tsimonq2: 03/10 12:07:18 <Laney> will do that in a minute...
<tsimonq2> Laney: oh that's what you meant, ok sorry
<rbasak> Odd_Bloke: relying on systemd-resolved sounds like a crutch to me.
<Odd_Bloke> rbasak: So my hypothesis is that maybe on xenial DNS is configured system-wide to fail fast but on yakkety the assumption is that systemd-resolved will always be there, and systemd-resolved is configured to fail fast.
<rbasak> Odd_Bloke: sure, I agree that sounds likely. I'm just saying that it doesn't sound like the root cause.
<Odd_Bloke> So I see just 169.254.169.254 in resolv.conf on xenial, where we don't have this issue.
<Odd_Bloke> I'm not able to easily check that changing the ordering fixes the issue, because having cloud-init After systemd-resolved causes a dependency cycle.
<rbasak> I would treat systemd-resolved as a red herring, and focus on finding out what DNS queries are timing out, why they are timing out, why the system is configured to make the queries even though they will time out, and how to get them to not time out despite or regardless of systemd-resolved.
<Odd_Bloke> Yeah, 127.0.0.53 is after 169.254.169.254 in /etc/resolv.conf, so I think I'm actually seeing fast failures from the same DNS server that seems to be giving slow ones during boot.
<Laney> ok
<Laney> tsimonq2: go go go
<Laney> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Yakkety Yak (16.10) Final Beta! | Archive: feature freeze | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-xenial | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | reverse-depends/seeded-in-ubuntu broken? http://ubuntuqa.tblwd.org/ | Patch Pilots: Laney
<tsimonq2> Laney: https://bugs.launchpad.net/ubuntu/+source/hardinfo/+bug/1629601
<ubottu> Launchpad bug 1629601 in hardinfo (Ubuntu) "FTBFS due to build flags introduced in vivid" [High,In progress]
<tsimonq2> that
<tsimonq2> the only FTBFS left in the lubuntu packageset
<tsimonq2> I have to go, be back in a few hours o/
<Odd_Bloke> rbasak: http://paste.ubuntu.com/23269859/ is the diff of nsswitch.conf between xenial and yakkety; it introduces "resolve" for hosts, which is provided by libnss-resolve: "nss module to resolve names via systemd-resolved".  Removing "resolve" fixes the boot time issue. \o/
<Odd_Bloke> Hmm, there's a new systemd package with changes to do with nss-resolve; let's see if that fixes this.
<Laney> tsimonq2: that looks weird, but maybe?
<Laney> xnox: you had your fingerprints on that one ^, want to sponsor?
<tsimonq2> Laney: Martin Pitt was gonna sponsor, but it seems he didn't get the time
<tsimonq2> including him, there's a total of three acks
<tsimonq2> it's just that nobody uploaded
<Laney> :)
<tsimonq2> if somebody could just upload already... ;)
<Laney> just avoiding having to review it if someone else has :P
<Laney> if I have to I'll look
<tsimonq2> well it has been reviewed
<tsimonq2> not my changelog entry though :P
<tsimonq2> ok I really have to go
<tsimonq2> o/
<Odd_Bloke> pitti: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1629797 is severely affecting boot time of all cloud instances; would you be able to take a look (at least to confirm that my root-causing is correct)?
<ubottu> Launchpad bug 1629797 in systemd (Ubuntu) "resolve service in nsswitch.conf adds 25 seconds to failed lookups before systemd-resolved is up" [Undecided,New]
<rbasak> Odd_Bloke: I still have the same opinion. That's not the root cause. The root cause is the *reason* the DNS requests are timing out, not that switching to systemd-resolved exposes it.
<rbasak> Ah
<rbasak> You might be saying that DNS requests aren't actually going out, because systemd-resolved is unavailable?
<Laney> jbicha: are you handling https://bugs.launchpad.net/ubuntu/+source/software-center/+bug/899878 ?
<ubottu> Launchpad bug 899878 in software-center (Ubuntu Trusty) "Software center have hardcoded colors and shows white font on white bg" [Low,In progress]
<rbasak> In that case, yes, I guess that cloud-init needs to interact with nsswitch/systemd-resolved somehow to arrange for its queries to work.
<jbicha> Laney: yes
<Laney> jbicha: ok, thanks, will unsubscribe sponsors then
<jbicha> ok
<Laney> done
<Odd_Bloke> rbasak: I think they're going out, but after the resolve service has spent a while waiting for resolved to appear (or something like that).
<rbasak> Odd_Bloke: ironic given that one of the benefits of systemd-resolved is to consolidate timeouts!
<Odd_Bloke> ^_^
<sakrecoer> hi everyone, since the last member with upload rights left us a bit impromptu, ubuntu studio has been struggling with this FFe/UIFe https://bugs.launchpad.net/ubuntustudio/+bug/1624690
<ubottu> Launchpad bug 1624690 in ubuntustudio-lightdm-theme (Ubuntu) "[UIFe/FFe] Please upload ubuntustudio-default-settings" [Undecided,New]
<sakrecoer> now we finaly have all the pieces required, and i am wondering if anyone here could help us get this through before RC..
<lamont> cjwatson: pitti: I am at a loss to understand how the open-iscsi test that is failing ever worked...
<lamont> as best I can tell, it tries to install a deb that never gets built
<cjwatson> Pass, I think that postdates my fiddling with it
<lamont> wondering if you could throw the current xenial bits against an autopkgtest clone?  (as opposed to -proposed)
<Odd_Bloke> cjwatson: ISTR that in the past when we've needed a new kernel module in builders we've had to ask for it (because we can't modprobe).  Am I remembering correctly?
<cjwatson> Odd_Bloke: Correct, that's quite a complicated thing to do.  What's the requirement.
<cjwatson> ?
<Odd_Bloke> cjwatson: overlayfs.
<cjwatson> We do it in lp:~canonical-sysadmins/canonical-is-charms/launchpad-buildd-image-modifier
<cjwatson> I think.
<cjwatson> Do you remember what the last one was?
<cjwatson> Oh no, I remember, we do it in lp:launchpad-buildd.
<cjwatson> Hackily.
<cjwatson> Feel free to propose a merge against that (debian/launchpad-buildd.init) and we can discuss it.
<Odd_Bloke> cjwatson: Will do; thanks!
<LStranger> hello there
<LStranger> I'm on concern of https://bugs.launchpad.net/ubuntu/+source/openbox/+bug/1336521 - how to solve problem for users of Trusty and Xenial? I understand, next release could receive a fix soon, but many users use LTS releases, and that bug is important usability bug.
<ubottu> Launchpad bug 1336521 in pcmanfm (Ubuntu) "Application Startup Notify fully ignored" [Undecided,Confirmed]
<rbasak> stokachu: I've been asked to help you out with some upcoming Juju-related uploads. What do you need, exactly?
<stokachu> rbasak: nothing at this moment
<stokachu> waiting to hear back from juju qa
<rbasak> stokachu: ah, OK. I'll wait for a ping from you then - thanks.
<stokachu> thanks, you should also have a email i cc'd you on
<rbasak> Received, thanks. That was helpful in giving me the background but it wasn't clear to me if that implied that I was supposed to do something or not. Thank you for clarifying :)
<stokachu> :) np
<willcooke> doko_, hey.  Can you tell me if this is in good enough state to be reviewed... https://bugs.launchpad.net/ubuntu-terminal-app/+bug/1625074    If not, I will chase people to get whatever is needed done
<ubottu> Launchpad bug 1625074 in ubuntu-terminal-app (Ubuntu) "[MIR] ubuntu-terminal-app" [High,Incomplete]
<stokachu> rbasak: referring to recent juju email, is it better to wait for yakkety (or newer) to contain the proper logic for handling 32bit packages in xenial? or since its a packaging issue we can upload yakkety as is and handle the logic in xenial seperately?
<rbasak> stokachu: that's probably a question for the SRU team member who'll be accepting this into Xenial. AIUI, the usual "must be in the development release first" requirement is solely to prevent future user-visible regressions on release upgrades. I'm not sure I follow whether that rationale would be impacted in this case.
<Laney> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Yakkety Yak (16.10) Final Beta! | Archive: feature freeze | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-xenial | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | reverse-depends/seeded-in-ubuntu broken? http://ubuntuqa.tblwd.org/ | Patch Pilots:
<stokachu> rbasak: yea im not sure either, but if it was me I would want it in yakkety before pulling it into xenial
<stokachu> slangasek: question for you when you're available
<slangasek> stokachu: hullo
<stokachu> slangasek: o/, so background: juju is dropping 32bit support in yakkety which they want to also drop in xenial
<slangasek> stokachu: I don't care about having the juju 32-bit-package-removal package glue in yakkety, provided this gets done before yakkety release
<stokachu> do i ask that they put that xenial logic in yakkety berore uploading?
<slangasek> and provided you think the SRU process gives you adequate testing
<stokachu> slangasek: for me I would feel better that they glue was in there before I do another upload to yakkety
<stokachu> i'd like to have all the unknowns worked out without having to do multiple yakkety uploads
<slangasek> stokachu: well, for yakkety you can just drop the 32-bit builds completely
<slangasek> and it's appropriate to then have them added to the 'obsolete packages' list in update-manager so that do-release-upgrade will remove them for you on upgrade to yakkety, just in case
<stokachu> ok
<stokachu> so they've completed the dropping of 32bit packages, ill make sure it gets added to obsolte packages in update-manager
<stokachu> then work with them to handle the logic in xenial
<nacc> rbasak: i had an idea this morning for how to integrate MRs into the git workflow -- if you're around, I'd like to bounce them off of you
<nacc> jgrimm: fyi, now that python-oslo.privsep's MIR has been approved (LP: #1616764), cinder, nova, nova-lxd should all migrate and drop off the ftbfs list
<ubottu> Launchpad bug 1616764 in python-oslo.privsep (Ubuntu) "[MIR] python-oslo.privsep" [High,Fix committed] https://launchpad.net/bugs/1616764
<jgrimm> nacc, cool cool
<nacc> coreycb: i assume you saw that python-taskflow grew a (new?) dep on python-pydotplus which is in universe?
<nacc> coreycb: so it's stuck in -proposed
<coreycb> nacc, <insert bad word>  I'll take a look, thanks :)
<nacc> coreycb: thanks!
<coreycb> nacc, I was going to take a pass through our stuck in proposed today anyway, so off I go to do that
<nacc> coreycb: 2x thanks then :)
<coreycb> :)
<coreycb> xnox, have any tips for getting an s390 machine to test out autopkgtest changes?
<nacc> coreycb: cpaelzer may be able to help, when he's back online, too
<nacc> jgrimm: --^
<coreycb> nacc, thanks that would be great
<nacc> coreycb: let me look if it's documented anywhere
<coreycb> nacc, thanks, and if not,  I can follow up tomorrow
<nacc> powersj: --^ or maybe you know?
<ngaio> On today's (and previous) daily images I'm running into an infinite loop with glxinfo such that no desktop shows on login. Which package should I report this against so it has a fighting chance of being fixed by release?
<dobey> ngaio: final freeze is in two days, so unless you have a patch already, i wouldn't get hopes too high of it being fixed
<dobey> ngaio: but probably should be filed against whatever package provides glxinfo, or your drivers.
<xnox> coreycb, if you are a coredev go to https://bileto.ubuntu.com/ create a ppa, upload, and it will be built & tested on s390x.
<xnox> coreycb, or open a bugreport with debdiffs/things to look into
<slangasek> xnox: hmm, that seems like the wrong acl, nah?  should be open to all ubuntu-dev, not just core-dev :)
<ngaio> dobey, running an Nvidia Quadro 1000M here (2011 era), and given it's from the live CD it must be using the free drivers
<ngaio> dobey, so you suggest I file it against nouveau?
<xnox> slangasek, enoclue. I think any can create the ppa, but a core-dev is needed to dput in any _source.changes.
<dobey> ngaio: sounds reasonable, yes
<xnox> slangasek, if building from "source packages" rather than branches.
<xnox> but maybe that has been changed.
<ngaio> dobey, thank you
<dobey> xnox: doesn't need to be a coredev, but it's currently only coredevs and trainguards that can upload directly to silo PPAs
<xnox> ack.
<xnox> coreycb, i'm happy to sponsor things into a silo =)
<dobey> and you need to be in some other group to create requests on bileto
<robru> dobey: xnox: core dev can do anything
<slangasek> xnox: ahh right, hmm I wonder if all of ubuntu-dev should be allowed there or not... probably so but we might have to check for assumptions
<xnox> slangasek, not until launchpad ppa copies with new binaries end up in new queue.....
<slangasek> xnox: right, that
<dobey> robru: right; was just clarifying that it's not only core devs that can do what was requested.
<robru> slangasek: also not until we get some kind of ACLs to that tickets aren't world-writable
<slangasek> xnox: otoh new binaries == packaging diff; the acl for upload to ppa doesn't have to match the acl for publishing
<slangasek> robru: I don't see a clear reason why we should trust ubuntu-core-dev with write access to tickets, but not ubuntu-dev?
<robru> slangasek: because ubuntu-dev is an order of magnitude larger than ubuntu-core-dev? (isn't it?)
<dobey> robru: but why does that matter?
<slangasek> robru: it is, but the only trust boundary here is about which /particular/ packages they're trusted to upload to the Ubuntu archive
<robru> dobey: because anybody who can access bileto can edit all tickets? the more people that is the more we have to trust all of them
<dobey> robru: well you're already trusting them by running the software they uploaded to the archive, i guess? :)
<robru> slangasek: so you're saying you're fine with all of ~ubuntu-dev having write access to all tickets? I've been worried about the security of this for awhile...
<slangasek> robru: I'm saying I'm equally ok with ubuntu-dev and ubuntu-core-dev having access; I may be missing the nuances of why the write access is a problem, but if it's a problem for ubuntu-dev I think it's a problem also for ubuntu-core-dev :)
<slangasek> because the average ubuntu-core-dev is no more in touch with bileto process than the average ubuntu-dev
<dobey> robru: i mean, they can just straight skip ci train and upload to the archive without any problem
<robru> slangasek: I guess I'm just not very familiar with what ubuntu-dev is but just in general the more people who have write access to bileto the more worried about it's insecurity I become.
<dobey> it's too bad each silo ppa can't reasonably be owned by a different team
<robru> dobey: yes that's a feature I've had on my mind for a while.
<slangasek> coreycb: why does nova-lxd not have autopkgtests?
<dobey> robru: can you not make tickets themselves only be writable by the creator of the ticket and any additional people in the irc nicks field?
<dobey> robru: maybe make that field be launchpad usernames instead of irc nicks?
<robru> dobey: no, because irc nicks can be trivially spoofed. I need to add a field in the db for team ownership of the ticket.
<dobey> robru: sure, but i mean if they were validated as usernames against lp, and only those people could modify the ticket (and thus add more usernames), that seems like it would be a "decent enough" ACL implementation
<slangasek> xnox: robru has reminded me that if you can put to bileto, you can make changes to the *upstream* source and push it to the archive without bileto saying boo; so yeah, the more restrictive acl seems necessary
<dobey> robru: you could even steal the little ajax widget to search for people on launchpad :)
<robru> dobey: I'd rather not change the semantics of the irc nicks field because that field is currently only used to ping people in the #ubuntu-ci-eng channel and changing those from irc nicks to lp names would break irc pings for a lot of people
<dobey> robru: oh ok. well another field then, and auto-fill irc nicks from the LP info :)
<jbicha> robru: LP has an IRC field?
<robru> jbicha: yes, in your account you can list your IRC nicks on various networks, but it's just a string field and anybody can put anything there. bileto checks for freenode nicks of ticket creators and records that in the ticket, it's purely for notification purposes, as it is trivially spoofed
<robru> jbicha: https://launchpad.net/~jbicha yours is listed for irc.ubuntu.com
<jbicha> right
<dobey> robru: i guess you'll have to port queuebot to telegram, and send message to people there. irc is old and busted
<robru> dobey: sigh, yes.
<nacc> caribou: can you give me some context for the dependency of clamav on llvm-3.6 (as opposed to 3.8 (which i think is what llvm-dev is currently pointing to) or 3.9)?
<nacc> caribou: i'm asking because llvm-toolchain-3.6 ftbfs in y (testcase failures), and the only reason its in main is clamav
<cjwatson> dobey,robru: Now that landing PPAs are ephemeral, I think you could probably reasonably use Archive.newComponentUploader or something to grant upload access to the landers of each individual ticket.
<cjwatson> (Though only if you knew the landers' Launchpad usernames.)
<robru> cjwatson: would that work for teams?
<cjwatson> Sure
<cjwatson> You'd probably still want the option to have more than one person-or-team though
<robru> cjwatson: so newComponentUploader grants upload rights to a person or team on just one archive without adding that team as a member of the ppa-owning team?
<robru> cjwatson: i wasn't aware it was possible to have upload rights to a ppa without being a member of the owning team
<cjwatson> robru: Right, it's an obscure API-only feature but it works fine.
<robru> cjwatson: thanks, I'll note that down so i don't forget
<cjwatson> The component will have to be 'main', of course.  (Or equivalently you can use newPocketUploader with pocket='Release'.)
<cjwatson> Since it's obscure and API-only it hasn't been polished much, hence the slightly weird options :)
<cjwatson> I never suggested it for non-ephemeral landing PPAs because it doesn't show up in the web UI so added uploaders would be liable to be forgotten about.
<slangasek> wow :)
<robru> Ah
<tsimonq2> ooh new Kubuntu dev :D
<bdmurray> xnox: Have you had a chance to retest bug 1620525?
<ubottu> bug 1620525 in linux (Ubuntu Yakkety) "sbuild with overlayfs fails in yakkety" [Critical,Triaged] https://launchpad.net/bugs/1620525
<xnox> i switched to unionfs =)
<xnox> let's see.
<xnox> bdmurray, i think it works now on xenial.
<xnox> will retest with a yakkety kernel on yakkety too.
<bdmurray> xnox: thanks
<LStranger> Oh, some people woke up so may be I can get some answer. :) I'm on concern of https://bugs.launchpad.net/ubuntu/+source/openbox/+bug/1336521 - how to solve problem for users of Trusty and Xenial? I understand, next release could receive a fix soon, but many users use LTS releases, and that bug is important usability bug.
<ubottu> Launchpad bug 1336521 in pcmanfm (Ubuntu) "Application Startup Notify fully ignored" [Undecided,Confirmed]
<LStranger> Maintainer in Debian promiced to push update into sid and stable soon but as for Ubuntu I have no idea whom to ask about LTS updates.
<bdmurray> Is there a related debian bug report?
<sarnold> LStranger: best would be to take a fix from the debian developer, prepare a debdiff for the ubuntu packages, build them locally, make sure it works, then post the debdiff to the bug and ask a sponsor to build it for everyone
<LStranger> Yes, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=838326 is it.
<ubottu> Debian bug 838326 in openbox "Openbox does not support startup notifications." [Important,Open]
<xnox> bdmurray, yakkety is bad
<xnox> wait i might be wrong
<LStranger> In fact, I rebuilt the package for Trusty and use it, so I'm positive it works, and it should so for Xenial, not checked it yet but relevant place in Openbox haven't changed. I'll check it, sure, tomorrow I think.
<bdmurray> LStranger: you might have a look at the following wiki page https://wiki.ubuntu.com/StableReleaseUpdates#Procedure.  Specifically, a test case would be helpful.
<LStranger> bdmurray: oh, thank you, will do.
<xnox> bdmurray, all is good on yakkety too.
<coreycb> slangasek, I agree nova-lxd needs autopkgtests.  we're planning to put some focus on improving autopkgtests next for all openstack core packages next cycle.
<slangasek> coreycb: ok, great :)
<coreycb> xnox, awesome thanks I'll try that out tomorrow
#ubuntu-devel 2016-10-04
<pitti> Good morning
<pitti> Odd_Bloke: 1629797> queue, will reply there
<pitti> lamont: indeed, it seems that test was written and tested only with locally built binaries, not with binaries from the archive -- this is just broken
<pitti> lamont: this was introduced in http://launchpadlibrarian.net/250336367/open-iscsi_2.0.873+git0.3b4b4500-14ubuntu1_2.0.873+git0.3b4b4500-14ubuntu2.diff.gz
<pitti> cyphermox: https://launchpad.net/ubuntu/+source/open-iscsi/2.0.873+git0.3b4b4500-14ubuntu5 â please let's not do that
<pitti> cyphermox: building the package to work around that broken assumption in the test is quite expensive -- also, it doesn't even work
<didrocks> good morning pitti! Had a nice week-end?
<pitti> didrocks: bonjour didrocks! yes, I enjoyed having a quiet day yesterday (German Reunion), last week was pretty intense :)
<didrocks> yeah, a nice rest after an intense week I guess ;)
<Mirv> there's zero flavors nowadays that'd have the alternate installer?
<Mirv> oh yes there is, lubuntu, just not in daily build dircetory
<Mirv> (because of bug #1530530 can't boot any normal Ubuntu installer, only final installation)
<ubottu> bug 1530530 in gfxboot-theme-ubuntu (Ubuntu) "Installer doesn't show up on some Chromebooks: "Error setting up gfxboot"" [Medium,Confirmed] https://launchpad.net/bugs/1530530
<Mirv> doh, that uses gfxboot too, so actually the only option is still USB -> USB installation, then copying to target HDD and hacking grub. or maybe a ready made image could be copied too, and of course if gfxboot could be disabled.
<dholbach> good morning
<dholbach> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Yakkety Yak (16.10) Final Beta! | Archive: feature freeze | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-xenial | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | reverse-depends/seeded-in-ubuntu broken? http://ubuntuqa.tblwd.org/ | Patch Pilots: dholb
<dholbach> looks like the topic is a bit long
<slangasek> s/(16.10 )// ? :)
<ginggs> reverse-depends/seeded-in-ubuntu are working again, can remove that
<Mirv> pitti: is there an issue starting autopkgtests right now? yesterday evening was fine, but now that I'm trying to restart a test from https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_39a8dbb93caf4ec889f8a1b7f69885db/bileto-2035-excuses/2016-10-04_06:35:02/2035_vivid_excuses.html for bzoltan it doesn't seem to start (waited 5+ mins and tried twice)
<pitti> Mirv: no known one -- did you get a confirmation page that the request was sent?
<Mirv> pitti: yes
<Mirv> http://people.ubuntu.com/~timo-jyrinki/autopkgtest.png
<pitti> Mirv: ack, I'll have a look
<pitti> cyphermox: I removed your open-iscsi upload from -proposed; I suggest talking to matsubara instead to actually fix the test -- they should *never* assume a structure in the upper tmpdirs, and never fiddle with test dependencies themselves
<pitti> you will either have the distro or the locally built .debs already installed, and if not, just use apt-get install for them
<pitti> cyphermox: i. e. here: http://launchpadlibrarian.net/250336367/open-iscsi_2.0.873+git0.3b4b4500-14ubuntu1_2.0.873+git0.3b4b4500-14ubuntu2.diff.gz
<pitti> it's even marked with "XXX fix this hack"
<cpaelzer> pitti: thanks for your explanation on the netplan bug, I replied and forwarded to IBM if they really need anything
<pitti> hey cpaelzer, guten Morgen!
<cpaelzer> pitti: hallÃ¶chen
<cpaelzer> my good morning today was creating an emergency GBE-over-luster-terminal fix so I skipped any good morning feelings :-/
<andrewsh> https://bugs.launchpad.net/ubuntu/+source/unity/+bug/887821 is said to be fixed, yet I observe that still happening
<ubottu> Launchpad bug 887821 in unity (Ubuntu) ""Show copy dialog" right click launcher entry doesn't work (on nautilus copy)" [High,Fix released]
<andrewsh> who should I prod to have it looked at?
* infinity changed the topic of #ubuntu-devel to: Yakkety Yak (16.10) Final Beta! | Archive: feature freeze | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-xenial | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | Patch Pilots: dholbach
<pitti> Mirv: http://autopkgtest.ubuntu.com/running#queue-ppa-vivid-amd64 â your request actually is there
<pitti> Mirv: so that's another aspect of that weird rabbitmq queueing bug in xenial :(
<Mirv> pitti: oh, ok, at least once it's indeed in the queue. I obviously didn't check for queues as it seemed the infra was free.
<pitti> Mirv: it actually wasn't visible in the queue -- that's part of the bug
<Mirv> ok
<andrewsh> pitti: when do you expect to upload the second bit of the systemd fix to xenial?
<pitti> andrewsh: still coordinating with sbeattie on bug 1628687
<ubottu> bug 1628687 in systemd (Ubuntu Xenial) "Assertion failure when PID 1 receives a zero-length message over notify socket" [High,In progress] https://launchpad.net/bugs/1628687
<pitti> andrewsh: I'm fine with SRUing that today, but I'm not sure if sbeattie wants to push it out of band as an USN
<andrewsh> pitti: I'm asking from position of a user and a downstream (we cherry-picked fixes from the Debian package)
<pitti> andrewsh: I see no rush in this (hence I'd be fine with SRUing); this is really not a big deal
<andrewsh> ack
<pitti> plugging one out of a dozen ways to DoS your local machine isn't going to make things any different :)
<pitti> so bug, yes; security, clearly not
<pitti> but given how much press echo this got, some people might think otherwise, and sbeattie might want to fix it solely to quiesce the peanut gallery :)
<ara> Hello! Can any of the SRU team members approve snap-confine in xenial-proposed, please? https://launchpad.net/ubuntu/xenial/+queue?queue_state=1&queue_text=snap-confine
<sil2100> xnox: hey!
<sil2100> xnox: do you feel you're a good person to do an upstart merge-proposal review? ;)
<sil2100> xnox: I'm looking for a volunteer that knows upstart code to take a look at a branch for our xenial-touch-systemd work
<xnox> sil2100, ..... ok
<LocutusOfBorg> hi jbicha, any idea for the link-grammar failure in autpkgtestsuite?
<jbicha> LocutusOfBorg: I wouldn't have synced it, sorry I didn't let you know in advance
<jbicha> LocutusOfBorg: maybe it's https://github.com/opencog/link-grammar/issues/437
<sil2100> xnox: https://code.launchpad.net/~vicamo/upstart/xenial-escape-systemd-strings/+merge/307140 <- this is for the xenial upstart branch, we can also propose and release that to trunk but from our POV it's not the main target
<sil2100> xnox: thanks! :)
<xnox> sil2100, it seems like it is implementing systemd-escape for the unit names the right way?
<pitti> Mirv, slangasek: I went through https://www.rabbitmq.com/consumer-prefetch.html and similar docs, and I belive I may have found the reason for the hidden test requests; restarted the workers now, let's see how it goes
<caribou> nacc: looking at it, maybe I can figure out how to build with the latest llvm
<Mirv> thank you
<sil2100> xnox: it's for the upstart-local-bridge basically
<sil2100> xnox: could you take a look at it and review?
<sil2100> We need this to land to get the systemd xenial phone switch happening
<caribou> nacc: well, looks like debian is still building with llvm-3.6 and building with 3.7 will require sensible code change :
<caribou> nacc: https://www.mail-archive.com/pkg-clamav-devel@lists.alioth.debian.org/msg04458.html
<dholbach> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Yakkety Yak (16.10) Final Beta! | Archive: feature freeze | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-xenial | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | Patch Pilots:
<pitti> Mirv: do you need to do something to get https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_39a8dbb93caf4ec889f8a1b7f69885db/bileto-2035-excuses/2016-10-04_06:35:02/2035_vivid_excuses.html updated?
<pitti> Mirv: oh, it's a per-timestamp file, I suppose we want the latest one
<pitti> ah, from https://bileto.ubuntu.com/#/ticket/2035
<sil2100> xnox: hey! Did you have a moment to take a look at the upstart MP? ;)
<xnox> sil2100, not yet. if i'll be landing it, i'll prepare a silo with said upload targetting yakkety and xenial.
<pitti> Odd_Bloke: I followed up on the bug; the root cause is clear, but how to fix it (cleanly) totally isn't
<ximion> Laney: asgen fails at Debian with an error in LZMA now (code 11, LZMA_PROG_ERROR), which indicates a corrupt internal state
<ximion> so, there is definitely be something fishy in the zarchive code
<acheronuk> why would a test such as this just time out? https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety/yakkety/amd64/k/kwin/20161004_005822@/log.gz
<Odd_Bloke> pitti: Yeah, I saw the response; thanks for looking at it. :)  It's frustrating that resolved can't modify the resolution order once it's up.
<pitti> Odd_Bloke: resolved isn't up yet
<pitti> and even if it was, it doesn't matter -- cloud-init blocks dbus, so nothign can talk to it
<pitti> Odd_Bloke: I'm trying something else
<Odd_Bloke> pitti: Cool. :)
<pitti> oh cool, this actually works
<sil2100> xnox: would be great - xenial or the xenial-overlay? I guess I could take the xenial package from the queue and copy it to the overlay earlier
<xnox> sil2100, is there a current difference of upstart between xenial and xenial-overlay?
<xnox> sil2100, where is the xenial-overlay archive?
<sil2100> xnox: no, I guess we use the main xenial upstart right now
<sil2100> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/stable-phone-overlay
<pitti> Odd_Bloke: followed up again with something relative unintrusive to test
<sil2100> We put packages for touch there as it's faster than waiting for it to go out as an SRU
<xnox> sil2100, but also means no security support?
<sil2100> xnox: there are no xenial products anywhere so we don't really care about security support
<sil2100> And right now it's an 'in-progress' development product
<Odd_Bloke> pitti: Trying now.
<sil2100> xnox: anyway, just release for normal xenial for now, I then pick up the SRU and copy to overlay to get it faster in our images for testing
<infinity> xnox: Hey you, upload your staged yakkety d-i changes.
<xnox> infinity, yo, it's in unapproved queue
<infinity> xnox: Oh, indeed, an hour ago.  Kay.
<Laney> hi ximion
<Laney> fun, reproducible?
<ximion> Laney: maybe 60% of the times...
<ximion> hmm, no
<ximion> 1 out of 3 runs succeeded
<ximion> only difference was compilation with the latest LDC snapshot
<ximion> Laney: the post on the D newsgroup has some helpful advice, but unfortunately nothing which raised a red flag yet
<smoser> pitti, around ?
<rharper> smoser: we need to run *before* basic for mount, but we need after systemd-resolved for DNS resolution (this is in cloud-init.service)
<rharper> the GCE Datasource triggers this when it happens as it's metadata URL is a hostname
<rharper> vs. ips like in EC2 and OpenStack
<jbicha> have we hit the language pack translation deadline for yakkety final yet?
<Odd_Bloke> smoser: rharper: pitti and I are working on the slow boot time issue, if that's what you're looking to chat about.
<smoser> Odd_Bloke, was it slow boot on gce ?
<smoser> they're related then.
<Odd_Bloke> smoser: Everywhere.
<smoser> well, its not everywhere.
<Odd_Bloke> OK, anywhere with the GCE datasource in the list.
<smoser> (fwiw, openstack does not show "slow boot" at least in serverstack, and neither does lxc)
<Odd_Bloke> Or the EC2 datasource.
<smoser> so the bug is bug 1629868
<ubottu> bug 1629868 in cloud-init (Ubuntu) "times out because of no dbus" [Undecided,New] https://launchpad.net/bugs/1629868
<smoser> and i'm pretty sure that htat is because cloud-init.service is now running before dns is up
<Odd_Bloke> smoser: The fix that pitti has proposed is to put Before=dbus.socket in cloud-init.service.
<smoser> because of a change made in bug 1611074
<ubottu> bug 1611074 in cloud-init "Reformatting of ephemeral drive fails on resize of Azure VM" [High,Fix committed] https://launchpad.net/bugs/1611074
<smoser> Odd_Bloke, probably After=
<smoser> no?
<smoser> rharper, had suggested systemd-resolved.service
<Odd_Bloke> smoser: Nope; systemd-resolved won't come up until well after cloud-init because of other dependencies.
<Odd_Bloke> smoser: The problem is that the resolve nss module sees the DBUS socket and waits 25 seconds for a response over it.
<smoser> the change that caused this was (i think)
<smoser>  - Move cloud-init.service to early boot: Add DefaultDependencies=no and Before=basic.target
<Odd_Bloke> (Which there won't be, because dbus.service won't start until after cloud-init.service)
<smoser> ah.
<Odd_Bloke> Whereas if there isn't a DBUS socket, the resolve nss module fails fast.
<Odd_Bloke> And we just use DNS directly.
<smoser> well that is just messed up.
<smoser> hm.
<rharper> smoser: I reproduced the slow boot on serverstack, and it is the GCE datasource due to the attempt to resolve the hostname
<smoser> before=debus.socket seems not so right.
<smoser> it seems like a very specific fix for the way it happens to work right now.
<smoser> rharper, why didnt i see it on friday then?
<rharper> smoser: agreed; cloud-init.service *needs* DNS
<smoser> in that system with the wierd clock that you saw.
<Laney> ximion: GC getting in the way somehow?
<smoser> it needs dns, but it does not need systemd-resolvd
<Odd_Bloke> resolved is not the only way of getting DNS.
<smoser> (doesn't need a caching name service)
<rharper> smoser: AFAICT it's racy w.r.t when systemd-resolved comes up
<smoser> so i suspect that Odd_Bloke, rharper and smoser are not really adding anything to pitti's brain
<rharper> well, it seems odd to dance around the idea that we want DNS but we don't have a direct way of expressing that
<smoser> so mostly i think we're just chattering without his input :)
<Odd_Bloke> It shouldn't be racy; cloud-init has to complete for basic.target, and systemd-resolved happens after basic.target.
<rharper> dbus.socket doesn't seem to be DNS related at all (unless you know how)
<smoser> rharper, right.
<smoser> its not.
<smoser> the fix that Odd_Bloke suggested was to put 'before=dbus.socket'
<smoser> so that when nss runs it does not see the socket
<smoser> and wait for a response over it
<smoser> rather it just goes on
<rharper> huh
<rharper> still seems obtuse
<smoser> right
<ximion> Laney: according to https://forum.dlang.org/post/igqwbqawrtxnigplgnka@forum.dlang.org it doesn't do that
<Odd_Bloke> The last comment on https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1629797 is relevant: "Moving dbus.service into early boot would be a bold step, and I don't think such a large change is appropriate two weeks before release."
<ubottu> Launchpad bug 1629797 in systemd (Ubuntu) "resolve service in nsswitch.conf adds 25 seconds to failed lookups before systemd-resolved is up" [Undecided,Triaged]
<rharper> https://github.com/systemd/systemd/issues/848
<ximion> Laney: oooooooh!!! Ilya (working on numeric stuff in D) has posted some very interesting hint for the deadlocking stuff there: https://issues.dlang.org/show_bug.cgi?id=15939
<ubottu> issues.dlang.org bug 15939 in druntime "GC.collect causes deadlock in multi-threaded environment" [Blocker,New]
<ximion> Laney: haven't seen deadlocks for a while though
<Laney> not with ldc
<smoser> Odd_Bloke, thanks for the bug pointer
<smoser> it just seems so hacky and randomly specific
<rharper> the Before=dbus.socket works on my openstack instance where it was hanging
<Odd_Bloke> Yeah, I've confirmed it works on GCE and EC2.
<xnox> robru, when i say yakkety+xenial as target, does it mean Ubuntu Archive for both?
<pitti> smoser: yes, around, just slowly responding due to too many parallel pings
<smoser> pitti, your suggested fix sseems to work, but it just seems somewhat random
<smoser> do you disagree?
<pitti> Odd_Bloke, smoser: yes, it is obtuse; we are doing this at a point where the entire early boot is blocked on cloud-init, which wants to run before networking, dbus, etc., but still use the network
<pitti> smoser: it is somewhat random, yes; I just don't have a better idea right now (see the bug)
<pitti> for now I'm just interested if that makes the hangs go away
<smoser> we started running before basic.service so that we could run before local mounts were done (so that the ephemeral/removable things in /etc/fstab would not be already mounted at that point)
<pitti> a better fix might be to move dbus.socket into late boot, but I don't know how many other things during early boot want to talk to dbus; that seems a bit too risky to do two weeks before release
<smoser> i agree with that being too risky
<smoser> but i dont know that i agree it'd be a better fix.
<pitti> well, ideas appreciated
<pitti> we can revert resolve, thus punting
<pitti> .. that spec to the next cycle (and running into it again)
<smoser> it seems to me that if the issue is (as i understand it) systemd-resolvd
<pitti> or run dbus.service earlier, or dbus.socket later
<smoser> that nss should do a better job of determining "should i try to talk to resolvd" than just saying "oh look a dbus socket!"
<pitti> moving dbus.service earlier or the socket into late boot seem too intrusive
<smoser> s/nss/the resolvd nss module/
<pitti> reverting resolve and punting to the next release, or running cloud-init before dbus.socket are less intrusive
<pitti> smoser: well, tell me how
<pitti> (also, as I said -- I just asked for testing this change to confirm it's really *that* problem -- I didn't say it was the final solution)
<smoser> well, hackily, systemd-resolvd.service could otherwise advertise its "up" (via a /run/yes-im-up-now)
<smoser> and nssmodule could require that before starting
<smoser> or, if the dbus socket was there...
<smoser> it could ask systemd: what is the status of the systemd-resolvd.service ?
<smoser> and if not started, not bother
<pitti> no, you can't
<pitti> as that also uses dbus
<pitti> so you need a side channel
<smoser> the issue isnt dbus
<smoser> right?
<pitti> it is
<smoser> the issue is the socket
<smoser> wait.
<pitti> well, it's "communicating over dbus"
<pitti> dbus.socket is running, but dbus.service cannot start yet
<smoser> communicating over dbus? or communicating over dbus to a service that is not started yet.
<smoser> ok. i thought it was communication specifically targetted at the not-yet-started systemd-resolvd
<smoser> rather than general dbus chatting.
<pitti> no, that's not the problem
<pitti> if resolved isn't running, it fails fast and punts to "dns"
<pitti> it == nss module
<smoser> oh.
<smoser> so it *does* ask systemd over the socket about resolved's status ?
<smoser> s/socket/dbus/
<pitti> yes, it tries to do a dbus call to resolved
<pitti> if the destination isn't running, that's fast
<pitti> but if dbus itself isn't running, the client libraries time out after 25 s
<smoser> and dbus.service isnt running just because
<smoser> do we have a reason that it needs basic.service ?
<pitti> becase cloud-init runs before=basic.target (and lots of other things) in early boot
<smoser> sorry. basic.target
<smoser> do we have a *known* reason
<pitti> no, see the bug -- it could be started earlier on, I just can't say if that breaks anything else
<pitti> kdbus *cough* *cough*
<pitti> so if we want to move dbus.service into early boot and that works for server/desktop etc. we can also try that
<ogra_> wasnt that renamed to kdbus2^Wbus1  ... ?
<pitti> ogra_: yes, but bus1 is not a drop-in replacement for dbus; will still take a bit until this will actually be useful
<ogra_> like kdbus :)
<pitti> well, kdbus worked great, it just wasn't accepted upstream :)
<pitti> there were also some design issues about it, but playing with the dkms module was fun
<bdmurray> mvo, sergiusens: Is bug 1580740 fixed in Yakkety?
<ogra_> well, i just dont get why they renamed it and not just simply changed the implementation keeping the name
<ubottu> bug 1580740 in Snappy "[SRU] Cannot open a browser link from a snap that provides a link" [High,Triaged] https://launchpad.net/bugs/1580740
<smoser> pitti, is our dbus.service provided by upstream ?
<smoser> wondering if we have delta there.
<pitti> smoser: yes, https://cgit.freedesktop.org/dbus/dbus/tree/bus/dbus.service.in
<nacc> caribou: thanks! yeah, i dug a little yesterday and realized after i pinged you that upstream only has up to 3.6 support
<gQuigs> doko_: any plans to try to upgrade python for 14.04 anymore?  https://bugs.launchpad.net/ubuntu/+source/python2.7/+bug/1348955
<ubottu> Launchpad bug 1348955 in python2.7 (Ubuntu) "update Python for trusty" [Undecided,Confirmed]
<nacc> caribou: we're seeing the ftbfs in llmv-toolchain-3.6 in y's test rebuild, hence my question
 * gQuigs would really like TLS1.2 support, which would help Juju 1.25 a bit...
<sergiusens> bdmurray it is not related to snapcraft, I hope it is; it involves bits in the core snap and the desktop to be installed (hopefully pulled in by snapd)
<rbasak> jamespage: in bug 1567811, could nova be impacted (ie. part of the regression risk)? If so, is nova being tested against xenial-proposed, and if not, do you have any opinion on whether this should be accepted into xenial?
<ubottu> bug 1567811 in libvirt (Ubuntu Xenial) "nova-compute should depend on libvirt-bin.service instead of libvirtd.service " [Low,Fix committed] https://launchpad.net/bugs/1567811
<bdmurray> sergiusens: I'm not sure I am following your response.
<sergiusens> bdmurray you asked if the aforementioned bug was fixed in yakkety, my response is, I don't know, I hope it is, I am not involved at all with that bug
<sergiusens> :-)
<bdmurray> sergiusens: got it
<nacc> cpaelzer: i think you might have been offline, but coreycb was looking for some help getting access to a s390 node, if possible
<nacc> cpaelzer: for debugging a autopkgtest on s390, iirc
<coreycb> nacc, yeah that'd be great if possible :)
<pitti> sbeattie: can you please let me know if you really want an USN for bug 1628687? otherwise I'll SRU it (but I don't want to go through the procedure a third time)
<ubottu> bug 1628687 in systemd (Ubuntu Xenial) "Assertion failure when PID 1 receives a zero-length message over notify socket" [High,In progress] https://launchpad.net/bugs/1628687
<lamont> pitti: it would be wonderful if there was something I could tell systemd (maybe via the kernel commandline?) that would cause it to actually run "systemctl status $FOO", instead of just telling me to
<robru> xnox: no, if there is a plus sign in your series, the first series is archive and all subsequent series are overlay ppa. It says which packages target which archive in the build log
<xnox> robru, =(
<robru> xnox: if you really need to do a xenial sru you can just copy from xenial overlay after publishing
<slangasek> robru: no, he can't
<slangasek> SRUs are not supposed to build against the overlay ppa
<slangasek> which may have different ABIs etc
<slangasek> I think there's meant to be a toggle for this in the list of upload targets?
<robru> Oh right. Well reuse the same mp for a second xenial ticket then
<robru> slangasek: the toggle only works if the ticket has one series. Dual/triple tickets are always hardcoded to overlay
<slangasek> right
<robru> slangasek: it's been on my mind for a while to allow specifying such special cases, but low priority
<slangasek> robru: considering I don't think the current dual/triple landings are a good idea anyway, I'd rather we not implement more such options that aren't being asked for :)
<robru> slangasek: it is being asked for, you just saw xnox ask for it, and he isn't the first one
<robru> slangasek: i think devel+stable is reasonable, but having vivid and yakkety together on the same ticket is really pushing the limits of what makes sense
<slangasek> robru: I'm pretty sure xnox isn't actually asking for that.
<slangasek> I'm pretty sure he just wants to do source uploads for both xenial and yakkety
<slangasek> he doesn't need any of the "dual landing" branch stuff
<robru> slangasek: he's frowned because he has no way to make a ticket that says yakkety archive + xenial archive
<nacc> doko_: re: python-cffi ftbfs, just did a testbuild with gcc-5 and it does build/pass the tests. I'm not sure how to debug the testcase regression due to the compiler?
<slangasek> robru: yes, but his use case is well served by having two tickets
<robru> xnox: are you wanting to land one mp to yakkety and xenial or are you planning on doing source uploads?
<coreycb> xnox, how long should I expect https://bileto.ubuntu.com to take to run autopkgtests against a ppa?
<robru> coreycb: ten million years, give or take
<coreycb> robru, lol, right on schedule then
<robru> coreycb: what ticket?
<coreycb> robru, https://bileto.ubuntu.com/#/ticket/2042
<robru> coreycb: you have to actually lander approve it before britney will pick it up, and expect it to take a good two hours before the tests even start
<coreycb> robru, gotcha, thanks for looking
<robru> coreycb: oh actually the britney run time is currently 15 minutes so that's a damn miracle
<coreycb> robru, ah excellent.  still not the best way to debug an autopkgtest faliure though it's definitely good for testing against a ppa.
<robru> coreycb: yeah so in about 15 to 30 it'll change from queued to running, and then however long your tests take, then you'll get the results. There are unfortunately a lot of delays polling the autopkgtests for the results
<slangasek> coreycb: the MIR for python-pykmip as a recommends of barbican seems stalled (last reply from jamespage on 20Sep).  Who can take care of this?
<nacc> doko_: nm, i think in coordination with upstream, we me have found the issue
<coreycb> slangasek, I'll take a look
<slangasek> coreycb: thanks
<bdmurray> happyaron: Your upload of fcitx in the xenial-proposed queue is missing the Launchpad-Bugs-Fixed line.
<jbicha> bdmurray: I suggest emailing happya_ron since I believe he's out this week
<Laney> Probably easier to reupload for him
<sbeattie> pitti: if you want to take it through the SRU process instead, that's fine. I won't make you respin your SRU again.
<smoser> pitti, so what do you think we should do here ?
<smoser> for the dbus bug... do you think the before= is right ?
<juliank> I'm thinking about doing an apt 1.3.1 release to go into the final to fix an issue with the auto-detect-proxy script which now accidentally reads from the helper's stderr as well when reading proxy line strings.
<juliank> https://github.com/julian-klode/apt/commit/a789a9dfdab4898c343f34d9ded83574b85d6d44
<juliank> But it's kind of boring
<jderose> pitti: on the surface, this feels like a systemd bug, but i don't have any solid evidence yet that it is in fact a systemd bug - https://bugs.launchpad.net/debian/+source/qemu/+bug/1630341
<ubottu> Launchpad bug 1630341 in qemu (Ubuntu) "yakkety: behavior change in `qemu-nbd -c $DEV $FILENAME`: doesn't automatically create partion devices" [Undecided,New]
<nacc> mwhudson: fyi, i think i figured out the libwebp armhf failure. I found a reference to a similar failure earlier this year at: http://gcc.1065356.n8.nabble.com/distro-test-rebuild-using-GCC-6-td1224722.html#a1226791. Specifically the openal-soft_1:1.16.0-3 failure, which indicates that neon support is being built for, but not supported, etc. Do we want to have neon support (-mfpu=neon) in libwebp? I
<nacc> have no idea, but based upon the gcc flags, I guess not? :) So we need to fix the logic to correctly detect that neon isn't actually supported by default? It seems like openal fixed this in CMakeLists.txt, but we aren't using cmake
<nacc> mwhudson: ah perhaps as simple as --disable-neon in configure flags
<slangasek> nacc: neon is optional on armv7, it is not part of our abi for armhf
<slangasek> runtime detection of neon is ok but not hard enablement of it
<sil2100> bregma: hey! Silo 2020 (the unity8-desktop-session) - is that already tested and good to go?
<bregma> sil2100, it's been waiting for ubuntu-terminal-app to get uploaded to xenial overlay
<bregma> sil2100, that's been uploaded (as you say) let me test on my xenial machine
<nacc> slangasek: right, but hard-disablement would be ok, right?
<nacc> slangasek: as i'm not sure that i konw enough here to make neon be detected at runtime (and not sure libwebp supports that anyways)
<nacc> slangasek: i know next to nothing about arm itself, so please cmiiw
<slangasek> nacc: neon is the vector math instruction set; hard disabling it is like hard-disabling SSE or altivec in terms of its performance impact.  But if runtime detection isn't supported in the code, hard-disabling is the right answer on armhf
<nacc> slangasek: ok, i'll do some more digging to see what's possible
<nacc> slangasek: regardless, the fix is found at least :) just need to decide which way to make the configure and build match :)
<nacc> slangasek: ok, looks like there is a separate configure flag to enable runtime detection, testing that build now
<slangasek> nacc: nice :)
<pitti> sbeattie: ack, will upload it as an SRU then; thanks!
<pitti> smoser: the Before= is right, it's just not very elegant
<sbeattie> pitti: thank you!
<smoser> pitti, shall ijust do that then ?
<pitti> smoser: no objection, but I'll add a WI to the blueprint to review that for 17.04
<pitti> smoser: I think starting dbus earlier in the game is a better fix long-term, then you can remove this again
<smoser> yeah. we should file bug/request upstream
<pitti> right
<pitti> smoser: sorry, what was teh bug # again?
<smoser> https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1629797
<ubottu> Launchpad bug 1629797 in systemd (Ubuntu) "resolve service in nsswitch.conf adds 25 seconds to failed lookups before systemd-resolved is up" [Undecided,Triaged]
<pitti> cheers
<pitti> smoser: added to https://blueprints.launchpad.net/ubuntu/+spec/foundations-y-local-resolver
<smoser> anyone able to help me out ?
<smoser> https://packages.qa.debian.org/p/python-json-patch.html
<smoser> python json-patch in ubuntu and debian is at 1.19
<smoser> upstream https://github.com/stefankoegl/python-json-patch
<smoser> or https://pypi.python.org/pypi/jsonpatch
<smoser> seem to think the latest thing is 1.14
<smoser> am i just missing something ?
<mwhudson> good morning
<dobey> mwhudson: hi!
<dobey> mwhudson: i have some questions about packaging of golang stuff. are you the best person to ask?
<mwhudson> dobey: probably yes
<dobey> mwhudson: i was looking at packaging the govendor tool, and it's not clear how to make a build use packaged golang libs, rather than the vendored bits, and how to keep it from installing the extra vendored bits to the system for others to use; curious if you know how i might be able to do that?
<mwhudson> dobey: often what happens in debian seems to be repacking the orig to delete the vendored stuff
<sbeattie> smoser: looks like perhaps the debian packager typoed 1.10 for 1.19?
<sbeattie> err, verse vica
<dobey> mwhudson: oh. yeah, i was hoping to avoid doing that.
<mwhudson> dobey: override_dh_auto_configure:\n\trm -rf vendor?
<mwhudson> well not exactly that i guess but ...
<mwhudson> dobey: does govendor make releases or are you just grabbing things off github?
<dobey> hmm, i figured that would result in debuild complaining about things.
<sbeattie> smoser: especially given that unpacking the orig tarball gives files with the date of May 7, 2015, when 1.10 was released.
<dobey> mwhudson: it has tags, so i presume there are releases, but i'm just working out of github tree for now (and would like to be able to set up recipe builds later)
<smoser> sbeattie, but he had to work fairly hard on doing that.
<smoser> $ tar tvf python-json-patch_1.19.orig.tar.xz
<smoser> drwxrwxr-x root/root         0 2015-05-07 12:12 python-json-patch-1.19/
<mwhudson> you can do the repacking with the watch file, but i don't know how that interacts with getting things from git
<dobey> hmm, ok
<sbeattie> smoser: I agree, but diffing the 1.10 tarball from https://github.com/stefankoegl/python-json-patch/releases with the 1.19 orig tarball in the debian source gives no differences.
<smoser> sbeattie, you're definitely correct
<smoser> i'm just impressed as that took some determination to do
<smoser> i filed bug
<sil2100> bregma: hey! How's 2020 testing going?
<nacc> jgrimm: libwebp ftbfs fixed
<jgrimm> cool
<nacc> mwhudson: memcached's test failure. on a porter box, i don't see the issue in a chroot, but it's also using -j1, is it possible that the test fail to run parallely (I see the log has -j4) on armhf?
<nacc> and, if so, is there a recommended way to indicate tests are not parallel?
<nacc> doko_: --^ as well, although i expect you to not be available
<mwhudson> nacc: was just talking to slangasek about that
<mwhudson> nacc: it's almost certainly alignment being handled differently on the porter vs the builder
#ubuntu-devel 2016-10-05
<nacc> mwhudson: probably my own ignorance but why would alignment and parallelism interplay like that? or is parallelism a red herring?
<sarnold> re-run locally with -j4 or re-run on the arhmhf with -j1 to find out? :)
<nacc> sarnold: so on the armhf porter, -j1 is used and it passes
<slangasek> nacc: the porter box's kernel does not raise SIGBUS
<nacc> sarnold: but on the test rebuild, -j4 was used and it failed
<nacc> slangasek: ah
<nacc> good info! :)
<slangasek> so parallel is a red herring
<sarnold> slangasek: wow, how (and _WHY_)? :)
<slangasek> sarnold: the better question is, why did the armhf builders start raising it
<sarnold> each arch has their own rules.. it feels to me like the builders ought to stick with 'usual'
<slangasek> sarnold: the usual is to not raise SIGBUS on anything armv7 or later.  But android kernels forced it on, so we used to get bugs that were not reproducible on the builders or porter box, only on phones
<slangasek> then when we moved builders to armhf guests on arm64, suddenly we were getting sigbus there, but I don't think anyone's been able to determine why
<slangasek> if we could get the porter box to also have it on, we'd be golden
<nacc> slangasek: mwhudson: i guess i'm at a loss on how to go further with the memcached failure then, given that i can't reproduce it (at least, not that i know of yet)
<sarnold> yeah, inconsistent seems like a quite route to insanity
<slangasek> nacc: mwhudson's hint (not validated yet by me) is to log into the armhf chroot on the arm64 porter box
<nacc> slangasek: interesting, I can try that tomorrow!
<nacc> slangasek: would you happen to know who i might turn to for llvm testcase failures?
<nacc> (unrelated to arm)
<slangasek> nacc: perhaps doko
<nacc> heh ok :)
<pitti> Good morning
<cpaelzer> nacc: coreycb: I already was on a birthday overloading my belly at the time yesterday :-/
<cpaelzer> coreycb: I'm here to help you get access to our node as interim help if you want that, but you'll need some extra access I'll send you in a query
<cpaelzer> coreycb: I think jamespage and beisner were of your Team and could share one where you already have VLAN access
<cpaelzer> coreycb: but we can discuss all that once you are online again
<cpaelzer> coreycb: and in any case if I'm not here jfh might be able to help as well (but same TZ)
<cpaelzer> ah - and good morning devel channel :-)
<pitti> roaksoax: you are double sure that you want to replace the stable MaaS 2.0 with a beta version of 2.1 a week before release? the upload does not point to a FFE bug, so please reupload with a pointer to that, so that this can be discussed somewhere (and/or discuss in #u-release)
<pitti> coreycb: can you please have a look at the failed armhf/s390x tests of http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#nova ? they complain about compute-kvm not running, which is understandable in an lxc container
<pitti> coreycb: so this is a regression between b2 and rc2
<sil2100> xnox: hey! Any news on the upstart merge and new release?
<doko_> caribou: is https://bugs.launchpad.net/ubuntu/+source/tomsfastmath/+bug/1619239 still in progress?
<ubottu> Launchpad bug 1619239 in tomsfastmath (Ubuntu) "[MIR] tomsfastmath (runtime dependency of clamav)" [High,In progress]
<caribou> doko_: we've postponed it until 17.04 & I have prepared a new clamav w/o the tomsfastmath dependancy that is about to be uploaded
<doko_> ta
<caribou> doko_: the security team's backlog for MIR reviews made it almost impossible to have it reviewed for 16.10
<doko_> Mirv: that looks like a qt issue: https://launchpad.net/ubuntu/+source/ubuntu-push-qml/0.1+15.10.20150826.1-0ubuntu2/+build/10990923
<Mirv> doko_: ack, so it does
<dpm> popey, doko_, has bug 1625074 been sorted out?
<ubottu> bug 1625074 in ubuntu-terminal-app (Ubuntu) "[MIR] ubuntu-terminal-app" [High,New] https://launchpad.net/bugs/1625074
<doko_> dpm, popey: wait for review from the security team
<dpm> doko_, ok, thanks, it seems they say review is underway
<popey> willcooke: ^ I think you mentioned some new info from the security team?
 * willcooke reads
<willcooke> so yeah, we have the OK to go ahead with MIRing before the security review is complete
<willcooke> doko_, I'll ask slangasek to confirm with you formally
<rbasak> ddstreet: please could you do the SRU paperwork for bug 1224007?
<ubottu> bug 1224007 in vlan (Ubuntu) "mtu not always set properly on bond/vlan interface" [Medium,Confirmed] https://launchpad.net/bugs/1224007
<jbicha> LocutusOfBorg: the link-grammar autopkgtest failure was my fault but it's all fixed now
<caribou> nacc: did you find anything regarding the llvm-3.6 FTBS so far ?
<stgraber> infinity: are you planning on refreshing the yakkety chroots pre-release? working on crappy internet today (aka LinuxCon) and just noticed it's pulling quite a lot of updates
<coreycb> pitti, I'll take a look, I thought I'd fixed it yesterday but perhaps not
<LocutusOfBorg> caribou, can I know the llvm issue context?
<LocutusOfBorg> jbicha, thanks
<caribou> LocutusOfBorg: the FTBS is very early in the rules file:
<caribou> dpkg-query: no packages found matching g++-6.1
<caribou> dpkg: error: --compare-versions takes three arguments: <version> <relation> <version
<caribou> LocutusOfBorg: just not sure if nacc has identified the issue already
<LocutusOfBorg> I know what the issue is
<LocutusOfBorg> and I know what the patch is
<LocutusOfBorg> usually asking me about llvm issues is a quickeer fix
<caribou> :)
<LocutusOfBorg> you just need to adjust the regex for new gcc
<caribou> LocutusOfBorg: yeah, that was my next step
<caribou> LocutusOfBorg: nacc told me about the FTBS since clamav which I uploaded is its only dependancy
<LocutusOfBorg> https://anonscm.debian.org/viewvc/pkg-llvm/llvm-toolchain/branches/3.8/debian/rules?r1=2038&r2=2041
<LocutusOfBorg> I want to get rid of old llvm in Debian and Ubuntu
<caribou> LocutusOfBorg: thanks; do you want me to take care of it or you want to do it yourself ?
<LocutusOfBorg> why aren't you using llvm 3.8 is unknown to me
<LocutusOfBorg> caribou, ENOYETCOREDEV
<caribou> LocutusOfBorg: oh, didn't know that
<LocutusOfBorg> and I want to get rid of that
 * LocutusOfBorg applied for core-dev but only one advocacy so far
<caribou> LocutusOfBorg: & Debian is still using 3.6 and from what I can gather, clamav needs sensible adaptation to use higher than 3.6
<caribou> LocutusOfBorg: & I don't have much to do about it myself, I just merged the package from debian
<LocutusOfBorg> well, yesterday Sylvestre started the transition to llvm-3.8
<LocutusOfBorg> so I suspect clamav being broken in Debian right now?
 * LocutusOfBorg does some dak query 
<LocutusOfBorg> https://buildd.debian.org/status/fetch.php?pkg=clamav&arch=amd64&ver=0.99.2%2Bdfsg-3%2Bb1&stamp=1475621172
<LocutusOfBorg> sigh, true
<caribou> LocutusOfBorg: ok, I'll wait until nacc comes in so we don't overlap on this
<LocutusOfBorg> configure: error: LLVM < 3.7 required, but "3.8.1"(381) found
<caribou> yep, that's what I got yesterday when I tried to build with 3.8
<LocutusOfBorg> ok let me fix llvm 3.6
<LocutusOfBorg> sigh
<caribou> LocutusOfBorg: don't bother, I can do it
<LocutusOfBorg> thanks
<LocutusOfBorg> if you want to forward patches to the debian bug reports... :)
<LocutusOfBorg> even if trivial, I can give you credits and maybe upload
<LocutusOfBorg> (having RC bugs helps in kicking them out of testing)
<caribou> LocutusOfBorg: wait, are we talking about the same thing ? I was referring to applying your regex modification to LLVM-3.6
<LocutusOfBorg> yes
<caribou> k, I'm on it
<LocutusOfBorg> core-devs: syncpackage -s costamagnagianfranco portaudio19
<LocutusOfBorg> please ^^
<LocutusOfBorg> patch for this bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833950
<ubottu> Debian bug 833950 in portaudio19 "libportaudio2: brltty-espeak stops working with libasound2 1.1.2-1" [Serious,Fixed]
<LocutusOfBorg> dholbach, ^^
<LocutusOfBorg> this is a serious bug that prevents blind people from using the system
<dholbach> in a all right now
<dholbach> sorry, in a call
<LocutusOfBorg> I aksed ginggs to sync, I can open a bug if needed
 * LocutusOfBorg TIA
<pitti> apw: I finally got an useful log, filed bug 1630578 about the eternal retry loop
<ubottu> bug 1630578 in autopkgtest (Ubuntu) "broken kernel causes eternal test retry loop" [High,In progress] https://launchpad.net/bugs/1630578
<dholbach> LocutusOfBorg, done
<LocutusOfBorg> <3
<dholbach> it will be sitting in the release team queue
<pitti> Laney: yay, armhf beat x86 this morning's queue run! (second after s390x)
<Laney> \o/
<Laney> Intel better be worried
<ogra_> intel is doomed (since yaears !)
<LocutusOfBorg> dholbach, thanks
<dholbach> :)
<LocutusOfBorg> blind people should appreciate that
<pitti> apw: and I reduced the reproducer from 5:30 hours to 1s, which is a lot more comfy :)
<apw> pitti, yay :)
<caribou> nacc: I'm about to upload a fixed llvm-toolchain-3.6
<rbasak> cyphermox: is grub2 2.02~beta2-36ubuntu3.4 in the Xenial queue supposed to supersede 2.02~beta2-36ubuntu3.3 in proposed? They refer to the same bug, but the earlier version is still v-needed.
<nacc> caribou: great!
<nacc> caribou: thank you
<caribou> nacc: well, you can thank LocutusOfBorg
<caribou> nacc: want me to upload clamav along with it ?
<nacc> caribou: ah that won't fix it though
<nacc> the regex fix?
<nacc> i sent that to debian already, or acked the one they had in their bug report
<nacc> it will still fail to build clamav
<nacc> err, not clamav, but its own testcase
<nacc> there are two failures
<caribou> nacc: oh, I didn't get that far, the build just killed my test server
<nacc> caribou: yeah, i didn't want to upload a partial fix, sorry -- i thought i had mentioned that to you earlier
<caribou> grrr
<nacc> let me find the test failures
<caribou> nacc: nope but no worry, I had a bit of time so I thought I'd give it a look
<nacc> http://paste.ubuntu.com/23280288/
<nacc> are the two failures i see with the regex fix
<Odd_Bloke> pitti: I've noticed that /var/log/syslog ends up with the first N messages with the same (later-than-boot) timestamp whereas journalctl has different, earlier timestamps for the same events.
<Odd_Bloke> pitti: Shall I file a bug for this?
<caribou> nacc: then maybe LocutusOfBorg can help more than I can
<pitti> Odd_Bloke: I suppose rsyslog records the dates when it receives the event, not the date from teh original event?
<pitti> Odd_Bloke: rsyslog actually has a mode to pull from the jouranl (which should preserve origianl timestamps), but we don't use that yet; at some point we should as it will also avoid truncated logs on bursts
<LocutusOfBorg> caribou, where are the failures?
<LocutusOfBorg> on i386?
<Odd_Bloke> pitti: Yeah, that rsyslog hypothesis seems likely.
<caribou> nacc: ^^
<nacc> LocutusOfBorg: http://paste.ubuntu.com/23280288/
<nacc> LocutusOfBorg: that occurs on amd64, not sure if the same tests fail on other archs yet
<cyphermox> rbasak: yes
<LocutusOfBorg> nacc, link?
<nacc> LocutusOfBorg: just provided? http://paste.ubuntu.com/23280288/
<LocutusOfBorg> not helping, I want a full build log
<LocutusOfBorg> e.g. a ppa build
<nacc> LocutusOfBorg: would my local sbuild's full log be sufficient?
<LocutusOfBorg> against yakkety?
<nacc> yes
<nacc> with the fix for the regex
<LocutusOfBorg> regex fix for llvm 3.6 against yakkety and nothing more
<nacc> yes
<LocutusOfBorg> let me upload on my ppa
<nacc> i have the same
<nacc> LocutusOfBorg: http://termbin.com/j435
<nacc> LocutusOfBorg: only change to the package was the regex fix for recognizing gcc 6
<nacc> bah seems cutoff
<rbasak> nacc: do you have SRU paperwork for bug 1575543 please?
<ubottu> bug 1575543 in loganalyzer (Ubuntu Xenial) "loganalyzer not work in ubuntu 16.04" [High,In progress] https://launchpad.net/bugs/1575543
<nacc> rbasak: was on my list to do today and upload
<nacc> i was fixing it live with a  requestor in #ubuntu yesterday
<rbasak> Seems to already be in the queue?
<nacc> bah, i thought i had *not* yet uploaded, let me fix the bug
<rbasak> But sure, it can be processed when you're ready :)
<nacc> rbasak: updated
<rbasak> Thanks!
<nacc> rbasak: thank you!
<juliank> eww, autopkgtest had an autopkgtest failure on amd64 for apt/1.3.1. I retried that now, let's see if it goes normally this time
<nacc> mwhudson: slangasek: fyi, reproduce the memcached failure on arm64 porter in armhf chroot
<nacc> mwhudson: http://paste.ubuntu.com/23280567/
<slangasek> nacc: nice, now you have something you can gdb :)
<rbasak> jamespage: what's the regression risk for the SRU in bug 1608934? Please could you fill that in?
<ubottu> bug 1608934 in Ubuntu Cloud Archive mitaka "ephemeral/swap disk creation fails for local storage with image type raw/lvm" [High,In progress] https://launchpad.net/bugs/1608934
<nacc> slangasek: yep :)
<nacc> mwhudson: slangasek: http://paste.ubuntu.com/23280630/ (gdb bt)
<nacc> will try and debug :)
<nacc> LocutusOfBorg: able to reproduce?
<LocutusOfBorg> sorry will try now
<nacc> LocutusOfBorg: np, I can also e-mail you the log (as I think it'e exceeding the pastebin's size)
<lamont> [  OK  ] Reached target Shutdown.
<lamont> [  397.076385]  connection1:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4294988998, last ping 4294990256, now 4294991552
<lamont> WHY do we still want to talk to the root fs after we get to shutdown?
<lamont> (it's trying to reboot...)
<koike> cyphermox, hey, shim was rejected by debian because of missing copyrights attributions, I just send you a merge proposal, could you take a look when you have some time please?
<smoser> pitti, https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety/yakkety/amd64/o/open-iscsi/20161005_154808@/log.gz
<smoser> why would we not have access to kvm there?
<slangasek> doko_: did you see that your tomcat8 sync brought a new dep with it (taglibs-standard)?
<cyphermox> koike: ack, but I'll merge that with some changes, we have a shim pending upload now...
<koike> cyphermox, ok, thanks
<slangasek> cyphermox: maybe I should merge in the packaging changes that I was making for Debian
<slangasek> cyphermox: i.e. maybe you want to hold off on work for a bit so I can stop having to redo my changes to debian/copyright ;)
<lamont> pitti: you around?  I'm trying to fathom what systemd et al might be dowing after "Reached target Shutdown" that requires the root disk still
<lamont> or how to get a working getty at that point. :/
<lamont> s/getty/shell
<koike> slangasek, ops, I hope I didn't cause a double work here
<slangasek> koike: don't worry; my changes are just fixing the order of stanzas in the file
<cyphermox> slangasek: ok
<pitti> lamont: did you try booting with systemd.debug-shell? (should be on Ctrl+Alt+F8)
<lamont> pitti: you're assuming I have more than ttyS1
<lamont> that's all I have
<pitti> ah, difficult then; after that there's little room for getty etc.; nothing should run then except /lib/systemd/systemd-shutdown, which essentially just umounts root and tells the kernel to power off
<pitti> booting with "debug console=ttyS1" might still help a bit
<nacc> slangasek: so memcached's configure script has a check to determine if it needs to do alignment or not, but it passes -O2 to the test compilation, which leads to a successful test of the program. If I manually pass no optimization flags, the test correctly raises a SIGBUS. Thoughts?
<slangasek> nacc: on a Linux system, messing around with possibly /not/ aligning is a waste of effort; there are various cases where the build and runtime behavior can be legitimately different, and even if the test succeeds it's an inefficiency in CPU and/or kernel to do the fix-up on userspace's behalf
<slangasek> nacc: just neuter the test and always choose to align
<nacc> slangasek: ok, i'll test that -- probably worth sending upstream too then?
<slangasek> the test succeeding or failing with different optimization levels is interesting, but not predictive
<slangasek> nacc: IMHO yes
<nacc> slangasek: ok, thanks!
<slangasek> maybe they have users on other platforms who wouldn't like alignment to be enforced, but I don't know what those are
<nacc> slangasek: is this the wrong way to go about it? the build succeeds with this patch, and afaict, there is no configure flag i can pass to say force alignment http://paste.ubuntu.com/23281367/
<nacc> oh i might not need to patch configure.ac anymore
<slangasek> nacc: that's what I would look to do
<slangasek> (though I would patch configure.ac and make sure the package used dh_autoreconf for configure)
<nacc> slangasek: yeah, i think it used to -- but there are changelog entries indicating memcached doesn't play properly with dh_autoreconf
<nacc> i'll try and investigate that
<nacc> slangasek: ah ok, i misread the changelog, so just patching configure.ac is sufficient
<nacc> jgrimm: --^ thanks to slangasek's help, memcached's ftbfs is fixed, so i think -server is now clean (pending another test rebuild for the remaining packages, and hopefully LocutusOfBorg figuring out llvm-toolchain-3.6). coreycb, I'm assuming you've got a handle on nova still?
<jgrimm> :) nice. thanks nacc
<coreycb> nacc, yep, I've got nova
<nacc> coreycb: great, thanks for confirming
<juliank> I'm starting preparing the apt 1.2.15 update for xenial. It's gotten a bit large, it really should have been 3 to 4 updates, but 1.3 development was too busy. Sources for RC1 are available at https://launchpad.net/~deity/+archive/ubuntu/apt-1.2 - binaries should get building soon
<juliank> The 1.2.15 update will fix the autoremoval code to only consider the latest provider of a given source package for protecting, so older kernels can effectively be removed even if some of their provides are being depended upon by other packages.
<juliank> It also fixes a ton of other bugs and buffer overflows and maybe underflows
<juliank> Overall, I cherry-picked 54 commits since 1.2.14
<juliank> Feedback is appreciated. I'll put this on my server-playing thinkpad once the PPA is built and give it a drive for a few days
<LocutusOfBorg> nacc, https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+sourcepub/6984130/+listing-archive-extra
<LocutusOfBorg> can't reproduce
<juliank> kirkland: I'm playing around with byobu and wondering if there's a way to make it automatically pick the last session when starting, as asked in http://askubuntu.com/questions/798763/how-to-make-byobu-automatically-select-last-used-session
<slangasek> coreycb: looks like nova autopkgtests still fail on armhf and s390x?
<slangasek> if nova's systemd units are relying on timeouts to detect daemon starts, may I suggest trepanning
<nacc> LocutusOfBorg: hrm, strange! care to upload?
<coreycb> slangasek, that was a lame attempt at a fix.. it turned out the service is continually restarting on all arch's, and just not getting lucky on armhf and s390x.  what do you mean by trepanning?
<coreycb> slangasek, I have a config option change that I'm testing to fix it
<slangasek> coreycb: I mean someone needs to let the evil spirits out of the head of whoever thought of implementing the service this way ;)
<coreycb> slangasek, agreed, it's not very intelligent
<nacc> from a process perspective, -updates and -security packages may not go through -proposed? Is that accurate?
<nacc> and by may, I mean 'might'
<slangasek> nacc: true
<nacc> slangasek: thanks!
<Unit193> slangasek: FWIW, you can change the topic with  /cs topic #ubuntu-devel Foo  now, when you're identified.
<slangasek> Unit193: what's '/cs'?
<Unit193> slangasek: Sorry, /msg ChanServ
<slangasek> ok
<nacc> rbasak: fyi, just shot you a couple MRs, no need to review them, they are for our process discussion
<nacc> smb: not sure if you've seen LP: #1591695, but given that someone is trying to contribute, would be good to pick up their change, if reasonable
<ubottu> Launchpad bug 1591695 in libvirt (Ubuntu) "libvirt-guest.sh will never sucessfully shutdown more than one virtual machine in my setup" [Medium,Triaged] https://launchpad.net/bugs/1591695
<rbasak> nacc: ack, thanks
<nacc> rbasak: also, i'm thinking we might be able to take LP: #1519120 off of the server-next list, unless you think wes should look at the NM changes GUI changes?
<ubottu> Launchpad bug 1519120 in network-manager (Ubuntu) "NetworkManager should provide default name for VLAN" [Low,Confirmed] https://launchpad.net/bugs/1519120
<nacc> and maybe replace it on the list with LP: #1541678
<ubottu> Launchpad bug 1541678 in vlan (Ubuntu) "if-post-down.d/vlan and if-pre-up.d/vlan should support predictable NIC names" [High,Confirmed] https://launchpad.net/bugs/1541678
<nacc> ah i see it was
<nacc> and assigned to you, rbasak :)
<rbasak> nacc: 120 I disambiguated in #14
<rbasak> comment #14
<rbasak> I'd be fine pulling that from server-next
<rbasak> And only leave us subscribed to follow any non-NM developments
<rbasak> (since it was confused with the separate vlan package bug)
<nacc> ack
<nacc> (and done)
<rbasak> Thanks!
#ubuntu-devel 2016-10-06
<slangasek>         // TODO:: fix alignment of src!
<slangasek> yathink
<rbasak> armhf and alignment? :)
<rbasak> I dealt with those in the past, but I got the impression our newer armhf kernels had traps to magically handle that.
<rbasak> At least, the same failures I saw in the past stopped happening.
<slangasek> rbasak: it's actually an increased problem, for whatever reason the arm64 kernels don't do fix-ups so when LP moved to armhf containers on arm64 things started failing.  Which is not a bad thing, given that the Android BSP kernels do the same
<rbasak> Ah, that makes sense.
<rbasak> Does /proc/cpu/alignment exist on arm64? On armhf, it's the default that changed in our kernels I think. But it makes sense to not fix it.
<rbasak> (well, "fix" it)
<tsimonq2> bug 1556599 looks *fun*
<ubottu> bug 1556599 in kubuntu-meta (Ubuntu) "ISO images don't have valid partition tables" [Undecided,New] https://launchpad.net/bugs/1556599
<slangasek> rbasak: yeah, no /proc/cpu/alignment at least on porter-arm64
<slangasek> tsimonq2: should probably be reassigned to the ubuntu-cdimage project; but also, we've been using the same boot code on all these images for a while now, and the list of tools the submitter mentions trying to use strongly suggests user error here
<tsimonq2> slangasek: yeah, I was thinking PEBKAC
<tsimonq2> hmm, anybody familiar with GNOME/GTK software? there's a rather trivial bug that I'd like to fix, but I've never even touched anything like that
<tsimonq2> (anybody familiar with that that has a half an hour to spare ;) )
<cyphermox> tsimonq2: just ask your question ;)
<tsimonq2> oh yeah I should do that
<tsimonq2> :P
 * tsimonq2 slips Lubuntu hat on
<tsimonq2> let me find this bug...
<tsimonq2> bug 1516454
<ubottu> bug 1516454 in gnumeric (Ubuntu) "gnumeric menu ->help ->about gnumeric -> license button, does not work." [Low,Confirmed] https://launchpad.net/bugs/1516454
<tsimonq2> shouldn't it be as simple as mapping the button to the correct spot?
<sarnold> are any errors printed to stderr? or xsession errors?
<tsimonq2> let me fire up my Lubuntu VM here...
<sarnold> you might get lucky and see an error message with the exact cause :)
<tsimonq2> good idea sarnold
<tsimonq2> it's been a Lubuntu bug for a while now and it seems trivial enough
<sarnold> I could imagine the actual cause could span a huge range of possibilities, from "no one has bothered to implement the dialog box yet" to "the name of the widget was misspelled in an API that doesn't provide any compile-time error checking"
<tsimonq2> the only error-looking output that I don't know what it is is an error about not being able to connect to the Accessbility bus
<tsimonq2> which I don't think would cause that?
<sarnold> probably not
<tsimonq2> if it was written in Qt, I'd be able to use Qt Creator's awesome little tools to figure it out
<tsimonq2> but unfortunately it doesn't seem like there's anything like that for GTK
<tsimonq2> the question is, where do I start?
<cyphermox> I'd look at the source code for where that button is defined
<tsimonq2> ok
<cyphermox> usually what I do is rgrep through the source for keywords I'm looking for ("License" in this case), to have somewhere to start with
<tsimonq2> what's the difference between grep and rgrep?
<cyphermox> rgrep is grep -r
<tsimonq2> oh ok
<sarnold> my first attempt kind of failed... no real license buttons here http://sources.debian.net/src/gnumeric/1.12.32-1/src/dialogs/dialog-about.c/
<cyphermox> no, doesn't appear to be
<sarnold> but I did giggle at "comments", _("Free, Fast, Accurate - Pick Any Three!"),
<cyphermox> I wonder if you're not seeing the about dialog rendering the contributors animation as a button
<sarnold> the screenshot -really- looks like it's supposed to be a clickable button. heh.
<cyphermox> oh indeed
<cyphermox> but also, oh, that looks like magic about dialog magic.
<tsimonq2> seems like there's no definition for that in the code...
<tsimonq2> I also need to update the bug to include the fact that Credits doesn't work either
<cyphermox> I bet GTK_TYPE_ABOUT_DIALOG does this automatically in some cases
<cyphermox> yep, that's deep in gtk
<sarnold> cyphermox: ha! that l9ooks like it
<sarnold> "You can specify license information with the âlicenseâ property " https://developer.gnome.org/gtk2/stable/gtk-migrating-GtkAboutDialog.html
<tsimonq2> so it might be a GTK bug?
<sarnold> well
<sarnold> They Probably Hoped[tm] that authors would set the properties and thus make the buttons useful
<cyphermox> tsimonq2: so, the gist of it is that when you reach an issue like this, it's often useful to go dig in yet more code -- in this case, the gtk source, to figure out what happens when the about dialog is being created -- so that GTK_ABOUT_DIALOG generates the License button itself; and the buttons are hooked up to specific properties that are configured as you insitanciate that object
<cyphermox> right
<cyphermox> it's not a GTK bug, but a property missing in gnumeric. as you mentioned, very straightforward to fix
<sarnold> you could bicker and argue about whether itt's a good idea to show the buttons if the properties aren't set...
<tsimonq2> ok, thanks guys for guiding me in the right direction :)
<cyphermox> sarnold: well, yeah, I suppose ;)
<cyphermox> tsimonq2: so the fix is a one-liner
<tsimonq2> \o/
<sarnold> dunno, I found GPL2 and GPL3 ilcense files there, that's a very long line :)
<cyphermox> sarnold: no
<cyphermox> you can set it with a property which takes an enum ;)
<sarnold> oh! I got distracted by the mention of the type of dialog box it would show and their recommendation to use paragraphs
<cyphermox> right; I think it would suffice to set license_type; and from there things would work and be correct
<cyphermox> Gnumeric says GPL2 or 3 at your choice, that reads to me as GPL2+
<tsimonq2> so I might need a license property?
<cyphermox> I think it ought to be license_type
<tsimonq2> I can dig into it more tomorrow when I've had a bit more sleep and my brain is ready for this type of debugging, but for now, I was wondering if you guys saw anything obvious
<cyphermox> tsimonq2: yep
<cyphermox> tsimonq2: https://developer.gnome.org/gtk3/stable/GtkAboutDialog.html#GtkAboutDialog--license might help
<cyphermox> my opinion would be to give you a chance to fix it yourself, and thus claim an upload (I'll be happy to sponsor)
<tsimonq2> awesome, thanks :)
<tsimonq2> cyphermox, sarnold: GPL-2, GPL-3, or both? I'm reading debian/copyright and I'm a bit unsure about what I should put...
<tsimonq2> or even GPL-2+?
<sarnold> tsimonq2: I haven't studied it closely but GPL-2+ feels like a likely fit
<tsimonq2> ok I'll assume that for the time being
<sarnold> tsimonq2: it might not hurt to check upstream gnumeric repo and see if they've already addressed it
<nacc> LocutusOfBorg: are you planning on uploading the fix for llvm-toolchain-3.6?
<tsimonq2> sarnold: good stuff
<tsimonq2> ok
<sarnold> tsimonq2: "cherrypick checkin ..." is a lot easier to review than new code :)
<tsimonq2> +1
<tsimonq2> hmmm, seems like it's *not* upstream
<sarnold> amazing how a tiny thing turns into a medium thing quickly :)
<tsimonq2> hmm, DuckDuckGo didn't return anything, so does this look right to you guys? http://paste.ubuntu.com/23282692/
<tsimonq2> multi-line GTK properties
<sarnold> tsimonq2: it's probably better to set the license-type property isntead: https://developer.gnome.org/gtk3/stable/GtkAboutDialog.html#GtkAboutDialog--license-type
<sarnold> https://developer.gnome.org/gtk3/stable/GtkAboutDialog.html#GtkLicense
<tsimonq2> ok got it
<tsimonq2> sarnold, cyphermox: that didn't work :(
<tsimonq2> and I should really go to bed
<tsimonq2> good night everyone o/
<sarnold> goodnight tsimonq2 :)
<pitti> Good morning
<cpaelzer> good morning
<LocutusOfBorg> nacc, I can't, I'm not a core-dev, just let caribou upload it
<smb> nacc, Thanks, I will have a look at the shutdown script issue
<Mirv> doko_: oSoMoN: cjwatson: re: Qt/QML arm64 problem. it doesn't indeed seem to be anything I can revert, and it doesn't happen on my arm64 device (frieza). so it's likely due to the builder kernel update, and it would need a real fix somewhere, I don't know where. it might go away once I backport V4 JIT for arm64 http://code.qt.io/cgit/qt/qtdeclarative.git/log/?qt=grep&q=arm64 but that won't happen for
<Mirv> yakkety of course.
<Mirv> (I'm sad that the search url there doesn't give any more entries of potential Qt side fixes)
<mardy> Mirv: do I understand correctly, that this is QML issue does not only affect tests, but also real apps?
<Mirv> mardy: maybe since it's happening in executing QML code, but only if you run apps on similar device/configuration to the builder machines.. whatever part of the configuration has the cause for the problem. so, things compile and run fine on my Bq tablet.
<mardy> Mirv: should we temporarily disable arm64 tests, or do you have some other tricks in the sleeve?
<cpaelzer> pitti: hi I was trying to set up an autopkgttest environment on my s390x lpar, using autpkgtest 4.1 I could avoid some issues (like bad default mirror), but eventually I'm stopped by sometihng not happening as expected "timed out waiting for "login prompt on ttyS0""
<cpaelzer> pitti: the image boots just fine if I throw it at a qemu-kvm, so I wanted to ask if there are known issues or obvious steps missing?
<pitti> cpaelzer: how did you create the image? you should normally use autopkgtest-buildvm-ubuntu-cloud for it
<cpaelzer> pitti: sudo ~/autopkgtest-4.1/tools/autopkgtest-buildvm-ubuntu-cloud -v --arch=s390x --mirror=http://ports.ubuntu.com/ubuntu-ports -r yakkety -s $((10*1024*1024*1024))
<pitti> cpaelzer: that will start a root bash on ttyS1 so that autopkgtest can talk to it; if that doesn't exist, it needs to be able to log into a getty on ttyS0, so that must start
<pitti> cpaelzer: (-s can take something like "10G")
<pitti> cpaelzer: if you boot it in kvm with -serial stdio, do you see the boot messages and can log in?
<cpaelzer> I didn't add any serial on my last try, the defaults worked
<cpaelzer> let me add -serial stdio
<cpaelzer> -serial stdio fails as the default sclp console already grabbed stdio
<cpaelzer> should I disable sclp
<cpaelzer> or is that it boots just fine via sclp console proof enough?
<cpaelzer> pitti: ^^
<pitti> cpaelzer: I don't know what sclp is
<pitti> cpaelzer: but if ttyS0 doesn't work for the console, then autopkgtest won't work with it
<cpaelzer> it is "their" native console protocol
<cpaelzer> and thereby what you get when you do nothing
<pitti> cpaelzer: hmm, no idea what that is, but I figure if a normal serial console doesn't work then the qemu runner and/or the image build needs to be adjusted for that
<cpaelzer> pitti: the default console is sclp which is a line mode console, using -nographic that already is connected to stdio and working fine
<cpaelzer> pitti: if I need a "normal" console I can use virtio-serial e.g. by appending -chardev socket,path=/tmp/port0,server,nowait,id=port0-char -device virtio-serial -device virtserialport,id=port1,name=org.fedoraproject.port.0,chardev=port0-char
<cpaelzer> pitti: I'm not sure what that implies for the ttyS0 you need for autopkgtest
<pitti> cpaelzer: what it does is it connects to ttyS0 and waits for a "login: " prompt
<pitti> cpaelzer: and then it either checks if there is a root shell on ttyS1, or if it can log into ttyS0 if you gave it a user and password as options
<pitti> cpaelzer: i. e. it needs a foot into the door -- it's really difficulty to communicate with a QEMU instance, there's nothing like lxc-attach or lxc exec or schroot -r
<cpaelzer> pitti: yeah I agree, so that is what you do via the -serial unix:/tmp/autopkg... then right?
<pitti> cpaelzer: and a serial console is the most common thing; I guess you can massage that to work with that console, might just need an option to specify a differnt device name?
<pitti> right
<cpaelzer> I'll add one on my own and see if/what spawns there
<Mirv> mardy: at the moment no other tricks, since I only just managed to rule out that it's not anything I changed (since I had recent qtbase and qtdeclarative updates), and that it does not happen on our arm64 hardware
<cpaelzer> pitti: without further tweaking nothing seems to spawn on those extra consoles (and no /dev/tty* entries created)
<cpaelzer> pitti: it is ok for me to step away, do you want a bug to document it for later on with what I've found so far?
<pitti> cpaelzer: if you want to dump it in a bug, sure; I can't work on it myself anyway as I don't have access to this env
 * pitti is still amazed how different everything is with s390x :)
<cpaelzer> pitti: I'll dump and I'm sure xnox can give you access to some in instance your team if you need/want
<Mirv> ok collected the arm64 issue facts to bug #1630906
<ubottu> bug 1630906 in ubuntu-push-qml (Ubuntu) "QML segfault on arm64 due to builder kernel change" [Undecided,New] https://launchpad.net/bugs/1630906
<Mirv> cjwatson: oSoMoN: doko_: bug #1630906 has the collected failures, happens on vivid + xenial + yakkety
<ubottu> bug 1630906 in webbrowser-app (Ubuntu) "QML segfault on arm64 due to builder kernel change" [Undecided,New] https://launchpad.net/bugs/1630906
<oSoMoN> thanks Mirv. LP times out when I want to mark myself affected :/
<pitti> xnox: can you please push your upstart commits to bzr? or want me to grab the diff from LP:
<pitti> ?
<pitti> xnox: I pushed it now
<doko_> caribou: please take this for Debian too: https://launchpad.net/ubuntu/+source/makedumpfile/1:1.6.0-2ubuntu1
<caribou> doko_: ok, will do
<cpaelzer> pitti: I found a s390x way to get a login prompt onto those unix sockets and documented it in the bug. is there a way to inject/replace the default -serial parameters with my tweaked ones on my system?
<cpaelzer> pitti: I wonder if unblocking these just gets to the next hurdle or if it would run fine then
<xnox> pitti, i have them locally, did not upload upstart to the archive yet, hence did not push.....
<xnox> pitti, my question is who uploaded things =)
<pitti> xnox: someone synced it from some PPA, and it's in -proposed; I had to do a followup upload, so I synced bzr and pushed my stuff on top
<xnox> cool, thanks.
<pitti> cpaelzer: not one with options, as I didn't expect this case; you can of course create a locally hacked up autopkgtest-virt-qemu to play around with
<cpaelzer> pitti: ok, looking at virt/autopkgtest-virt-qemu atm
<xnox> sil2100, 2016-10-06 08:45:17 +0100 (sil2100) Publishing packages.
<xnox> it would be nice not to land my stuff for me =)
<xnox> sil2100, especially without autopkgtest results.
<xnox> anyway, it's superseeded now. so doesn't really matter at all.
<sil2100> xnox: ah, right, the yakkety one - yeah, sorry, prematurely published that one
<sil2100> We wanted the xenial one badly and it was ok, so I insta-published the yakkety one without checking if all autopkgtests ran
<sil2100> xnox: but the xenial one was fine, everything passed and was green
<xnox> sil2100, i thought you will copy xenial ppa into xenial overlay ppa (using copy-package, not release)
<xnox> because xenial one is now stuck in SRU queue, and will be probably rejected there (as there is no bug # reference)
<sil2100> I did do a copy-package to the overlay, but I thought you wanted to have that released in xenial-updates too?
<xnox> excellent then =)
<xnox> yeah, i do want it in xenial-updates, eventually
<sil2100> My understanding was we release it to xenial-updates too as an SRU but I copy it to the overlay to have it faster (since as you can see we're really desparate for it ;p)
<sil2100> Sorry for the issues anyway
<xnox> desparate times, need desparate measures =)
 * xnox is struggling to escape from this island at the moment
<coreycb> sil2100, slangasek, robru:  hi, question about bileto.ubuntu.com ACLs.  any chance we could grant permissions to per-package uploaders so they wouldn't require a sponsor to test PPA fixes?
<cjwatson> I thought that happened ages ago
<jbicha> I can push to bileto and I am not a coredev; I'm not sure if that applies to any Ubuntu package or just packages I have upload rights for
<jbicha> robru or someone had to add to me to the access list since ~ubuntu-dev don't have rights to bileto by default
<cpaelzer> interesting, the create new tickets fails with a 401 instantly for me
<cjwatson> you may just need to be added to bileto-users
<cjwatson> jbicha: bileto does archive.checkUpload in LP, so it should honour the usual permissions
<cpaelzer> yeah, do requests to get added to bileto-users have a defined process a.k.a who should I bother?
<cjwatson> I guess sil2100 or robru could answer that
<sil2100> Yeah, I can do that
<cpaelzer> sil2100: https://launchpad.net/~paelzer that would be me
<sil2100> Yeah, the tricky part is... there is no fine grained ACL for bileto right now
<jdstrand> pitti: hi! yesterday I uploaded click-apparmor 0.3.17 to fix an autopkgtest failure and it migrated (yay)
<cpaelzer> sil2100: to understand is that just membership of the normal LP group at https://launchpad.net/~bileto-users ?
<sil2100> cpaelzer: yeah
<pitti> jdstrand: nice!
<cpaelzer> sil2100: that was the discussion before - is the ACL good enough to - once being member of the bileto-users - only push packages you are supposed to
<jdstrand> pitti: apparmor-easyprof-ubuntu got hung up on click-apparmor 0.3.15 and 0.3.15 failures (boo :)
<cpaelzer> sil2100: and cjwatson referenced that it calls archive..checkUpload
<jdstrand> pitti: and I thought it would get retried against 0.3.17 and then pass, but it looks like the retry against 0.3.17 didn't happen
<sil2100> cpaelzer: yeah,  basically for the publish step that's true, but there is a problem elsewhere
<pitti> jdstrand: maybe you retried before 0.3.16 was published?
<jdstrand> pitti: can you look at update_excuses.html and advise?
<pitti> jdstrand: I'd just try it again
<sil2100> cpaelzer: since there is no finer ACL, this means that anyone having access to bileto can basically modify/interact with any other ticket, not only his/her own
<jdstrand> pitti: plausible? this was several weeks ago-- click-apparmor failed initially cause of a problem in click, which took a while, then that exposed an autopkgtest failure in click-apparmor, and I dragged my feet on fixing it
<pitti> jdstrand: http://autopkgtest.ubuntu.com/packages/c/click-apparmor/yakkety/amd64 so the run for apparmor-easyprof-ubuntu/16.10.3 happened two weeks ago against 0.3.16
<jdstrand> s/which took a while/which took a while to get fixed/
<pitti> jdstrand: yeah, we don't auto-retry failed tests
<jdstrand> ah
<jdstrand> ok, so that explains it
<sil2100> cpaelzer: so even though there is no risk of publishing something you dont't have power over, but a problem in possibility to hijack (or by accident) do something with other landings
<pitti> jdstrand: I have a bug about that, but right now that doesn't happen
<jdstrand> pitti: so, what should I do to get it migrating?
<pitti> jdstrand: just retry the test
<sil2100> cpaelzer: will bring this up a few people and will get back to you if we can do something here
<sil2100> *bring this up with a few
<jdstrand> pitti: I'm not sure from update_excuses.html what to retry. the apparmor-easyporof-ubuntu tests passed and the links for click-apparmor are to the known failing versions
<pitti> jdstrand: the queue is currently veeeery long (glibc update), but I'll cut that off in a few hours
<pitti> jdstrand: retry the click-apparmor ones for a-e-u (i. e. the failing ones), that's the right thing
<jdstrand> autopkgtest for click-apparmor/0.3.16: amd64: Regression
<pitti> jdstrand: a retry will always run against the latest version of the package (it doesn't have any other choice anyway :) )
<jdstrand> retry that one ^
<pitti> correct
<jdstrand> (and the other two?
<jdstrand> ok, thanks!
<pitti> jdstrand: so on a re-run you'll get a result for .17
<jdstrand> ok, that wasn't clear to me either (if I saw '0.3.17 (not tested)' or really any reference to 0.3.17, I would've tried that I think, but that is probably part of the bug you are referring to :)
<cpaelzer> thanks sil2100, that is totally enough - myself and coreycb just wnated to clarify if that is possible and what would have to be done - seems to be in the right hands now
<coreycb> sil2100, cpaelzer, thanks!
<sil2100> cpaelzer, coreycb: I'll see what we can do, I'll poke you later today once I know more ;)
<pitti> jdstrand: I mean bug 1491145
<ubottu> bug 1491145 in Auto Package Testing "trigger tests for updated reverse test dependencies" [Medium,Triaged] https://launchpad.net/bugs/1491145
<sil2100> In the end we'd like to make bileto 'the tool' for any Ubuntu related landing, but yeah, we're still not there yet
 * jdstrand nods
<jdstrand> pitti: ok, retried. Thanks! :)
<pitti> jdstrand: actually no, that's something different
<jdstrand> pitti: I'm not sure how often this happens, but perhaps a FAQ entry in https://wiki.ubuntu.com/ProposedMigration would make sense?
<pitti> jdstrand: sure (it hasn't come up by now)
<pitti> cpaelzer: thanks for bug 1630963! I can trivially reproduce with a VM that didn't have the setup-testbed bits installed
<ubottu> bug 1630963 in autopkgtest (Ubuntu) "issues using user and password in adt-virt-qemu" [Undecided,New] https://launchpad.net/bugs/1630963
<pitti> cpaelzer: I still get a login failure though, looking into that now
<cpaelzer> pitti: I didn't get it complete either, but I tohught those easy steps would help you to fix it
<pitti> cpaelzer: right; fixing was trivial, I just don't have automatic test cases for a VM without ttyS1
<pitti> cpaelzer: I'm getting a timeout on VirtSubproc.expect(term, b'\nlogout', 10)
<pitti> i. e. --debug shows me it sent the password and the command, but it doesn't log out
<pitti> cpaelzer: same for you?
 * cpaelzer is rereading his console
<cpaelzer> timeout on    VirtSubproc.expect(term, b'\nlogout', 10)
<cpaelzer> pitti: yes
<pitti> great
<caribou> LocutusOfBorg: nacc: sure I can upload
<LocutusOfBorg> caribou, you can grab from my ppa the changes, but I think your patch was already good, since it is just a copy-paste
<pitti> cpaelzer: oh, let me guess -- no passwordless sudo?
<caribou> LocutusOfBorg: yeah, I got everything ready here, I was about to upload when nacc mentionned the other failures
<pitti> cpaelzer: I'm going to teach it $SUDO_ASKPASS
<LocutusOfBorg> I can't reproduce the failures, don't know
<caribou> LocutusOfBorg: ok, uploaded along with clamav
<LocutusOfBorg> yep saw it :)
<LocutusOfBorg> doko_, what is this patch? http://launchpadlibrarian.net/254386710/llvm-toolchain-3.7_1%3A3.7.1-2ubuntu1_1%3A3.7.1-2ubuntu2.diff.gz
<LocutusOfBorg> I don't see it applied on 3.8, neither forwarded in Debian
<cpaelzer> pitti: thanks for patching it so fast, but FYI even when making sudo pw-less in guest and host I still run into the timeout we both saw before
<pitti> cpaelzer: yep, still debugging
<pitti> cpaelzer: I think it fails earlier, I see a "Password:" prompt which is from login, not from sudo
<pitti> cpaelzer: you can tell that this isn't the preferred/commonly used way to use VMs :)
<cpaelzer> ok, I let you do so - just read your closing comment as "without pw it should be good"
<pitti> cpaelzer: no chance to get that root shell on ttyS1 on s390x?
<pitti> i. e. what autopkgtest.service does
<cpaelzer> pitti: oh I think it could work, I just don't know how yet :-)
<cpaelzer> pitti: establishing the services you usually have for ttyS1 for hvc didn't work
<cpaelzer> although I could have had minor issues that didn't throw errors, yet still blocked it from working
<cpaelzer> pitti: I'll look at it once more and let you know if I get a root shell onto it
<pitti> cpaelzer: I'm making progress, but seems automatically logging in is rather flaky on ttyS0
<cpaelzer> pitti: I get closer step by step, it missed most of your setup-testbed in regard to consoles
<cpaelzer> pitti: I now have spawned a root-something on my hvc1
<cpaelzer> and after a few issues I think I have that set up, running adt with that now
<cpaelzer> an "id" on that console gives me root, so one step further
<barry> did something change with today's dist-upgrade to cause gpg-agent not to run in the session?
<pitti> barry: there was a race condition, fixed in https://launchpad.net/ubuntu/+source/upstart/1.13.2-0ubuntu34
<pitti> barry: chances are that it's that
<pitti> barry: still in -proposed, but feel free to grab that and test
<barry> pitti: ack, thanks
<cpaelzer> pitti: ok I'm over the login thing I think - only to hit "KVM_S390_MEM_OP failed: Cannot allocate memory"
<cpaelzer> pitti: I'll enable more debugging to see what command caused that
<cpaelzer> likely around: <VirtSubproc>: failure: timed out on client shared directory setup
<cpaelzer> 9p supported at all there ?
<pitti> cpaelzer: maybe not in the s390x version of qemu?
<cpaelzer> pitti: I'll ask people who know
<xnox> 9p is supported in s390x
<xnox> but it has different name
<cpaelzer> there one is :-)
<cpaelzer> 10p
<xnox> only 2.7 qemu fixed to have aliases which are arch independant
<pitti> cpaelzer: "10p"? /me isn't sure, joke or serious
<cpaelzer> must-p would be a joke in the sense of the container p-hole :-)
<cpaelzer> xnox: adt is currently adding "-virtfs local,id=autopkgtest,path=/tmp/autopkgtest-virt-qemu.84_ut07n/shared,security_model=none,mount_tag=autopkgtest" to qemu
<cpaelzer> xnox: do you have at hand what the alternative is or shall I check docs to puzzle that together
<xnox> cpaelzer, that will not work, as -virtfs is not ported to use s390x device names
<xnox> one needs to spell out things with -device.
<cpaelzer> I thought so
<xnox> let me look it up for you.
<pitti> if a more verbose syntax works on x86 too, happy to use that; otherwise we can add a hack to not use 9p at all, but then it'll be dog slow
<cpaelzer> pitti: the verbose syntax usually works usually everywhere arch-wise, but not back in time with some older versions
<pitti> cpaelzer: >= trusty should be fine, that's where I backport it to
<pitti> cpaelzer: ah, found out why the user/password login broke
<pitti> apparently reading from the tty now reads one char at a time
<pitti> meh, /me so doesn't want to implement his own line buffering
<pitti> argh, that wasn't it even
<barry> pitti: yep, upstart's -proposed fixes it for me.  thanks!  i love being west of you :)
<pitti> lol
<cpaelzer> xnox: the 9p changes worked - thanks
<cpaelzer> pitti: I updated bug 1630909 with the next stage that fails - if you have a pointer where I should look at let me know
<ubottu> bug 1630909 in autopkgtest (Ubuntu) "failing console access on s390x" [Undecided,New] https://launchpad.net/bugs/1630909
<cpaelzer> actually the title isn't so much console anymore given what fixes we already documented in that bug :-)
<caribou> LocutusOfBorg: llvm-toolchain build failed : https://launchpad.net/ubuntu/+source/llvm-toolchain-3.6/1:3.6.2-3ubuntu3/+build/10997680/+files/buildlog_ubuntu-yakkety-powerpc.llvm-toolchain-3.6_1%3A3.6.2-3ubuntu3_BUILDING.txt.gz
<john_s> trying to compile a cifs.ko module; the resulting module is 10x as big and refuses to load due to "format exec error". What am I doing wrong here?
<pitti> cpaelzer: turns out this nut is a lot harder to crack than I thought (surprise) - I get awfully long timeouts and blocking on reading ttyS0, not sure why
<pitti> cpaelzer: I'll keep looking at user/password login, but might take a bit
<xnox> pitti, ttyS0 shouldn't exist.
<pitti> xnox: I'm debugging on x86 :)
<xnox> ah
<xnox> =)
<pitti> xnox: but yes, it should totally exist
<xnox> on s390x.... there is only one console, and one must use -no-defaults to specify where one wants it to be redirected. very obscure.
<cpaelzer> xnox: so is the POP defining the machine
<xnox> ?
<cpaelzer> xnox: that it has this kind of console
 * xnox doesn't know what POP means.
<cpaelzer> Principles of Operation
<john_s> source is from ubuntu linux-source-4.4.0-xxx package. Vermagic on original module is 4.4.0-38, new module has 4.4.19
<john_s> existing kernel won't load it.
<xnox> in qemu s390x virtio-ccw machine type pre-defines a slcp console which one cannot modify using any command line option s=(
<cpaelzer> yeah because that is in "the definition" of the machine
<cpaelzer> xnox: still I couldn't agree more that it sucks in  virtual and Linux centric world
<cpaelzer> to have such a console is an integral part of the architecture as defined - that is why it is in there IMO
<cpaelzer> xnox: pop at http://www-01.ibm.com/support/docview.wss?uid=isg2b9de5f05a9d57819852571c500428f9a
<xnox> i'm fine with forcing slcp console, i'm not fine with not able to redirect that on to file/socket/dev/null on the hypervisor side of things
<xnox> afterall, the virtual machine only knows that there is slcp, and shouldn't care where it is connected to on the host side.
<cpaelzer> xnox: I'd recommend to ask borntraeger and mihaijlov in ubuntu-s390x
<xnox> so POP is fine, machine definition is fine, but qemu args are limited.
<cpaelzer> they are the right persons to do so
<cpaelzer> xnox: might be because it is line mode
<cpaelzer> which makes it "different" (tm)
<xnox> it redirects just fine when i do -no-defaults, specify slcp by hand =)
<xnox> i don't think it is line mode in qemu though.
<xnox> it seems to be better than that.
<cpaelzer> ok, then the time is right to do so, really just catch borntraeger and mihajlov
<xnox> cause e.g. qemu VM window has colours and can run emacs
<cpaelzer> I think this relation allows backward feature requests as well
<xnox> i might just email qemu mailing list and enquire, and add them to CC
<john_s> this is neat, I solved it, thanks. I fixed /lib/modules/version/build/Makefile and then recompiled my module with make -C /lib/modules/version/build/ M=$(pwd)
<nacc> LocutusOfBorg: caribou: ack, thanks
<nacc> smb: thanks!
<caribou> LocutusOfBorg: slangasek was asking about moving away from llvm-3.6 in the foundation meeting minutes ago
<caribou> LocutusOfBorg: in clamav I mean, you might not
<nacc> caribou: ack, it's on server team's mind too -- presumably something we might want to pursue upstream? I can file an issue tracker, etc.
<caribou> nacc: as LocutusOfBorg was saying yesterday, Debian is also transitioning to llvm-3.8 so it is an issue upstream as well
<nacc> caribou: got it
<nacc> caribou: tracked in llvm's issue tracker too?
<caribou> nacc: don't know where to check
<nacc> err, i meant clamav's
<nacc> https://bugzilla.clamav.net/show_bug.cgi?id=11606
<ubottu> bugzilla.clamav.net bug 11606 in libclamav "Update to LLVM >= 3.8" [Normal,Assigned]
<caribou> nacc: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=839850
<ubottu> Debian bug 839850 in src:clamav "clamav: FTBFS with LLVM 3.8" [Serious,Open]
<nacc> caribou: ok, so those two combined :)
<caribou> nacc: I like the upstream's comment "Please use './configure --enable-llvm=no' until this can be resolved."
<nacc> caribou: pretty accurate ,but at least it's assigned to someone :)
<pitti> jsalisbury: meh, I was hoping to grab a kernel from http://kernel.ubuntu.com/~jsalisbury/lp1627108/, but it's again gone after just 15 minutes :)
<pitti> jsalisbury: (wanted to see if my bug report is a dupe or not)
<jsalisbury> pitti, sorry, I've been removing them after getting test results from om26er.  I'll leave them around for others to test from now on :-)
<jsalisbury> pitti, I'll start putting them in sub directories, with the SAH1 as the name.
<pitti> jsalisbury: cheers! I'll report on the bug once we have a "good" kernel
<jsalisbury> pitti, great, Thanks!
<pitti> jsalisbury: I. e. I suppose I should start with testing a "good" one to even know if it's the same issue
<jsalisbury> pitti, good idea
<jsalisbury> pitti, I'll have the next kernel posted in 15 minutes or so
<coreycb> xnox, you mentioned earlier that s390x and armhf autopkgtests are run under LXD.  did any other arch's switch to running under LXD recently as well?
<caribou> doko_: xnox: slangasek: that's pretty much the latest status from upstream on clamav + llvm-3.8 : https://bugzilla.clamav.net/show_bug.cgi?id=11606
<ubottu> bugzilla.clamav.net bug 11606 in libclamav "Update to LLVM >= 3.8" [Normal,Assigned]
<pitti> coreycb: no, i386, amd64, and ppc64el run in OpenStack VMs (i. e. ~ qemu)
<coreycb> pitti, ok, thanks
<doko_> LocutusOfBorg: can't remember, maybe didn't work with gold?
<jderose> pitti: you're not gonna like this, but starting u-s-d with upstart seems to fix the problem. i'll attach some details to the bug in a sec... but assuming this is a workable fix, are you open to switching u-s-d back to upstart for yakkety (at least at release) since yakkety still has the upstart user session anyway?
<pitti> jderose: nice discovery
<pitti> jderose: well, that is "unexpected" and thus an interesting handle to debug
<jderose> pitti: mostly a lucky guess i think :) thanks for all the pointers
<pitti> jderose: might be a bit hard to properly order it against the other unity bits
<jderose> pitti: ah, okay. so are  there other things that will only interact with u-s-d correctly when it's started with systemd?
<pitti> jderose: no, I just figure it's a side effect of the dbus user session somehow; I think when run with upstart it runs in the logind scope (and thus "session") while as a systemd service it runs outside
<pitti> jderose: wrt. ordering: unity apparently wants to start after u-s-d
<jderose> pitti: ah, okay. i haven't yet tried with systemd but without dbus-user-session. on that note, how difficult is it to undo the dbus-user-session stuff? not even knowing the details dbus-user-session, that sounds like a lot of work :D
<pitti> jderose: which can be expressed if both run from upstart or both frmo systemd, but not with one here, one there
<jderose> pitti: hmm, is this ordering problem easy to reproduce? things seem to work okay in the quick test i just did, but that's not a big sample size
<pitti> jderose: can't work
<jderose> okay, that makes sense
<pitti> jderose: yeah, I guess it's not crucial, I figure it avoids flickering if u-s-d changes the theme while unity is already running, or something similar
<pitti> jderose: so this still sounds like some polkit problem to me, that pkexec from within a session does soemthing else than from outside
<jderose> pitti: okay, so it's not as bad as unity not starting at all or something like that, more just a UX issues?
<pitti> jderose: right; good enough for local testing for sure, just not something I'd like to ship
<jderose> pitti: is it still helpful for me to try it started under systemd, but purging dbus-user-session?
<pitti> jderose: that was the "can't work" bit
<jderose> right... but is it a useful hint possibly?
<pitti> jderose: you can run dbus-user-session with upstart, but not "no user session" with systemd
<pitti> jderose: yes, it's absolutely an useful hint
<jderose> ah, okay, now it's making more sense i think
<pitti> jderose: need to be off for a few hours for dinner and some family time, back in ~ 3 hours
<jderose> pitti: k, enjoy. thanks again for the help!
<pitti> jderose: please leave a note in the bug as a reminder?
<jderose> pitti: yup, will do
<pitti> jderose: thanks for the experiments!
<pitti> unexpected results are always helpful :)
<LocutusOfBorg> doko_, I still don't get why you didn't fix llvm 3.8, and if the change needs to be propagated in Debian too
<doko_> LocutusOfBorg: using cmake ...
<jderose> pitti: another very interesting hint. seems like a bunch O stuff is getting restarted (or "re-triggered"?) every time you press a hotkey - https://bugs.launchpad.net/ubuntu/+source/unity-settings-daemon/+bug/1626651/comments/20
<ubottu> Launchpad bug 1626651 in unity-settings-daemon (Ubuntu) "brightness keys are handled slower in Yakkety than Xenial" [High,Triaged]
<pitti> jderose: yes, that's why it's so slow -- every pkexec runs a full PAM session which includes a systemd --user; in xenial that didn't really do anything, but now we actually do have a bunch of user services
<pitti> jderose: which is why I proposed to use common-session-noninteractive, as it avoids all that overhead
<jderose> pitti: yeah, sorry, i don't think that comment was very helpful in the end, still learning
<pitti> jderose: no worries :)
<pitti> jderose: I'm glad someone else starts to understand it too :)
<pitti> jderose: need to do some glibc handholding and then look into that
<jderose> pitti: so i've been experimenting with common-session-noninteractive. it still seems perhaps i bit more expensive than when i start usd under upstart, but it's totally workable, just a small regression if any
<pitti> jderose: right, that would be the obvious (from my POV) fix; but it doesn't explain why it would be fast to run pkexec in the session instaed of from the user bus, hence my surprise
<jderose> pitti: okay. one quick thing if you have a moment: why is including @common-session so much more expensive on yakkety than xenial? looking at /etc/pam.d/pollkit-1, it seems the same
<jderose> or, maybe that's what you just said above
<pitti> jderose: because pam_systemd now has a lot more things to do
<pitti> well, that would be by first guess
<pitti> quite obviously I don't understand the full picture yet
<Unit193> pitti: fwiw, tried usrmerge, but not in an encrypted install yet. :P
<jderose> pitti: well, that makes me fell a little better because i *really* don't understand the full picture yet :)
<jderose> pitti: if i go looking for packages that might get broken by "common-session-noninteractive", what exactly am i looking for? i'm not sure i understand the difference from the perspective of a pkexec consumer
<pitti> jderose: mostly between "is this more like running a new session (like su -) or just running a program in the same session but with different (root) privs
<pitti> jderose: interactive sessions get their own systemd --user, XDG_RUNTIME_DIR, pam_limits etc.
<jderose> pitti: and by "session" you mean pam session?
<pitti> yes, PAM specifically but also conceptually
<pitti> like "is this like another user logging in" or more like a setuid root thing
<pitti> the backlight helper is clearly the "suid root" category
<pitti> and I suspect the same for most other users of pkexec
<jderose> yeah, i can't think of anything that doesn't fit that model... but there certainly could be
<pitti> I was wondering if there is anything using pkexec that shoudl rather use something like "su -" or gksu
<pitti> jderose: wow, there are now millions of uevents like KERNEL[2471.462232] add      /kernel/slab/inode_cache/cgroup/inode_cache(4399:user@0.service) (cgroup)
<pitti> jderose: that rather smells like kernel 4.8 fallout, possibly related to bug 1626436 / bug 1627108
<ubottu> bug 1626436 in linux (Ubuntu) "[4.8 regression] boot has become very slow" [Medium,Triaged] https://launchpad.net/bugs/1626436
<ubottu> bug 1627108 in linux (Ubuntu Yakkety) "X1Carbon comes to a crawl during high CPU usage tasks" [High,In progress] https://launchpad.net/bugs/1627108
<pitti> jderose: so testing under kernel 4.4 is another useful data point
<jderose> pitti: okay, okay. so this is something that has made the bug worse since cking filed it then?
<pitti> jderose: I can explain the lot of usd-backlight-helper and systemd --user forkstats, but not why there are so many uevents and thus udevd workers, as that's all entirely system side (session doesn't have the privileges to trigger uevents)
<jderose> pitti: how are your observing these events?
<pitti> jderose: udevadm monitor -e --udev
<pitti> pkexec /usr/lib/unity-settings-daemon/usd-backlight-helper --get-brightness80
<pitti> now booting 4.4 to compare
<pitti> jderose: confirmed; 4.4 now, and zero uevents
<jderose> pitti: so with 4.4, are the brightness keys noticeably slower still than on xenial?
<pitti> jderose: still feels like an 0.1 or 0.2 s delay, so I think yes
<pitti> not bad enough to actually feel slow, but it's not instant reaction
<jderose> pitti: but more or less workable? because i know with 4.8 right now, it's pretty darn bad :)
<pitti> I don't have x here to compare
<pitti> jderose: right, but 4.8's boot speed is pretty darn bad too :)
<jderose> yeah
<pitti> 15 s vs. 1.5 with 4.4
<pitti> and I have a feeling this is related
<pitti> if the creation of every new cgroup causes 3 uevents, then every service that starts up at boot will also cause tons of uevents
<pitti> which might explain the boot speed regression and high loads
<pitti> jsalisbury: ^ does that ring a bell?
<pitti> https://bugs.launchpad.net/ubuntu/+source/unity-settings-daemon/+bug/1626651/comments/21
<ubottu> Launchpad bug 1626651 in unity-settings-daemon (Ubuntu) "brightness keys are handled slower in Yakkety than Xenial" [High,Triaged]
<jderose> pitti: is there a reason starting unity-settings-daemon under upstart would prevent usd from being effected by these extra uevents?
<pitti> jderose: going to look at that next
<pitti> we only explained the uevent/udev bits so far
<jsalisbury> pitti, it doesn't ring a bell off hand, but sounds like something to look into.
<jderose> pitti: also, please don't let me keep you from your glibc work :)
<pitti> jderose: just landing that, all good
<pitti> jsalisbury: it's at least plausible that genreating lots of uevents around cgroup creation would cause slower boot speed
<pitti> jderose: will poke for a bit and leave notes in the bug; impractical to re-join IRC between each session restart/reboot, and night anyway, so TTY tomorrow
<jderose> pitti: with "common-session" and starting u-s-d with upstart, i'm still seeing as many uevents under 4.8... but it's crazy fast now, i'd say basically the same as X
<pitti> jderose: did you actually only start u-s-d under upstart, or the entire session?
<jderose> pitti: er, when i comment out the systemd bits in /etc/X11/Xsession.d/00upstart... does that mean there's no systemd user session at all?
<pitti> jderose: correct
<jderose> okay, so that's what i did :)
<pitti> jderose: well, there's still a systemd --user, but it's not being used to start the unity session
<jderose> pitti: is this a potential sort-term fix, or are there other consequences to doing this?
<pitti> jderose: it would throw us back from all the porting work; I think we left all the upstart bits in place
<jderose> pitti: yeah, i have some stuff started by the upstart user session and it's still working fine with out-of-the-box yakkety. for what that data point's is worth :)
<jderose> pitti: if reverting back to the upstart user session for yakkety is a reasonably low risk change, my vote would be to do so, then sort out the systemd user session stuff properly for Z;)
<pitti> jderose: haha, I know
<pitti> it's also a reasonably low impact bug..
<jderose> pitti: i guess, but it sure makes a bad first impression. especially if you just ordered a shiny new System76 laptop with shiny new Ubuntu 16.10 on it... for example :)
<pitti> jderose: hang on
<Unit193> pitti: dbus-user-session is a requirement of systemd user sessions and is otherwise unrelated, correct?  x-d-s still depends on it.
<pitti> Unit193: x-d-s?
<Unit193> Erm, right.  xubuntu-default-settings.
<pitti> Unit193: correct; but OTOH moving from session to user centric model actually caused the majority of regressions
<pitti> less so the actual upstart â systemd move, as that's just mechanics of what tells unity et al to start
<Unit193> So it's only been partially reverted, alright.
<pitti> Unit193: does that slow backlight chnaging affect xubuntu too?
<jderose> pitti: so currently dbus-user-session isn't used when you use the Upstart user session stuff, only with the systemd session stuff, right?
<pitti> that would be a surprise
<pitti> jderose: it is, just less
<pitti> in particular not for settings-daemon
<Unit193> pitti: I don't know.
<Unit193> bluesabre: â
<pitti> jderose: followed up to the bug, I now completely understand what's going on
<jderose> pitti: awesome, reading...
<bluesabre> I noticed the slow backlight in xubuntu yakkety, thought it was my laptop
<pitti> bluesabre: even after https://launchpad.net/ubuntu/+source/xubuntu-default-settings/16.10.2 ?
<bluesabre> pitti, I believe so, can confirm in ~2 hours
<pitti> bluesabre: well then, however that happens, the fix should be the same
<jderose> pitti: okay, that sounds very promising! what can i do to help confirm common-session-noninteractive wont cause problems? (i've already been experimenting with it on a few systems, nothing weird yet.)
<pitti> jderose: mostly that, testing
<pitti> jderose: but after that I'm actually reasonably sure that it doesn't regress, mostly because for all that time we did *not* start a full PAM session either :)
<pitti> and the *only* difference between interactive and noninteractive is pam_systemd
<jderose> pitti: yeah, the reasoning makes sense to me (even though i don't understand the details as well)
<pitti> preparing upload now
<pitti> jderose: thanks for your help on this! this steered me into the right direction
<jderose> pitti: happy to! glad my stumbling around was helpful :)
<pitti> jderose: uploaded, now need to find someone to review
<jderose> pitti: awesome
<LocutusOfBorg> doko_, is this failure a binutils fault? https://launchpadlibrarian.net/288571350/buildlog_ubuntu-yakkety-powerpc.llvm-toolchain-3.6_1%3A3.6.2-3ubuntu3_BUILDING.txt.gz
<LocutusOfBorg> secure-plt is something that llvm is not injecting
<Unit193> If anyone is sync happy, geoip-database is a free sync. :3
* infinity changed the topic of #ubuntu-devel to: Yakkety Yak (16.10) Final Beta! | Archive: final freeze | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-xenial | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | Patch Pilots:
<nacc> smb: LP: #1546674 may also be worth fixing at the same time, if you do pick up that fix from LP: #1591695
<ubottu> Launchpad bug 1546674 in libvirt (Ubuntu) "virt-aa-helper Apparmor profile missing rules for name resolution" [High,Triaged] https://launchpad.net/bugs/1546674
<ubottu> Launchpad bug 1591695 in libvirt (Ubuntu) "libvirt-guest.sh will never sucessfully shutdown more than one virtual machine in my setup" [Medium,In progress] https://launchpad.net/bugs/1591695
<nacc> cpaelzer_: --^ as well, in case you are coordinating with smb on libvirt bugs
<doko_> LocutusOfBorg: please ask the powerpc maintainers
<nacc> doko_: LocutusOfBorg: is it possibly related to: https://llvm.org/bugs/show_bug.cgi?id=20572 ?
<ubottu> llvm.org bug 20572 in Backend: PowerPC "PowerPC backend does not support secure PLT" [Normal,New]
<nacc> doko_: LocutusOfBorg: ah no, it's presumably LP: #161127
<ubottu> Launchpad bug 161127 in mysql-dfsg-5.0 (Ubuntu Dapper) "Fix for MySQL Bug #22413 should be backported to LTS releases" [Medium,Fix released] https://launchpad.net/bugs/161127
<nacc> bah
<nacc> LP: #1611227
<ubottu> Launchpad bug 1611227 in qtbase-opensource-src (Ubuntu) "Don't use gold linker on powerpc (GCC6)" [Undecided,Fix released] https://launchpad.net/bugs/1611227
<nacc> LocutusOfBorg: fyi, fixed there with: http://paste.ubuntu.com/23286833/
<nacc> LocutusOfBorg: presumably something similar needed for llvm-toolchain-3.6?
<nacc> rbasak: at this point, should the vivid/wily tasks for LP: #1455818 be marked as won't fix and new tasks opened for xenial?
<ubottu> Launchpad bug 1455818 in mysql-5.6 (Ubuntu Wily) "[SRU] mysql-server-5.6.postrm fails when /usr/share/mysql-common/configure-symlinks doesn't exist" [High,Triaged] https://launchpad.net/bugs/1455818
#ubuntu-devel 2016-10-07
<bluesabre> backlight
<bluesabre> woops
<rbasak> nacc: yes
<nacc> rbasak: ack, will do
<rbasak> Thanks!
<nacc> rbasak: and actally, i'm going to delete the vivid/wily tasks for mysql-5.7, as it doesn't exist there, if that's ok with you? i've never been quite sure on that policy
<rbasak> Deleting tasks is a little dangerous, as they can't be recreated (Launchpad bug)
<rbasak> So I usually use Invalid instead, since I found out about that.
<nacc> rbasak: oh i didn't realize that, as i thought i had recreated them in the past
<nacc> will just leave at don't fix
<nacc> *won't
<rbasak> Sure
<nacc> rbasak: if you have the time, i would like to still chat tmrw to talk about the UOS session
<rbasak> nacc: sure
<nacc> rbasak: thanks
<pitti> Good morning
<cpaelzer_> good morning
<LocutusOfBorg> nacc, probably  yes
<LocutusOfBorg> coreycb, pandas sync?
<LocutusOfBorg> not sure BTW
<smb> nacc, we could. or are you on that libvirt apparmor one already cpaelzer ?
<smb> nacc, cpaelzer for xenial the question is whether we want to push things over the current proposed to limit the number of releases
<smb> erm and morning
<cpaelzer> smb: morning :-)
<cpaelzer> smb: no deep in qemu atm - no touch on libvirt by me
 * smb hands cpaelzer a snorkel
<smb> cpaelzer, ack, then I will have a look as time permits
<cpaelzer> smb: if the fix is easy and the current xenial hasn't passed proposed I'm for your suggestion of pushing over the current one
<cpaelzer> smb: the current one is only the preventive fix for the service names
<cpaelzer> smb: that one surely can take a sibling I think
<cpaelzer> smb: otherwise if bigger I'm for "one change at a time"
 * cpaelzer is known as snorkler
<smb> cpaelzer, right, the not shutting down all guests is more annoying that that and the fix is rather simple
<LocutusOfBorg> nacc, llvm-toolchain-3.7 fixed for powerpc
<LocutusOfBorg> caribou, ^^ feel free to steal the patch for 3.6
<caribou> LocutusOfBorg: ok, will look at it
<LocutusOfBorg> let me know if you upload please
<caribou> nacc: rbasak: LocutusOfBorg has a fix for the powerpc FTBS on 3.7 that I can backport to 3.6
<caribou> nacc: rbasak: then Debian has just removed llvm usage from the package until upstream fixes things to use LLVM 3.8
<caribou> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=839850
<ubottu> Debian bug 839850 in src:clamav "clamav: FTBFS with LLVM 3.8" [Serious,Fixed]
<caribou> So either I upload a new LLVM 3.6, or we just disable LLVM in clamav, & forget about 3.6
<caribou> nacc: rbasak: not sure what's the best option now that we're in Final Freeze
<rbasak> caribou: thanks! Maybe best to ask the release team?
<rbasak> caribou: maybe from an SRU perspective, if it's just the binary name, it'd be better to add a workaround to clamav for that for Yakkety only (and not copy that forward to Z)?
<rbasak> I don't know what mechanism we might use exactly, but what I mean is the principle that we do the minimal thing for Yakkety now and then fix llvm in Z.
<rbasak> And that minimal thing could be in clamav so as not to risk other packages.
<caribou> rbasak: imho, minimal for Y is to add LocutusOfBorg's two line patch to llvm3.6 to fix the powerpc's FTBS
<caribou> clamav remains untouched
<rbasak> caribou: is that minimal though? It could impact every SRU as dependent packages are rebuilt.
<caribou> llvm-toolchain-3.6 builds for all architectures
<caribou> rbasak: according to nacc & my check, only clamav depends on llvm3.6
<rbasak> Oh, OK. That's fine then I guess :)
<caribou> rbasak: that being the reason to get rid of it, but now is a bit too late
<rbasak> Yeah.
<rbasak> It sounds fine to me then if the release team agree.
<caribou> rbasak: I'll fix that for Z
<caribou> ok, I'll check with them
<rbasak> Thanks again for handling this!
<caribou> LocutusOfBorg's fix is already in 3.7
<jamespage> pitti, hey - need some help on bug 1631328
<ubottu> bug 1631328 in systemd (Ubuntu) "ceph-osd stays blocked on Yakkety: "No block devices detected using current configuration"" [Undecided,New] https://launchpad.net/bugs/1631328
<jamespage> what's the right way to install a new udev rules file that relies on a user/group that the package maintainer script has not yet created
<jamespage> it appears the yakkety udev drops that part of the rule when loading them?
<pitti> jamespage: such rules shouldn't be a problem -- we install those all the time, as long as the postinst actually addgroups them
<jamespage> pitti, it does
<rcj> X on yakkety with two displays is giving me an area that acts like a hall of mirrors
<jamespage> pitti, but I'm def seeing the behaviour I think I am
<jamespage> pitti, udev complains about the missing user/group
<jamespage> about 2 seconds before they are created
<jamespage> and then block devices don't get the correct perms (ceph/ceph) until I do a restart or reload of udev
<pitti> jamespage: yes, I figure it picks up the new rule during unpack via inotify
<jamespage> that was my guess
<pitti> jamespage: your postinst needs to udevadm trigger those after group cretion
<pitti> but it seems it already does?
 * jamespage looks
<jamespage> I don't think so
<pitti> jamespage: merely installing an udev rule also doesn't actually do anything -- in order for them to get active the device needs to get removed/added or udevadm triggered
<pitti> jamespage: oh, I thought because you said so in #8
<jamespage> pitti, yeah I know that - the charm does that bit once its configured with block devices etc...
<jamespage> the charm does a udevadm trigger to make udev pickup disks its just prepared for use
<jamespage> the trigger is firing, but the perms are not applied
<jamespage> so its kinda like an incomplete rule application
<jamespage> pitti, I guess a fix is to reload the udev daemon in the postinst script
<pitti> jamespage: udevadm control --reload?
<pitti> jamespage: could work, yes, if that's a race condition
<pitti> it only auto-updates via inotify every 5 seconds or so, to avoid bursts
<jamespage> pitti, its def a race condition
<jamespage> its a shame that when udev does not detect a user/group, it just sets up the rules partially
<jamespage> that feels a bit odd
<pitti> jamespage: it's actually odd that it runs the rules at all during package installation
<jamespage> pitti, its not
<pitti> normally that doesn't wiggle devices
<jamespage> pkgs installed, charm configures block devices, then triggers the udevadm trigger
<jamespage> pitti, my issue is that the rule gets partially loaded due to the race with user/group setup
<jamespage> pitti, http://paste.ubuntu.com/23288779/ look ok?
<pitti> jamespage: that's after the addgroup?
<jamespage> pitti, addgroup is done in ceph-common, rule is installed in ceph-osd
<jamespage> ceph-osd -> ceph-base -> ceph-common
<pitti> jamespage: well, still needs to be "after" -- if ceph-osd depends: ceph-common that's also fine
<jamespage> so it should happen that way
<coreycb> LocutusOfBorg, looking at pandas
<coreycb> LocutusOfBorg, synced, thanks for the nudge
<LocutusOfBorg> thanks
<nacc> smb: cpaelzer: yeah, i trust your judgment(s)
<nacc> LocutusOfBorg: ack (re: powerpc fix)
<nacc> caribou: ack on fixing powerpc for now and removing the dep in Z
<caribou> nacc: I'm on it; will upload early monday morning unless the release team tells me otherwise
<caribou> (or before eod if they ping me)
<nacc> caribou: great, thanks for following up on it!
<cpaelzer> nacc: it is scary you trust me and I don't even remember what I wrote
 * cpaelzer reading back
<nacc> cpaelzer: re: libvirt fixes and whether to combine more into -proposed
<cpaelzer> nacc: ah yeah, I already discussed on this and more with smb - good for now
<nacc> cpaelzer: thanks!
<cpaelzer> nacc: I debugged and triaged a bug we had, but we decided to postpone until after release
<cpaelzer> nacc: so it got to the backlog with some extra info
<smb> nacc, cpaelzer yeah ... actually its alrady uploaded now
<cpaelzer> smb: thanks
<nacc> smb: thanks!
<smb> cpaelzer, Oh to clarify, nacc mentioned different messages of apparmor which I could not reproduce at all. For those I asked in the bug report for confirmation they are not gone for other reasons. The one we looked at are new to yakkety while the other ones were in Xenial
<nacc> cpaelzer: it was just another libvirt bug in the server-next queue
<pitti> cyphermox: do you have some time or know someone to verify bug 1592721?
<ubottu> bug 1592721 in network-manager (Ubuntu Xenial) "Don't write search domains to resolv.conf in the case of split DNS" [Medium,Fix committed] https://launchpad.net/bugs/1592721
<cyphermox> ok
<pitti> it's otherwise ready to release
<cyphermox> yep
<tsimonq2> pitti: you mentioned a quote in the last foundations meeting (yes I read those :P) stating something like "if it
<tsimonq2> argh I hate this enter key placement!
<tsimonq2> "if it's hard, do it more often"
<tsimonq2> pitti: where did you find that? :P
<tsimonq2> pitti: or is that your quote? I was just wondering because it was in quotation marks
<chiluk> cyphermox: looks like a regression on your most recent update to initramfs-tools..https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1631474
<ubottu> Launchpad bug 1631474 in initramfs-tools (Ubuntu) "No networking with initramfs-tools 0.122ubuntu8.3 and ip=dhcp boot option" [Undecided,New]
<pitti> tsimonq2: I think it's a Google motto
<pitti> tsimonq2: but I really like it
<slangasek> chiluk: LP: #1631474 : you may want to also sync with lamont on this
<ubottu> Launchpad bug 1631474 in initramfs-tools (Ubuntu) "No networking with initramfs-tools 0.122ubuntu8.3 and ip=dhcp boot option" [Undecided,In progress] https://launchpad.net/bugs/1631474
<chiluk> slangasek ok .. at the moment, I'm just tryign to understand what the user is attempting to accomplish with ip=dhcp ... perhaps they are using a nfs root?
<chiluk> I don't know just yet.
<chiluk> slangasek I'll drive it for the time being.. it looks like a fairly straightforward bash change.
<slangasek> chiluk: ok
<chiluk> I just need to figure out what's not exactly working
<pitti> bdmurray: can http://launchpadlibrarian.net/275354292/update-manager_1%3A16.10.2_1%3A16.10.3.diff.gz be changed to not pull in the whole python3-launchpadlib stack into standard? (http://people.canonical.com/~ubuntu-archive/priority-mismatches.txt)
<slangasek> chiluk: there's mention in the bug of AWS, which is a particularly strange place to be doing nfs or iscsi root, I would think
<cyphermox> well, it's really broken anyway
<chiluk> yeah that's my thought as well. and that is correct it is in aws
<pitti> bdmurray: like, dropping it to a Suggests: and gracefully not doing PPA changelogs if the module doesn't exist, or doing REST calls with urllib?
<slangasek> cyphermox: what's really broken?
<cyphermox> that logic there in initramfs -- I see exactly what's wrong
<cyphermox> we don't skip on, all, and dhcp when parsing IP
<chiluk> yeah the device isn't getting declared explicitly?
<cyphermox> chiluk: well, klibc had a mess of different options differently configured
<pitti> infinity: ah, perl is being dragged in by the new  "rename" -- that seems awfully heavy too
<cyphermox> do basically the if there that looks if ip= contains BOOTIF needs to not run if ip = (dhcp|all|on)
<cyphermox> s/all/any/
<chiluk> ah ok.
<pitti> infinity: which is not seeded and purges without issue in a VM, and is by itself just a recommends of perl -- WTH
<chiluk> cyphermox: want me to punt it back to you?
<cyphermox> chiluk: well if you want to do it, feel free, or I can fix it myself
<cyphermox> it needs a fix in both xenial and yakkety
<chiluk> cyphermox you would likely end up sponsoring the upload anyways.
<cyphermox> well, you could get one more sponsored upload I can vouch for ;)
<cyphermox> I don't mind either way
<chiluk> alrighty.. I'll do the legwork then.
<chiluk> I really could use the uploads ..
<chiluk> it might take me a little longer than you to fully wrap my head around what this awesome bash script is doing.. but this is a good opportunity to spread the expertise.
<tsimonq2> pitti: cool :)
<smoser> cyphermox, around ?
<smoser> pokign aroudn with open-iscsi and such.
<smoser> i launch a vm with a nick on a lxdbr0 and then run
<smoser> http://paste.ubuntu.com/23290520/
<cyphermox> smoser: seems to me like a badly configured dhcp server?
<smoser> is it expected that dhclient use 'ip' from busybox ?
<cyphermox> yes, that's fine
<smoser> well, dhcp server is configured by lxd
<smoser> http://paste.ubuntu.com/23290551/
<smoser> and stgraber says it should work
<cyphermox> are there free IPs?
<cyphermox> what packets go through?
<cyphermox> tbh there is nowhere near enough information there to know what is wrong, but it's not likely because of which /bin/ip we use
<smoser> i'm trying to do ipv6 dhcp
<smoser> so probably
<smoser> and there are 2 hosts on that network
<cyphermox> smoser: well, we do exactly that to deploy maas instances in an ipv6 only network and it works
<cyphermox> lamont: ideas?
<smoser> cyphermox, well, "works" is a bit of a strong word. :)
<cyphermox> it *works*
<smoser> lamont has been strugging with it for quite a while
<cyphermox> yeah, there's various pieces into that, not just dhcp.
<lamont> smoser: initramfs-works.
<lamont> shutdown later doesn't
<lamont> in that it shuts down the interface whjere the root disk lives
<lamont> which could ultimately be an initramfs-tools bug, but it's not a configuration bug
<lamont> having said that, bridges and ivp6 address diescovery have their moments... since they "optimized" the bridge code to not forward multicast packets taht weren't "needed", and having that on has caused great pain with ipv6 address discovery for me.
<lamont> smoser: packet traces are a very good start for figuring out what is happening with dhcp
<smoser>  http://paste.ubuntu.com/23290593/
<lamont> smoser: . /lib/functions (or such) and run configure_networking() ?
<smoser> yeah, i can try.
<smoser> so fyi, i run: dhclient -6 -d -v eth0
<smoser> it errors like in
<smoser> http://paste.ubuntu.com/23290520/
<smoser> second time, it actually tries to do something
<smoser> but still fails
<smoser> so it surely seems to me that the 'ip' that is causing garbage was bringing the interface up
<smoser> which seems important.
<lamont> smoser: the code that actually runs in the initramfs is: . /scripts/functions; configure_networking
<lamont> and that code works
<smoser> well, that fails the same way for me.
<lamont> and what do the packet traces look like?
<smoser>  message status code NoAddrsAvail: "no addresses available"
<smoser> stgraber, ^
<smoser> "NoAddrsAvail:"  ?
<lamont> tcpdump -ni any por5 547
<lamont> only without the typo
<jderose> cyphermox: bah, your initramfs-tools update for xenial broke some of my PXE boot related tooling :P still digging into the details, not yet sure if it's fragile assumptions on my end or a bug on your end... will let you know
<jderose> but the symptom is a kernel panic when trying to PXE boot
<cyphermox> jderose: there is a bug
<cyphermox> I bet your PXE deployments pass ip=dhcp
<jderose> cyphermox: have the # or link handy?
<jderose> cyphermox: yes, indeed it does
<cyphermox> https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1631474
<ubottu> Launchpad bug 1631474 in initramfs-tools (Ubuntu) "No networking with initramfs-tools 0.122ubuntu8.3 and ip=dhcp boot option" [Undecided,In progress]
<cyphermox> entirely my fault, I derped there adding the logic to parse BOOTIF.
<cyphermox> chiluk is working on the fix and I'll sponsor it as soon as it's ready
<jderose> cyphermox: happens to everyone, no worries :)
<cyphermox> it's kind of crippling ;)
<chiluk> yeah I'm finding some other issues as well while I look through the code.
<jderose> cyphermox: also, if you ever have a proposed package with PXE boot related changes... i'm always happy to test, feel free to ping me anytime :)
<chiluk> jderose can you add your /proc/cmdline to the bug and paste it here as well
<chiluk> so I know how people are using this.
<chiluk> thanks.
<chiluk> I'm trying to make sure all cases get covered.
<jderose> chiluk: yup, will do
<jderose> chiluk: done
<chiluk> cyphermox: for example if ! echo "${IP}" | grep -qc 'BOOTIF'; then  will always return true regardless
<chiluk> jderose: would you be willing to test an updated initramfs-tools for me shortly?
<jderose> chiluk: yup, absolutely! prefer a ppa, but i can manage a deb too, will just take a bit more hacking around (my tooling doesn't make debs especially easy)
<chiluk> sure I'll create a ppa ..
<chiluk> one sec.. I'm trying to test it myself and the deb is failing to install ..
<chiluk> which is strange.
<jderose> chiluk: awesome, easy peasy then
<cyphermox> chiluk: what?
<jderose> chiluk: oh, for completeness here and not just in the bug, my current cmdline is something like: initrd=initrd.img-4.4.0-36-generic root=/dev/nfs nfsroot=10.17.76.1:/var/lib/tribble/ephemeral ip=dhcp ro nomodeset net.ifnames=0
<chiluk> cyphermox: the IP variable should never contain BOOTIF
<chiluk> so the grep will always fail so the if will always be true
<cyphermox> that's not true
<cyphermox> the IP variable totally can and does contain BOOTIF sometimes
<cyphermox> BOOTIF == whatever interface teh system used to boot with
<chiluk> cyphermox does dash support ;& fall-through syntax?
<cyphermox> I do not know
<chiluk> it looks like a no.. which pisses me off
<chiluk> why aren't we just using bash..
<jderose> chiluk: not sure if it will be helpful, but i rather recently discovered https://www.shellcheck.net/ and it's kinda badass :)
<cyphermox> chiluk: http://paste.ubuntu.com/23290876/
<cyphermox> should be sufficient afaik
<chiluk> crap cyphermox that's finding a world of bugs on just this one area.
<cyphermox> oh, looking for on should be strict, in case we ever have devices that start in on ;)
<cyphermox> I'm going to have to come back later, I have a dinner planned tonight
<jderose> cyphermox: enjoy, thanks for the quick response!
<chiluk> ok cyphermox... I'll put together a patch and ppa and get that out to folks as soon as I'm happy
<chiluk> my kingdom for full bash interpretter instead of fricking dash.
<chiluk> I'm trying to make things pretty here.
<ScottK> infinity: Kubuntu would like to get a security fix in before release:   https://anonscm.debian.org/git/pkg-kde/frameworks/kcoreaddons.git/commit/?id=ab7258dd8a87668ba63c585a69f41f291254aa43
<infinity> ScottK: Security fixes welcome.
<ScottK> K. Thanks.
#ubuntu-devel 2016-10-08
<Gehenna> We have gotten all the nice and several data of a girl with her photos in Mega. The access link is just on the Onion Network and will be available for 1 hour only, then it will be destroyed automatically and we will post it with a new link again here or in any other place: http://zerobinqmdqd236y.onion/?cba299c34f92e825#ZIefAgO9RJfAr3miBUfvomyM7YIVz8dbhksPnNQAB5Y=
<Bluefoxicy> How appropriate.  Gehenna can go to hell.
<remote> yo
<remote> someone has produced a ubuntu-server image for armhf (rpi3) devices, but ubuntu only released an image for rpi2 -- where can I find the discussions on this (if there are any) ?
<remote> http://cdimage.ubuntu.com/ubuntu/releases/16.04/release/
<remote> https://wiki.ubuntu.com/ARM/RaspberryPi
<remote> fo0bar: you made that image
<remote> why isn't it officially supported?
<xnox> remote, can't remember the progress. there was some progress on it. i think generic armhf runs on rpi3 now, or some such, no?
<xnox> the progress on those, may have stalled.
<remote> i don't know but from what i've seen at this point the information is a bit messy
<remote> there was first mention that images for rpi worked on rpi2, and rpi3, then I faced a large heading link saying "download image for RPI2" after which I found there were two different images, one of them wasn't hosted on ubuntu servers and so i'm trying to find out what's up with it as I may decide to use it
<remote> xnox: can we find out quickly if the official armhf supports rpi3?
<xnox> remote, rpi3 should be able to run arm64 images.
<xnox> not armhf images
<xnox> however, given small amount of ram armhf images make sense too.
<xnox> i do not know what is "supported". I'm sure binaries do run fine =)
 * xnox does not buy support
<remote> feck, i didn't even know it had an arm 64 processor
<remote> i can't stand this lack of information it's like a bunch of people produce a lot of different software packages to help rpi users but nobody talks about why it's needed in first place
<remote> i need to learn how to read and type 10x faster
<remote> xnox: it does run fine (as-in it boots, and I can login)
<xnox> remote, i took a keyboarding course and it took forever typing pointless sequences. But i did learn touch typing, it was ~4h a week for three months.
<xnox> so if you schedule to work on it, via keyboaring apps, it can be done.
<remote> i never met someoneone who types faster than me
<xnox> oh, ok.
<remote> it's just too slow
 * xnox can't wait for focus follows eye sight
<remote> humans need better output
<fo0bar> remote: see https://wiki.ubuntu.com/ARM/RaspberryPi/RaspberryPi3 for info, including a list of outstanding bugs to get proper support at the end.  in short, the biggest blocker was u-boot didn't have rpi3 support as of xenial's release
<remote> what's that?
<fo0bar> so the one-off rpi3 xenial image uses a PPA with some backported packages
<remote> fo0bar: awesome, thanks for digging it for me
<xnox> did you ever look at one window, and use shortcuts for that window, whilst cursor is another? e.g. press Ctrl-L to type a URL in a webbrowser window, only to clear your bash screen instead?
<remote> this means nothing to me, i'm never used ubuntu before (debian)
<remote> what's PPA?
<fo0bar> (this is for 32-bit kernel/userland.  64-bit is possible as explained in that wiki page, but the kernel support was still in its very early days last I checked)
<remote> yeah i'm going to read through it
<clivejo> !ppa
<ubottu> A Personal Package Archive (PPA) can provide alternate software not normally available in the offical Ubuntu repositories - Looking for a PPA? See https://launchpad.net/ubuntu/+ppas - WARNING: PPAs are unsupported third-party packages, and you use them at your own risk. See also !addppa and !ppa-purge
<remote> fo0bar: did you have any problems with your custom image for rpi3?
<remote> some service failed at boot time but i can't find it back
#ubuntu-devel 2016-10-09
<pishuilu> cyphermox: Hi, I am ShuiLu Pi ,a member of Ubuntu Kylin team. I have just updated the ubuntu kylin slideshow , and have merged into the main branch,  would you please upload slideshow package to ubuntu?
<Bluefoxicy> I don't get it.
<Bluefoxicy> when I try to print https://gtmgstaticfiles-nbzlbgytj5azbyp7y4yu.netdna-ssl.com/zeroglide/pdfs/zero-glide-sizing-guide.pdf it doesn't print.
<Bluefoxicy> Restarting cups via systemctl prints a page that says "PCL XL error subsystem: kernel error: illegaltag operator: 0x1b position: 240515"
<Bluefoxicy> There we go.  Used an HL-2170 driver (it's a Brother HL-2270DW) instead of PCL6
#ubuntu-devel 2017-10-02
<Unit193> sarnold: I'm presuming you aren't around?
<jbicha> LocutusOfBorg: would you like to update geary to 0.12.0 (released today)?
<jbicha> I intend to NMU it because I don't like leaving it as a git snapshot in Debian but the delay may be too long for artful
<LocutusOfBorg> sorry but ENOTIME for some time
<LocutusOfBorg> I have 500 packages to look at
<jbicha> wow ok
<GunnarHj> Laney: Any chance you can look at the FFe at bug #1707929?
<ubottu> bug 1707929 in xkeyboard-config (Ubuntu) "[FFe] Revert blacklisting of Indic layouts" [High,Triaged] https://launchpad.net/bugs/1707929
<Laney> GunnarHj: sorry about that - looks OK to me, feel free to merge the pkg with Debian (that's the only change there)
<GunnarHj> Laney: Right; thanks!
<jbicha> speaking of Indic, we should discuss LP: #1719934 comment 5, maybe at tomorrow's Desktop meeting?
<ubottu> Launchpad bug 1719934 in ubuntu-meta (Ubuntu) "Missing fonts in list of languages" [Medium,In progress] https://launchpad.net/bugs/1719934
<jibel> jbicha, can you use another bug report instead of repurposing this one ? It's specifically about missing fonts not moving others from one seed to another
<jbicha> jibel: sure, but I was pointing out that there were other Indic fonts dropped at 16.04 besides those 2
<jbicha> jibel: and if we put fonts-indic in desktop-common than your merge proposal is unnecessary
<madigens> hm, is ubuntu using google's noto font family for extended language support or is planning to? noto is among the highest quality families with the widest language coverage out there.
<madigens> i often find it cringeworthy to open some wikipedia page and see a mixture of good and bad design in the side panel, even if i speak only two of the listed languages
<GunnarHj> Laney: Another thing: Would appreciate your advice re bug #1720250. There is a proposal in this PPA:
<ubottu> bug 1720250 in im-config (Ubuntu) "im-config configuration ignored with gdm3" [High,Confirmed] https://launchpad.net/bugs/1720250
<GunnarHj> https://launchpad.net/~gunnarhj/+archive/ubuntu/im-config/+packages
<GunnarHj> and it's especially the change of debian/user/im-config.service which is over my head. The change seems to solve the issue, but we don't want bad side effects...
<Laney> GunnarHj: where did that come from?
<Laney> ok, comment 8
<GunnarHj> Laney: Right, from Mitsuya Shibata.
<Laney> not sure about this
<Laney> I think basic.target is too basic - it'll execute with non-graphical logins
<Laney> And it probably starts up multiple times (RemainAfterExit=yes)?
<Laney> Don't think ripping out PartOf=graphical.target is good, we need that when we go back to user sessions properly in 18.04
<GunnarHj> Laney: Any other idea for a solution this cycle? Without the change, im-config is ignored.
<jbicha> madigens: Ubuntu installs fonts-noto-cjk, fonts-nanum, fonts-liberation (and of course the Ubuntu fonts) by default
<jbicha> madigens: there are more font weights in fonts-noto-cjk-extra but that's a large package so we try to only install that for users of CJK language packs
<GunnarHj> jbicha: If you add fonts-indic, as we talked about, the coverage would be rather good.
<Laney> GunnarHj: not off the top of my head
<Laney> well, ok, maybe you can add an ExecStartPre to check $XDG_SOMETHING and not start if it's not set
<GunnarHj> Laney: I'd need handholding to do that. :)
<Laney> problem is you want to make it exit when the user logs out
<Laney> and ideally clear the environment variables
<GunnarHj> Laney: Are you saying that this mechanism would result in user session variables not being cleared at logout?
<Laney> looks like it to me
<Laney> only if you're logged in somewhere else at the same time
<Laney> if it's the last session then the systemd --user instance itself would go away
<Laney> I guess we had that bug before though
<GunnarHj> Laney: Any chance you could summarize your doubts on the bug report? Mitsuya might be able to address them. (AFAIK we haven't had this bug before.)
<madigens> jbicha: are you using the super OTCs for the CJK fonts? they save a lot of space
<GunnarHj> madigens: We use the weight specific OTCs, not the "super" one.
<madigens> oh well :)
<GunnarHj> madigens: The difference is small from a size POV.
<Laney> GunnarHj: done, and I thought of something to maybe do
<GunnarHj> Laney: Do you mean that we should basically keep the current file, and add something in /etc/profile.d as a workaround for now?
<Laney> I think it'd make for a better solution than a unit which might cause problems
<Laney> well, give it a go :-)
<GunnarHj> Laney: Right, thanks for clarifying. We'll try that route.
<Laney> I don't much like stuffing /etc/profile.d/ with desktop things, but it feels like it offers the cleanest solution atm
<Laney> until we get the user sessions hooked back up again
<soc> hi
<soc> can someone help me with an environment variable issue?
<soc> some application sets XAUTHIROTY, I beleive it is lightdm, and it seems I can't override it
<soc> setting it in .profile is too late, and in .pam_environment it just gets overridden
<nacc> chrisccoulson: is there going to be a correspondign 56.0 upload to artful as to the other releases?
<nacc> chrisccoulson: re: firefox
<chrisccoulson> yes, but tomorrow now
<chrisccoulson> well, later
<nacc> chrisccoulson: ack, thanks
<chrisccoulson> actually, I may as well just do it now
<nacc> chrisccoulson: :)
<nacc> chrisccoulson: didn't meant to pester you into doing it ASAP, just was curious and was responding to someone asking about it
<nacc> thanks chrisccoulson
#ubuntu-devel 2017-10-03
<smoser> RAOF, when you get around to sru processing tomorrow, could you look at letting cloud-init in ? it looks like it should be good for bug 1717477
<ubottu> bug 1717477 in cloud-init (Ubuntu Zesty) "cloud-init generates ordering cycle via After=cloud-init in systemd-fsck" [High,Fix committed] https://launchpad.net/bugs/1717477
<smoser> (thanks in advance)
<RAOF> smoser: I'm on leave starting tomorrow for a week and a bit; my next regular SRU rotation would be Wed the 18th.
<RAOF> smoser: I presume you'd like it done before then, though, so I'll check it out after I track down this deadlock.
<smoser> RAOF, thanks for the heads up. have a nice holiday!
<RAOF> smoser: Sorry I didn't get to cloud-init today; please feel free to ping the next SRU guy on your list :)
<alkisg> Ubuntu's firefox 55 made adobe flash crash by just right clicking on it. Now firefox 56 made flash crash without getting displayed at all (LP: #1720908). Upstream firefox releases don't have those issues... could someone fix the new .diff?
<ubottu> Launchpad bug 1720908 in firefox (Ubuntu) "Firefox cannot load Flash because of libxul broken dependency" [Undecided,Confirmed] https://launchpad.net/bugs/1720908
<chrisccoulson> alkisg, works fine here
<alkisg> chrisccoulson: thanks, let me try in a few VMs to see if something else is amiss (I tried 2 real installations already)
<alkisg> Are you using flashplugin-nonfree, or adobe-flashplugin?
<alkisg> *flashplugin-installer
<pchamtaczke> Hi, is there any api to get Ubuntu
<pchamtaczke> *Ubuntu Security Notifications?
<alkisg> chrisccoulson: I can't find any way for firefox 56 + flash to run. Test cases so far: (1) mate 16.04 amd64 + firefox 56 + adobe-flashplugin=broken, (2) the same in i386=broken, (3) unity 16.04 amd64 + firefox 56 + flashplugin-installer=broken.
<alkisg> In all those cases, if I revert to previous firefox versions, they work.
<alkisg> 1 and 2 are real PCs (different ones), while 3 is a VM...
<Unit193> So all of it is for 1604?
<alkisg> Yes, I haven't tested e.g. 17.10 or anything
<Unit193> I was going to confirm that I've seen no crashing due to flash.
<chrisccoulson> alkisg, ok, I can see the issue. It also means there's another bug, because it should fail on later releases too, but it doesn't
<alkisg> ty
<chrisccoulson> at some point, we've stopped enabling BIND_NOW
<chrisccoulson> which most likely happened here https://launchpad.net/ubuntu/+source/firefox/49.0+build4-0ubuntu2 (cc doko)
<alkisg> chrisccoulson: I verified that the "immediate bug" isn't there in zesty, but the "right click crashes" bug is there
<alkisg> *immediate crashing
<alkisg> E.g. firefox 54 in zesty works, while firefox 56 crashes on right click
<acheronuk> LocutusOfBorg mitya57 : can we maybe get into artful? https://packages.debian.org/source/experimental/qtwebview-opensource-src
<acheronuk> I think I saw lisandro say it was due to go into sid imminently
<LocutusOfBorg> just sync it?
<LocutusOfBorg> and ask release
<acheronuk> LocutusOfBorg: I can't 'just sync it', I can only request-sync
<acheronuk> anyway, I was asking to be polite to Qt peeps
<acheronuk> oh, and @ tsimonq2 ^^^
<acheronuk> amarok -dev was asking for it
<LocutusOfBorg> sorry but I don't speak qt :) don't you have uploads powers?
<LocutusOfBorg> my point is: if you want it to be syncd, I guess a chat with some release team member is preferred
<acheronuk> LocutusOfBorg: no, I'm not MOTU
<LocutusOfBorg> in caze, I think mitya57 is the best person to do that sync
<LocutusOfBorg> *case
<acheronuk> LocutusOfBorg: indeed, hence including him in my initial ping
<tsimonq2> acheronuk: Is it urgent for this cycle?
<acheronuk> tsimonq2: ask the guy in #kubuntu-devel
<acheronuk> he was requesting it for amarok
<tsimonq2> Ok
<chrisccoulson> alkisg, ok, got a fix for the context menu crash as well, although it won't be in the version I've already uploaded
<alkisg> chrisccoulson: thanks a lot! :)
<mitya57> acheronuk, LocutusOfBorg: doesn't it need a FFe first?
 * mitya57 replied on all 3 channels
<bdmurray> doko: Is there a plan for python3 apps depending on DLFCN? bug 1708947
<ubottu> bug 1708947 in gdebi (Ubuntu) "gdebi-kde crashed with ModuleNotFoundError in /usr/lib/python3/dist-packages/PyKDE4/__init__.py: No module named 'DLFCN'" [Medium,Confirmed] https://launchpad.net/bugs/1708947
<slashd> rbasak, good day, could you please have a look at the newest debdiff (comments#38) created by niedbalski (re: percona-xtradb-cluster-5.6) LP: #1657256. I'm asking you since you did the first sponsoring round (before the compilation issues)
<ubottu> Launchpad bug 1657256 in percona-xtradb-cluster-5.6 (Ubuntu Artful) "Percona crashes when doing a a 'larger' update" [Medium,In progress] https://launchpad.net/bugs/1657256
<nacc> slashd: rbasak is on a swap day
<slashd> nacc, thanks, I'll ping him tomorrow then.
<slashd> niedbalski, tinoco ^
<nacc> slashd: np
<GunnarHj> Laney: Unfortunately the /etc/profile.d workaround we talked about yesterday doesn't work well enough. Can you please take a look at the latest comments on bug #1720250?
<ubottu> bug 1720250 in im-config (Ubuntu) "im-config configuration ignored with gdm3" [High,Confirmed] https://launchpad.net/bugs/1720250
<Laney> GunnarHj: Not really, I don't know why that would happen, can you debug?
<GunnarHj> Laney: No, I wouldn't know how to do that. Sorry.
<Laney> Sorry also.
<GunnarHj> Laney: Is the first variant a no-go?
<GunnarHj> Laney: As a 17.10 hack...
<Laney> GunnarHj: It should be possible to look at what the difference between the two is that makes profile.d not work
<Laney> check the environment you get in both cases
<GunnarHj> Laney: The environment is identical in the two cases. The problem is that the suggestion window does not show up when typing, which makes the too pretty useless, I suppose.
<Laney> Why would that be though?
<GunnarHj> Laney: No idea.
<GunnarHj> s/too/tool/
<GunnarHj> Laney: It shows up on Xorg.
<Laney> look at the process list on both maybe
<GunnarHj> Laney: Yeah.. It just struck me that there are two instances of IBus running, and that setting variables in /etc/profile.d might be too late for the instance which is actually used.
<GunnarHj> Laney: But I can take a closer look at the process lists. (Need to move to artful first...).
<Laney> you can look at /proc/<pid>/environ too
<Laney> to see what the processes saw
<GunnarHj> Laney: Ok, I'll make a try.
<Laney> Cool!
<acheronuk> mitya57: yes, I guess it would require a FFe :/
<mitya57> acheronuk, if you file one then I will subscribe and sync when it is approved
<acheronuk> mitya57: ok. I'll try to get to it this evening, but if not, in the morning
<mitya57> acheronuk, please subscribe me when you do it then
<acheronuk> mitya57: I will
<doko> bdmurray: yes, fix them. googling for that message shows some work arounds
<Unit193> mdeslaur: Thanks very much for the newsbeuter security update!
<doko> chrisccoulson: is there currently a reason to build thunderbird with gcc-5 in artful?
<Unit193> Are we going to have one more merge of glib2.0?  It fixes one nasty bug in Xubuntu where a bunch of mounts end up on the desktop.  (cc jbicha, Laney, etc)
<jbicha> Unit193: didrocks is working on the glib 2.54.1-1 merge this week
<Unit193> It's still regressed from Zesty, though not dang awful.
<Unit193> jbicha: Thanks!
#ubuntu-devel 2017-10-04
<nacc> cjwatson: random question -- I thikn you did this change a while ago for man subpages: http://git.savannah.gnu.org/cgit/man-db.git/commit/?id=7de45db026166ea55f9b7c240928ef0de0245a3f. As we added subsubcommand with git-ubuntu, would it make sense to find the longest concatenation with a manpage? (That is, `man git ubuntu lint` currenly opens `man git-ubuntu` even though `man git-ubuntu-lint` is alsoo
<nacc> available
<nacc> it seems like currently it tries git-ubuntu (finds it) and also tries lint (without git-ubuntu-)
<cjwatson> nacc: maybe; it would need a fair bit of refactoring as the code that does that is horribly special-cased right now
<nacc> yeah, I see that :)
<cjwatson> I would take patches for it but I think it would have to be in a few passes, with cleanup first
<nacc> cjwatson: thanks -- I'm not sure if it's always correct either way to do what I'm suggesting (but I thinkn worst case we'd iterate a few times and not find it)
<nacc> cjwatson: yep, i'll consider it, as it'll be a good improvement for our use case :)
<cjwatson> I think it would be OK to do so; interactively asking for several pages is pretty rare
<nacc> yeah
<cjwatson> (well, OK, I have no data, but from observation)
<nacc> I've only done it on accident :)
<KD2JRT> I'm vaguely curious if a 32 elevation path is workable from NYC
<KD2JRT> *pass
<KD2JRT> er, wrong channel
<acheronuk> mitya57: subbed you: https://bugs.launchpad.net/ubuntu/+bug/1721191
<ubottu> Launchpad bug 1721191 in Ubuntu "[FFe qtwebview-opensource-src] Sync 5.9.1-2 (universe) from Debian unstable (main)" [Wishlist,New]
* NIGGGGGGGGGGGGER changed the topic of #ubuntu-devel to: NIGGERS EAT SHIT!!! NIGGERS EAT SHIT!!! NIGGERS EAT SHIT!!! NIGGERS EAT SHIT!!! NIGGERS EAT SHIT!!! NIGGERS EAT SHIT!!! NIGGERS EAT SHIT!!! NIGGERS EAT SHIT!!! NIGGERS EAT SHIT!!! NIGGERS EAT SHIT!!! NIGGERS EAT SHIT!!! NIGGERS EAT SHIT!!! NIGGERS EAT SHIT!!! NIGGERS EAT SHIT!!! NIGGERS EAT SHIT!!!
<NIGGGGGGGGGGGGER> !ops
<ubottu> Help! Channel emergency! mneptok, Hobbsee, cjwatson, lamont, kees, darkwing, Unit193, idleone, infinity, Laney, or slangasek!
* Unit193 changed the topic of #ubuntu-devel to: Zesty Released, Artful Beta 2 Released | Archive: final beta freeze | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-zesty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | Patch Pilots:
<Son_Goku> it's a weird day when I see @ubuntu.com email address added as a CC to a package I'm reviewing in Fedora...
<Son_Goku> also... hi jbicha
<slashd> rbasak, good day I don't know if you saw my irc message yesterday (you were on pto I think), and just in case I left the comment (#53) in the bug (LP: #1657256). To summarize, would you be able to perform a 2nd review of percona-xtradb-cluster-5.6 since the last upload had some compilation issues ?
<ubottu> Launchpad bug 1657256 in percona-xtradb-cluster-5.6 (Ubuntu Artful) "Percona crashes when doing a a 'larger' update" [Medium,In progress] https://launchpad.net/bugs/1657256
<rbasak> slashd: I already said (weeks ago) on IRC that that debdiff is unacceptable for Artful.
<rbasak> slashd: I'll dig out the IRC logs.
<rbasak> 17:14 <rbasak> ddstreet: sorry, I didn't realise you had a new patch for me there. I don't think forcing use of gcc-6 is a suitable fix for the development release though. I suspect doko wouldn't be happy about that.
<ddstreet> slashd niedbalski i believe i passed that info on to you guys...
<ddstreet> rbasak sorry, i thought they had addressed that, i'll follow up with them
<niedbalski> rbasak, doko what would be the preferred approach then? I wonder if disabling all the introduced warnings is suitable though,.. also a reminder that current vanilla package fails to build from source.
<niedbalski> rbasak, saw your comment on the public bug, will follow up from there, thanks for the input.
<slashd> rbasak, thanks for the recap, I was in conference and vacation, I might have missed it.
<jbicha> Son_Goku: I subscribe to a lot of bugs, I forget which bug you are thinking of
<Son_Goku> jbicha: rhbz#1481630
<Son_Goku> aww, no bot to turn that into a url
<Son_Goku> meh: https://bugzilla.redhat.com/show_bug.cgi?id=1481630
<ubottu> bugzilla.redhat.com bug 1481630 in Package Review "Review Request: VirtualBox-guest-additions - VirtualBox Guest Additions" [Medium,New]
<jbicha> that's a very interesting bug since that's related to upstreaming virtualbox drivers to the Linux kernel, and I use virtualbox
<Son_Goku> well, I was a bit surprised, since it's not extraordinarily helpful to you (Ubuntu isn't RPM-based, sadly :P )
<rbasak> s/sadly/gladly/ :-)
<jbicha> Son_Goku: it is helpful. VirtualBox was broken for a few days just before Ubuntu Final Beta because the upstreamed drivers didn't work right (at least in Ubuntu)
<Son_Goku> rbasak: I don't think so :)
<jbicha> also I occasionally run latest or dev Fedora in VBox as a reference and installing the guest additions there is a pain sometimes
<jbicha> Fedora 27 might be affected by the same problem Ubuntu had with Linux 4.13
<Son_Goku> jbicha: which was what?
<Son_Goku> incidentally, 4.13 has already rolled out to Fedora 26 too
<Son_Goku> https://bodhi.fedoraproject.org/updates/FEDORA-2017-c0e81a1c7a
<Son_Goku> https://bodhi.fedoraproject.org/updates/FEDORA-2017-6d64333469
<Son_Goku> jbicha: are you referring to login screen being busted in VirtualBox?
<jbicha> Son_Goku: could be, I haven't used Fedora recently, the Ubuntu bug was LP: #1718679 and we set CONFIG_DRM_VBOXVIDEO=n in the Ubuntu kernel to workaround it
<ubottu> Launchpad bug 1718679 in linux (Ubuntu) "Upgrade to 4.13.0-11.12 in artful amd64 VM breaks display on wayland" [High,Fix released] https://launchpad.net/bugs/1718679
<Son_Goku> iirc, I don't think wayland *ever* worked with vbox
<jbicha> yes, Fedora agressively pushes new kernels to stable releases
<jbicha> it works fine for me
 * Son_Goku shrugs
<Son_Goku> I don't use vbox so I dunno
<jbicha> sometimes I've had a problem with the login screen not refreshing correctly but once logged in, things are good
<Son_Goku> jbicha: that's the only issue I've seen people report about vbox in general
<nacc> would it be reasonable for `dpkg-source --print-format` to not complain about the format of binary package stanzas? (it's a fatal error)
<madigens> hm! how do i get a wayland session in artful? in both virtualbox and on a laptop with some radeon 5xxx igp i can't select it on the login screen
<nacc> madigens: #ubuntu+1
<madigens> nacc: thanks
<ackk> mvo, any chance you could have a look at https://code.launchpad.net/~ack/apt-btrfs-snapshot/fix-arg-parser/+merge/328776 ? should be trivial
<mvo> ackk: sure, sorry, that totally escaped my view. looks great, thank you for this
<ackk> mvo, np, thanks for looking
<sarnold> Unit193: indeed, I'm not here :)
<sarnold> Unit193: well, I guess I'm here now, but not here sunday.
<Unit193> Heh, I was right, I have no clue what that was about anymore. :D
<niedbalski> rbasak, could you please review the latest patch on LP: #1657256? thanks.
<ubottu> Launchpad bug 1657256 in percona-xtradb-cluster-5.6 (Ubuntu Artful) "Percona crashes when doing a a 'larger' update" [High,In progress] https://launchpad.net/bugs/1657256
<sarnold> Unit193: success! :D
<juliank> bdmurray: I think https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1721364 is opinion. As I just wrote in the comments, the behavior was explicitly changed so dependencies of meta packages are removed when explicitly removing the meta package and marked as manually when the meta package (dependencies) breaks
<ubottu> Launchpad bug 1721364 in apt (Ubuntu) "Never-MarkAuto-Sections not working" [High,New]
<juliank> bdmurray: So, it would be great if you could test installing a package that conflicts with ros-desktop and see what that does
<bdmurray> juliank: Do you have a suggestion for a conflicting package?
<juliank> bdmurray: Use equivs-build to create one conflicting with ros-desktop (for example) and installl that with apt install ./path/to/dummy.deb
<juliank> bdmurray: Example on my system with a package conflicting with my jak-machine-master package and installing that vs. removing jak-machine-master explicitly :https://paste.ubuntu.com/25675324/
<juliank> We also have the opposite variant of never-mark-auto which moves auto bits on installs to new dependencies (used for oldlibs), I like that.
<bdmurray> juliank: The Move-Autobit-Sections? My concern is recommending people use autoremove or enabling that and having a whole mess of packages removed if they did something silly and removed a metapackage.
<juliank> bdmurray: Life sucks either way. The current behavior makes most sense from a UI perspective. If we just did the mark as manual bit on all removals, we'd have tons of users complaining that "Hey, I told apt to remove gnome, but all the stuff is still there"
<juliank> "My system continuous to grow, apt does not remove packages I tell it to!"
<juliank> bdmurray: I don't think that people removing a meta package explicitly is a common situation. If they remove it accidentally, they are covered by the manual bit moving. Maybe we should make it harder and ask people "Removing the following packages allows other packages to be automatically removed, do you want to continue?"
<juliank> Or move "The following packages were automatically installed and are no longer required:" to the end and rename it "The following packages were automatically installed and will be removed when running autoremove" or something
<juliank> There was generally a question whether removals should be shown last
<juliank> currently they are shown at the top, but moving them right before the prompt and coloring them red would probably help a lot (and autoremove stuff yellow)
<juliank> For gnome-software and other app store-type applications, the problem with manual bit moving does not really arise, as they likely don't (and really should not) allow meta packages to be removed in the first place.
<juliank> Well, at least not enable explicit removals
<bdmurray> juliank: Better messaging and fixing https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776790 would be helpful too
<ubottu> Debian bug 776790 in apt "apt: Please document APT::Never-MarkAuto-Sections in apt.conf(5)" [Minor,Open]
<jbicha> juliank: you give gnome-software too much credit. Currently it does allow metapackages to be removed with no warning :(
<bdmurray> jbicha: is there a bug reported about that?
<jbicha> a workaround is to mark metapackage Depends with compulsory_for_desktop in the appstream metadata but we haven't really done that thoroughly yet
<juliank> jbicha: Probably should be hidden. They are really an "OS" thing
<jbicha> LP: #1546636 sort of mentions the issue
<ubottu> Launchpad bug 1546636 in gnome-software (Ubuntu) "Review "System Applications"" [Low,Triaged] https://launchpad.net/bugs/1546636
<jbicha> juliank: the Remove button is hidden for those compulsory apps. I disagree that we should hide the apps completely from Software
<jbicha> you can install addons for some apps, leave reviews, etc.
<jbicha> https://anonscm.debian.org/viewvc/pkg-gnome/desktop/unstable/epiphany-browser/debian/patches/dont-make-compulsory.patch?view=markup
<jbicha> ^ is an example (in reverse) of what that appstream tag looks like
<juliank> jbicha: I guess we should give gnome-software the ability to always move manual bits then
<jbicha> (gnome-software uses packagekit in Ubuntu as of 17.10)
<juliank> Well, yes, PackageKit might want to do that in general then, but we need an option for that in APT
<rbasak> niedbalski: thanks! Quick glance. 5.6.34-26.19-0ubuntu3 is already taken. Can you prepare a debdiff against the already uploaded 5.6.34-26.19-0ubuntu3 to 5.6.34-26.19-0ubuntu4? I expect that debdiff to include only the FTBFS fix, as I think the other necessary fixes are already present in 5.6.34-26.19-0ubuntu3?
<niedbalski> rbasak, ok, doing that.
<niedbalski> rbasak, ok, I don't think is going to be possible, I incorporated a small nitpick on the original patch (that prevents a warning), thus the ibuf* patch actually differs from ubuntu3.
<rbasak> niedbalski: if you want to update what you did in ubuntu3, that's fine. Just include it in ubuntu4 and bullet point that additional change separately in the changelog.
<niedbalski> rbasak, perfect.
<rbasak> niedbalski: but ubuntu4's changelog should include things that are already covered in ubuntu3's changelog. Does that make sense?
<rbasak> Sorry
<rbasak> niedbalski: but ubuntu4's changelog *shouldn't* include things that are already covered in ubuntu3's changelog. Does that make sense?
<niedbalski> rbasak, yes, it does.
<niedbalski> rbasak, ok, the new patch in top of current proposed is attached to the bug. thank you for looking.
<powersj> rbasak: the package to team mapping page shows source packages, correct? Is there a fast way (doing this in python) to say what team owns a binary? e.g. Look up lxd-client and know it is based on lxd  source and therefore the owner is ubuntu-server
<nacc> powersj: apt-cache show lxd-client | grep Source
<nacc> powersj: if it comes up with an answer that is the Srouce
<nacc> otherwise the binary package is the same as the source package
<powersj> nacc: thanks!
<nacc> powersj: there are probably better ways, but that should always work (maybe | grep ^Source: )
<powersj> yeah now I have to decide if there is a faster way to do that in python, rather than running that command O(10k) of times
<nacc> powersj: @lru_cache
<powersj> nacc: ah right! I've seen rbasak use that in the triage script
<powersj> thanks again!
<nacc> powersj: np, we use it pretty heavily in the importer code
<powersj> nacc: that will only find packages that are in the release I'm running right? e.g. php7.0 won't be found since I'm running artful
<nacc> powersj: rmadison can do it (with some help) or use chdist and bin2src
<nacc> powersj: (and of course apt-cache assumes your apt cache is up to date)
<powersj> right, was playing with python apt module to do all of that, then realized I'm missing a bunch of packages since I'm not on xenial
<nacc> ah sure
<nacc> so chdist could probably create the right layouts for you
<nacc> and maybe python-apt can be told to use different root dirs
<nacc> infinity: not urgent, but do you think it would be reasonable for `dpkg --print-format` to not error out when it finds invalid binary package stanzas in d/control?
<nacc> infinity: specifically a patch like http://paste.ubuntu.com/25676319/ which results in (IMO) improved behavior as: http://paste.ubuntu.com/25676320/
#ubuntu-devel 2017-10-05
<rbasak> powersj, nacc: grep-dctrl -S may be helpful. Give it stuff in /var/lib/apt/lists.
<rbasak> Actually that's backwards (affects input not output).
<rbasak> But still, grep-dctrl may be helpful here.
<nacc> rbasak: good point
<hyperair> kirkland: hey i noticed your github mirror of byobu. do you accept PRs to that, or would you prefer that i push to lp?
<Unit193> didrocks: Thanks for glib2.0, it should fix some nasty crap.
<didrocks> Unit193: heh, hoping so. running it happily for 24h at least :)
<Unit193> didrocks: Oh?  Did you get nasty mounts on the desktop?
<didrocks> Unit193: no, I didn't in my case. I think jdstrand had some, but I saw it's supposed to fix it in that new release
<Unit193> It's still regressed from zesty, but much better. (So says my Debian install, or the packages direct from Debian.)
<Unit193> Great, so now when I try to switch to a TTy, lightdm pops back up.  That in itself is bad, but trying to switch to a TTY to remove .xauthority and .iceauthority so I can actually login...
<ogra_> you can always add "text" to the kernel cmdline in grub (as a last resort)
<ogra_> that will boot to tty and block lighdm fom starting
<Unit193> No, it doesn't do that anymore (last I checked), you have to do the new easy to remember 'systemd.unit=multi-user.target'.  That's what I ended up with since I couldn't ssh in (NM not logging me on yet?), just hard when grub doesn't like the USB keyboard. :D
<Lowas> #ubuntu-artwork
<ogra_> Unit193, oh, i didnt know we improved our userfriendliness so much :P
 * ogra_ shakes head
<Unit193> Yeeeah...  I poked around with a few services to see if 'text' was pretty effortless to get back.  Would take someone that knows systemd better than I.
<Unit193> ogra_: In theory dumping '3' in might work too, easier to remember but not as nice as 'text' :P
<ogra_> heh, so the redhat initlevel stuff silently sneaked into debian via systemd
<ogra_> s/initlevel/runlevel/
<Unit193> Untested!
<doko> niedbalski, rbasak: is that the percona issue?
<niedbalski> doko, yes, I am awaiting for review on the latest patch from rbasak.
<jdstrand> didrocks, Unit193: this is my bug: https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1712100
<ubottu> Launchpad bug 1712100 in nautilus (Ubuntu) "some disk volumes showing up that should probably be filtered" [Low,New]
<Unit193> jdstrand: The linked bugs contained in that were the ones I found.  I had a nice list of "dev, pts, sys, proc", etc, etc.  sshfs mounts too.  It got nasty.
<jdstrand> icky
<rbasak> niedbalski: "+ # Turn on Werror (warning => error) when using maintainer mode."
<rbasak> niedbalski: is it possible that upstream have left that there exactly for us to what we need? Did you try turning off that mode to see if it fixes the build, and if so, is doing that suitable for us?
<rbasak> Though actually I see other instances of -Werror too that you've had to address.
<rbasak> So perhaps not.
<niedbalski> rbasak, yes, tried that, still I saw dependencies being compiled with the flags.
<rbasak> doko: do you have an opinion on how to handle this please? I suggested not making the new gcc-7 warnings into errors if they don't appear to reveal actual bugs. Does that seem OK to you?
<lag> Hola
<lag> When a package is built, are the logs stored/publicly available?
<lag> Similar to: https://kojipkgs.fedoraproject.org//packages/mesa/17.2.2/2.fc27/data/logs/aarch64/build.log
<Unit193> https://launchpad.net/ubuntu/+source/mesa â https://launchpad.net/ubuntu/+source/mesa/17.2.2-0ubuntu1/+build/13541743 â https://launchpad.net/ubuntu/+source/mesa/17.2.2-0ubuntu1/+build/13541743/+files/buildlog_ubuntu-artful-arm64.mesa_17.2.2-0ubuntu1_BUILDING.txt.gz
<lag> Unit193: Ideal, thanks
<Stravy> hi there, sorry to bother you if this message is not in the right channel. I posted a bug report concerning Artful but I'm not sure it's in the right place to be seen : https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1719612
<ubottu> Launchpad bug 1719612 in initramfs-tools (Ubuntu) "non-us keyboard layout not setup in initramfs" [Undecided,New]
<ddstreet> sil2100 my vlan sru has been in proposed for 2 wks, can you push it to updates?  cpaelzer uploaded it but i think he's out
<sil2100> ddstreet: sure, I'll get to it in a bit possibly
<ddstreet> thanks!
<sil2100> I'm slowly running through the pending page
<sil2100> ddstreet: hm, there seems to be a nova autopkgtest regression with the new vlan, doesn't look related but still worrying as this test is generally passing for others
<ddstreet> sil2100 i saw that, but the failure is 'nova-something isn't running'
<sil2100> ddstreet: but I did see some nova issues with this test recently for other SRUs as well, just different architectures
<ddstreet> don't see how that could be related, but i'll try running the autopkgtest for it locally without the -proposed vlan pkg
<sil2100> slashd: you mentioned that the nova autopkgtest issues are being investigated ^ ?
<ddstreet> sil2100 i also have an initramfs pkg in -proposed but only at 6 days, i added a comment to its bug noting that the linux-lts-* test failures are unrelated to the initramfs pkg update
<slashd> sil2100, yes but let me double-check with freyes one more time ^^
<slashd> sil2100, yes look the regression potential section "The failures are not related to this change, nova autopkgtest failure is being analyzed at https://bugs.launchpad.net/ubuntu/+source/nova/+bug/1713059
<slashd> "
<ubottu> Launchpad bug 1713059 in nova (Ubuntu Xenial) "drop db sync commands from OpenStack packages" [High,Fix committed]
<freyes> slashd, ddstreet, sil2100, a new nova package was uploaded (xenial) to fix the nova autopkgtest failure, probably still waiting to be approved
<sil2100> freyes: but do you know if the same could be the case on zesty?
<sil2100> freyes: since we're seeing nova test failures on zesty as well
<freyes> sil2100, let me take a look, for zesty there were no failures with my patch
<sil2100> slashd: ^
<slashd> sil2100, freyes there is a magnum (s390x) failure IIRC on zesty
<sil2100> For vlan I also see a failure like that for nova
<sil2100> e.g. the nova autopkgtest failing
<slashd> sil2100, magnum one seem to always fail : http://autopkgtest.ubuntu.com/packages/m/magnum/zesty/s390x
<sil2100> I'm trying to figure out if this is related to the issue freyes was mentioning: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty/zesty/s390x/n/nova/20170921_203340_e5492@/log.gz
<slashd> sil2100, ok freyes ^
<freyes> sil2100, is /var/log/ from the testbed published somewhere?
<powersj> rbasak: nacc is it possible to create a precise chdist now given that it appears the precise Release file is not signed?
<powersj> https://paste.ubuntu.com/25680735/
<nacc> powersj: i think you can set allow_insecure (see man apt-secure) for just the precise chdist
<nacc> powersj: each chdist has it's own etc/apt/apt.conf.d
<cjwatson> it's signed, you just need an older ubuntu-keyring I think
<powersj> ok for now I added "[trusted=yes]" to the apt sources.list lines
<powersj> thanks
<Unit193> sarnold: Unfortunatly I remembered.
<sarnold> Unit193: ha! :D what's up?
<Unit193> sarnold: Since Ubuntu doesn't have codesearch, do you happen to know of anything else other than (presumably) Ubuntu's geoclue and ubiquity that use http://geoip.ubuntu.com/lookup?
<sarnold> Unit193: aha! :) sad to say my own archive mirror of unpacked sources is now woefully out of date since I never automated the unpacking step :( One Of These Days [tm]
<sarnold> Unit193: jamie's got some scripts that can do the search "eventually".. it's not real quick, kind of manual..
<sarnold> jdstrand: no real rush, is there any chance you could search for users of http://geoip.ubuntu.com/lookup? re 1617535 maybe it'd be nice to be rid of the package entirely?
<Unit193> sarnold: Oh fancy!  Didn't know you had such a thing.  I'm not entirely sure it's worth grepping the entire repo for, though. :3
<Unit193> sarnold: If the goal is to remove that, searching for other terms might be more useful as that isn't likely used.  I know of some external tool that uses the geoip service but not geoclue.
<sarnold> ohhh
<Unit193> ...On a related but different note.
#ubuntu-devel 2017-10-06
<Tonio_> hi there !
<Tonio_> my @ubuntu.com email address doesn't forward to my gmail account since yesterday 23h59....
<Tonio_> who may I contact to get that fixed please ?
<Tonio_> I checked the canonicam smtp server and it seems to accept the email but nothing coming afterwards...
<Tonio_> also, am I on the good channel to ask for this ?
<dasjoe> No, wrong channel. This one is for Ubuntu development, currently focused on the soon to be released 17.10
<dasjoe> Please email rt@ubuntu.com with a link to your Launchpad profile and the details of your problem.
<Tonio_> thx dasjoe :)
<xnox> Laney, nplan tests started to fail on s390x but it seems like "reboots" of the lxc container... don't really reboot? i've touched files in /run and i can see them after every reboot mark
<xnox> and i expect a fresh /run between each reboot
<Laney> why would that have started now?
<xnox> not sure yet
<xnox> but i see it on s390x/lxc only at the moment
<xnox> http://autopkgtest.ubuntu.com/packages/nplan/xenial/s390x
<xnox> http://autopkgtest.ubuntu.com/packages/nplan/artful/s390x
<xnox> Laney, is there a better way for me to debug what autopkgtest-virt-lxc is doing? as manual lxc containers do reboot with fresh /run for me
<Laney> xnox: pass autopkgtest --debug and ... -- lxc --debug ...
<Laney> got to have lunch now, see you in a bit
<xnox> Laney, so with debug logs it seems like lxc-wait was timing out... and the container did not actually stop to complete the shutdown part when rebooting
<xnox> i've made lxc-wait to be run without a timeout, and increased the wrappers timeout to be longer
<xnox> imho it looks wrong that lxc-wait timeout is less than the overall command timeout is.
<xnox> as the test suite goes to pretend that everything is awesome, when it did not reboot
<xnox> and it looks like reboot command was not delievered.... cause i can do lxc-attach out of band and doing sudo reboot makes the test go further
<xnox> Laney, i am suspecting we either need to switch s390x to lxd provider and use the pre-published lxd base images, or we need to cherrypick these lxc commits and regenerated artful lxc autopkgtest runner http://launchpadlibrarian.net/336056950/lxc_2.0.8-0ubuntu7_2.0.8-0ubuntu7.1.diff.gz
<Laney> xnox: can you SRU them or at least provide a PPA for xenial?
<Laney> I'm not going to work on lxd or anything like that for s390x, since we'll be using bos02 soon
<Laney> thanks for finding the problem
<xnox> Laney, do you have RT# of what is blocking you from using bos02?
<Laney> no
<Laney> but you don't have to worry about that
<xnox> Laney, trello card? i thought you had RT#
<Laney> no
<Laney> maybe William does, but I don't
<xnox> Laney, well i'm blocked landing systemd in artful now due to nplan/s390x "regression"
<Laney> ok, and you found the fixes, so if you provide me with an lxc then I can upgrade to that and then we'll be happy again
<xnox> Laney, can you please skiptest nplan/s390x? i guess i can create a qemu vm locally, and test nplan in the adt qemu vm on s390x locally first.
<xnox> ok
<xnox> hmmmm https://launchpad.net/~ubuntu-lxc/+archive/ubuntu/lxc-stable
<seb128> slangasek, hey, is foundations reviewing their rls-aa-incoming bugs still? some like bug #1717009 didn't see much activity
<ubottu> bug 1717009 in fwupd (Ubuntu) "fwupd breaking access to certain usb devices" [High,New] https://launchpad.net/bugs/1717009
<Laney> xnox: did you get an s390x build of that?
<Laney> I mean... I guess I could hack the template...
<xnox> Laney, well, it's not that simple.
<xnox> Laney, as autopkgtest-build-lxc fails with netplan only instances.
<Laney> because why?
<xnox> Laney, so it seems we either need bos02 autopkgtest going or switch to lxd or fix more things.
<xnox> Laney, because it fiddles with /etc/network/interfaces; does not expect networkd config to be in runtime dirs; and expects chroot alone to work to get working networking, when it also needs to enter the pid and mount space and ipc namespace because resolved is now a stub resolver
<xnox> or like setup resolv.conf from the host
<xnox> so new lxc template help to get autopkgtest-build-lxc going further, but not to successful completion
<xnox> this is reproducible on any arch
<xnox> but s390x is the only one using lxc backend =/
<Laney> guess we should just get this in
<smoser> bdmurray, around ?
<bdmurray> smoser: I have an appointment shortly what's up?
<smoser> hey.
<smoser> wanted to know what you need from us for cloud-init sru exception
<bdmurray> smoser: Ah, I'll have a look again when I get back then.
<smoser> ok. thanks.
<lamont> -loadkeys '/etc/console-setup/cached_UTF-8_del.kmap.gz' > '/dev/null'
<lamont> +loadkeys '/tmp/tmpkbd.vNPuVc' > '/dev/null'
<lamont> wtf?  /etc/console-setup/cached_setup_keyboard.sh seems "not right" after the upgrade just now
<mdeslaur> cyphermox: any ideas on that console-setup thing? ^
<iratemin> Looking for some assistance on a wifi problem.  Upgraded 17.04 - 17.10 last night.  Wifi connects but continues to show a ? instead of strength.  Unable to resolve any address.  Can ping 8.8.8.8.  Tried forcing DNS to 8.8.8.8,8.8.4.4. but didnt fix it.
<iratemin> NetworkManager.conf already had wifi.scan-rand-mac-address=no set as others had found a few months ago.
<nacc> iratemin: #ubuntu+1 for support
<iratemin> ok, thank you  sorry if this was the wrong spot.
<slangasek> seb128: we did discuss 1717009 in yesterday's meeting, we declined to target it for 17.10 at the time because we think we already have a full plate between now and release; this seems like something fixable in SRU once an upstream fix is available?
<seb128> slangasek, sounds fine, the bug tag should be tagged to rls-aa-notfixing then right? would be nice also to add a comment stating the decision so others know what's going on :-)
<bdmurray> smoser: Looking at https://wiki.ubuntu.com/CloudinitUpdates again all the "TODOs" in the Automated and Manual Test Results need to be done for the tag to get change to v-done correct?
<cyphermox> mdeslaur: nope. looks wrong.
<smoser> bdmurray, yes. so we open a master bug, put that template in, and then for each master bug we would need to attach that stuff.
<smoser> is that what you were asking ?
<smoser> previously i was asking if you thought this was "Ready to Use"
<bdmurray> smoser: And *all* bits are required for it to be verified?
<smoser> yes that'd be the intent.
<bdmurray> smoser: Then, yes its about ready to use - just some formatting changes to the page that I could make.
<smoser> (but until we replace 'manual' with 'automated', the collected results will be human done)
<smoser> bdmurray, sure. thanks!
<bdmurray> smoser: Should I remove the draft header too?
<smoser> please.
<smoser> bdmurray, i have another question... with your general SRU team member hat on
<smoser> cloud-init upstream dropped a dependency on python3-prettytable.
<smoser> we dropped that dependency in the artful packaging
<smoser> should we drop it in the xenial and zesty packaging ?
<smoser> or just leave it as legacy
<bdmurray> If its not used might as well drop it for new installs.
<smoser> ok. thanks.
<smoser> blackboxsw, ^ i can make that packaging change quick in ubuntu packaging.
<smoser> blackboxsw, ok. i did that. you might want to re-fetch upstream.
<smoser> s/might/will/
<blackboxsw> refetching
<blackboxsw> thx
<NMCUNIX> Hi Guys
<NMCUNIX> I'm on Kubuntu 17.10 beta 2 - Can I also install the new Gnome Ubuntu desktop by simply doing : sudo apt install ubuntu-session   ?
<jbicha> bdmurray: silly question, but do xdiagnose and xterm need to be demoted to universe before they are added to utils/demoted.cfg in ubuntu-release-upgrader?
<bdmurray> jbicha: demoted.cfg is created automatically so yes
<jbicha> ok, maybe we'll get that done next week
#ubuntu-devel 2017-10-07
<hwpplayer1> please join #ubuntu-science for scientific programming and science discussion
<hwpplayer1> I want to make an IRC Meeting on #ubuntu-science at UTC+3 19:00 Istanbul who wants to join are welcome
<infinity0> what's the process for getting debian packages in ubuntu? i'm just wondering why sagemath 8.0 is not in artful yet
<infinity0> it depends on rpy2-2.8 which is a recently-new package because the "rpy2" package dropped support for python2 after 2.8
<Unit193> infinity0: https://ubottu.com/y/aa way past "Debian import freeze/feature freeze", well into final freeze.
<infinity0> ah ok so it'll probably be in the next one
<tsimonq2> yep
<cjwatson> well, also somebody tried to get it into artful but so far it fails to build
<cjwatson> https://launchpad.net/ubuntu/+source/sagemath/8.0-8ubuntu2
<infinity0> ah right, + python-sphinx (>= 1.5.6), -- that requires you to drop a patch from debian/patches/ that backports an upstream commit adding sphinx 1.6 support
<cjwatson> the build failure seems to be related to cython, not a lot to do with sphinx?
<cjwatson> (but I haven't looked very closely)
<infinity0> right, looks like the cython build-dep was also lowered to 0.25, it needs 0.26
<rbasak> LocutusOfBorg: ^
<acheronuk> doko: Preparing to unpack .../kodi-repository-kodi_2%3a17.3+dfsg1-3_all.deb ...
<acheronuk> Unpacking kodi-repository-kodi (2:17.3+dfsg1-3) ...
<acheronuk> dpkg: error processing archive /var/cache/apt/archives/kodi-repository-kodi_2%3a17.3+dfsg1-3_all.deb (--unpack):
<acheronuk>  trying to overwrite '/usr/share/kodi/addons/repository.xbmc.org/addon.xml', which is also in package kodi-data 2:17.3+dfsg1-3
#ubuntu-devel 2017-10-08
<Unit193> acheronuk: https://bugs.debian.org/877960
<ubottu> Debian bug 877960 in kodi-data,kodi-repository-kodi "kodi-data,kodi-repository-kodi: both ship usr/share/kodi/addons/repository.xbmc.org/{addon.xml,icon.png}" [Serious,Open]
<ivaat> hi
<ivaat> installing my own 3.14.5 from source breaks with missing aes-x86_64.ko http://paste.ubuntu.com/25698069/
<ivaat> ido have libssl installed as well
<ivaat> what could i be missing
<arunkumar413_> is this the official ubuntu development channel/
<KristoferV> Hi, I have a Mx Master and I failed to follow the guide from Arch wiki. Probably, because I have no idea how to configure xbindkeys. Is anyone willing to help me? Got an answer on #ubuntu to come here.
<ivaat> hi KristoferV
<KristoferV> hi..
<ikonia> KristoferV: how is this a development problem ?
<ikonia> no-one told you to come here for support that I saw ?
<ikonia> #ubuntu is the correct place for ubuntu support #archlinux is the correct linux for problems with the archlinux documentation
<KristoferV> i am on ubuntu..
<KristoferV> I can head there then and annoy those people then?
<ikonia> right so #ubuntu is the place for ubuntu upport, #archlinux is where you should be if you're having problems with the archlinux documentation
<KristoferV> gonna go there then
<arunkumar413_> is UUID present in all computers bios chip
<jbicha> cjwatson: can you look into why desktop-common hasn't been updated at https://people.canonical.com/~ubuntu-archive/seeds/platform.artful/
<jbicha> I pushed the update to bzr on Friday
<hwpplayer1>  jbicha: what's wrong with that ?
<jbicha> hwpplayer1: it's out of date and it looks like it's used by the kubuntu-meta update script which I need to run
<hwpplayer1> jbicha : Does it have a source code
<jbicha> it's supposed to be a http mirror of https://code.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/platform.artful
<hwpplayer1> jbicha : i see
#ubuntu-devel 2018-10-01
<smoser> Pretty sure this is not just me
<smoser>  https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/1795410
<ubottu> Launchpad bug 1795410 in ubuntu-meta (Ubuntu) "cannot bring up window menu via keybinding (alt-space or otherwise)" [Undecided,New]
<smoser> anyone more desktop familiar able to triage that ?  I didn't know what package to put it on.
<didrocks> smoser: I just put it on mutter. It's either mutter/G-Sâ¦
<smoser> i have no mutter process running
<Laney> it's a library
<smoser> just upgraded then rebooted then logged in. but it had probably been 3 weeks since reboot.
<smoser> see, ignorance of destkop <--
<smoser> thanks
<smoser> didrocks: any suggestion on how to get the window menu to come up? i'm really used to having the browser window on all visiable workspaces
<smoser> well, configured some shortcut to it and that seems to work.
<jbicha> smoser: that should have been the default
<smoser> it is the default.
<smoser> but it doesnt do anything
<smoser> does it work for you jbicha ?
<didrocks> smoser: it doesn't work for me, but Trevinho is the one following most of the upstream on those 2 componentsn
<jbicha> yes
<ddstreet> smoser are you able to verify lp #1755858?
<ubottu> Launchpad bug 1755858 in open-iscsi (Ubuntu Xenial) "iscsid autostarts on all servers when it has nothing to do" [Undecided,New] https://launchpad.net/bugs/1755858
<bdmurray> seb128: Do you still want emails from the Launchpad retracers which run on porter-i386?
<seb128> bdmurray, I guess not, I was not even aware that those were still a thing, I didn't receive any for years. In fact I haven't been looking at the retracer for years, since you picked that up :)
<seb128> thanks for asking though
<bdmurray> seb128: no problem, I'll update the crontab
<seb128> thx
<seb128> on what machine is that again?
<seb128> I forgot all the details about those: p
<bdmurray> osageorange / porter-i386
<seb128> thx
<blaze> can someone shed a light for me about what happened to the networking since CC?
<smoser> infinity or sil2100 could one of you look at the cloud-initramfs-tools uploads for bionic and xenial for bug https://bugs.launchpad.net/maas/+bug/1792905
<ubottu> Launchpad bug 1792905 in cloud-initramfs-tools (Ubuntu Bionic) "[2.5] iSCSI systemd services fails and blocks for 1 min 30 seconds" [High,In progress]
<smoser> infinity: the change suggested was iiuc yours to begin with, so i'm guessing you agree with it.
<infinity> smoser: I often disagree with myself!
 * infinity looks.
<nacc> heh
<infinity> smoser: Oh, that change.  Yeah, happy to take that.
<infinity> smoser: b and x, you say?
<smoser> yes. it is in c.
<infinity> smoser: Accepted * 2
<infinity> smoser: I'd suggest the testcase for this package specifically should just be "dpkg -S /lib/modules" and make sure it's in the list of owners.
<smoser> infinity: i was just typing a SRU template for the cloud-initramfs-tools upload.
<smoser> i will put that in as the test case. thank youl
<infinity> smoser: Since testing the actual bug is a bit more convoluted and may be fixed belt-and-bracers via including the dir in images, etc.
<sarnold> bdmurray: hello :) is there a reason for 1794136 1795128 1757013 1795395 to be private? they look related to 1794292 (public) and I don't see a coredump on any of them
<bdmurray> sarnold: even though the coredump is gone the stacktrace should be inspected for anything private
<sarnold> bdmurray: hm, is this new? or do I just now have more privileges to see things than I used to? :)
<bdmurray> sarnold: No not new. I don't know did you level up recently? ;-)
<sarnold> bdmurray: I *am* surprised to see "private" bugs
<bdmurray> sarnold: I don't see anything new in your LP account
<sarnold> bdmurray: heh, then perhaps I'm just not very observant. :) I just know I've lost access to bugs before when people fiddle with the switch, so I assumed that was still the case
<aidanh010> What kind of bug do I need to file to indicate that something fixed in cosmic needs to be backported to bionic? The package has two open bugs one by me and one by someone else, both of which have technically been fixed but need to be backported
<nacc> aidanh010: link to bug?
<nacc> aidanh010: you need to open (or request) a task for the appropriate release
<aidanh010> both of these: https://bugs.launchpad.net/ubuntu/+source/golang-github-docker-docker-credential-helpers
<nacc> !sru | aidanh010
<ubottu> aidanh010: Stable Release Update information is at https://wiki.ubuntu.com/StableReleaseUpdates
<nacc> aidanh010: they are fixed in 18.10?
<aidanh010> yeah I just upgraded test server and confirmed it
<nacc> aidanh010: ok, i've indicated they need to be fixed in 18.04, via tasks, please update them with your testing info
<aidanh010> ok thanks nacc
<sarnold> bdmurray: hah, there's still some python2 -> python3 bugs around here.. 1795274
<sarnold> bdmurray: https://launchpadlibrarian.net/391075166/HookError_ubuntu.txt
#ubuntu-devel 2018-10-02
<andrewsh> jbicha: you upload 1.11-2ubuntu1 of redshift somehow removes the ubuntu-mono-light/dark icons
<andrewsh> your*
<andrewsh> and that's despite the changelog entry saying it still has --enable-unity enabled
<andrewsh> hmmm, the diff shows s,--enable-ubuntu,--enable-unity,; is that right?
<Unit193> -	dh_auto_configure -- --enable-randr --enable-vidmode --enable-geoclue2 --disable-geoclue --with-systemduserunitdir=/usr/lib/systemd/user/ --enable-ubuntu
<Unit193> +	dh_auto_configure -- --enable-randr --enable-vidmode --enable-geoclue2 --disable-geoclue --with-systemduserunitdir=/usr/lib/systemd/user/ --enable-unity
<Unit193>  Yep.
<andrewsh> that doesnât seem correct to me
<andrewsh> since --enable-ubuntu did install the icons, and --enable-unity doesn't (does that work at all?)
<Unit193> You'll also note the changelog disappeared.
<andrewsh> AC_ARG_ENABLE([ubuntu], [AC_HELP_STRING([--enable-ubuntu],
<Unit193> configure: WARNING: unrecognized options: --disable-maintainer-mode, --enable-unity
<andrewsh> actually, I think ritesh could just enable it in Debian
<cyphermox> MIR team ping; doko, didrocks, jdstrand: do we meet this week?
<didrocks> cyphermox: nothing to say apart from "done Vulkan MIR, still work needed"
<cyphermox> yeah, I'm not done with mine.
 * jdstrand is here and has nothing to report
<cyphermox> there are two bugs open, but I'll take ledmon (I have prior context on it)
<cyphermox> let's skip then
<didrocks> k
<jdstrand> +1
<jdstrand> I was actually wondering if every other week might make more sense
<jdstrand> but meeting and adjourning quickly is fine too
<seb128> LocutusOfBorg, hey! Do you know if something changed in cosmic for virtualbox/the vboxvideo driver that could explain https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1792932 (live CD failing to boot to a working session under virtualbox)
<ubottu> Launchpad bug 1792932 in xorg-server (Ubuntu Cosmic) "Cosmic Desktop fails to boot in vbox: Xorg assert failure: Xorg: ../../../../dix/privates.c:384: dixRegisterPrivateKey: Assertion `!global_keys[type].created' failed." [High,Triaged]
<seb128> tjaalton, ^ moving the discussion here
<tjaalton> k
<seb128> vorlon, do you know who could help tjaalton to figure out if something change on the initramfs side in cosmic that would impact the vboxvideo driver? that's the bug just mentioned before which is a blocker for cosmic but we are failing at getting traction/understanding of the issue, seems the vboxdriver is taking too long to init and tjaalton thinks that might be because it's missing from the installed initrd
<tjaalton> having it there might help, but it's never been on the installer initrd afaik
<seb128> ah
<seb128> I probably misunderstood, I though you said that was changed/explained it was taking to long to init
<xnox> blame kernel? =)
<seb128> tjaalton, so was the driver init faster in bionic? or boot slower? or did we just get lucky?
<tjaalton> something changed that makes it racy now
<seb128> I'm a bit unsure what changed/what you think is creating the issue now
<tjaalton> I'll test on another machine with I can use to test this..
<seb128> k, thx
<seb128> let me know if we can help with something
<LocutusOfBorg> apw, are you using vboxvideo inside the kernel?
<tjaalton> the window of failure is only a few seconds, and something either made X quicker to start or vboxvideo slower to init, or both
<LocutusOfBorg> ^^ which version? did you sync it to 5.2.18?
<LocutusOfBorg> tjaalton, now vboxvideo is a kernel module, not sure how it can take seconds to boot
<xnox> isn't this a general gdm fails to init on boot, sometimes?
<LocutusOfBorg> but... installing virtualbox-guest-x11 makes it work?
<xnox> or like you mean you don't get plymouth either?
<tjaalton> LocutusOfBorg: takes > 25s
<LocutusOfBorg> because I do something more on that package, wrt a normal kernel module
<tjaalton> LocutusOfBorg: after first reboot it works, because the kernel module is already loaded before X starts
<LocutusOfBorg> no real idea... seems not really vbox related?
<tjaalton> I'll compare bionic/debian/cosmic..
<LocutusOfBorg> sforshee, https://irclogs.ubuntu.com/latest/%23ubuntu-devel.html
<LocutusOfBorg> it will update with some new messages
<LocutusOfBorg> tjaalton, the kernel vboxvideo is now mainline, so they aren't using the vbox provided anymore
<LocutusOfBorg> is it possible to have a spin with the vbox provided one, or a custom kernel so we know if this is the cause?
<tjaalton> LocutusOfBorg: it's in staging
<LocutusOfBorg> tjaalton, exactly
<LocutusOfBorg> so this is the upstream one
<LocutusOfBorg> tjaalton, as said, install virtualbox-guest-dkms and reboot
<LocutusOfBorg> and tell me which one is used, and if it works
<tjaalton> it's fine after the system is installed
<tjaalton> only the installer instance is broken
<LocutusOfBorg> so, seed vbox-guest-dkms or a custom kernel that sforshee can provide you? is it possible?
<sforshee> will using the driver from virtualbox-guest-dkms even make a difference? Seems like this is a problem of when the device is ready
<tjaalton> yeah I don't think it would
<tjaalton> looks like bionic image on vbox just hangs if I click "show apps"
<tjaalton> so it's not exactly bug free there either :)
<tjaalton> and second/third attempt shows just a corrupt screen afte X has loaded
<coreycb> RAOF: hi, can you reject keystone from the xenial unapproved queue? I need to learn how to use dput.
<smoser> what is the right tag for verification on bionic for
<smoser>  https://bugs.launchpad.net/ubuntu/xenial/+source/cloud-initramfs-tools/+bug/1792905
<ubottu> Launchpad bug 1792905 in cloud-images "[2.5] iSCSI systemd services fails and blocks for 1 min 30 seconds" [Critical,Triaged]
<smoser> right now
<smoser> basically, 2 independently functioning fixes are in -proposed for bionic.
<smoser> i've verified one of them.
<smoser> i do not want to hold up this SRU at all as we really need an image built with *either* of the fixes.
<tjaalton> LocutusOfBorg, sforshee: debian testing (4.18) has vboxvideo loaded in 5-6s, compared to 25-30s in cosmic. it's not in initrd there either
<sforshee> hmm
<tjaalton> this is the live image
<tjaalton> on both
<sforshee> it's not like there are any driver-specific options that might be different, it's just enabled or disabled
<sforshee> tjaalton: can you provide a dmesg from both? Maybe there will be some clues there
<tjaalton> sforshee: yeah I'll try..
<tjaalton> sforshee: oh, there's an error about module verification, could that be it?
<tjaalton> anyway, I'll dump these somewhere..
<tjaalton> sforshee: https://aaltoset.kapsi.fi/vbox-slow/
<tjaalton> well, on bionic it's still slow but xserver doesn't fail the same way
<sforshee> tjaalton: there's certainly something weird, a couple of big delays that account for most of the difference but nothing in dmesg tells me why
<sforshee> the delay from systemd starting to the vboxvideo module loading looks to be about 7s
<sforshee> still awfully long
<tjaalton> right, well the root bug is something changed in xserver 1.20 compared to 1.19 which makes it fail now if vesa is loaded first
<tjaalton> sforshee, seb128, LocutusOfBorg: we just need https://gitlab.freedesktop.org/xorg/xserver/commit/0a9415cf793babed1f28c61f8047d51de04f1528
<tjaalton> the diff to bionic log was that glamor init succeeds now, when it shouldn't
<seb128> tjaalton, good work figuring that issue out!
<tjaalton> the commit says the feature was enabled in mesa 17.3 but in fact it was in 18.1 which was why I didn't think of that earlier..
<seb128> no worry, glad that you figured it out before cosmic is out :)
<tjaalton> well, the author helped..
<tjaalton> as I first thought it was a regression in xserver
<coreycb> bdmurray: i'm going to add some patches to the bionic neutron upload if you haven't gotten to that one yet
<coreycb> bdmurray: feel free to reject that
<bdmurray> coreycb: Oh, could you update the regression potential in bug 1790598 then?
<ubottu> bug 1790598 in neutron (Ubuntu Bionic) "metadata service calls to nova-api-metadata with IP based SAN's fails" [High,Triaged] https://launchpad.net/bugs/1790598
<coreycb> bdmurray: the other patches that I'm adding are for a different issue. Still want me to update 179058?
<bdmurray> coreycb: Well, Regression Potential of minimal isn't great.
<coreycb> bdmurray: well i can't argue with that. we'll get it updated.
<bdmurray> coreycb: thanks
<mwhudson> do the git-ubuntu imports contain enough info to reconstruct the dsc?
<nacc> mwhudson: for an existing publish?
<mwhudson> yes
<nacc> mwhudson: every DSC is stored in a special branch
<mwhudson> ah cool
<nacc> mwhudson: which srcpkg?
<mwhudson> nacc: uhh i think it was dh-golang this time
<nacc> i can try and find the right ref for you
<mwhudson> basically i run debdiff and it says "can't find dsc"
<nacc> yeah
<mwhudson> hmm i guess i also need the tarball for that to do anything useful
<nacc> https://git.launchpad.net/ubuntu/+source/dh-golang/log/?h=importer/ubuntu/dsc
<nacc> we have a git-ubuntu export-orig
<mwhudson> nice
<nacc> to get the orig tarball out of the pristine-tar (or downlaod it from LP if we don't have it in pristine-tar)
<nacc> in *theory*, if you have a full repo cloned, you can get the equivalent srcpkg locally; that was the hope, at least :)
<nacc> the above is the DSC files in ubuntu, there is a corresponding importer/debian/dsc branch for those
<nacc> it's not an ABI yet (that is, those branches may change content, etc.), but in the current implementation that's what the importer does
<mwhudson> i'm glad someone is thinking about these things :)
<nacc> tbf it's mostly rbasak at this point. I just have memories :)
<RAOF> coreycb: Keystone rejected from xenial. Enjoy your dput!
#ubuntu-devel 2018-10-03
<alkisg> Hi all, my package epoptes got a major update due to GSoC, and today has migrated to debian testing. Would it be possible to request a sync even so late in the release cycle? We (upstream) don't support the old epoptes release anymore...
<alkisg> It's been tested in hundreds of schools in September, so I don't expect any regressions
<RAOF> alkisg: You're after a Feature Freeze Exception
<RAOF> !ffe | alkisg
<ubottu> alkisg: Feature Freeze Exception. See https://wiki.ubuntu.com/FreezeExceptionProcess for the freeze exception process.
<alkisg> RAOF: thank you, that "FeatureFreeze for new upstream versions" seems like a lot of work, are all those necessary? The new version involved a python2/gtk2 to python3/gtk3 rewrite, so I'm not sure what a diff woulc reveal about it
<alkisg> Anyways let me try it and see... thank you
<tjaalton> isn't ffe mostly for seeded packages?
<RAOF> Not unless we've changed that recently?
<RAOF> Seeded packages get extra scrutiny (and have a harder freeze during image building), but AFAIK an FFe is still expected, even for something in universe.
<RAOF> alkisg: The diff is not meant to be of the code, but of the changelog - ie: âPlease describe what's new, and why we should have itâ
<RAOF> alkisg: âMigrated from python2 â python3 and gtk2 â gtk3â should be a pretty compelling reason :)
<alkisg> https://bugs.launchpad.net/ubuntu/+bug/1795797
<ubottu> Launchpad bug 1795797 in Ubuntu "FFe: sync epoptes 1.0.1-1 (universe) from Debian unstable (main)" [Undecided,New]
<willcooke> LocutusOfBorg, hi!  Do you know if Debian has any plans to upgrade modem manager in sid to 1.8?
<Laney> willcooke: cyphermox is the mainatiner of that
<willcooke> Laney, ah, thx.  In which case, cyphermox - Do you know when/if Debian will update m-m?
<cyphermox> I'm updating modemmanager
<cyphermox> I don't know about NM
<rbasak> sil2100_: around? May I have a second SRU opinion on bug 1782031 please? Seems to me there may be a functional (surprising) change to users there if unknown/notchecked ends up going to fail.
<ubottu> bug 1782031 in openscap (Ubuntu Xenial) "[SRU][xenial] Enable SCE option and systemd probe in libopenscap8" [Undecided,In progress] https://launchpad.net/bugs/1782031
<sil2100> rbasak: hey! I'm preparing lunch now but I'll look at it afterwards (and after one small meeting)
<ahasenack> infinity: hi, you said squid-4 is crashing for you regularly? wrt #1794553
<alkisg> Hi, regarding https://bugs.launchpad.net/ubuntu/+bug/1795797, I got an ACK from ubuntu-release and then I ran `syncpackage epoptes -d unstable`.
<alkisg> I think I have enough permissions there to upload myself, so I don't need a sponsor, right? So I should just close the bug now?
<ubottu> Launchpad bug 1795797 in Ubuntu "FFe: sync epoptes 1.0.1-1 (universe) from Debian unstable (main)" [Low,Triaged]
<rbasak> alkisg: looks like it has entered proposed: https://launchpad.net/ubuntu/+source/epoptes
<alkisg> rbasak: what's the process after that? Do I need to test it and give an "OK" somewhere? Do I need to wait for some approval? Or it's ok and I should just close the bug?
<rbasak> alkisg: usually bugs only get marked Fix Released when they land in the release pocket. Migration will take an hour or two unless it gets stuck for some reason. But for sync bugs, it's more fuzzy. syncpackage has a -b option that'll mark Fix Released that predates proposed migration. I doubt people running it today wait for that to finish before closing the bug through the script.
<rbasak> alkisg: it should appear in http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html if it gets held up for some reason. Otherwise it should land in the release pocket in an hour or two
<rbasak> (actually it appears in there briefly regardless)
<alkisg> Thank you, so I'll just wait until it appears in the release pocket and I'll close the bug then
<rbasak> That'll be fine. Thank you for looking after this in Ubuntu for us!
<alkisg> Thank you for this great OS too. :)
<rbasak> mdeslaur, jbicha: looking at brotli in xenial unapproved. Does the Xenial backport need to be rebased on 1.0.3-1ubuntu1.2 that's in the security pocket? It's not obvious to me why a no change rebuild was needed for security, so I'm wondering if any consideration of that reason is needed for the Xenial backport.
<jbicha> just a guess but I'm thinking the packages in bionic release are frozen and we need a new package version to promote it to main ??
<rbasak> Why the security pocket?
<mdeslaur> rbasak: because it was needed for a webkit2gtk security update and we don't build with -updates enabled
<rbasak> mdeslaur: I don't follow. Why would a no change rebuild be needed in that direction?
<rbasak> Unless I misunderstand the depndency direction?
<mdeslaur> to promote it to main, and be properly handled by ubuntu-support-status, we need a no-change rebuild
<rbasak> Oh
<rbasak> Right
<mdeslaur> the no-change rebuild needs to happen in -security
<rbasak> Ah, so that the webkit2gtk build can find it?
<mdeslaur> yeah
<rbasak> No implications for a Xenial SRU then. Thanks!
<mdeslaur> hrm, I also needed an armhf fix in bionic
<mdeslaur> or it FTBFS
<mdeslaur> does the xenial sru one build on armhf?
<rbasak> jbicha: ^ that's a question for you I think
<jbicha> I didn't test on armhf :)
<jbicha> rbasak: I think I'll need an AA to handle this SRU anyway
<rbasak> It's in xenial unapproved atm
<jbicha> currently I believe we're not sure whether we're going to be able to do further security uploads for webkit2gtk in xenial since the new version wants gcc-6
<jbicha> so once brotli & woff2 are in place, I was going to do an SRU to re-enable woff2 support there
<rbasak> OK, so you still want to land this brotli SRU?
<rbasak> Could you test the armhf build please, eg. in a PPA? Would save going round the queue twice.
<jbicha> I am testing the armhf build now
<rbasak> Thanks
<rbasak> juliank: in bug 1795614, please could you describe the actual impact to users of the bug? Right now all I see is a technical description of the problem, but I can't infer from that how users are actually affected.
<ubottu> bug 1795614 in packagekit (Ubuntu Bionic) "packagekit frontend locking" [Undecided,Triaged] https://launchpad.net/bugs/1795614
<rbasak> mwhudson: bug 1785026, Regression Potential "Nothing." isn't acceptable. Please see the docs and update.
<ubottu> bug 1785026 in skiboot (Ubuntu Bionic) "[LTCTest][OPAL][OP920] OPAL PRD generated logs is not available in /var/log/opal-prd.log file" [Undecided,In progress] https://launchpad.net/bugs/1785026
<rbasak> mwhudson: same with bug 1794936 please. " It is assumed that any SRU candidate patch is well-tested before upload and has a low overall risk of regression, but it's important to make the effort to think about what could happen in the event of a regression." -- so "unlikely" is also pointless.
<ubottu> bug 1794936 in dh-golang (Ubuntu Bionic) "new gccgo version update (4:8.2.0-1ubuntu2.1) is triggering dh-golang <1.35 bug" [Undecided,In progress] https://launchpad.net/bugs/1794936
<rbasak> mwhudson: think of it as informing anyone performing SRU verification on where to look.
<rbasak> tjaalton: shouldn't bug 1794690 go in via the security pocket?
<ubottu> bug 1794690 in libxkbcommon (Ubuntu Bionic) "Backport 0.8.2 for a CVE update" [Undecided,In progress] https://launchpad.net/bugs/1794690
<daniel-mcr> Hi all, apologies if this is not the right place to ask this. I'm using Debian 9 with Gnome 3, Software and Updates, Updates tab, drop down When there are other updates is blank, is this intentional?
<tjaalton> rbasak: maybe?
<daniel-mcr> If it is not the right place, please advise which channel etc. Thanks
<rbasak> tjaalton: could you liase with the security team please? If it's going to security, then it's a different process than an SRU upload
<tjaalton> ok
<juliank> rbasak: I added something about race conditions and broken install operations to that
<rbasak> daniel-mcr: if you're not using Ubuntu, then Ubuntu channels are the wrong place. Try #debian on OFTC for user support for Debian users.
<daniel-mcr> rbasak: cheers, appreciated.
<daniel-mcr> rbasak: Sorry OFTC?
<cjwatson> https://wiki.debian.org/IRC
<daniel-mcr> cjwatson: cheers
<cjwatson> Or indeed https://www.debian.org/support#irc
<rbasak> juliank: so that explains why frontend locking is necessary, but how does this particular bug impact users? What's wrong for users as a consequence of this bug? Eg. what user story is broken?
<jbicha> rbasak: brotli built on all arches for me, but like I said before I think we need an AA to handle this SRU
<jbicha> https://launchpad.net/~jbicha/+archive/ubuntu/arch/+sourcepub/9464055/+listing-archive-extra
<rbasak> jbicha: AA -> because it's a new binary? AIUI, an SRU team member needs to consider it against SRU policy and accept, and only then will it go into the new queue for an AA to review.
<rbasak> jbicha: thanks for testing the armhf side
<jbicha> it needs to be promoted to main too
<jbicha> similarly, there is woff2 in the xenial new queue
<didrocks> bdmurray: hey! do-release-upgrade -d on bionic doesn't want to update to cosmic, telling I'm not on the last supported version
<xnox> didrocks, change from 'lts' to 'normal' in /etc/....
<xnox> didrocks, we park people on ltses... everytime they get to one
<bdmurray> update-manager/release-upgrades
<didrocks> even if they run manually with -d?
<xnox> didrocks, /etc/update-manager/release-upgrades
<bdmurray> Yeah, because -d on LTS would be the LTS release under development
<xnox> didrocks, we keep saying "--prompt=normal|lts" should be a command line falg
<bdmurray> xnox: we do?
<xnox> bdmurray, we have =)
<didrocks> bdmurray: oh, I wasn't seeing it like that, but ok, kind of makes sense
<didrocks> the error message is confusing though
<didrocks> thanks xnox, bdmurray :)
<xnox> bdmurray, to be fair '-d' could be either, as it will never be the case that there is both "a normal devel release" and "a new lts release" because we will not jump past an lts release, to a normal devel one.
<infinity> ahasenack: So it would seem.
<ahasenack> infinity: can you try the packages from the ppa I posted in the bug/
<ahasenack> ?
<infinity> ahasenack: Can do, though I'm not sure how to trigger the crash itself.
<ahasenack> infinity: sure. I'm counting on it going from "frequent" to "haven't seen it since <x>"
<ahasenack> infinity: any particular config you might be using?
<infinity> ahasenack: a pretty stock squid-deb-proxy, modulo adding a few more whitelist sites.
<ahasenack> I also have squid as a cache for my home network and haven't seen the crash yet
<ahasenack> ok
<ahasenack> I'm not using squid-deb-proxy, though, just squid with a generous caching config
<infinity> ahasenack: I'll give it a whirl.  I also need to figure out how to undo my telling appot to "ignore future erors of this type". :P
<ahasenack> that might be something in /var/crash/ itself, but I'm just guessing
<ahasenack> infinity: is squid restarted automatically when it crashes? Also, the logs from /var/log/squid/cache.log could be useful, maybe they say what triggered the crash, if you still have them
<infinity> ahasenack: Logs don't look particularly helpful.  And yes, I tihnk it's respawned when it dies.
<ahasenack> ok
<infinity> ahasenack: Oh, hrm, I also seem to have two squids running.  One with squid-deb-proxy.conf, one without.  That doesn't seem right.
<ahasenack> doesn't the deb-proxy one run in another port?
<ahasenack> 8000 maybe?
<ahasenack> it runs with its own config file, it *shouldn't* conflict with normal squid
<infinity> ahasenack: Yes, but the non-deb-proxy shouldn't be running at all.  It certainly wasn't in the past.
<infinity> I wonder what changed to make that happen, and if it was my fault somehow.
 * ahasenack tries "apt install squid-deb-proxy"
<infinity> ahasenack: Oh, it switched to systemd units.  I bet there used to be a "please don't run" thing in /etc/default that's now ignored. :/
<infinity> # cat /etc/default/squid
<infinity> DAEMON=nonexistant
<infinity> Yeah.
<ahasenack> a fresh install in bionic has the same result, two squids running
<infinity> So now I get two when I don't want two.
<infinity> I guess I could mask the service.  Ick.
<ahasenack> hm, I don't have an /etc/default/squid
<ahasenack> is this system something you have been release-upgrading for a while?
<ahasenack> I guess in bionic you could create an /etc/default/squid file, because the sysv initscript will source that if it exists, and use $DAEMON to run it
<ahasenack> and the initscript has this check: [ -x $DAEMON ] || exit 0
<ahasenack> so if you set DAEMON to something that is not -x, the initscript will silently exit
<ahasenack> same for squid-deb-proxy's initscript, except it sources /etc/default/squid-deb-proxy if it exists
<infinity> ahasenack: Right, exactly.
<infinity> ahasenack: Hence I created that to stop squid from running.
<infinity> ahasenack: And the sysv->systemd upgrade entirely ignores that.
<ahasenack> right, and with systemd, that doesn't work anymore bceause the file is not read
<ahasenack> sounds like a bug
<infinity> ahasenack: The squid changelog claims it's documented in NEWS.Debian... Which doesn't appear to exist. ;)
<ahasenack> I see it in the source, maybe it's not being installed
<ahasenack> how is that file handled again?
<infinity> ahasenack: dh_installchangelogs, however NEWS.Debian should be debian/NEWS (or debian/<package>.NEWS) in the source, which is the bug here.
<infinity> ahasenack: So the maintainer has been screaming his news into the void for a while. :P
<ahasenack> I've seen some packages using <package>.docs:NEWS*
<ahasenack> ok, I see the dh_installchangelogs manpage
<ahasenack> ok, I can fix that
<ahasenack> and submit to debian
<infinity> ahasenack: I'm not super happy about /etc/default being ignored in systemd upgrades, but this isn't the first package to do it, so I think I just need to get over it.
<infinity> ahasenack: But functional news would have helped, since I actually read it :)
<infinity> (yay, apt-listchangelogs)
<ahasenack> indeed, on both accounts
<ahasenack> I've seen that /etc/default/ bug in bind9 in the past
<ahasenack> (and fixed it)
<infinity> ahasenack: Aaaanyhow, I *doubt* the crash relates to running two instances at once, but I suppose there's an outside chance it might.  Maybe I should mask out the non-deb-proxy one for a while and see if things are better before I try your PPA.
<ahasenack> infinity: I'll ask the original reporter if he is also running squid-deb-proxy, but I also doubt it
<infinity> Since the crash started happening at the same time as the ignoring of /etc/default, that's a couple too many variables.
<infinity> ahasenack: Original reporter was jibel, he may well be running squid-deb-proxy.
<ahasenack> just asked
<ahasenack> do you know him?
<infinity> Seems a more likely use of squid for a QA engineer than having a full proxy.
<ahasenack> jibel: oh, is that you?
<infinity> ahasenack: Do I know him? :P
<infinity> ahasenack: (hint: you were just at a sprint with him)
 * ahasenack refrains from further silly questions
<nacc> lol
<ahasenack> infinity: one more question: which squid was crashing: the deb-proxy one, the main one, or both randomly? Can you tell?
<infinity> ahasenack: Can't tell now, crash reports are gone. :/
<ahasenack> ok
<infinity> (and not sure I could have known with the crash report, but maybe...)
<ahasenack> nothing about the crash in squid's own logs either?
<ahasenack> jibel's might have been the "main" squid, at least the command line shown in the bug doesn't include the extra config from deb-proxy
<infinity> Not that I could find in either set of logs.
<ahasenack> ok, thanks
#ubuntu-devel 2018-10-04
<coreycb> sil2100: hey! any chance you could take a look at neutron in the bionic unapproved queue? it has some critical bug fixes.
<seb128> bdmurray, hey. Are those "[bionic/nautilus] Possible Regression" emails supposed to be sent daily? Also I think Trevinho responded to it, was it good enough or was there still concerns?
<bdmurray> seb128: Hi! The emaisl are supposed to be sent whenever a new regression is found which could be daily. One of the emails I received talked about the crashes in general as a bunch rather than each one individually. As an example I'd prefer to know that crash 69d1bc is a memory error, while crash b9dfd02 will be fixed by the next SRU, etc....
<seb128> Trevinho, ^
<seb128> bdmurray, k, let's see if we can get what you need ... is there a place that shows all the report ids that are of a concern atm?
<seb128> I deleted some of the emails, I though the content was the same
<bdmurray> https://people.canonical.com/~ubuntu-archive/phased-updates.html
<Trevinho> seb128: I've looked at all of them,
<Trevinho> personally the only fix I'm concerned about is https://code.launchpad.net/~3v1n0/ubuntu/+source/nautilus/+git/nautilus/+ref/ubuntu/bionic-fix-file-remote-type-search-crash
<Trevinho> and covered by that branch
<seb128> Trevinho, can you take those ~20 ids and do a list of "id: <reason>" to help bdmurray?
<bdmurray> Trevinho, seb128: or "id, id, id: <reason>" if there are some that are the same type
<Trevinho> most of them are like: "I don't know", actually, a part from the one mentioned above which might cause some of them which I've marked as duplicated alaready
<Trevinho> already*
<seb128> Trevinho, I think we need a full summary in one email to help bdmurray to be confident if the update is fine or not
<bdmurray> "I don't know" doesn't sound like the phasing should be increased, unless its an old crash.
<Trevinho> as for the most of them I'm quite sure they happen as per other upstream changes and just changed the trace compared to what we had before, but nothing really concerning
<seb128> Trevinho, well "I don't know" doesn't give confidence it's not a regression?
<seb128> right
<seb128> well if you write that it's fine
<seb128> "not a new issue, different signature but the problem was already existing"
<Trevinho> these unknowns, are more of them related to different trace I think, but most of them seems like memory errorrs unrelated to an actual change, but I can see if I can resume it
<seb128> Trevinho, well, we just need a list and show that we looked at all the reports and are confident the SRU is still fine
<seb128> seems you are confident
<seb128> but your reply didn't convince bdmurray
<Trevinho> seb128: yeah, but if we want to be better, would be nice to reupload to fix to #1795028
<seb128> so please provide it in a format that he can review/understand enough to be fine with it as we are
<seb128> Trevinho, ok, I can look at doing that ... do you think we should block the SRU until that one lands?
<Trevinho> as I think there might be crashes related to memory issues that might be caused by that too...
<seb128> ah
<Trevinho> maybe it's better.
<seb128> sounds like we do
<seb128> k, let me put on my list to sponsor this week
<seb128> bdmurray, ^ we are going to do a follow-up SRU with a fix and then we let you know the status :)
<Trevinho> that branch is based on `XubuntuCancel` one though, so let me know if you want me to rebase it on top of ubuntu/bionic instead
<rbasak> sil2100: I'm going to finish up SRU reviewing packagekit that I started yesterday now, if that doesn't clash with you?
<Trevinho> seb128: ^
<bdmurray> seb128: got it, let me know if you want the SRU reviewed.
<seb128> Trevinho, yes please, let's not interlock those
<seb128> bdmurray, will do, thx
<Trevinho> ack
<sil2100> rbasak: no problem, thanks for the heads-up
<seb128> bdmurray, oh, other topic, I mentioned it at the sprint, but it would be nice to remove 15.04/15.10 from the error tracker legend ... is there a bug tracker/place for such requests?
<bdmurray> seb128: https://bugs.launchpad.net/errors/
<seb128> bdmurray, thx
<seb128> bdmurray, https://bugs.launchpad.net/errors/+bug/1796107
<ubottu> Launchpad bug 1796107 in Errors "Remove 15.04 and 15.10 from the graph/legend" [Undecided,New]
<bdmurray> seb128: got it, thanks
<doko> oSoMoN, tdaitx: the libreoffice tests fail with OpenJDK 11. does it need just a rebuild?
<doko> are these related at all?
<oSoMoN> doko, not sure, I need to take a closer look at the error, but I'm stepping out now, can do later in the evening
<rbasak> sil2100: did you manage to look at bug 1782031 please?
<ubottu> bug 1782031 in openscap (Ubuntu Xenial) "[SRU][xenial] Enable SCE option and systemd probe in libopenscap8" [Undecided,In progress] https://launchpad.net/bugs/1782031
<rbasak> From history:
<rbasak> sil2100_: around? May I have a second SRU opinion on bug 1782031 please? Seems to me there may be a functional (surprising) change to users there if unknown/notchecked ends up going to fail.
<ubottu> bug 1782031 in openscap (Ubuntu Xenial) "[SRU][xenial] Enable SCE option and systemd probe in libopenscap8" [Undecided,In progress] https://launchpad.net/bugs/1782031
<rbasak> 13:53 <ubottu> bug 1782031 in openscap (Ubuntu Xenial) "[SRU][xenial] Enable SCE option and systemd probe in libopenscap8" [Undecided,In progress] https://launchpad.net/bugs/1782031
<tdaitx> oSoMoN: btw, hsqldb1.8.0 also breaks with openjdk-11 (System::runFinalizersOnExit() was removed) and libreoffice depends on it (it is the only dependency), do you know why? hsqldb 2.4 fixes this and we do have it in the archive, but it is not clear if it is a sane replacement for LO
<sil2100> rbasak: looking at it now
<ahasenack> infinity: hey, for when you are around, do you have squid's apparmor profile enabled by any chance?
<infinity> ahasenack: How would I know?
<ahasenack> infinity: aa-status on the box, or ps faxwZ and check if the squid process is listed as "confined"
<ahasenack> infinity: I got logs from jibel that show apparmor denied messages right around the crash, so I'm thinking he did enable it
<infinity>  ps faxwZ | grep squid | awk '{print $2}'
<infinity> (enforce)
<ahasenack> yep, enforce, sorry
<ahasenack> so it's enabled
<infinity> I didn't actively enable it.  Surely, it's a default thing?
<ahasenack> I didn't think it was
<ahasenack> I had to explicitly enable it in my test boxes/vms
<ahasenack> something to investigate, but it gives a hint about this bug
<infinity> I mean, this laptop install dates back to vivid, so I can never remember exactly what all I may have done to it, but I'm pretty sure my squid setup is just a side-effect of "apt-get install squid-deb-proxy" and editing the whitelists.
<ahasenack> noted
<ahasenack> now let's see what kind of DENIED messages you have related to squid
<infinity> So, maybe the AA profile isn't enabled by default *anymore*, but it was in the past, and the maintainer scripts (correctly) don't change the current setup on upgrade?
<ahasenack> lots of things
<ahasenack> could have happened. I will check that, but now I want to see if I can correlate the profile with the crash
<infinity> ahasenack: http://paste.ubuntu.com/p/PM8D6WdQD8/
<sil2100> rbasak: hmmm, indeed an interesting case this is
<infinity> ahasenack: And I woke up to apport telling me of a new crash.  Yay.
<ahasenack> [95825.651047] audit: type=1400 audit(1537596453.254:301): apparmor="DENIED" operation="connect" info="Failed name lookup - disconnected path" error=-13 profile="/usr/sbin/squid" name="run/dbus/system_bus_socket" pid=24740 comm="squid" requested_mask="wr" denied_mask="wr" fsuid=0 ouid=0
<ahasenack> ok,
<ahasenack> there are two messages
<ahasenack> one about the net_admin capability
<ahasenack> and the above
<ahasenack> I've seen other fixes in apparmor profiles about this disconnected path issue
<infinity> SIGABRT is comm_openex().  That's the same one we were looking at before, right?
<ahasenack> yes, the result of the failed assert
<infinity> That does smell of something an AA denial could cause.
<ahasenack> let me get you a diff
<ahasenack> for the profile
<ahasenack> I'll also post it to the bug
<infinity> Kay.
<jdstrand_> ahasenack: make sure the profile uses attach_disconnected
<ahasenack> jdstrand_: yeah, it's not using it
<ahasenack> that will be my diff :)
<ahasenack> I'm also wondering about the net_admin capability
<ahasenack> but that has been in use since squid3 as far as I can tell
<ahasenack> early squid3
<jdstrand> * bind to any address for transparent proxying
<jdstrand> from man capabilities
<infinity> Yeah, squid seems like a solid net_admin consumer.
 * jdstrand nods
<sil2100> rbasak: let me think about it and leave a comment tomorrow, I think I have a split opinion about this SRU
<ahasenack> infinity: apply this to /etc/apparmor.d/usr.sbin.squid: https://pastebin.ubuntu.com/p/R6Z84ZdsfP/
<ahasenack> then issue sudo apparmor_parser -r -T -W /etc/apparmor.d/usr.sbin.squid
<ahasenack> jdstrand: looks ok? ^
<rbasak> sil2100: thanks
<rbasak> jmbl: ^
<infinity> ahasenack: Applied.
<ahasenack> infinity: does dmesg show a profile_replace going on for squid and squidguard?
<infinity> ahasenack: Applied.Oct  4 12:24:10 nosferatu kernel: [1057755.099944] audit: type=1400 audit(1538677450.686:496): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="/usr/sbin/squid" pid=18164 comm="apparmor_parser"
<infinity> Oct  4 12:24:10 nosferatu kernel: [1057755.109369] audit: type=1400 audit(1538677450.695:497): apparmor="STATUS" operation="profile_replace" info="same as current profile, skipping" profile="unconfined" name="/usr/sbin/squid//squidguard" pid=18164 comm="apparmor_parser"
<ahasenack> cool
<infinity> Erm, that.
<ahasenack> now we wait I guess
<infinity> I love waiting.
<ahasenack> :)
<ahasenack> you have been getting one crash per day basically?
<ahasenack> I wonder if logrotate triggers it
<ahasenack> I tried here, no dice
<infinity> Probably.
<jdstrand> ahasenack: lgtm
<ahasenack> jdstrand: thx
<infinity> Oct 04 00:00:14 nosferatu squid[32112]: assertion failed: comm.cc:428: "!isOpen(conn->fd)"
<infinity>  Oct 04 00:00:15 nosferatu squid[10409]: Starting Squid Cache version 4.1 for x86_64-pc-linux-gnu...
<infinity>  Oct 04 00:00:15 nosferatu squid[10409]: Service Name: squid
<infinity> Hrm, unless I logrotate at midnight now, that's not the trigger.
<ahasenack> ok
<ahasenack> is the crash always around that timE?
<infinity> ahasenack: Not sure.
<infinity> ahasenack: Huh.  Yep.  Midnight every day.
<ahasenack> fascinating
<infinity> ahasenack: So maybe cron.daily moved?  Isn't it meant to be 6am or something?
<infinity> Yeah, cron.daily and, thus, logrotate, is 6:25...
<ahasenack> 25 6    * * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
<ahasenack> mine is that
<infinity> Except there's also a systemd timer for logrotate now?
<infinity> Fun.
<jibel> ahasenack, this machine has been upgraded since utopic, so it might be something that was set then removed
<ahasenack> do you see logrotate messages around that time?
<infinity> Not sure where I'd see them.
<infinity> Ahh, syslog apparently.
<infinity> And yes, logrotate is at midnight here.
<infinity> Thanks, systemd new world order, for changing everything.  Love you.
<infinity> ahasenack: So yeah, I think it's fair to assume that the service restart/reload from logrotate is the trigger.
<ahasenack> can you run it manually with logroate -f /etc/logrotate.conf? It will rotate your logs earlier than expected, if you care about it deeply
<infinity> ahasenack: I can get sciency about that in a few minutes, sure.  Should probably unapply the apparmor patch first, confirm a few times that it's reproducible, then apply pach.
<infinity> patch, too.
<ahasenack> that's fine, whenever you can
<ahasenack> I'll post on the bug with the patch
<ahasenack> jibel: can you check if you have the squid apparmor profile enabled? Check with "ps faxwZ | grep squid", see if it's listed as enforced
<ahasenack> jibel: ah, sorry, just saw your bug update
<infinity> vorlon: My Technical Architect, is that a thing we should care about?  logrotate moved to systemd timers (apparently) and now runs at midnight instead of the previously-expected cron.daily time.
<infinity> s/My/Mr/
<infinity> Didn't mean to imply you were a Fisher Price My First Architect.
<sarnold> lol
<jmbl> rbasak, sorry was away from desk. ok thanks. I am happy to help answer any questions. Unfortunately, we need that functionality to ship a product. sighhhh :-)
<infinity> ahasenack: Oh, changing apparmor profiles doesn't apply to running processes, does it?
 * infinity suspects not.
<sarnold> you need to apparmor_parser --reload /path/to/profile
<jdstrand> infinity: if the process is already runningg under the parser, it does with apparmor_parser -r (or --replace, not --reload though)
<jdstrand> infinity: if the process started outside of confinement, it needs to be restarted (see 'sudo aa-status')
<infinity> Kay, I did replace.
<infinity> So, this fix isn't a large enough hammer.
<infinity> https://paste.ubuntu.com/p/nN5HqbS7ZB/ <-- ahasenack
<infinity> I also tried a hard restart for kicks.
<infinity> Looks like it's happer about net_admin, but still whiney about dbus, and still asserting.
<infinity> happier, too.
<ahasenack> I didn't handle dbus in that patch
<ahasenack> that log is a bit different though
<ahasenack> infinity: let's zero in on apparmor first, though. If you disable apparmor profile for squid, does the crash disappear?
<infinity> ahasenack: Maybe! (how?  sorry, I'm apparmor stupid)
<ahasenack> aa-complain /usr/sbin/squid I *think* is enough
<ahasenack> it should still log, but not actually deny
<ahasenack> not sure if restarts are needed, just give it a try
<sarnold> argh. sorry about --reload. :( been dicking with systemd lately :(
<infinity> ahasenack: No dice: https://paste.ubuntu.com/p/4zm9dDKgk2/
<infinity> I should probably fix the config file it's complaining about too, but I can't imagine that being the issue. :P
<ahasenack> it's not, I get that too
<ahasenack> just no crash
<ahasenack> infinity: so is this enough to crash it? /usr/sbin/squid -k rotate
<infinity> ahasenack: Yup.
<ahasenack> hm
<infinity> ahasenack: So, I guess apparmor was a red herring (but clearing out all those sketchy DENYs still seems like a solid plan)
<ahasenack> yep
<ahasenack> now why can't I get it to crash
<infinity> That's a mystery I'm not sure I can solve.
<ahasenack> infinity: is that a host, or a container/vm? And amd64 I assume?
<infinity> ahasenack: amd64 bare metal.
<ahasenack> ok
<ahasenack> infinity: is this squid the version from the ppa, or 4.1 from cosmic?
<infinity> ahasenack: cosmic.
<infinity> ahasenack: Not against trying the PPA now that we have a consistent reproducer.
<ahasenack> infinity: can you try the ppa one, and then run /usr/sbin/squid -k rotate command?
<infinity> ahasenack: URL to the PPA again?
<infinity> (or short name for apt-add...)
<ahasenack> infinity: add-apt-repository ppa:ci-train-ppa-service/3450
<infinity> Why does squid take so friggin' long to shut down?
<infinity> (longterm complaint, this isn't new)
<ahasenack> I know
<ahasenack> it waits 30s
<infinity> Err, wat?
<infinity> There's a sleep in there, it's not DOING anything?
<ahasenack> it's like a graceful shutdown, but it always does that, regardless if there are open connections or not
<infinity> That should be fixed..
<infinity> Oh, that's fun.  Upgrading squid doesn't restart squid-deb-proxy.
<infinity> Probably also a longstanding bug, but ew.
 * infinity restarts manually.
<ahasenack> interesting
<ahasenack>  /o\ surrounded by bugs
<infinity> I mean, squid can't be expected to know about *all* its potential rdeps, but the ones it does know about (cf: the apparmor profile knows of some), it should probably try to detect and restart.
<ahasenack> there are ways to link systemd units, maybe it could be done
<infinity> Or that.
<infinity> Oct  4 13:06:43 nosferatu squid[17502]: assertion failed: comm.cc:428: "!isOpen(conn->fd)"
<infinity> (with the new squid)
<ahasenack> ok
<infinity> So, no dice.
<ahasenack> thanks for your help
<infinity> I wonder if it's just a stupid assertion that needs to not? :P
<infinity> Like, exiting a loop there might be just as sane as DYING HORRIBLY.
<infinity> (note: I've not looked at the code at all, maybe it's the 1 in 100 times when assert() is used correctly)
<infinity> ahasenack: The other possibility is that this is really expected behaviour, and upstream just didn't think about people like us who trap all unclean exits as errors and whine about them.
<infinity> ahasenack: Note that this is the child process that's dying and respawning, not the master, AFAICT.
<infinity> ahasenack: So maybe that assert just needs to be an exit, and we can wash our hands of it.
<infinity> ahasenack: But an understanding of WTF is going on would be helpful to determine that.
<infinity> ahasenack: I make that assertion based on my master processes running since I started them, and the children having new start times after rotate.
<ahasenack> hm
<infinity> Also, this seems to not have anything to do with squid-deb-proxy, it's the non-deb version that we're testing and killing with squid -k rotate, it looks like.
<ahasenack> found an old bug, looking at it: https://bugs.squid-cache.org/show_bug.cgi?id=4796
<ahasenack> many comments
<sarnold> ew. I have to admit I would have expected socket interaction with logfile rotating to have been sorted out twenty years ago.
<infinity> So many wheels to reinvent.
<infinity> ahasenack: Seems stalled on another round of review/commit, but the last patch looks plausibly not the worst?
<infinity> Oh, and the discussion moved to github... Somewhere.
<ahasenack> yeah, tracking
<ahasenack> infinity: about the long shutdown: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=898469
<ubottu> Debian bug 898469 in squid "Squid waits on shutdown even though there are no active clients" [Normal,Open]
<ahasenack> been there since 3.5.x
<infinity> Also, misreading "FreeBSD" as "Fedora" and then seeing libc.so.7 in a backtrace was mildly terrifying for a split second.
<ahasenack> hehe
<infinity> OH NO REDHAT WHAT HAVE YO DONE.
<ahasenack> saw someone with a plan B of using restart for logrotate instead of "squid -k rotate"
<infinity> ahasenack: Which then runs into the long shutdown issue. :)
<ahasenack> true
<infinity> ahasenack: I wonder if it would be out of line to suggest that the Debian/Ubuntu packages should drop the default for that to 5s or something.
<ahasenack> yeah
<infinity> Since it can be jacked back up by the config file for people who actually want that.
<infinity> I mean, even 5s is too long.  The real bug should be fixed upstream, but whee.
<infinity> (The part where it doesn't differentiate between active clients and *any open socket*, and thus always waits the max time)
<infinity> I assume this actually, hilariously, means that the log sockets we're currently asserting on are also responsible for the shutdown taking 30s.
<infinity> Not that fixing A will fix B.
<infinity> Just related code with two stupid bugs that should probably date and make hundreds of little bugs.
<ahasenack> debian should also be affected by the crash
<infinity> One would assume, yes.
 * ahasenack reads through the bug one more time
<infinity> But they don't have a crash handler installed by default, so less likely to notice.
<infinity> As I pointed out, it's the *child* that dies and respawns, so there's not DoS or anything here.
<infinity> So without a crash handler, you'd have to be scouring logs to even notice it happened.
 * infinity grabs his crossbow and goes to hunt wild tacos.
<sarnold> mm tacos
<ahasenack> got it in debian
<ahasenack> Oct  4 20:17:00 sid-squid4 squid[582]: assertion failed: comm.cc:428: "!isOpen(conn->fd)"
<ahasenack> not sure how yet, I ran -k rotate multiple times, sometimes with an open connection
<ahasenack> but getting there
<ahasenack> infinity: got a reproducer, and a one-line config change that explains why squid-deb-proxy doesn't crash by default, but squid does
<ahasenack> squid-deb-proxy has cache_dir specified, as does my home proxy. With that, it doesn't crash on squid -k rotate
<ahasenack> I'll update the upstream bug, and might file a debian one as well now that I have a simple reproducer
<infinity> ahasenack: Shiny.  Well-sleuthed.
<infinity> ahasenack: So, the TLDR for me is that if I mask out the main service (as I wanted to do anyway), the bug goes away for me? :P
<infinity> ahasenack: (not at all a valid excuse to not fix it, obviously)
<ahasenack> infinity: yes
<ahasenack> or add cache_dir to squid.conf, for reasons
<infinity> Should it not have a baked-in default for that anyway, pointing to a dpkg-owned directory?
<ahasenack> if you want to confirm it
<ahasenack> squid-deb-proxy does the right thing
<infinity> Seems like a packaging bug tickling the upstream bug.
<ahasenack> squid.conf, I don't know why there is no default, probably because you have to specify a size
<ahasenack> the cache is only in ram then, without cache_dir, afaik
<infinity> A default config with no cache dir seems vaguely useless.
<ahasenack> let me see if there is an option where you don't have to specify the max size
<infinity> But maybe I'm not imagning some weird use of squid where you would be happy with a tiny RAM cache.
<infinity> imagining*
<ahasenack> well, it's a proxy and a cache
<ahasenack> two things in one
<ahasenack> the proxy bit can be used for access control
<infinity> There are other proxies that are better at that if you don't also want the caching, IMO.
<ahasenack> all cache_dir types require a size parameter, something hard to guess a good default for
<infinity> But fair point.
<ahasenack> #Default:
<ahasenack> # No disk cache. Store cache ojects only in memory.
<infinity> I still think preconfiguring a cache dir (even if tiny) makes sense.  But, again, still not an excuse for not fixing the upstream bug.
<ahasenack> after all, squid-deb-proxy does have a default cache dir
<infinity> I'd rather waste some arbitrary value (500M?) of everyone's disk than eat their RAM.
<infinity> If I had to pick a "sane" unpacked-but-not-user-configured state.
<ahasenack> # use a different dir than stock squid and default to 40G
<ahasenack> cache_dir aufs /var/cache/squid-deb-proxy 40000 16 256
<ahasenack> that's from squid-deb-proxy
<ahasenack> someone made the call
<nacc> infinity: yeah, esp. as a default configuration setting these days
<vorlon> infinity: ah, poor merger I that I didn't notice the change to timers also changed the time it ran.  I think that yes, we ought to move it to again run in the 6am window.
<jbicha> vorlon: if you're around, there are some proposed hints: https://code.launchpad.net/%7Eubuntu-release/britney/hints-ubuntu/+activereviews
#ubuntu-devel 2018-10-05
<smoser> hey. just wondering.
<smoser> I had the idea that our team could get a jump on testing of -proposed by uploading to a PPA exactly what we uploaded to -proposed
<smoser> then we could test that before an SRU team member reviewed and let into -proposed.
<smoser> I tried that, but
<smoser> Uploads aren't permitted to pocket: proposed
<smoser> i guess thats easily fixable by not setting the release to 'xenial-proposed' in our changelog.
<TJ-> I seem to have found a package-install failure on upgrade on bionic for libc6-{,dev-}armhf-cross, reported it in comment #32 of Bug #1769657
<ubottu> bug 1769657 in gcc-defaults-ports (Ubuntu) "update toolchain packages for bionic" [Undecided,New] https://launchpad.net/bugs/1769657
<sarnold> TJ-: anything in dmesg or auditd logs?
<TJ-> sarnold: not found anything, no.
<sarnold> TJ-: thanks for looking. I didn't see any problems with installing these brand-new, so I wondered if it was something more specific to your system..
<TJ-> sarnold: yeah, I've tried several times in different ways (apt --reinstall  vs dpkg -i) and the same issue occurs. I've re-fetched the .debs in case of corruption too
<TJ-> sarnold: I guess I should strace it
<sarnold> how about debsums -a libc6-armhf-cross libc6-dev-armhf-cross  ?
<TJ-> sarnold: reports !=   because the installed files are the previous package still
<TJ-> the strace looks weird; the various hf -> libhf directory names and symlinking make it confusing but it seems like it is unlink-ing the file then wondering where it has gone!
<alkisg> Hi, `apt install` in 18.04 deletes e.g. "/var/cache/apt/archives/sl_3.03-17build2_amd64.deb" right after `apt install sl`. That would be a bug and not a design choice, right?
<alkisg> I.e. it autocleans all downloaded debs right after their installation. I think it didn't do that a few months ago, so it must be a recent issue...
<alkisg> Example: apt purge sl; apt clean; strace -fe trace=file apt install sl 2>&1 | tail; ls /var/cache/apt/archives/
<alkisg> ==> unlink("/var/cache/apt/archives/sl_3.03-17build2_amd64.deb") = 0
<rbasak> infinity: you might be interested in bug 1795919. glibc is implicated. Do you happen to know of any changes in this area?
<ubottu> bug 1795919 in dovecot (Ubuntu) "fs quota calculation is wrong" [Undecided,Incomplete] https://launchpad.net/bugs/1795919
<infinity> rbasak: Not sure I see much implication there, based on the mailing list post's "science". :P
<rbasak> infinity: I thought it was "glibc upgrade triggers the bug with nothing else changed"?
<infinity> rbasak: No, it was "I recompiled it on a machine with glibc 2.24", which really doesn't tell me at all what he changed.
<infinity> rbasak: The implication of "machine with glibc 2.24" is "everything there is older and different".
<infinity> rbasak: Yes, he's right that the header changed, https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=4d728087ef8cc826b05bd21d0c74d4eca9b1a27d
<infinity> rbasak: But that should have been something vaguely close to a no-op.  And if it wasn't, it's a kernel bug.
<infinity> (ie: glibc has stopped (re)defining kernel stuff, and glibc has nothing to do with quotas)
<rbasak> Perhaps dovecot is "uncalculating" the size based on the wrong block size?
<infinity> rbasak: Simple reproducer welcome? :P
<infinity> rbasak: Worth noting that 2775445504 (reported by dovecot) /1024 is exactly 2710396 (reported by repquota)
<rbasak> tdaitx: are you waiting for something on https://code.launchpad.net/~tdaitx/ubuntu/+source/initramfs-tools/+git/initramfs-tools/+merge/355346? We don't have automatic sponsorship as part of the process; if you need sponsorship you'll need to find a sponsor out of band.
<coreycb> tjaalton: hi, any chance you could take a look at neutron in the bionic unapproved queue during your sru rota today? it has some critical bug fixes.
<tjaalton> coreycb: on it
<coreycb> great, thanks tjaalton
<rbasak> vorlon: ready for the Launchpad git switch. Do I need to work out what API call to make and tell you? cjwatson asked us to test on qastaging first.
<alkisg> Hi, `apt install` in 18.04 deletes e.g. "/var/cache/apt/archives/sl_3.03-17build2_amd64.deb" right after `apt install sl`. That would be a bug and not a design choice, right?
<alkisg> I.e. it autocleans all downloaded debs right after their installation. I think it didn't do that a few months ago, so it must be a recent issue...
<rbasak> Could that be intentional to keep things clean?
<alkisg> I didn't find any documentation about it, and it would be rather strange to invalidate the purpose of apt caching without documentation...
<cjwatson> rbasak,vorlon: I don't recall if there are any usd-import-team repositories on qastaging (hard to check because qastaging does tend to time out an awful lot).  Might be worth creating some if not so that we can make sure they still work.
<cjwatson> The API operation would be `ubuntu = lp.distributions['ubuntu']; ubuntu.vcs = 'Git'; ubuntu.lp_save()`
<cjwatson> I guess we can find out if the API change works, but it's not clear how much more we can test with all the timeouts :-/
<vorlon> cjwatson, rbasak: are you ready for me to run that API operation on qastaging?
<cjwatson> vorlon: Sure
<vorlon> cjwatson, rbasak: done
<cjwatson> https://code.qastaging.launchpad.net/ubuntu/+source/at looks plausible
<rbasak> Thanks!
<cjwatson> Which I guess is literally the only effect, isn't it
<cjwatson> vorlon: I think you can go ahead and do production too
<nacc> we probably didnt' update the 'default' repo in qa staging?
<cjwatson> Indeed, that's not a concern
<nacc> ack
<vorlon> cjwatson, rbasak: also done on prod
<rbasak> Thank you!
<nacc> woop, nice work rbasak, vorlon !
<cjwatson> LGTM
<nacc> and cjwatson :)
<rbasak> I wonder if we should also point HEAD to the applied branches
<oSoMoN> doko, FYI I'm tracking the libreoffice autopkgtest failure caused by openjdk 11 with bug #1796361
<ubottu> bug 1796361 in libreoffice (Ubuntu) "autopkgtests fail with openjdk 11~28-3ubuntu1 in cosmic-proposed" [Undecided,New] https://launchpad.net/bugs/1796361
<rbasak> Any opinions on that?
<nacc> rbasak: good question
<cjwatson> I would, but you know my opinion on applied vs. unapplied
<rbasak> That's intended for first timers - they don't necessarily know about quilt, and pointing HEAD to applied/ubuntu/devel would show them exactly what they might expect from master somewhere else.
<rbasak> cjwatson: I forget. Did you want everything always applied?
<nacc> rbasak: yeah, it's probably a reasonable default -- would change the workflow for developers, but that's not too big of a deal
<cjwatson> I've always preferred applied, yes
<cjwatson> But don't know git-ubuntu well enough to be certain
<rbasak> OK. Consider that decided, though I need to land a code change to make the importer do that, but edge is currently broken, so it won't be for a few days
<nacc> rbasak: just update the HEAD on the push?
<rbasak> Yeah. We already do, don't we? So we just need to tweak what it sets it to.
<nacc> rbasak: uh possibly :)
<rbasak> Trivial code change, but I want to get it into the production importer, so it's just a case of going through the snap publication, etc.
<rbasak> So as soon as I've fixed edge :)
<nacc> lol
<nacc> aack
<plars> bdmurray: hi, do you think you can take a look at this and see if there's anything else that would be useful? https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1796193
<ubottu> Launchpad bug 1796193 in apt (Ubuntu) "unattended do-release-upgrade asks about /etc/cron.daily/apt-compat" [Undecided,New]
<plars> bdmurray: I don't have access to the systems right this minute due to a power outage, but hopefully that will be resolved soon. It's causing some problems with some automated testing that I'm trying to get running
<nacc> ibverbs-providers Provides some libraries and Breaks older versions of them. If you specify ibverbs-providers and ibverbs-providers:i386 to be installed, dpkg complains: https://paste.ubuntu.com/p/gTKq8kYnWN/
<nacc> why does it do that? the breaks is on a version older than the one specified, afaict
<nacc> nm, it's fixed in 18.10!
<nacc> LP: #1796388 fwiw
<ubottu> Launchpad bug 1796388 in rdma-core (Ubuntu Bionic) "ibverbs-providers not coinstallable although it is multi-arch" [Undecided,New] https://launchpad.net/bugs/1796388
<tdaitx> rbasak: regarding https://code.launchpad.net/~tdaitx/ubuntu/+source/initramfs-tools/+git/initramfs-tools/+merge/355346 it is just that this is a fix for the attachment to that bug, not to the bug itself, it came out during last sprint conversations
<tdaitx> it's on hold right now
<Unit193> rbasak: Plans of having the rest of the repository in VCS?
<nacc> Unit193: i think there are plans, but probably not until we do the remiport the world step to fix the main repositories
<nacc> Unit193: and then we will phase in universe slowly
<Unit193> OK, most of the packages I have an interest in are in universe. :)
<nacc> Unit193: fair :)
<Unit193> And just last night, I `pull-lp-source $pkg`;scp pkg/debian/patches/*.patch server:wwwdir/source/  and linked someone, having a browsable source would be useful indeed. :)
<nacc> Unit193: heh, we can do one-offs of things that are priorities to developers as well
<Unit193> cjwatson: Not seen you active, so just going to say thanks for your recent work in twisted!  Didn't see https://github.com/twisted/twisted/pull/1053, and great to hear you might be picking up the ed25519 pull too.  Also glad the openssh/openssl issue seems to have been fixed in a pretty reasonable way (rather than bundling,or whatnot.)
<cjwatson> Unit193: np - still a fair distance to having ed25519 working, but we're gradually trundling along
<Unit193> Yes, but I still appreciate your work on it.
#ubuntu-devel 2018-10-06
<fooctrl> I'm remastering Ubuntu 18.10 (with latest updates) with all necessary drivers to work on MacBook Pro 2017 (touchbar), however, after I try booting the newly created image it fails due to "(initramfs) unable to find a medium containing a live file system chroot" error, any idea what the problem might be here?
<fooctrl> please note, I previously did the same thing with Ubuntu 18.04 (with different kernels) and it worked fine
<rbasak> Unit193: if you have a set of packages of particular interest, give me an MP against our whitelist to get them added
<Unit193> rbasak: Howdy, at the moment I don't, just wondered when about it'd be happening.  Easier to check something real quick if you can load something like sources.d.org, or when linking/talking about a patch.
<rbasak> OK
<rbasak> The main reason we haven't done it yet is because we know we want to reimport and force push everything, and so it seems like a waste to do that twice for all of universe.
<Unit193> Yep, that's fine.  nacc responded saying likely after that reimport.
<rbasak> Yep
<Rounin> So... I just upgraded to 18.10 today, and the analogue input/output in my soundcard disappeared... HDMI works just fine, but that means no microphone
<Rounin> Anyone else have a... Radeon HD 6500/6600 / 6700M Series sound card? Didn't know Radeon made soundcards, but I guess they do
<TJ-> Rounin: is the device completely missing?
<Rounin> TJ-: I'm afraid I don't know what device it was to begin with... What's missing is the input and output that used to be shown in the volume control applets etc.
<Rounin> Now it's just got the one digital out
<Rounin> There's no /dev/snd or /dev/audio, but I suppose that disappeared years ago
<TJ-> Rounin: what does "aplay -l" show ?
<Rounin> TJ-: Oh! Well, what do you know: card 0: PCH [HDA Intel PCH], device 0: ALC269VB Analog [ALC269VB Analog]
<Rounin> And then card 1: HDMI [HDA ATI HDMI], device 3: HDMI 0 [HDMI 0]
<TJ-> Rounin: so, if this is a desktop install, does the pulsaudio config show both those devices and are they enabled, and the correct profiles selected?
<Rounin> TJ-: /etc/pulse contains some files, but they don't seem to have references to hardware that I can see here and now
<Rounin> That's very interesting, though, that ALSA can see it... Sounds like a PulseAudio issue then
<Rounin> Sounds like good news in a way
<Rounin> At least it's not the kernel
<TJ-> Rounin: I was meaning the GUI Sound Settings tool, pavucontrol
<TJ-> Rounin: it is possible the default device is set to the HDMI not the built-in HDA
<Rounin> TJ-: Ah yes, that contains just the one card
<TJ-> Rounin: now we're making progress :)
<Rounin> Same thing with pacmd list-cards ... It lists the HDMI out. Whereas aplay -L lists several analog outs. One with stereo sound, one with 2.1 surround, one with... Well, several
<TJ-> Rounin: if you create a new log-in and use that, do both devices appear there?
<TJ-> Rounin: this could be a user-local config issue with PA
<Rounin> Good question...! I Wonder if I can switch users while logged in... Let's find out
<TJ-> Rounin: best to move to #ubuntu+1 to continue this; this channel is for development work not debugging
<Rounin> Oh ok
<tsimonq2> rbasak, bdmurray: Do either you recall if test updates are SRUable? bug 1793612
<ubottu> bug 1793612 in node-tap (Ubuntu Bionic) "node-tap in bionic fails autopkgtests due to timeouts" [Undecided,New] https://launchpad.net/bugs/1793612
<tsimonq2> The patch fixes the autopkgtest, which is a good thing and should have a fairly low regression potential, but is it worth an SRU?
<rbasak> There was some discussion of that.
 * rbasak looks
<rbasak> Here's the thread: https://lists.ubuntu.com/archives/ubuntu-release/2018-March/004352.html
<tsimonq2> Ahh, right.
<rbasak> Re-reading it now, I think it's inconclusive and so I guess the current answer is: it's subjective.
<rbasak> Feel free to contribute to the thread.
<tsimonq2> Right, I'm getting that vibe as well.
<tsimonq2> I think I'll go ahead and upload it, because from the feedback given by the SRU team members who have contributed, this package generally fits the acceptance criteria.
<tsimonq2> rbasak: It's in the queue now, you're welcome to review.
<tsimonq2> Thanks for the input regardless.
<Unit193> Not sure if it's the goal, but ruby-openssl was just uploaded and it closed Debian #900161
<ubottu> Debian bug 900161 in src:ruby-openssl "ruby-openssl: FTBFS against openssl 1.1.1" [Serious,Fixed] http://bugs.debian.org/900161
<TJ-> Should d-r-u for armhf 16.04 -> 18.04 work? or are ports expected to use apt full-upgrade ?
#ubuntu-devel 2018-10-07
<Unit193> rbasak: I'm going to guess there's no way you're still around.
<Unit193> Re: ruby-openssl, https://bugs.launchpad.net/ubuntu/+source/ruby-openssl/+bug/1759179 also is affected, and seems fixed in https://packages.qa.debian.org/r/ruby-openssl/news/20181006T133518Z.html (cc: xnox)
<ubottu> Launchpad bug 1759179 in ruby-openssl (Ubuntu) "autopkgtest fails with openssl 1.1.1 pre3" [Undecided,New]
<xnox> Unit193, ergh. we already had that new upstream release of ruby-openssl for a long time.
<xnox> Unit193, so we neither care, nor need the debian's one.
<xnox> Unit193, and the bug is out of date from pre ffe, and thus is fix-released for a long time now.
<xnox> Unit193, that bug is literarly way to old to be revelant any more, closed.
<Unit193> xnox: Heh yeah saw the new version, wasn't sure if the autopkgtests were still failing and seems the Debian upload has some changes to that.
<filib> Hi guys I would like to contribute to the Ubuntu community testing some code, how can I do??
#ubuntu-devel 2019-09-30
<[rg]> hello, is there an interal bug list for ubiquity?
<Skuggen> Anyone know the specifics of the user used to run dep8 tests? We have a test failing for MySQL 8.0.17 that gives the same failure as if it had been run as root, but the test does not have needs-root (and the test runner would give a warning if it detected being run as root)
<Skuggen> Might be that the SUDO_USER environment variable is set
<xnox> CarlFK:  i'm still not convinced it's a good idea =) sorry, setting to won't fix
<xnox> CarlFK:  maybe you can find someone else who is more agreable to get that change in.
<RAOF> Skuggen: as far as I know, there are no guarantees about the user your dep8 test is run under. If you need to be non-root, create a new user in the test and run under that.
<RAOF> (I recently ran into this with colord; you could check its dep8 tests if you like)
<Skuggen> RAOF: Thanks! Might be simpler to disable that one test (it is also run during the build)
<ahasenack> vorlon: I am taking the bug, yes, thanks. Could I add a review slot for you when the time comes? I'm planning on not even activating the service unit, since the timer will call it.
<ahasenack> just let it run over the weekend to confirm it works with just the timer unit activated
<ahasenack> (I just let it run over the weekend ...)
<Beret> I'm still hitting that weird bug reporting bug I've seen nearly all cycle
<Beret> I filed it but it's weird - https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1845950
<ubottu> Launchpad bug 1845950 in apport (Ubuntu) "Bug reporting doesn't work upon a crash" [High,New]
<rbasak> Beret: so that sort of happened to me yesterday, but in Bionic. It was the Privacy settings - disabling reporting there also seemed to disable manually requesting a report in the way you describe. It isn't that for you is it?
<Beret> rbasak, problem reporting is set to "Automatic" on the affected system
<Beret> so doesn't look like that's it here
<rbasak> ack
<rbasak> What's the current expectation for Python 2 in Eoan?
<rbasak> If I have a port ready for a package in universe, do you want an FFe or should I wait for the next cycle?
<vorlon> ahasenack: yes, I can review
<rafaeldtinoco> rbasak: https://pastebin.ubuntu.com/p/q58SPFKByt/
<rafaeldtinoco> rbasak: the merge request that is accurate is
<rafaeldtinoco> https://code.launchpad.net/~rafaeldtinoco/ubuntu/+source/simplestreams/+git/simplestreams/+ref/xenial-1686437-keystone-v3
<rbasak> rafaeldtinoco: would it be best to get Bryce to sponsor it tomorrow?
<rafaeldtinoco> yep
<rafaeldtinoco> I think so
<rafaeldtinoco> its complex enough for context switch
<rafaeldtinoco> you're right
<xnox> Laney:  vorlon: i hate initramfs-tools! end of message
<ahasenack> <systemd> phew
<xnox> ahasenack:  related
<ahasenack> :)
<bdmurray> juliank: Would using Version.section, seen in bug 1845593, also fix bug 1841675?
<ubottu> bug 1845593 in ubiquity (Ubuntu Eoan) "Installation crashes with "Free software only" option enabled." [Critical,Fix released] https://launchpad.net/bugs/1845593
<ubottu> bug 1841675 in ubuntu-release-upgrader (Ubuntu Eoan) "do-release-upgrade crashed with AttributeError in tryMarkObsoleteForRemoval(): 'Package' object has no attribute 'section'" [Medium,Confirmed] https://launchpad.net/bugs/1841675
<juliank> bdmurray: sounds like ir
#ubuntu-devel 2019-10-01
<doko> oSoMoN: is thunderbird supposed to migrate in eoan?
<oSoMoN> doko, yes, once I manage to fix the enigmail pcc64el test failures
<oSoMoN> doko, I'm on the case
<rafaeldtinoco> morning o/
<xnox> infinity:  kees: stgraber: vorlon: can i get a response on https://lists.ubuntu.com/archives/technical-board/2019-August/002456.html ? or should I open some bug report and start uploading things referencing it?
<juliank> I'm trying to UEFI boot eoan kernels in eoan's qemu, but I get emulation failures
<juliank> sudo kvm -boot c -hda fat:rw:/boot/efi -drive file=/dev/nvme0n1p2,format=raw,readonly,if=virtio -drive if=pflash,format=raw,readonly,file=/usr/share/OVMF/OVMF_CODE.fd   -drive if=pflash,format=raw,file=/tmp/M
<juliank> Y_VARS.fd
<juliank> basically
<juliank> qemu fails the emulation with invalid opcode, kvm with emulation failure
<juliank> ah, not enough mram for the vm
<juliank> yeah, more ram makes it work more
<juliank> still aborts after a kvm_mem_ioeventfd_add: error adding ioeventfd: No space left on device later on
<juliank> oh, but I have a new kernel, I should reboot
<juliank> yes, yes, now it works :)
<juliank> 5.3 is one of the worst kernels in recent history
<juliank> so many bugs
<xnox> vorlon:  infinity: why do we ship pool/ on the isos signed by the cdimage key, instead of simply doing "apt install --download-only" during squashfs building? especially since pool/ on subiquity & desktop images are there only for the offline install case and/or optional components, and not for general consumption.
<xnox> (classic server iso has a more useful pool/ that is genuenly useful even post-install)
<xnox> vorlon:  infinity: with apt install --download-only, image building gets simplier and drops using a GPG key.
<xnox> (useful discussion with Chipaca and zygo got me thinking)
<vorlon> xnox: historically there was no squashfs at all, so you couldn't do that.  So I don't think anyone's thought deeply about doing apt --download-only into the squashfs
<xnox> vorlon:  does it sound crazy, or doable?
<vorlon> it doesn't initially sound impossible to me, but it needs more thinking
<rbasak> You'd have to be careful about how you call "apt-get update", because the moment you do, offline install will be broken
<rbasak> (but that's not a blocker)
<infinity> xnox: If you download a bunch of debs into the squashfs, then you need to exclude them in the copy when you install, which complicates the installer.  Not a blocker, but a point.  Personally, though, the location of the repo doesn't matter to me, I still want it signed, cause it's too easy to screw up what you're doing with apt when you mix signed and trusted sources.
<infinity> xnox: But they don't need to be signed with the cdimage key to achieve that goal, and my plan when we moved to building ISOs in LP instead of just squashfses was to sign with an ephemeral key generated at build time, and trust that one in the installer.
<xnox> infinity:  subiquity is already layered, and the point is that you do want to install those. Most of the time the pool will have like optional things in it needed in the target system, but not installed by default. something like 'zfsutils'
<xnox> infinity: and there is no harm in copiying them to target, if they are small enough.
<xnox> infinity:  or like we run apt cache clean when done
<xnox> infinity:  i'm trying to reduce number of artefacts inside the .iso and things needed for subiqutiy netboot.
<infinity> xnox: Uhh, what?
<infinity> xnox: None of this is relevant for netboot.
<xnox> infinity:  yes and no.
<xnox> infinity:  airgapped netboot matters on s390x
<infinity> xnox: In the netboot case, anything you'd find on the ISO pool is fetched from the archive.  See the "net" in "netboot".
<xnox> infinity:  to be able to complete the install from the iso, whilst netbooting that iso.
<infinity> xnox: Airgapped netboot implies a local mirror, dude.
<xnox> infinity:  and z has no way to access an ISO normally
<infinity> xnox: There's no story for netboot without an apt mirror.
<infinity> xnox: Please don't invent one.
<xnox> infinity:  well there could be =)
<infinity> There never has been.
<infinity> Please don't go out of scope.
<xnox> infinity:  dude stop. i know it's not a requirement.
<infinity> The whole point of "netboot" is a very minimal boot artifact that bootstraps you into doing the rest from an archive mirror.
<infinity> It's not just "not a requirement", it's entirely antithetical.
<xnox> infinity:  but instead of having: base, installer, modules, pool/, kernel, initrd I am thinking that we could restructure subiquity iso for it to only be: base.squashfs, installer.squashfs, kernel, initrd
<infinity> Moving parts of the archive into the netboot to avoid the archive is the opposite of what netboot is for.
<xnox> which can complete offline installs, or netboot installs, without needed to have access to cdrom mount which contains base/installer/kernel/initrd
<xnox> infinity:  no, the point of netboot is not at all to be minimal =)
<xnox> infinity:  the point of netboot that it does network boot. The minimal is not in scope at all.
<xnox> infinity:  cause i am downloading in RAM the full 500MB+ iso and booting subiquity off it, in full.
<infinity> Yeah, fine.  "minimal". :P
<infinity> But also, you're not dowloading the full ISO, just squashy bits.
<infinity> So sort of minimal. :P
<xnox> and mirroring contents of an iso, and keeping all the pieces matching sounds hard, hence point to an .iso (which is just one file) is  more simple for the user.
<xnox> in turns out subiquity is coupled to the contents of just not the squashy bits =/
<xnox> and it's too many things to remember to download, hence download .iso is easier, and casper supports that a lot better.
<infinity> It's coupled to the pool?  I can't see how or why that would be, since it didn't even HAVE a pool until recently.
<xnox> not to the pool per-se, but that there is /cdrom mount with a valid pool
<xnox> and that there is different squashfs, called in particular way and moutable
<xnox> and other auxiliry files in a specific layout, which keeps on changing from release to release.
<xnox> anyway
<infinity> I assume mwhudson has been consulted with your plans for his spec?
<xnox> that's why i think it's obsurd the amount of things we have in an .iso and if combinding things inside the iso will make things a lot easier to manage / build / mirror / netboot / offline-install
<xnox> i'm just doing implementation prototype now, and realising that some of the things we speced out, were a lot more pretier in the spec than in practice.
<xnox> anyway.
<infinity> Anyhow, I'm very much -1 on "just point to the ISO, who cares if it's twice the size of what we actually need".
<xnox> simplifying contents of .iso is a tagent
<infinity> People never had problems mirroring the old d-i netboot structures and unpacking them.  I don't see why this needs to suddenly be "hard".
<xnox> infinity:  let me get the delta.
<infinity> Multiple files isn't a killer.
<infinity> Be sure to get the delta on an LTS point release ISO.
<xnox> infinity:  they mirrored the one archive.
<infinity> Which ships with two kernels, two sets of modules, etc, and you don't need all of that to boot one machine.
<xnox> infinity:  d-i runs from an initrd, subiquity is a snap.
<infinity> xnox: Yes, they mirrored the archive, and we identified that as a thing we need to figure out for this to work properly.
<xnox> infinity:  and like maas does download cloud-image squashfs mounts that, and runs system from there curtin and all that.
<infinity> How subiquity is packaged is entirely irrelevant.
<infinity> Unless you're proposing snapd in firmware. :P
<xnox> well i don't want to create a new artefact at all. I.e. such that an iso has the things one needs to either unpack, or publish, or boot directly.
<xnox> *any new*
<infinity> Okay, making the ISO "unpackable" seems not terribly difficuly.  But I don't see how that would look a lot different from today's ISO.
<infinity> Not that "unpacking an ISO" is really any easier for people than "mirror these bits".
<xnox> infinity:  point is that today, when doing network boot, casper doesn't know the layout and the contents of the iso. It blindly mounts all the things it sees, in alphabetical order, and boots it. And pieces inside it have loosely coupled dependencies on the rest of the iso layout.
<infinity> You're making that sound a lot worse than it is.
<xnox> and i don't feel like encoding in casper filenames to walk/download, or which ones are mandatory, if normal boot path doesn't. Cause we change livecd-rootfs and eventually add code to use new pieces. without touching casper normally.
<LocutusOfBorg> jamespage, hello, please src:gnocchi fix on armhf autopkgtests?
<LocutusOfBorg> you probably want to add curl to test dependencies
<LocutusOfBorg> (assuming curl is available might be not the best idea=
<jamespage> yep (although it would be nice in test envs where consistent)
<LocutusOfBorg> jamespage, this is true, I can't understand why curl is installed everywhere except armhf, but in any case if you use it directly, a dependency is the best thing to do...
<LocutusOfBorg> Laney, ^^ do you happen to know why?
<Laney> no, something in cloud images depends on it presumably
<jamespage> most likely - its part of the server and cloud-image tasks
<jamespage> LocutusOfBorg: anyway fix uploaded
<LocutusOfBorg> thanks
<xnox> infinity:  like people will not mirror .disk/info and .disk/casper-uuid-generic correctly =) unless you ask for url to the full .iso =)
<infinity> xnox: Okay, so if casper doesn't see squishyfses, it tries to grab the ISO from a well-known location (or a preseeded location, if given), mounts, and carries on.
<infinity> xnox: That doesn't imply a layout change is necessary either.
<xnox> infinity:  yeah. but enqually the current iso listing is, well.... tasteless
<xnox> and not as cute as for example maas artefacts. kernel + initrd + filesystem (which is both used for ephemeral boot, provisioninged, and is deployed/layed on disk)
<xnox> infinity:  not sure about the well-known location, cause at the moment initrd is coupled to the iso contents. I.e. it must be at least the same kernel abi. And the well known location changes, for a given initrd.
<xnox> that's why i kind of want to decouple things more, such that vmlinuz+initrd pair can use/deploy many .isos; i.e. not necessarily the one matching the build that vmlinuz+initrd came out of.
<infinity> Then you want kexec.
<infinity> Comparing this to maas isn't fair, as their initrd is also the entire "installer", much like d-i.
<infinity> We're getting our installer from a massive rootfs that must actually be usefully bootable.
<xnox> infinity:  no their initrd is not the intire installer.
<xnox> infinity:  their initrd has cloud-config, which they drive ephemerally booted cloud-image squashfs without kernel (the lxd squashfs)
<xnox> which talks to maas to run curtin, talk back to maas, and shutdown.
<xnox> so their initrd has all the kernel modules + cloud-url / overlayroot stuff
<infinity> xnox: Oh, right, they have two rootfses.  Forgot about that bit.
<xnox> infinity:  i still have no idea why we ship linux-firmware package on s390x
<xnox> is it useful for like mellanox scsi cards? because that's like the only peripheral that could be used on the mainframe
<infinity> xnox: Because it's arch:all and a dep of the kernel.  If literally no drivers for s390x reference firmware in it, request the dep be dropped from s390x kernels?
<infinity> xnox: (the kernel team should have tooling to discover said deps)
<sarnold> mellanox scsi?
<xnox> is it scsi
<xnox> Mellanox ConnectXÂ®-4 LX adapter as the, IBM 10GbE RoCE Express2, FC# 0412, offers the best cost effective Ethernet adapter solution for 10Gb/s Ethernet speeds
<xnox> sarnold:  what is that?
<xnox> PCIe not Scsi right?!
<xnox> https://blog.mellanox.com/2017/08/mellanox-delivers-connectx-4-lx-ibm-z14/
<sarnold> man that's one catchy name
<infinity> sforshee: How feasible would it be to conditionalise linux-firmware deps in the kernel build with a build-time scan of objects to decide if they actually have external firmware deps in the first place?
<infinity> sforshee: (One could do this scan manually and twiddle deps manually too, but then the world explodes the first time that situation changes for $flavour and no one notices)
<xnox> sarnold:  infinity:  so 13% of our subiquity s390x iso is linux-firmware.deb
<xnox> probably more than that, cause pieces of it are copied into initrd.ubuntu and hte xecond ubuntu.ikr initrd.
<xnox> *the second
<infinity> Technically, that would also mean most linux-firmware deps would move from the metapackage (where they live today) to linux-modules-extra-ABI, which actually has the dep in most cases.
<infinity> xnox: I'm not sure that's a useful datapoint I care about, since removing it from s390x doesn't help amd64, and s390x is the enviornment least likely to care about the installer being a bit chubby.
<infinity> xnox: But from the POV of things being clean, I agree that useless l-f deps shouldn't exist.
<xnox> infinity:  currently subiquity requires pool to be there, but i think it can be empty. Pool is 20% of the iso, most of which is the kernel debs, as things are small and tiny below linux-modules-extra.
<xnox> infinity:  and currently subiquity would use the .deb from the pool, even if the network is available, if the one over the network is no newer.
<infinity> Yes, by design.
<infinity> But not ideal for netboot.
<xnox> (for example installing daily devel image, one will have to fetch linux.deb into target anyway, so doesn't matter if it comes from the predownloaded .iso or the archive) There is runtime RAM penalty.
<infinity> Anyhow, I tihnk "make it netboot" takes first priority, then "figure out how to put it on a diet" might come second.
<xnox> so i'm not sure there is a massive difference in downloading a few (less than 10) files that add up to 381 with 80 later (460 total) or 575MB in one go.
<infinity> I am somewhat concerned about the RAM usage in general, but I hope that's just me living in the past when computers didn't have gobs of RAM.
<xnox> to me, it sounds interesting point that maas deploys useful baremetal machine; they used to have d-i & cloud-image based installer, and use cloud-image based installer and do fetch over the network and boot in ram the cloud-image squashfs.
<xnox> realistically, our cloud-image squashfs is small enough to do that, on all but extra-small / small VM sizes in the cloud.
<xnox> and all bare-metal servers are larger than S sizes in amazon.
<xnox> infinity:  i agree that it should "netboot" as a priority, and optimizations / changes can be iterated on top of htat.
<infinity> Holding an ISO in RAM probably throws those calculations off a bit, but point taken that MaaS basically does the same thing, ish, just slightly slimmer.
<xnox> infinity:  i am pondering in my head, how i can come up with something that can be a thin/independant overlay that can be put on top of the maas squashfs. Or even if we could just use cloud-image with elaborate config of "talk to snap store, fetch subiquity, and please run it" =)
<infinity> I don't think we want to reimplement MAAS here.
<infinity> Having two rootfses instead of one isn't really going to help subiquity, when it needs to function with only one for the ISO already.
<xnox> infinity:  true
<xnox> infinity:  i am also still pondering to have more UI in casper initrd
<xnox> infinity:  like "I didn't find cdrom, or drive, and no network was provided", would you like to "ip=dhcp? url=http://releases.ubuntu.com/{release}/ubuntu-server-live.iso"
<xnox> infinity:  or like able to type in ip= command, vlan, url from there.
<infinity> s/casper/subiquity initramfs hook that ends up in casper initrd/ maybe?
<xnox> such that one doesn't need to reboot, if there is console access (remote kvm) and one made a typpo
<xnox> yeah
<xnox> basically interactise it to be on par with network-console d-i page
<infinity> I wouldn't be against such fanciness for v2 (or v0.2 :P)
<xnox> (which is what s390x people use today)
<infinity> The only problem you have with early interaction is that we won't do keyboard/locale setup until we enter subiquity.
<infinity> So it assumes everyone knows how to blindly type on pc101 on their local keyboard.
<infinity> s/pc101/us101/
<infinity> Unless we can do it so early that we're still getting raw keyboard input.
<infinity> Which might be true in early initrd.  I'm not sure how "configured" the linux console is before we do things to it.
<infinity> As someone whose chosen keyboard layout happens to also be the accepted default everywhere, I don't usually have to think about this sort of thing.
<sforshee> infinity: on the surface it seems feasible to base the linux-firmware dep on scanning objects in the package, I'd have to play with it to see how hairy it works out to be in practice
<infinity> sforshee: Yeah, I figure it's not as simple as one sentence on IRC.  But I was also pretty sure you already have tools for scanning module->firmware relationships that you use for d-i udebs, and also just to know if you're missing junk (for HWE, etc).
<infinity> sforshee: So turning that into a "if binary package foo needs firmware, it should depend on it, if not, not" would move firmware deps to modules or modules-extra (or sometimes nowhere for some flavours), which feels more "correct".
<infinity> sforshee: To get it right, I imagine you'd also have to build-dep on linux-firmware to know what it ships.  And flavours with their own firmware packages would get those in the build-deps too.  Or something.  Maybe.  I dunno.  Also happy to have you file it under Flying Cars, decide it's too much trouble, do a one-time scan of s390x for xnox to decide if you can drop the l-f dep from generic/s390x meta deps, and call it done. :P
<sforshee> infinity: firmware required my modules is supposed to be declared in the .modinfo secion, so it's pretty easy to get at. Not all drivers are so straightformward though, e.g. iwlwifi will accept a range of firmware versions but only declares a single version in .modinfo
<sforshee> still, one would hope that version is in fact in linux-firmware
<infinity> sforshee: I try to pretend iwlwifi doesn't exist, except every three years when it's laptop buying season and I have to begrudgingly admit that theirs works better than everyone else's and buy another one.
<sforshee> infinity: must be nice
<infinity> Maybe the free ath drivers are finally on par by now, I haven't done side-by-side for a while.
<sforshee> yeah me neither, they seemed to be doing pretty good for a while but I'm not sure now
<xnox> infinity:  i wonder if we will find that we do compile wifi drivers on s390x even though that's impossible to use
<infinity> xnox: I feel like the maintainer of the s390x port should know the answer to that. :)
<xnox> infinity:  if only they would rotate me into the kernel team finally
<infinity> xnox: You need to be in the kernel team to look at /boot/config*?
<xnox> infinity:  nah =) but like digging and optimising it.
<infinity> I guess I should stop reading things not produced by my team. ;)
<xnox> enotime for that
 * xnox checks which version zfcpdump-kernel is at
<xnox> https://launchpad.net/ubuntu/+source/zfcpdump-kernel is v4.13
<infinity> Pretty sure if we rotated you into the kernel team, bjf would murder you in the first week.
 * xnox is happy we shipped it as a full source package
<infinity> Likely for the best that you're not. :P
<xnox> well i'll move to portland to rotate into the kernel team
<infinity> Moving to Portland gets you rotated into management.
<sarnold> look if you joined the channel you're going to have to move here
<sarnold> don't worry you'll like birkenstocks I swear
<infinity> I hear the current administration is very sympathetic to Russians.  No better time to immigrate.
<ejat> hi, why gnome-session-bin & gnome-session-common package version in eoan still 3.33.92-1ubuntu1 where gnome-shell already 3.34.0-1ubuntu1?
<seb128> ejat, because no-one updated gnome-session yet, but there are no change out of translations in the update ...
 * ejat facing re-login issue (cant login)after locking screen / come back from sleep 
<ejat> how to debug/get the log
<ejat> just recently i faced this issue
<ejat> using eoan -proposed
<ejat> anyone can advise me how to debug/get log can't login after locking screen/ come back from sleep ?
<ahasenack> can you switch to a console? ctrl-alt-f2 for example
 * gQuigs has found ctrl-alt-f5 the most reliable, with the way gdm/gnome-shells now work.. 
<ejat> ahasenack: yups ... like gQuigs say
<mwhudson> infinity, xnox: i'm all for making the ISO layout simpler but it's not going to be hard to get subiquity to not put file:///cdrom in sources.list if it's not there
<mwhudson> also my last attempt to simplify casper-helpers broke two other things i had no idea existed so eh
#ubuntu-devel 2019-10-02
<RAOF> Hey, tjaalton: https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1845317 is already fixed in eoan, right?
<ubottu> Launchpad bug 1845317 in mesa (Ubuntu Bionic) "Add new pci-id's for CML-S, ICL" [Undecided,New]
<tjaalton> RAOF: bah no.. forgot to add it to the new version.. will fix in -1u2
<tjaalton> hmm actually
<tjaalton> the new pci-id's are there
<tjaalton> just the marketing name changes are missing, which isn't critical for this bug
<tjaalton> RAOF: nope, some cfl id's are missing, I'll upload -1u2
<RAOF> Ta
<tjaalton> RAOF: will you still accept it? projects are waiting for the update
<RAOF> tjaalton: Sure, if the fix is heading to eoan shortfly.
<tjaalton> great, thanks
<tjaalton> uploaded
<ddstreet> rbalint hi, i'm wondering why you added this https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?h=ubuntu-eoan&id=053719c8971705307aa8cb5cbcd679defa89f70a
<ddstreet> is there something i'm missing?
<rbalint> ddstreet, it was added in https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?h=ubuntu-eoan&id=b09b6ed4682 and when i merged 241 i accidentally merged it away making the script using ret=1-s and fail-s
<ddstreet> rbalint but why did you add it back?  it's not needed, in fact it makes things worse
<rbalint> ddstreet, to keep it consistent i readded it, but we can drop the whole ret=... part and use only fails
<ddstreet> well it skips calling fail() which gathers info
<ddstreet> which can be useful debugging failures
<ddstreet> i'm just not seeing the benefit of adding it as an ubuntu-specific patch...
<rbalint> ddstreet, i agree, let's convert all the ret=... parts to fail ...
<ddstreet> rbalint honestly i'd prefer if the entire boot-smoke test was pulled from debian, there are various other issues in the one we carry
<rbalint> ddstreet, looking at the (salsa)/master..ubuntu-eoan delta we have extra checks, but if all of those are found to be obsolete then sure, carrying less delta is better
<rbalint> ddstreet, i see open PR-s on https://salsa.debian.org/systemd-team/systemd/merge_requests and mine does not progress, so i did not look into trying to push delta pieces to Debian more actively
<ahasenack> good morning
<rbalint> ddstreet, i'm dropping the ret=... parts with 243, it is a bit late for 242 if you don't mind
<ddstreet> yep that's fine, not really a big deal either way
<rbalint> ddstreet, i'm prepping next 242 upload in ppa:ci-train-ppa-service/3797 , if you have something urgent for eoan, please ping me
<tjaalton> launchpad git down?
<rbasak> It was (short notice scheduled outage) but was reported to be back now.
<rbasak> Check #launchpad
<tjaalton> ah
<tjaalton> still getting 'fatal: Could not read from remote repository.' for some kernel repos
<tjaalton> but I'll wait if it'll settle down
<cjwatson> Might be a bit overloaded since it's trying to page stuff back in
<cjwatson> My clones of LP itself are going super-slowly
<cjwatson> Oh, and it's recipe-o-clock, one moment
<tjaalton> worked this time
<cjwatson> Cancelling some recipe builds which should help as well
<ali1234> what is the difference between binutils and binutils-multiarch?
<ali1234> i am trying to build a cross-toolchain that targets debian-style multiarch
<ali1234> i built gcc with --enable-multiarch but then when linking, this happens: https://paste.ubuntu.com/p/bBcJJDhphC/
<ali1234> strace output at the bottom shows tha binutils is not searching the multiarch paths, ie it searches $SYSROOT/lib but not $SYSROOT/lib/arm-linux-gnueabihf
<ali1234> so my question is what do i need to do to binutils to make this work?
<ali1234> i assume it is something done at build time due to the existence of the two binutils packages
<ali1234> i see in debianrules it is configured with "--libdir=/$(PF)/lib/$(DEB_HOST_MULTIARCH)" - i should probably do something like that?
<ali1234> or maybe 129_multiarch_libpath.patch is the key?
<tjaalton> ahasenack: sssd 2.2.2 in debian, btw
<ahasenack> yeah, but FF :(
<rafaeldtinoco> ali1234: https://wiki.debian.org/Multiarch/HOWTO
<rafaeldtinoco> might help you
<rafaeldtinoco> and https://wiki.debian.org/CrossToolchains
<ali1234> already read it.it doesn't explain what debian did to binutils
<rafaeldtinoco> ali1234: well, without too much of reading (output) id say your linker (for another arch) can't find the libs (made for that arch)
<ali1234> nope
<rafaeldtinoco> if it was run time the variable LD_LIBRARY_PATH would be the one checked by the linker (statically set in the ELF) and check for the shared libraries etc
<ali1234> the problem is my linker doesnt have 129_multiarch_libpath.patch which makes it search the multiarch directories
<rafaeldtinoco> since this is link time, I think LIBRARY_PATH only is the env variable you would need
<rafaeldtinoco> but I prefer doing that inside lxc containers using qemu-user-static
<ali1234> what i dont understand is why gcc has multiarch support upstream but binutils needs a patch
<rafaeldtinoco> ali1234: great.
<ali1234> and also i don't know how to apply the required patch because i am building the toolchain with abe
<ali1234> and also i don't know if there are other patches required in other tools
<rafaeldtinoco> ali1234: you can open a bug to the package in question
<rafaeldtinoco> and suggest the patch
<rafaeldtinoco> and explain how to reproduce in a simple example
<ali1234> what, binutils upstream?
<rafaeldtinoco> so someone else can merge it
<ali1234> i kind of assumed that it had already been proposed, i mean that patch has been around for as long as multiarch
<ali1234> so like 10+ years
<ali1234> i kind of figured there's a reason it hasn't been merged upstream
<ali1234> also you can't reproduce it in a simple example - it requires that you have a multiarch compiler and multiarch libs installed
<rafaeldtinoco> ali1234: https://wiki.dlang.org/GDC/Cross_Compiler/Existing_Sysroot
<ali1234> yes, that
<rafaeldtinoco> gives as example doko's url on that patch
<rafaeldtinoco> http://bazaar.launchpad.net/~doko/binutils/pkg-2.24-debian/view/head:/patches/129_multiarch_libpath.patch
<ali1234> yes
<ali1234> so then that seems to indicate that it is only that one patch required
<ali1234> there is a mistake in those instructions though - they don't build gcc with --enable-multiarch so they will have the exact opposite problem that i have
<ali1234> binutils supports multiarch but gcc doesn't
<rafaeldtinoco> yep, when debugging readelf has to be the binary for the arch being debugged
<ali1234> i get the feeling that there are no more than 5 people in the whole world who actually understand the problem :(
<rafaeldtinoco> as multiarch is not compiled
<rafaeldtinoco> just 1 example ^
<ali1234> i don't know what that means
<ali1234> gcc has a configure switch "--enable-multiarch" which appends the extra directories to the search path. identical to what the patch does for binutils. except it is in the upstream source
<ali1234> if you don't turn it on, then gcc won't be able to find your libs
<ali1234> if you don't patch binutils then it wont be able to find your libs
<ali1234> so you need both, or neither
<ali1234> it doesn't even really have anything to do with architectures, it is just that the libraries are in a different directory to normal
<rafaeldtinoco> ali1234: arent u mixing up multiarch term with cross compiling ?
<ali1234> you can have this problem with a native compiler
<ali1234> no, i'm not
<ali1234> they are two different things
<rafaeldtinoco> i know they are =)
<ali1234> you can have a native multiarch compiler
<ali1234> multiarch just means that libs are in /lib/$arch-triplet instead of /libs and this means all search paaths have to be adjusted, or your compiler will not be able to find anything
<rafaeldtinoco> right
<ali1234> so my pain point is that the support for this exists upstream in gcc and enabling it is a compile time switch, but for binutils you have to apply a patch
<ali1234> which seems insane given how closely related they are. you would think they'd both have it
<rafaeldtinoco> I see what you mean now
<ali1234> if you have a system where one of them supports it and the other doesn't, you will have a bad time
<rafaeldtinoco> ali1234: when you say binutils, you mean only ld ?
<rafaeldtinoco> or all binaries ?
<ali1234> well the atch applies to the binutils source
<ali1234> it only seems to touch ld and gold
<ali1234> but binutils is binutils
<rafaeldtinoco> this page covers lots of stuff about this:
<rafaeldtinoco> https://wiki.debian.org/Multiarch/LibraryPathOverview
<rafaeldtinoco> This requires modifications to glibc's ld.so loader (can possibly be provided via platform back-end changes). Backwards compatibility most likely requires that both the new multiarch location and the old location are searched.
<rafaeldtinoco> According to the primary multiarch assumption, the system library search paths are modified to include the multiarch target string:
<ali1234> sure. i'm not compiling glibc though
<rafaeldtinoco> its the same case though
<ali1234> yes
<rafaeldtinoco> its basically saying you will have a problem with the linker
<rafaeldtinoco> depending on LIBRARY_PATH
<ali1234> ld.so, yes, but i'm not compiling that either
<ali1234> i'm trying to make a toolchain that targets an existing debian sysroot
<rafaeldtinoco> i see, for it to coexist
<ali1234> so it already has all the runtime stuff
<rafaeldtinoco> so you can generate armhf packages lets say
<ali1234> right, and link against packaged libraries that already exist
<rafaeldtinoco> using the second toolchain (cross compiling)
<rafaeldtinoco> etc
<ali1234> exactly
<rafaeldtinoco> yep , i used to work @ linaro
<rafaeldtinoco> i used armhf containers for that
<rafaeldtinoco> or arm64
<rafaeldtinoco> etc
<ali1234> containers are so slow though
<rafaeldtinoco> its a good idea
<ali1234> this is for raspbian
<rafaeldtinoco> yep, depending on qemu-user-static isnt good
<ali1234> linaro bootstrapped their original cross compiler
<rafaeldtinoco> because its not multi threaded also
<ali1234> but it's now horribly out of date, and nobody at rpi-foundation knows how to make a new one
<rafaeldtinoco> gotcha
<rafaeldtinoco> ali1234: and why gcc6 ?
<ali1234> not gcc6
<rafaeldtinoco> not 6 from your output ?
<ali1234> ive been working on this for literally years
<ali1234> gcc6 was the default for raspbian stretch
<rafaeldtinoco> gcc version 6.4.1 20180425 [linaro-6.4-2018.05 revision 7b15d0869c096fe39603ad63dc19ab7cf035eb70] (Linaro GCC 6.4-2018.05)
<rafaeldtinoco> gotcha
<ali1234> but i want to be able to target current raspbian, which is 8.3
<ali1234> and then whatever the next one is... and so on
<rafaeldtinoco> so your will at the end is to cross compile
<rafaeldtinoco> all raspbian
<ali1234> yes
<rafaeldtinoco> in a fast way
<ali1234> no
<rafaeldtinoco> so you dont depend on actual hw ?
<ali1234> i dont want to cross compile anything that already exists in raspbian
<rafaeldtinoco> or to have multiple toolchains
<ali1234> i want to cross compile things that don't exist in raspbian, using the raspbian libraries that do exist
<rafaeldtinoco> hum. i see
<ali1234> compiling raspbian itself ain't my problem. afaik they have some arm servers to do it
<rafaeldtinoco> yep
<rafaeldtinoco> i was about to point you https://www.socionext.com/en/products/assp/SynQuacer/Edge/
<rafaeldtinoco> but as you said, its likely something to allow others as well
<rafaeldtinoco> to contribute generating new packages
<rafaeldtinoco> without having necessarily the arch
<ali1234> yeah i bet that is still slower than cross compiling
<rafaeldtinoco> its not =)
<rafaeldtinoco> Linux firewall 5.0.0-30-generic #32-Ubuntu SMP Wed Sep 18 00:24:43 UTC 2019 aarch64 aarch64 aarch64 GNU/Linux
<rafaeldtinoco> $ nproc
<rafaeldtinoco> 24
<rafaeldtinoco> its not super fast
<rafaeldtinoco> but its ok
<ali1234> how much does it cost?
<rafaeldtinoco> ~ $1k
<rafaeldtinoco> 1.2k i suppose
<ali1234> hmm that's actually kind of reasonable for 24 core
<rafaeldtinoco> ARMv8 rev 1
<rafaeldtinoco> you can run armhf kvm guests
<rafaeldtinoco> or lxd guests
<rafaeldtinoco> like I do
<rafaeldtinoco> I do ubuntu armhf/arm64 debugs on that machine
<rafaeldtinoco> actually
<ali1234> still, the lack of cross compiler annoys me, and i'm not the only one
<rafaeldtinoco> yep yep
<rafaeldtinoco> orthogonal things
<rafaeldtinoco> just for you to have in mind ^
<ali1234> so the problem i have now is that i built the compiler i have now with linaro abe
<ogra> just get a Pi4 4GB, a fast USB3 SSD and be done ... my builds on that HW run as fast/slow as on launchpad
<ali1234> lol, launchpad is really slow
<ogra> i have seen and done slower arm builds :)
<ali1234> anyway, abe lets you set gcc configure options (and binutils configure options) so i was able to enable multiarch for gcc, cos it is upstream. but it has no way to apply a patch to binutils
 * ogra did the original ubuntu arm port bootstrapping on an nslu2 ;)
<rafaeldtinoco> ogra: #) =)
<ali1234> how many times did you have to run "make" before it worked?
 * rafaeldtinoco gets back to eoan installer problem
<rafaeldtinoco> as BETA is broken
<ogra> endless times :)
<rafaeldtinoco> ali1234: let me know your findings
<ogra> not many people know though that we actually supported ARMv5 for one release
<ogra> (jaunty IIRC)
<ali1234> okay a question: the binutils-source package: is the tarball inside it pre-patched?
<ali1234> same question for gcc-8-source
<sarnold> ali1234: if the tarball name includes 'dfsg' in it, that's a clear sign that it has been; otherwise it's harder to tell
<ali1234> i'm not talking about the source package
<sarnold> ahhhhhh
<ali1234> binutils-source is a "binary" package that installs /usr/src/binutils/binutils-2.31.1.tar.xz
<ali1234> (or whatever version)
<ali1234> thing is... it also installs a "patches" subdir so i am wondering if i need to apply those manually?
<rafaeldtinoco> ali1234: you should read a bit about debian packaging
<ali1234> this isn't a source package >.<
<rafaeldtinoco> ah
<rafaeldtinoco> lol
<rafaeldtinoco> ok
<rafaeldtinoco> :P
<blackboxsw> Hey folks, I've got a package postinst script that takes certain cleanup actions based on determining the Ubuntu series based on contents  of /etc/os-release.    If a system is performing a do_release_upgrade, can we rely on etc/os-release to contain the target series when a new series package is upgraded?
<blackboxsw> I am presuming that /etc/os-release would be updated to the target "upgraded" ubuntu release name/content prior to upgrading to the packages for that release because packaging may have release-specific configuration behavior. So, for our postinst scripts, we're going to assume the upgraded xenial content is present in /etc/os-release prior to upgrading to any of the other xenial deb packages.
<blackboxsw> *do-release-upgrade* rather
<blackboxsw> Is that the correct assumption that /etc/os-release will be present during a do-release-upgrade before upgrading 3rd party debs? Or is there a potential race we need to worry about.
<ali1234> what if /etc/os-release is updated but nothing else on the system is?
<sarnold> blackboxsw: I believe if you need to go this route, you'll need to declare Pre-Depends: checks https://www.debian.org/doc/debian-policy/ch-relationships.html#binary-dependencies-depends-recommends-suggests-enhances-pre-depends
<sarnold> blackboxsw: those tend to add brittleness though so it'd probably be worth exploring alternatives further
<blackboxsw> sarnold: in our case, and alternative would be for our postinst to look at the previous package version $2 when running "configure" an 'know' that it came from a different series during an upgrade path. So, we could explore that as an option
<blackboxsw> then our new package would know it's upgrading across a release
<sarnold> blackboxsw: at least there's loads of those in the archive to crib off of :) it's a bit more effort to keep track of the allowed upgrade paths, but feels more likely to be reliable to me
<blackboxsw> ali1234: in our case, we have only package-specific config changes that are made based on values in /etc/os-release. So, no external dependencies beyond that
<blackboxsw> thanks for the suggestions
<ali1234> well, why do you need to know the release at install time then?
<ali1234> or are you just trying to figure out that the release has changed?
<Unit193> If anyone cares about wayland and wxgtk, https://packages.qa.debian.org/w/wxwidgets3.0/news/20191002T204524Z.html fixes two-finger touchpad scrolling.
<Unit193> https://salsa.debian.org/freewx-team/wx/commit/9fe0c523faa50746099444ed7b50fccf7bbda136.patch is actually surprisingly small..
<chiluk> is anyone going to KubeCon ? I'd love to catch up with some of my old ubuntu peoples.
<ahasenack> hm, I have a postinst calling gpg, and am wondering if I should add gpg (or gnupg) to d/control's Depends
<ahasenack> the package is flagged as optional in bionic
<ahasenack> and important on trusty
<ahasenack> haven't seen a system without /usr/bin/gpg, but looks like it's possible
<infinity> ahasenack: apt-cache show gnupg | grep ^Essential
<infinity> ahasenack: If that doesn't return anything (compare to, say, "apt-cache show coreutils | grep ^Essential"), then you need a dependency.
<infinity> ahasenack: Relying on "I think most people have this installed" isn't the way to go. :)
<ahasenack> yep, I'm adding it, I checked Priority before
<ahasenack> and there is no "Essential" as you said
<mwhudson> some gpgv* is guaranteed to be there
<mwhudson> because apt
<mwhudson> but not everything
<Unit193> Package: gpgv, Priority: important, Build-Essential: yes.  So it's somewhat important, one might say.
<Unit193> (Note that you really should still depend on it, if you need it, though.)
#ubuntu-devel 2019-10-03
<blahdeblah> wgrant: you around?
<blahdeblah> wgrant: I'll just drop Q here and if you have a chance I'd appreciate an opinion.
<blahdeblah> I think https://code.launchpad.net/conn-check is the tool OLS/snap store were using for external connectivity diagnosis.
<blahdeblah> Is that still your preferred direction for that function in headless environments where you have no ssh access?
<wgrant> blahdeblah: Hmm, I think that'd be my preference, yes.
<blahdeblah> wgrant: cool - thanks for the quick response. Hope things are going well with you.
<wgrant> blahdeblah: Likewise :)
<doko> jamespage, coreycb: python-pbr autopkg test fails
<rbalint> doko, what is the plan for linux/5.3.0-16.17/i386 autopkgtest in eoan?
<rbalint> doko, i can add a hint to let systemd migrate, but there are other options
<rafaeldtinoco> good morning o/
<rafaeldtinoco> dannf: tks for testing sg3-utils, ill ask someone to review the mr!
<ackk> hi, is there a way (dch or similar) to change version and distro in the last entry of a d/changelog, without adding entries?
<ackk> I tried something like dch -v <version> -D <distro> "" but that does create a new entry
<GunnarHj> ackk: How about doing it manually?
<ackk> GunnarHj, yeah that's what I have right now, was just wondering if there was nicer way
<GunnarHj> ackk: Ok.
<rafaeldtinoco> ackk: dch -e ?
<rbalint> why does systemd autopkgtest pull in linux from -proposed? https://people.canonical.com/~ubuntu-archive/proposed-migration/eoan/update_excuses.html#systemd
<rbalint> i mean why does linux's autopkgtest do that when triggered by systemd :-\
<jibel> vorlon, I just tried on a uefi machine, booted in legacy mode, install on entire drive, the ESP is not created.
<vorlon> jibel: ok. It's possible we missed the boat for 19.04, and only managed to land this in 19.10dev + 18.04.3
<jibel> 2 days old image
<vorlon> wait
<vorlon> you mean it doesn't create it even with eoan?
<jibel> yes
<vorlon> then that sounds like a regression
<jibel> eoan 20191001.2
<jibel> and if I reboot it'll obviously won't boot
<vorlon> ok, I will go digging and snarling
<jibel> thanks
<didrocks> thx :)
<cyphermox> uefi machine booted in legacy mode though
<cyphermox> I don't think partman-auto ever accounted for creating the ESP
<cyphermox> (it's marked $efi IIRC)
<cyphermox> ergo, if it worked in previous releases, I wonder why; or somebody already addresses the recipes and I'm operating from incorrect data
<vorlon> cyphermox: there was a whole thing about this where I was insisting that we always create the ESP on amd64 and that we install both grub-pc and shim-signed
<vorlon> where did that go?
<cyphermox> *shrugs* I don't know. I agree we should try to always create an ESP, but I don't recall who did the work or if it was finished
<cyphermox> I just pulled partman-auto to have a look
<vorlon> cyphermox: https://bugs.launchpad.net/ubuntu/+source/grub-installer/+bug/1803031/comments/5 "system booted in UEFI mode; full disk automatically partitioned; no error prompts shown and system is ootable after install.  system booted with UEFI ut with CSM enabled; idem." You say *you* tested this for bionic
<ubottu> Launchpad bug 1803031 in grub-installer (Ubuntu Disco) "error: cannot find EFI directory." [Undecided,Confirmed]
<cyphermox> when booting in legacy mode, you'll install in legacy mode, and grub-installer shouldn't try to find an EFI directory
<cyphermox> or at least, at the time of that bug, I think it would not
<cyphermox> this would have changed since, now that we try to install both
<cyphermox> vorlon: when I tested this, I did test all the test cases listed and all was working, whether or not you were booting in legacy mode or not
<vorlon> cyphermox: ok, my /intent/ with specifying "install in CSM mode" was that we verify that when legacy booting the install media, you end up with a target system with an ESP that's bootable
<vorlon> sorry if that wasn't clear
<cyphermox> "install in CSM mode" is either installing in UEFI mode, or installing in legacy
<cyphermox> you can't tell that it's "UEFI but booted with CSM", because CSM just does legacy
<cyphermox> but again; I think we're looking at things around the point where plans changed
<cyphermox> ie. we were fixing the missing ESP bug, separately from making the changes to have both bootloader flavors installed on disk
<cyphermox> I mean, otherwise the bug is meaningless; you always want to have an ESP on disk, even in legacy (not UEFI w/ CSM)
<cyphermox> I posit that's true; but this bug wasn't addressing that at all
<cyphermox> jibel: did what you see lead to a crash at install time or not booting? or are we "just" checking for sanity?
<jibel> cyphermox, the system doesn't boot
<jibel> because it boots in uefi mode but there is no esp
<cyphermox> ok; because it's EFI but booted the install media in legacy
<cyphermox> right
<jibel> cyphermox, on this machine, on the boot menu legacy is the first entry when booted in uefi mode
<jibel> the probability is high that a user will boot the iso in legacy mode
<cyphermox> yes
<teward> jbicha: ... have we considered just *disabling* that user from sending to the devel-discuss list until they stop sending the announcements?  Not sure how active that one user is though
<sarnold> Unit193: ^^ xedniv doesn't appear able to address his constant disconnects.. any chance you've got Magic Powers that could help?
<teward> sarnold: i poked -ops btw
<teward> for here and -server and elsewhere
<teward> nobdoy's alive :P
<sarnold> and lo a magician appears :)
<teward> indeed.
<sarnold> I think xedniv is following me around, in at least four of my channels ..
<teward> dax: #ubuntu-server too if you can
<dax> i can't
<sarnold> dax: excellent, thanks :)
<tjaalton> how can one select another component as the 'active' one on a lp bug report? if there's an external project as the active, it's not possible to propose it for an ubuntu series without changing the url and reloading the bug page, right?
<cjwatson> tjaalton: I believe that's the only place in Launchpad that requires URL-hacking for a functional purpose.
<tjaalton> right, ok
<cjwatson> (And yes, it's gross.)
<tjaalton> :)
<infinity> marcustomlinson: Could you have a poke at LP: #1846555 ?
<ubottu> Launchpad bug 1846555 in libreoffice (Ubuntu) "libreoffice-style-hicontrast not installable due to libreoffice-style-sifr relationships" [Undecided,New] https://launchpad.net/bugs/1846555
<marcustomlinson> infinity: hey, sure, thanks for pointing that out! I'll prep an upload tomorrow morning
<infinity> marcustomlinson: Ta.
<cyphermox> vorlon: first step of looking into this ESP issue; partman-efi changes seem to do good; but I notice we'll need a partman-auto change as well, along with the probably grub-installer change you mentioned too.
 * vorlon nods
<Unit193> sarnold: I'd say "better late than never", buut.
<sarnold> Unit193: oh don't let a few bans deter you from a kline if it's still going on :)
<jbicha> teward: I think it's appropriate to ask first (re: devel-discuss)  :)
#ubuntu-devel 2019-10-04
<Ark74> hello guys!
<Ark74> I'm learning how to build and edit packages from source
<Unit193> Careful, before you know it you'll have your very own repo of packages.
<Ark74> I don't quite get, why if I add build dependencies to debian/control, it will ask for install build dependencies when I only want to install the binaries
<Ark74> Unit193, yeah, I'm learning to backport some recent versions
<Ark74> Ok, that reads confusing
<Ark74> When building I add dependencies, once build the binaries in order to install it now also requires to install build dependencies, why?
<Ark74> wheren't they only for build?
<cjwatson> Ark74: In general yes, build-deps are only for build; but sometimes build-depending on something will cause your built packages to gain runtime dependencies too.  You probably need to be more specific about what's going on.
<Ark74> cjwatson, maybe I took a bone too big to start learning, but I'm trying to figure out LibreOffice backport from PPA
<Unit193> That's not likely to be the best first package.
<Ark74> yeah, I now
<Ark74> I have completed a 16 hour build
<cjwatson> Ark74: Well, I'm less thinking about what you're packaging, and more exactly what the specific Build-Depends and Depends at issue are
<Ark74> but I added some dependencies on debian/control > Build-Depends and now, now that I have a local repository it tries to install a whole bunch of dependency packages
<Ark74> unless I add those packages to Build-Depends the build fails
<cjwatson> "it tries to install"   what exact commands did you run that caused "it" (what?) to try to install which specific packages that you weren't expecting?
<Ark74> mostly java packages, libwpd, libwps, libwpg, liborcus
<cjwatson> I think it might be helpful if you put some kind of transcript on paste.ubuntu.com and shared a link
<Ark74> https://paste.ubuntu.com/p/wZXBXBZsnF/
<Ark74> "paquetes NUEVOS" are new packages
<cjwatson> Looks normal enough
<cjwatson> Well, maybe, not sure about the Java pile
<cjwatson> But that transcript does not say what command you ran that resulted in that
<Ark74> that was sudo apt update ; sudo apt dist-upgrade
<Ark74> I already had the ppa
<Ark74> libreoffice ppa
<cjwatson> libwpd, libwps, libwpg, liborcus don't seem like a surprise; note that it's only installing the runtime packages, not the -dev packages
<Ark74> then used aplty to setup a local repo for the packages build
<cjwatson> OK, so what you need to do is look at the Depends fields of the .debs you have and compare them against the ones in the libreoffice PPA
<Ark74> hmmm, you are right
<cjwatson> Narrow down what's actually been added there
<cjwatson> You aren't going to get anywhere fast with an undifferentiated pile of output from apt
<cjwatson> And hopefully you have build logs that you can diff against the ones in the PPA
<cjwatson> Also hopefully you have a diff of the changes you made to the source package
<cjwatson> All those things are vital diagnostic tools when looking into this kind of problem
<Ark74> well, I took the source from the PPA, so I thought there would not be much difference
<cjwatson> You made changes
<Ark74> the only changes I did where the builder failed
<Ark74> adding dependencies
<cjwatson> Regardless, you made changes
<cjwatson> A diff is a way of concisely expressing exactly what those changes were
<Ark74> I have the list
<Ark74> one sec
<cjwatson> You can generate it by running debdiff against the old and new .dsc files
<cjwatson> Also, if you found that "the builder failed" on the packages that had already built cleanly in the libreoffice PPA, then perhaps that's a warning sign that something is wrong with your build setup and maybe hacking around it by adding Build-Depends is incorrect
<Ark74> https://paste.ubuntu.com/p/xrGwzhC5Nh/
<cjwatson> Sorry, not prepared to look at it in that form
<cjwatson> A debdiff is the standard way of representing this kind of thing
<cjwatson> A pile of sed statements is unreadable
<cjwatson> (And judging from that you might very well have edited Depends lines by accident ...)
<Ark74> You might be right
<cjwatson> This is why you need to look at a diff, if nothing else to see if your noninteractive file-editing machinery misfired
<Ark74> thank you, that makes sense
<Ark74> let me play with debdiff, so I can be sure if I screw in the way
<Ark74> cjwatson, seems this will take some time, in case I don't see you around when I'm done, let say thanks! to point out the proper way to tackle this.
<Ark74> *let me say
<cjwatson> No problem, good luck
<Ark74> I'll be around, thanks!
<LocutusOfBorg> is only me or the bugs pages are showing badly?
<LocutusOfBorg> https://bugs.launchpad.net/ubuntu/+source/dkms/+bug/1838921
<ubottu> Launchpad bug 1838921 in OEM Priority Project "ability to install dkms without version checking and retire it when kernel fixed issue" [High,New]
<tjaalton> slow alright
<tjaalton> or just bad
<cjwatson> LocutusOfBorg: we're fixing
<cjwatson> slight fallout from migration to git
<LocutusOfBorg> thanks!
<ahasenack> good morning
<infinity> marcustomlinson: What's the effect of the last hunk of change (to debian/rules) in your libreoffice upload?
<infinity> marcustomlinson: http://launchpadlibrarian.net/445268811/libreoffice_1%3A6.3.2-0ubuntu1_1%3A6.3.2-0ubuntu2.diff.gz
<infinity> marcustomlinson: The USE_GIT_TARBALLS bit, which isn't mentioned in the changelog.
<marcustomlinson> infinity: no affect on anything runtime, that flag is used during build-time to grab origs
<marcustomlinson> infinity: it's supposed to be build as N for every release
<marcustomlinson> infinity: must have miss it last release
<infinity> marcustomlinson: Okay, so only has effect when constructing a new upstream?
<marcustomlinson> infinity: yes
<infinity> Check.
#ubuntu-devel 2019-10-05
<ali1234> rafaeldtinoco: i started rewriting abe in python to learn how it works. it does some things that i find unusual. you wouldn't happen to know anything about that would you?
